Cisco 300-415: Túneis de Plano de Dados, BFD e Roteamento Ciente de Aplicação — 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

O Cisco SD-WAN separa o plano de controle do plano de dados e constrói um overlay criptografado e orientado por políticas sobre diferentes tipos de transporte. O controlador vSmart gerencia o plano de controle do overlay e a conectividade dos WAN Edges, distribuindo rotas, chaves de segurança e intenção via OMP. Os roteadores WAN Edge formam túneis de plano de dados IPsec seguros para outros WAN Edges, enquanto as conexões de controle com o vSmart, vBond e vManage usam DTLS por padrão (ou TLS). A atividade e a qualidade do caminho são continuamente medidas com BFD, que alimenta as políticas de Roteamento Ciente de Aplicação (AAR) para direcionar as aplicações pelos túneis de melhor desempenho, de acordo com as classes de SLA baseadas em perda, latência, jitter ou MOS.

Fundamentos do Overlay e do Plano de Dados

• Plano de controle versus plano de dados

  • Plano de controle: Os WAN Edges estabelecem conexões de controle DTLS/TLS seguras com o vBond (para travessia de NAT e orquestração), vSmart (troca de políticas e rotas via OMP) e vManage (gerenciamento, configuração de dispositivos e armazenamento de certificados). No estado de staging, os dispositivos formam conexões de controle, mas não estabelecem túneis de dados.
  • Plano de dados: Os WAN Edges formam túneis IPsec diretamente para outros WAN Edges para o tráfego de usuário. O plano de dados é responsável pelo encaminhamento e aplica as decisões de engenharia de tráfego comunicadas pela política do plano de controle.

• Túneis de plano de dados IPsec e TLOCs

  • Um Localizador de Transporte (TLOC) identifica unicamente uma conexão de transporte WAN e é definido pela tupla {system-IP, color, encapsulation}. O encapsulamento é IPsec ou GRE; na maioria das implantações e no IOS XE SD-WAN (cEdge), o IPsec é usado.
  • As cores (colors) são rótulos semânticos para tipos de underlay e propriedades de NAT (por exemplo, mpls, biz-internet, public-internet, lte, private1–private6). Cores públicas geralmente implicam travessia de NAT com a assistência do vBond.
  • Os túneis são formados entre cada par de TLOCs alcançáveis, a menos que sejam restringidos. Com dois sites, cada um com um WAN Edge e dois TLOCs públicos, e sem atributos restrict, quatro túneis IPsec são formados (full mesh entre os pares de cores).
  • A extensão de TLOC (TLOC extension) permite que dois WAN Edges redundantes em um site compartilhem transportes através de um cross-link, habilitando a redundância de transporte sem duplicar circuitos físicos por chassi.

• Rótulos de transporte e de serviço

  • O vSmart usa o OMP para anunciar rotas e TLOCs e para alocar rótulos transportados no cabeçalho do overlay. Os rótulos de transporte identificam TLOCs remotos para demultiplexar o tráfego através do overlay. Os rótulos de serviço identificam a VPN de serviço de destino ou um serviço encadeado. Esses rótulos são internos ao overlay SD-WAN e não são rótulos do underlay MPLS.

• Compromissos operacionais e modos de falha

  • Transportes com cores incorretas (por exemplo, marcar MPLS como public-internet) podem causar formação de túneis subótima ou falhas na travessia de NAT.
  • O atributo restrict impede o crescimento indesejado do full-mesh; omiti-lo em cores de internet pode levar a uma escala excessiva de túneis e a uma sobrecarga desnecessária de sondagem.
  • Problemas de certificado ou de relógio impedem a conectividade do plano de controle (DTLS/TLS). Sem a convergência do plano de controle com o vSmart, nenhuma chave do plano de dados é trocada e os túneis IPsec não são formados.

Medição de Atividade e Qualidade do Caminho com BFD

• Operação do BFD

  • O Cisco SD-WAN executa o BFD em cada túnel de plano de dados para fornecer detecção de atividade quase em tempo real e medição de qualidade. O BFD usa hellos periódicos e leves para detectar o estado up/down (blackouts) e sondas ativas para medir latência, jitter e perda (brownouts).
  • Temporizadores e intervalos principais
    • Intervalo de Hello: comumente 1000 ms (configurável por cor ou globalmente).
    • Multiplicador: comumente 6 (configurável), resultando em um tempo de detecção de intervalo-de-hello × multiplicador (por exemplo, ~6 segundos).
    • Intervalo de App-probe para amostragem de desempenho do AAR: tipicamente 1 segundo (configurável), com médias móveis calculadas sobre uma janela curta para suavizar picos transitórios.
  • Métricas do BFD
    • Latência: tempo de ida e volta (round-trip time) das sondas em cada túnel.
    • Jitter: variação na latência entre as sondas.
    • Perda: percentual de sondas não retornadas.
    • MOS: derivado da latência, jitter e perda para adequação para voz.

• Tratamento de brownout versus blackout

  • Blackout: Uma sessão BFD down (sem conectividade) aciona a remoção imediata do caminho do encaminhamento. O tráfego é deslocado de acordo com a preferência do próximo túnel disponível, sem esperar pela avaliação do AAR.
  • Brownout: O BFD permanece up, mas as métricas medidas violam os limites de SLA. O AAR pode direcionar fluxos de aplicações específicas para túneis alternativos que atendam aos SLAs, mesmo enquanto o túnel original continua a transportar outro tráfego.

• Orientações de design e compromissos

  • Temporizadores agressivos aceleram o failover, mas aumentam a sobrecarga de CPU e de largura de banda, especialmente em malhas grandes. Equilibre os intervalos de hello e de sonda em relação à escala e à estabilidade do transporte.
  • Características de caminho assimétricas (por exemplo, satélite ou celular) exigem limites de SLA mais relaxados e multiplicadores potencialmente mais altos para evitar flapping.
  • Para voz e aplicações interativas, prefira intervalos de app-probe mais rápidos e habilite histerese/hold-down para reduzir a oscilação durante congestionamentos transitórios.

Roteamento Ciente de Aplicação (AAR): Design de Políticas e SLA

• Identificação e classificação de aplicações

  • Os WAN Edges usam DPI (NBAR2 no IOS XE SD-WAN) para classificar aplicações por assinaturas, heurísticas de protocolo e, quando disponível, metadados como TLS SNI e QUIC ALPN. Para tráfego criptografado sem metadados identificáveis, o motor recorre a atributos de fluxo (5-tupla) e mapeamentos configurados (portas, DSCP).
  • A classificação geralmente ocorre nos primeiros pacotes e é armazenada em cache para consistência da sessão. Mantenha as assinaturas atualizadas para manter a precisão.

• Classes de SLA e política de medição

  • Defina classes de SLA com limiares para perda, latência, jitter e, opcionalmente, MOS. Cada classe de SLA referencia um perfil de sonda de desempenho (app-probe) que controla o intervalo de amostragem e o comportamento de suavização do BFD.
  • Exemplos típicos de SLA:
    • Voz: latência ≤ 150 ms, jitter ≤ 30 ms, perda ≤ 1%, MOS ≥ 4.0.
    • Transacional: latência ≤ 200 ms, perda ≤ 1%.
    • Bulk: sem SLA rigoroso; prefira caminhos de maior largura de banda e menor custo.

• Comportamento de preferência de caminho

  • A política de AAR vincula listas de aplicações a classes de SLA e especifica uma cor preferencial (preferred-color) e uma cor de backup (backup-color) (ou listas de TLOC). A lógica de decisão:
    1. Se o caminho preferencial atender ao SLA, envie o tráfego pelo preferencial.
    2. Se o preferencial violar o SLA, mas o de backup o atender, direcione para o backup.
    3. Se nenhum caminho atender ao SLA, use o melhor caminho disponível por preferência ou custo (degradação suave).
  • O direcionamento em brownout é por fluxo; fluxos existentes podem ser movidos dependendo da política (o direcionamento de novos fluxos é o padrão; a movimentação no meio do fluxo pode ser restringida para TCP, a menos que a resiliência da sessão seja projetada).

• Elementos de construção de política

  • Crie listas de aplicações (grupos de DPI), classes de SLA (perda/latência/jitter/MOS) e listas de TLOC (cores) no vManage. Em seguida, crie uma sequência de política de AAR mapeando lista de apps → classe de SLA → cores preferenciais/de backup.
  • Combine com políticas de dados de tráfego se precisar definir DSCP, impor zonas ou inserir encadeamento de serviços (service chaining) antes das decisões de AAR.
  • Use a control-policy separadamente para influenciar a aceitação/anúncio de rotas; não confunda AAR (data-policy) com control-policy. Listas de sites definem o escopo onde o AAR se aplica.

• Trade-offs de design

  • SLAs excessivamente rigorosos podem causar oscilação. Introduza histerese ou temporizadores de penalidade para evitar mudanças frequentes de caminho.
  • Considere o custo: posicione caminhos celulares medidos apenas como backups de último recurso; habilite limites de dados onde disponível.
  • Coordene com QoS: o AAR escolhe o caminho; o QoS por caminho e o enfileiramento ainda devem proteger as classes críticas durante o congestionamento.

Verificação e Solução de Problemas

• Verificações rápidas de integridade

  • Plano de controle:
    • cEdge: show sdwan control connections
    • vEdge: show control connections
  • Túneis do plano de dados:
    • cEdge: show sdwan tunnels
    • vEdge: show ipsec outbound-connections / show ipsec inbound-connections
  • Sessões e qualidade do BFD:
    • cEdge: show sdwan bfd sessions; show sdwan app-route stats
    • vEdge: show bfd sessions; show app-route stats

• Exemplos de trechos de comando

  show sdwan tunnels
  show sdwan bfd sessions
  show sdwan app-route stats sla-class <name>
  show sdwan app-route statistics flows
  show sdwan omp tlocs

  show control connections
  show omp routes | include <prefix>
  show ipsec sa detail

• O que procurar

  • O estado do túnel é “up”, mas a perda/latência/jitter do BFD excede o SLA: brownout — espere o direcionamento do AAR. Valide se o caminho de backup atende ao SLA e se a política vincula a lista de aplicativos correta.
  • Sessão BFD oscilando (flapping): reduza a agressividade ou investigue quedas/enfileiramento no underlay; verifique o MTU e a fragmentação (manuseio do DF-bit) para evitar a perda de probes.
  • Nenhum túnel formado sobre uma “color”: verifique a semântica de NAT/público/privado da “color”, a configuração de NAT da interface e se o vBond está acessível para a travessia de NAT. Confirme a hora e os certificados se as conexões de controle estiverem ausentes.
  • Escala inesperada de full-mesh e probes: aplique “restrict” nas “colors” de internet ou use listas de TLOC para delimitar a conectividade.
  • Classificação incorreta do DPI: atualize as assinaturas do NBAR2 e confirme que não há sobreposições conflitantes de porta L4. Para aplicativos criptografados, considere a classificação baseada em SNI/ALPN ou a marcação DSCP upstream.

• Raciocínio operacional

  • Sempre valide a conectividade do plano de controle primeiro (vBond para orquestração/NAT, vSmart para OMP/política, vManage para configuração/certificados). Sem o vSmart, as chaves do plano de dados não são distribuídas e nenhuma SA IPsec é formada.
  • Correlacione as decisões do AAR com as medições do BFD e as classes de SLA. Se um caminho for selecionado contrariamente à expectativa, inspecione o status de conformidade com o SLA no momento da decisão, não apenas as médias atuais.
  • Para projetos com dois DCs, evite rotas LAN duplicadas harmonizando o AS do overlay nos WAN Edges do DC ao redistribuir OMP↔BGP através de uma interconexão de DC.

Cenário de Problema Prático

A Contoso Health opera 300 clínicas com transportes duplos em cada local: MPLS (color mpls) e banda larga (color biz-internet). Os usuários relatam qualidade de voz ruim de forma intermitente, enquanto os aplicativos de dados funcionam bem. O objetivo é preferir MPLS para voz, fazer failover para a banda larga durante brownouts e garantir um failover rápido em caso de blackout, sem oscilação.

1. Validar a integridade do overlay e a formação do plano de dados

• Justificativa: Confirmar os pré-requisitos. Use show sdwan control connections para garantir que a conexão DTLS/TLS com vSmart/vBond/vManage está estável e show sdwan tunnels para verificar a malha completa de túneis MPLS e de banda larga. Se os túneis sobre a “color” biz-internet estiverem faltando, verifique a atribuição da “color” e o NAT; o vBond deve estar acessível no espaço público para auxiliar na travessia de NAT.

2. Calibrar os temporizadores do BFD e dos probes

• Justificativa: Defina o “hello” do BFD para 1000 ms e o multiplicador para 6 para uma detecção de atividade (“liveness”) balanceada (~6 s) e uma escala razoável. Configure o intervalo do “app-probe” para 1 s para uma detecção oportuna de brownout. Temporizadores excessivamente agressivos podem causar sobrecarga de CPU e oscilação (“flapping”); muito relaxados, impedem a capacidade de resposta para voz.

3. Definir classes de SLA

• Justificativa: Crie uma classe de SLA Voice-SLA com latência ≤ 150 ms, jitter ≤ 30 ms, perda ≤ 1% e MOS ≥ 4.0. Crie uma Data-SLA com latência ≤ 200 ms e perda ≤ 1%. Esses limiares refletem a sensibilidade da voz e o desempenho típico da WAN; o MOS consolida a experiência do usuário em várias métricas.

4. Construir listas de aplicativos

• Justificativa: Use o DPI (NBAR2) para definir a App-List-Voice para mídias SIP/RTP/Teams/Zoom e a App-List-Data para aplicativos transacionais. Inclua padrões TLS SNI/QUIC ALPN para plataformas modernas de voz/vídeo. Onde a classificação for incerta, recorra às marcações DSCP EF/AF41 aplicadas na borda da LAN.

5. Construir a política de AAR

• Justificativa: Mapeie a App-List-Voice para a Voice-SLA com preferred-color mpls e backup-color biz-internet. Mapeie a App-List-Data para a Data-SLA com preferred-color biz-internet e backup-color mpls para preservar a largura de banda do MPLS. Isso garante que a voz use o MPLS quando estiver íntegro e mude para a banda larga apenas durante brownouts ou blackouts, enquanto os dados preferem a internet, que tem um custo mais eficaz.

6. Adicionar histerese e hold-down

• Justificativa: Configure um temporizador de reversão (“revert timer”) para que a voz retorne ao MPLS somente após conformidade sustentada com o SLA (por exemplo, 30–60 s). Isso evita a oscilação durante picos transitórios de jitter. Da mesma forma, aplique uma penalidade ou amortecimento (“dampening”) na banda larga se ela violar repetidamente o SLA dentro de uma janela de tempo curta.

7. Coordenar QoS e MTU

• Justificativa: Em ambos os transportes, garanta que o enfileiramento EF e o “shaping” estejam alinhados com as taxas do circuito. Uma incompatibilidade pode inflar o jitter/perda vistos pelos probes do BFD e pelo RTP de voz. Valide o MTU do caminho e desative o DF-bit onde a fragmentação for inevitável, evitando quedas de probes que se mascaram como perda.

8. Verificar e iterar

• Justificativa: Use show sdwan app-route stats sla-class Voice-SLA para confirmar a aprovação/reprovação do SLA por túnel. Observe os fluxos ao vivo com show sdwan app-route statistics flows para garantir que a voz seja direcionada para o MPLS e mude para a banda larga apenas quando o MPLS violar o SLA. Durante os testes, congestione intencionalmente o MPLS para validar o comportamento de brownout e, em seguida, meça o tempo de reversão.

Seguindo esses passos, a Contoso Health garante que o BFD forneça detecção rápida de blackout, que o AAR reaja a brownouts usando classes de SLA precisas e que o DPI classifique com exatidão os aplicativos de voz. A combinação resulta em qualidade de voz previsível, uso eficiente dos transportes e comportamento de failover controlável em toda a malha SD-WAN.

← Configuração de WAN Edge e Gerenciamento de Templates · Todos os domínios · Política Centralizada e Engenharia de Tráfego →

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