Cisco 300-415: Operações, Monitoramento e Solução de Problemas — Guia de estudos

By Laurynas Brazys · 13 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

Faz parte do Cisco SD-WAN 300-415 ENSDWI — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

As operações, o monitoramento e a solução de problemas no Cisco SD-WAN se concentram no Cisco SD-WAN Manager (anteriormente vManage), na camada de controladores (orquestrador vBond e controladores vSmart), nos roteadores WAN Edge (por exemplo, séries ISR 4000 e ASR 1000 executando IOS XE SD-WAN) e nas sobreposições (overlays) de dados e controle que eles formam. O plano de controle, gerenciado pelo vSmart, constrói e mantém a topologia e as políticas via OMP e distribui chaves de criptografia entre os edges. Os dispositivos WAN Edge formam conexões de controle DTLS por padrão (ou TLS, se exigido), coordenam a conectividade inicial através do vBond (que deve ser acessível no espaço de IP público para a travessia de NAT) e estabelecem túneis de plano de dados IPsec. Uma higiene operacional robusta utiliza telemetria rica, runbooks fixos, controle de alterações e APIs automatizadas para manter a garantia de SLA e reduzir o tempo médio de reparo (MTTR).

Monitoramento, Dashboards e Saúde

• Dashboards: O Cisco SD-WAN Manager fornece visualizações em tempo real e históricas da saúde dos sites, status dos dispositivos, conexões de controle, SLA de túneis, experiência de aplicação e conformidade de políticas. Os widgets padrão destacam as conexões de controle (alcançabilidade de vBond/vSmart/vManage), a adesão ao SLA do roteamento sensível à aplicação (app-aware routing) e a utilização de interfaces. As visualizações detalhadas (drill-downs) correlacionam alarmes, eventos e estatísticas por dispositivo ou site.
• Alarmes e eventos: A plataforma gera alarmes sobre alterações na alcançabilidade do controlador, estado da sessão OMP, falhas de certificado, reinicializações de dispositivos, divergências de política e degradação de desempenho (perda/latência/jitter acima do SLA). Os eventos incluem códigos detalhados, como DCONFAIL para falhas de conexão de controle e divergências explícitas de nome da organização (organization-name) durante o onboarding. Os alarmes suportam confirmação (acknowledgment), liberação (clearance) e encaminhamento (email/SNMP/syslog) para sistemas de operações centrais.
• Saúde do dispositivo: As pontuações de saúde (health scores) combinam indicadores do plano de controle e de dados com CPU, memória, logs de falhas (crash logs) e erros de interface. A saúde do WAN Edge deve ter uma linha de base (baseline) estabelecida; os limites (thresholds) devem ser ajustados para evitar a fadiga de alarmes. A sincronização de tempo (NTP) é crítica; o desvio de relógio (clock skew) é uma causa raiz comum de falhas na validação de certificados e de dados de tendência enganosos.
• vAnalytics e planejamento de capacidade: O vAnalytics adiciona visibilidade profunda de aplicações (classificação baseada em NBAR2 a partir do cflowd), linhas de base de qualidade de caminho e previsões de capacidade. Ele destaca os principais consumidores de banda (top talkers), as contribuições para o tempo de resposta da aplicação (rede versus servidor) e as janelas projetadas de saturação de interface. Para o planejamento de capacidade, use o throughput do 95º percentil em janelas contínuas de 30 dias e correlacione com violações de SLA de túnel; avalie onde largura de banda adicional ou ajustes de política (QoS/AAR) produzem o melhor retorno de SLA.
• Experiência de aplicação: Os dashboards de aplicação vinculam os fluxos ao desempenho do túnel e ao tratamento de QoS. Se uma aplicação crítica apresentar baixo desempenho em um caminho com jitter crescente, confirme se o roteamento sensível à aplicação (app-aware routing) está honrando o SLA e se as políticas de enfileiramento (queueing) estão alinhadas com as marcações DSCP de ponta a ponta.

Telemetria, Syslog, SNMP e Exportação de cflowd

• Telemetria por streaming: O Cisco SD-WAN Manager consome telemetria orientada a modelo (model-driven telemetry) dos controladores e edges para métricas de controle, interface e plataforma. O streaming reduz a sobrecarga de consultas (poll overhead) e aumenta a granularidade em comparação com o polling SNMP legado. Para análise externa, o IOS XE SD-WAN suporta telemetria orientada a modelo do tipo dial-out para coletores gRPC; dimensione cuidadosamente os coletores e as taxas de amostragem para evitar sobrecarga nas filiais (branches).
• Syslog: Edges e controladores podem exportar syslog para coletores centralizados. Encaminhe eventos significativos (por exemplo, reconvergência de controle, atualizações de política OMP, renovação de chaves IPsec, falhas). Use syslog estruturado para uma melhor análise (parsing). Limite a taxa (rate-limit) e filtre para manter o desempenho dos coletores.
• SNMP: Use SNMPv3 para consultas (polling) seguras de interfaces, CPU, memória e sensores de ambiente. Traps SNMP podem ser habilitados para alarmes importantes (controle inativo, BFD inativo, CPU alta). O SNMP por si só é insuficiente para a telemetria de aplicações modernas, mas continua valioso para a integração com ferramentas NMS existentes.
• cflowd (exportação de fluxo sensível à aplicação): O Cisco SD-WAN usa cflowd (semelhante a NetFlow/IPFIX) para exportar registros por fluxo, incluindo ID da aplicação (NBAR2), DSCP, bytes/pacotes, flags TCP e metadados de desempenho, como tempo de ida e volta (round-trip time), perda e jitter. A exportação pode ser direcionada para o Cisco SD-WAN Manager/vAnalytics e para coletores externos. Equilibre a visibilidade e a sobrecarga ajustando a amostragem, os timeouts de fluxos ativos/inativos e os destinos de exportação. A exportação excessiva em plataformas de baixo custo pode impactar a CPU; prefira a análise no lado do controlador quando viável.

Solução de Problemas de Controle, OMP, BFD e Túneis

Um fluxo de trabalho consistente restringe o domínio de falha rapidamente:

1. Estabeleça o escopo e a camada

• É apenas no plano de controle, no plano de dados ou na camada de aplicação?
• Use os painéis de sites e dispositivos do SD-WAN Manager para ver se vários dispositivos, sites ou apenas um caminho/cor (color) são afetados.

2. Valide as conexões de controle

• O vBond deve estar acessível em seu IP público; por padrão, os controladores usam a porta 12346 para DTLS/TLS.
• O transporte de controle padrão é DTLS; muitas políticas de data center exigem TLS para os controladores. Garanta que os middleboxes permitam o protocolo selecionado.
• Verifique a sincronização de tempo e os certificados (cadeia raiz, validade, acessibilidade de CRL/OCSP).
• Erros comuns:
  • DCONFAIL: Falha genérica de conexão de controle; as causas raiz incluem o bloqueio da porta 12346, falha na travessia de NAT, rejeição de certificado ou roteamento para os controladores.
  • Incompatibilidade de organização: O org-name incorporado nas credenciais/configuração do dispositivo deve corresponder ao dos controladores; caso contrário, as sessões OMP não serão formadas.

3. Verifique o OMP e a política

• O OMP transporta rotas, TLOCs e service-chains entre o vSmart e os roteadores de borda (edges). Confirme a adjacência OMP com todos os nós vSmart no cluster para evitar um estado de controle assimétrico.
• Valide as rotas recebidas/anunciadas e a aceitação da política. A política pode filtrar TLOCs ou prefixos inadvertidamente, causando blackhole no tráfego.
• Os TLOCs são definidos pelo system IP, cor (color) e encapsulamento (GRE ou IPsec). Incompatibilidades de cor ou encapsulamento entre pares impedem a formação do túnel em um determinado transporte.

4. Inspecione o BFD e o SLA

• O BFD monitora perda, latência e jitter por túnel e alimenta o roteamento ciente da aplicação (app-aware routing). Oscilações (flapping) ou jitter alto acionam o direcionamento (steering). Confirme se os temporizadores do BFD/classes de SLA correspondem à intenção do projeto. Temporizadores excessivamente agressivos em circuitos de baixa qualidade levam a failovers desnecessários.

5. Verifique o IPsec/plano de dados

• Inspecione as estatísticas do túnel, SAs do IPsec, encaps/decaps, replay-drops e PMTU. Problemas de NAT-T e black holes de PMTU são comuns, especialmente em banda larga.
• Valide se o QoS shaping está alinhado com a largura de banda contratada; o excesso de subscrição (oversubscription) infla as leituras de perda/jitter e engana o AAR.

Comandos show úteis em roteadores de borda (edges) IOS XE SD-WAN:

show sdwan control connections
show sdwan omp peers | routes | tlocs
show sdwan bfd sessions
show sdwan ipsec inbound-connections outbound-connections
show platform hardware qfp active datapath utilization
show interfaces counters errors
show clock detail

Trade-offs e modos de falha:

• TLS vs DTLS: O TLS pode ser exigido pela política de segurança e atravessar proxies rígidos com mais eficiência; o DTLS oferece menor sobrecarga (overhead) no handshake. Escolha de forma consistente em toda a malha (fabric).
• Sensibilidade do BFD: Temporizadores curtos melhoram o tempo de reação, mas aumentam o uso de CPU e os falsos positivos em links com ruído.
• Complexidade da política: Políticas centralizadas ricas podem se desviar da intenção original; prefira objetos de política hierárquicos e bem comentados e simule antes de implantar.

Gerenciamento do Ciclo de Vida, Conformidade e Automação

• Planejamento de atualização de software:

  • Sequência: Atualize o cluster do SD-WAN Manager, depois o vBond, depois o vSmart e, por fim, os WAN Edges. Mantenha a compatibilidade de versão conforme as notas de lançamento (release notes). Os controladores devem estar saudáveis e sincronizados antes de mexer nos edges.
  • Repositórios de imagens: Use o repositório de software do SD-WAN Manager para preparar as imagens. As imagens dos controladores comumente usam os formatos .qcow2 ou .ova; os edges usam pacotes IOS XE SD-WAN específicos da plataforma.
  • Modo de manutenção: Coloque o WAN Edge em modo de manutenção para drenar o tráfego de forma controlada. O dispositivo retira as rotas TLOCs/OMP para que as sessões migrem para caminhos/sites alternativos antes da reinicialização, minimizando o impacto para o usuário.
  • Rollback: Mantenha uma imagem anterior comprovadamente funcional preparada. Se as verificações posteriores falharem, faça o rollback para a última versão funcional conhecida. O IOS XE SD-WAN suporta instalações em banco duplo (dual-bank) e downgrade orientado pelo controlador.
  • Agendamento: Use janelas de mudança com verificações prévias (status de controle/OMP/BFD, CPU/memória) e verificações posteriores (SLA de aplicação, contagem de túneis, taxas de erro).

• Conformidade e desvio de configuração:

  • O estado desejado é definido pelos templates de dispositivo. O SD-WAN Manager destaca o desvio (drift) entre a configuração em execução e o template; corrija com fluxos de trabalho de “reattach” ou de aceitação de desvio quando justificado (por exemplo, uma correção de emergência via CLI).
  • Trilhas de auditoria registram quem mudou o quê e quando (com escopo de RBAC). Integre com um SIEM externo via syslog/webhooks para um histórico imutável.
  • Conjuntos de regras de conformidade: Valide se o org-name, o esquema de IP do sistema, o uso de cores, as cifras IPsec, AAA e NTP estão em conformidade com os padrões.

• Operações e relatórios orientados por API:

  • As APIs REST /dataservice expõem endpoints de monitoramento, configuração e ação. Automatize a geração de relatórios (tendências de SLA, principais aplicações), atualizações em massa, onboarding de sites e verificações de conformidade.
  • Use tokens e contas com escopo de RBAC. Implemente fluxos de trabalho idempotentes e validações prévias (pre-flight) antes de aplicar mudanças em escala.

• Triagem de desempenho:

  • Comece com o SLA do túnel (perda, latência, jitter), depois CPU/memória do dispositivo, e então quedas/erros de interface e profundidade das filas (queue-depths). Correlacione com os KPIs de aplicação do cflowd.
  • Identifique se a degradação é por qualidade do link, congestionamento/QoS ou do lado do servidor, comparando a experiência de múltiplos sites para a mesma aplicação e caminho.
  • Sinais de capacidade: Utilização crescente no percentil 95, quedas de pacotes (queue drops) em classes de prioridade e trocas frequentes de caminho pelo AAR indicam a necessidade de mudanças na política ou na largura de banda.

• Resposta a incidentes, controle de mudanças e RCA:

  • Runbooks definem as ações de primeira resposta: capturar os estados de controle/OMP/BFD, coletar logs relevantes/pacotes de suporte técnico (tech-support bundles) e congelar mudanças não essenciais.
  • O controle de mudanças impõe a revisão por pares (peer review) para atualizações de política e implementações em fases com canaries.
  • A análise de causa raiz (RCA) combina eventos do controlador (quem/quando), telemetria de fluxo (qual tráfego) e métricas de caminho (onde degradado) para isolar o problema. Exemplos: ORG mismatch após uma mudança de onboarding, um filtro de política não intencional removendo um TLOC, um black hole de PMTU na banda larga após uma mudança no CPE do provedor.

Cenário de Problema Prático

A Contoso Health opera 150 clínicas conectadas via SD-WAN de transporte duplo (MPLS cor mpls e banda larga cor biz-internet) usando WAN Edges ISR 4000. Após uma janela de manutenção para migrar os controladores para um novo data center, vários sites relatam baixo desempenho do sistema de prontuário eletrônico (EHR) e interrupções intermitentes.

1. Verificar a saúde do plano de controle no SD-WAN Manager

• Justificativa: Se o controle estiver instável, todos os sintomas subsequentes no plano de dados e de políticas se manifestarão. O painel mostra múltiplos eventos DCONFAIL e ORG mismatch durante a mesma janela, indicando inconsistências de onboarding após a mudança dos controladores.

2. Validar a alcançabilidade e as portas dos controladores

• Justificativa: O novo data center impõe o uso de TLS para os controladores. Confirme se os middleboxes permitem TLS para os controladores na porta de controle padrão 12346 e se o vBond está alcançável em IP público para a travessia de NAT. Uma porta bloqueada em um firewall regional explica as falhas de sites agrupados.

3. Corrigir a divergência de organization-name

• Justificativa: Edges que falham na autenticação mútua com os controladores devido à divergência de org-name não conseguem formar OMP. Compare o org-name do template do dispositivo com os certificados do controlador; atualize os templates para corresponderem e aplique-os novamente (reattach). Isso restaura a adjacência OMP com o vSmart para os sites afetados.

4. Reconciliar o tempo e os certificados

• Justificativa: A mudança do DC alterou a alcançabilidade do NTP. Relógios dessincronizados fizeram com que algumas validações de certificado falhassem. Aponte todos os edges e controladores para um NTP redundante e verifique a convergência dos relógios para estabilizar a autenticação e as sessões de controle.

5. Verificar rotas OMP, TLOCs e aceitação de políticas

• Justificativa: A migração do controlador incluiu uma refatoração de política. Use os comandos show sdwan omp routes/tlocs e a visualização de políticas para confirmar que os prefixos críticos e todos os TLOCs são aprendidos e não filtrados. Uma política de dados (data-policy) com ordem incorreta estava descartando o tráfego do servidor de EHR; reordene e aplique (commit) para restaurar a alcançabilidade.

6. Avaliar o comportamento de BFD/SLA e AAR

• Justificativa: A lentidão do EHR pode refletir a qualidade do caminho. O BFD mostra um aumento de jitter na banda larga; o AAR está alternando (flapping) entre os caminhos. Aumente a histerese na classe de SLA e garanta que o QoS priorize os fluxos de EHR com base no DSCP. Isso reduz as trocas desnecessárias de caminho.

7. Realizar atualização de software direcionada com modo de manutenção

• Justificativa: Um bug conhecido na versão atual do IOS XE SD-WAN reporta intermitentemente o jitter de forma incorreta na conexão biz-internet. Prepare a correção recomendada no repositório de software. Coloque um subconjunto de edges em modo de manutenção, atualize, valide as verificações posteriores e, em seguida, implemente de forma ampla. Mantenha a imagem de rollback preparada.

8. Automatizar a verificação e os relatórios via API

• Justificativa: Use as APIs /dataservice para exportar relatórios de adesão ao SLA pós-incidente, desempenho de aplicações e estabilidade do controle em todas as clínicas. A automação garante uma verificação consistente e gera um registro auditável para o controle de mudanças.

9. Documentar a RCA e reforçar os controles

• Justificativa: As causas raiz foram a omissão de uma regra de firewall na porta de controle 12346, o desvio (drift) do org-name nos templates e a má configuração do NTP, agravados por um problema na ordem da política. Atualize os runbooks de onboarding, imponha validação pré-mudança baseada em API (alcançabilidade do controlador, verificações de org-name, status do NTP) e exija simulações de política antes de aplicar (commit) para evitar recorrência.

← Integração com Nuvem · Todos os domínios

Pratique estas questões → · Prática cronometrada no ExamRoll.io →