Cisco 300-415: Política Centralizada e Engenharia de Tráfego — 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

A política centralizada na Cisco SD-WAN é a estrutura que permite programar o comportamento do tráfego e a intenção de roteamento a partir dos controladores vSmart em toda a malha (fabric). O vSmart, que gerencia o plano de controle de sobreposição (overlay) via OMP, distribui políticas de controle centralizadas (para rotas OMP e TLOCs) e políticas de plano de dados, como dados, roteamento ciente de aplicação (app-route) e cflowd. Essas políticas moldam a topologia (hub-and-spoke, restrição de malha), selecionam caminhos com base no desempenho da aplicação, direcionam fluxos para serviços e segmentam o tráfego por VPN. Como as políticas podem alterar tanto a alcançabilidade do plano de controle quanto o encaminhamento do plano de dados, um projeto cuidadoso, a pré-visualização e a implantação em fases são essenciais para evitar interrupções.

Tipos de Política Centralizada e Componentes Básicos

• Política de controle centralizada

  • Escopo: Plano de controle (OMP) entre os dispositivos WAN Edge e o vSmart.
  • Finalidade: Filtrar/modificar anúncios de rotas OMP e TLOCs, definir atributos (preferência, tag, origem, TLOC) e construir topologias (hub-and-spoke, malha parcial).
  • Direção: De entrada (inbound), para o vSmart a partir do WAN Edge, e de saída (outbound), do vSmart para o WAN Edge.

• Política de dados centralizada

  • Escopo: Classificação do plano de dados (L3/L4, campos, app-ID) no WAN Edge, instalada pelo vSmart.
  • Finalidade: Permitir/negar fluxos, definir VPN, definir TLOC, definir DSCP/marcação, policiar (police), espelhar (mirror) e inserção/encadeamento de serviços.
  • Direção: Avaliada no WAN Edge em relação ao lado do serviço (LAN) ou ao lado do túnel (WAN), dependendo de onde é programada; os projetos geralmente visam a entrada do lado do serviço (service-side ingress) para fluxos de usuário para a WAN e o lado do túnel para o retorno, se for necessário um comportamento simétrico.

• Política de roteamento ciente de aplicação (app-route)

  • Escopo: Seleção de caminho no plano de dados com base na aplicação e no SLA (perda, latência, jitter) medidos pelo BFD.
  • Finalidade: Direcionar o tráfego para TLOCs/cores preferenciais, definir classes de SLA baseadas em sondas (probes), definir fallbacks e realizar engenharia de tráfego dinâmica por aplicação/família.
  • Comportamento principal: Avalia continuamente o desempenho do caminho; pode trocar de caminho quando o SLA se degrada.

• Política cflowd

  • Escopo: Telemetria de fluxo (semelhante a IPFIX/NetFlow) gerada pelos WAN Edges.
  • Finalidade: Habilitar/desabilitar exportadores por VPN, definir taxas de amostragem, modelos e coletores (vManage ou externos).
  • Nota de design: A amostragem deve equilibrar a visibilidade com a sobrecarga (overhead) de CPU/largura de banda; a habilitação por VPN suporta relatórios segmentados.

Listas de políticas são objetos de correspondência (match) reutilizáveis:

• Lista de sites (Site list): IDs de site usados para selecionar onde as políticas são anexadas e para corresponder a sites de origem/destino da rota.
• Lista de VPNs (VPN list): VRFs (VPNs) usadas para segmentar o escopo da política e construir regras por segmento.
• Lista de prefixos (Prefix list): Prefixos IP para corresponder a rotas OMP ou tráfego de dados.
• Lista de prefixos de dados (Data prefix list): Objeto de prefixo especializado para classificação de política de dados.
• Lista de TLOCs (TLOC list): Tuplas de IP do sistema, cor e encapsulamento usadas para corresponder ou definir atributos de TLOC.
• Lista de cores (Color list): Uma ou mais cores de transporte (ex: biz-internet, mpls, public-internet) para direcionamento/afinidade de link.
• Lista de aplicações (Application list): Aplicações/grupos do NBAR2 para classificar o tráfego para políticas de app-route ou de dados.
• Classe de SLA (SLA class): Limiares de latência, perda e jitter vinculados à app-route para direcionamento baseado em desempenho.

Estrutura e avaliação da sequência de políticas:

• As sequências são ordenadas, e a primeira correspondência prevalece (first-match wins). Cada sequência tem:
  • Condições de correspondência (Match): Listas/campos (site/VPN/prefixo/TLOC/cor/app, portas L4, DSCP, protocolo).
  • Ações (Actions): Aceitar/negar (Accept/deny), definir atributos (TLOC, VPN, DSCP, preferência, tag), inserção de serviço, policiar (police), espelhar (mirror).
• Ação padrão (Default action): Aplicada se nenhuma sequência corresponder. Padrões comuns são accept (para controle/dados) para evitar quedas não intencionais; padrões de deny explícitos são usados deliberadamente e exigem validação cuidadosa.
• Direção:
  • A direção da política de controle é no vSmart (OMP de entrada/saída).
  • As políticas de dados e app-route operam no tráfego no WAN Edge; escolha o comportamento do lado do serviço ou do lado do túnel para se adequar ao fluxo que você pretende afetar e garanta a simetria do tráfego de retorno quando serviços stateful estiverem no caminho.

Projeto de Políticas de Plano de Controle e Manipulação de Rotas/TLOCs

A política de controle é a ferramenta autoritativa para moldar a topologia de overlay, pois determina quais rotas OMP e TLOCs um site pode enviar ou receber:

• Manipulação de rotas OMP

  • Use a política de controle de entrada (inbound) para filtrar, marcar (tag) ou definir atributos em rotas aprendidas de um site antes que elas entrem na RIB do overlay no vSmart.
  • Use a política de controle de saída (outbound) para limitar quais rotas são anunciadas para sites específicos (ex: não anunciar prefixos aprendidos de spokes para outros spokes).
  • Ações comuns: definir preferência (influencia o melhor caminho OMP), definir tag (para correspondência subsequente), definir origem, definir restrições de site de origem (site-of-origin).

• Manipulação de TLOC

  • Faça a correspondência com atributos de TLOC (System IP, color, encap) para filtrar ou preferir transportes específicos.
  • As ações incluem alterar os atributos ou preferências de TLOC preferenciais para que os anúncios de rota tendam a uma determinada “color” (ex: preferir MPLS para sub-redes críticas).
  • Trade-off: Uma filtragem de TLOC excessivamente agressiva pode isolar sites se o transporte restante falhar. Prefira o ajuste de atributos em vez de uma negação geral (blanket deny), a menos que você tenha caminhos redundantes.

• Padrões de topologia

  • Hub-and-spoke: A política de controle de saída (outbound) do vSmart para os spokes nega o anúncio de rotas originadas nos spokes para outros spokes; os hubs recebem e anunciam tudo.
  • Restrição de malha (Mesh): Semelhante ao hub-and-spoke, mas permite pares específicos de spoke-para-spoke (ex: malhas regionais) por meio de exceções nas sequências da política.
  • Segmentação: Combine listas de VPN com filtragem de rotas para manter os overlays por VPN isolados; anuncie apenas a rota padrão (default) ou prefixos selecionados para sites com restrições.

Modos de falha e trade-offs:

• Uma política de controle de saída (outbound) mal aplicada com uma negação padrão (deny default) pode remover rotas críticas, isolando sites. Sempre use “accept” como padrão e adicione negações direcionadas, a menos que sua pré-visualização (preview) confirme explicitamente a cobertura.
• Alterar atributos OMP em escala pode desencadear instabilidade de rotas (route churn); escalone a implantação por listas de sites para reduzir o choque no plano de controle.
• A reescrita de atributos de TLOC pode levar a um encaminhamento assimétrico se o caminho reverso não for influenciado de forma equivalente; valide ambas as direções.

Roteamento Ciente de Aplicação (AAR), Inserção de Serviços e Segmentação

O roteamento ciente de aplicação (AAR) e a política de dados, juntos, fornecem engenharia de tráfego de alta granularidade:

• AAR e direcionamento de tráfego

  • As classes de SLA definem perda/latência/jitter aceitáveis; as sondas (probes) BFD por par de TLOCs alimentam as medições em tempo real.
  • A política de app-route faz a correspondência com aplicações ou campos L3/L4 e seleciona listas de “color”/TLOC preferenciais; se o SLA for violado, o failover ocorre conforme a política.
  • Dicas de projeto:
    • Evite limiares de SLA muito rígidos que causam instabilidade (flapping); inclua histerese usando multiplicadores de sonda (probe) e limiares razoáveis.
    • Para aplicações sensíveis à reordenação de pacotes, prefira “mover no próximo novo fluxo” em vez de trocas no meio do fluxo, ou fixe os fluxos usando “consistent hashing” onde houver suporte.
    • Quando tanto a AAR quanto a política de dados definem o TLOC, dê precedência à AAR para a seleção de caminho e use a política de dados para inserção/marcação de serviços; evite ações sobrepostas na mesma classe de tráfego.

• Encadeamento de serviços (service chaining) e inserção de serviços

  • A ação “service” da política de dados insere o tráfego através de serviços on-premise ou em colocation (firewall, IDS/IPS, nós de serviço SD-WAN).
  • Encadeie múltiplos serviços em ordem quando necessário; garanta a inserção simétrica para serviços stateful tanto no caminho de ida quanto no de volta.
  • Trade-offs: Cada salto de serviço (service hop) adiciona latência e potenciais domínios de falha. Implemente verificações de saúde (health checks) e comportamentos de fail-open/closed consistentes com a postura de segurança.

• Segmentação de tráfego

  • As VPNs fornecem segmentação rígida (hard segmentation); a política centralizada se aplica por VPN usando listas de VPN.
  • O roteamento entre VPNs (route leaking) pode ser alcançado com a política de dados usando “set VPN” para fluxos específicos; restrinja estritamente com correspondências de prefixo/aplicação e audite com frequência.
  • Para serviços compartilhados (ex: DNS, identidade), anuncie os prefixos de serviço de uma VPN de serviços para as VPNs consumidoras com a política de controle, em vez de vazamentos amplos no plano de dados (data-plane leaks).

Exemplo de trecho de app-route ilustrando o direcionamento baseado em SLA:

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

Operações: Anexação, Validação e Solução de Problemas

Anexação de políticas via vSmart:

• Defina políticas centralizadas no vManage e anexe-as a listas de sites e listas de VPN. O vSmart compila a política e a distribui para os WAN Edges por meio de sessões OMP seguras com DTLS/TLS na VPN 0.
• Defina o escopo das alterações com cuidado; uma única instância de política pode afetar centenas de sites. Use listas de sites para escalonar as implantações por região ou função.

Simulação, pré-visualização e implantação escalonada de políticas:

• Pré-visualização (Preview): Antes da ativação, use a pré-visualização do vManage para inspecionar a política compilada específica do dispositivo (o que cada WAN Edge receberá). Confirme a lógica de correspondência/ação (match/action), as ações padrão e as direções.
• Simulação: Use a simulação de políticas para testar correspondências de fluxo e ações esperadas (por exemplo, qual TLOC uma determinada aplicação/5-tupla usará). Valide os mapeamentos de classe de SLA e a classificação de aplicações.
• Implantação escalonada (Staged deployment):
  • 1. Anexe a uma lista de sites canário (poucos sites).
  • 2. Monitore os KPIs do plano de controle e do plano de dados (contagens de rotas OMP, BFD, acertos de app-route).
  • 3. Expanda a lista de sites incrementalmente.
• Versionamento e reversão (rollback): Mantenha as versões anteriores da política; se um comportamento inesperado for detectado, desative a nova política ou reverta para a versão anterior prontamente.

Depurando resultados não intencionais e precedência:

• Verificação do plano de controle

  • show omp tlocs, show omp routes: Confirme a presença/ausência de rotas e TLOCs de acordo com a intenção da política.
  • show policy received/installed: Verifique os contadores da política de controle e quais sequências corresponderam.
  • Sintoma: Spokes não conseguem alcançar outros spokes após a implantação → verifique as linhas de negação (deny) da política de controle de saída para os spokes e as ações padrão.

• Verificação do plano de dados e AAR

  • show app-route stats/flows e show bfd sessions: Valide o estado do SLA e as decisões de caminho.
  • show sdwan policy service-path ou equivalente: Confirme os contadores de inserção de serviço e a ordem de encadeamento.
  • show ip route vpn X e traceroute vpn X: Verifique o caminho de encaminhamento real.
  • Sintoma: Mudanças de caminho inesperadas/instabilidade (flapping) → flexibilize o SLA ou ajuste os multiplicadores de sonda (probe); garanta que uma política de dados sobreposta não esteja também definindo o TLOC.

• Precedência e conflitos de políticas

  • As decisões de AAR geralmente têm precedência na seleção de caminho; use a política de dados principalmente para inserção de serviço, marcação e controle de acesso.
  • Critérios de correspondência sobrepostos entre políticas podem criar ambiguidade. Mantenha os domínios de correspondência mutuamente exclusivos ou introduza ordenação e tags para desambiguar.
  • A aceitação padrão (Default accept) pode mascarar sequências ausentes; adicione contadores explícitos de “apenas observação” (por exemplo, mirror/police baixo) ou logs temporários para validar as correspondências antes de aplicar negações (denies).

• Validação do cflowd

  • show cflowd statistics/exporters: Garanta que os exportadores por VPN estejam ativos e amostrando conforme o esperado.
  • CPU alta após habilitar o cflowd → aumente o intervalo de amostragem ou restrinja a VPNs/aplicações essenciais.

Cenário de Problema Prático

A Northwind Traders está migrando para o Cisco SD-WAN e precisa impor um modelo hub-and-spoke para as VPNs de PCI, direcionar o Office 365 para o melhor caminho de Internet e inserir um serviço de firewall regional para o tráfego de convidados (guest) sem impactar as aplicações críticas.

Abordagem:

1. Construir listas de políticas

   • Crie listas de sites: HUBS (data centers), SPOKES (filiais).
   • Crie listas de VPN: PCI_VPN, GUEST_VPN, CORP_VPN.
   • Crie listas de aplicações: O365, BEST_EFFORT.
   • Crie listas de cores: PRIVATE (mpls), DIA (biz-internet, public-internet). Justificativa: Listas reutilizáveis permitem um escopo preciso e uma implantação escalonada segura; a separação de VPNs suporta a segmentação.

2. Definir classes de SLA

   • GOLD: perda de 0,5%, latência de 100 ms, jitter de 20 ms.
   • SILVER: perda de 1%, latência de 150 ms, jitter de 30 ms. Justificativa: Alinhe os limites (thresholds) ao desempenho realista do transporte para evitar instabilidade de caminho (path flapping); mais rigoroso para O365 do que para best-effort.

3. Implementar política de controle para hub-and-spoke de PCI

   • Entrada (Inbound) para o vSmart: marque com tag as rotas aprendidas dos SPOKES na PCI_VPN.
   • Saída (Outbound) do vSmart: para os SPOKES, anuncie as rotas do HUB e as rotas padrão; negue o anúncio de rotas de PCI originadas nos SPOKES para outros SPOKES; para os HUBS, anuncie tudo. Justificativa: A topologia é imposta no plano de controle, garantindo que os spokes só aprendam sobre outros spokes através dos hubs e preservando a segmentação na VPN de PCI.

4. Criar política de app-route para O365 e best-effort

   • Corresponder O365 na CORP_VPN com SLA GOLD; cor preferencial DIA com fallback para PRIVATE.
   • Corresponder BEST_EFFORT com SLA SILVER; preferencial PRIVATE com fallback para DIA. Justificativa: O O365 tem melhor desempenho pela Internet direta quando o SLA é atendido; faça failback para MPLS conforme necessário. O tráfego best-effort pode preferir MPLS por custo/política, permitindo o fallback para DIA.

5. Inserir firewall regional para tráfego de convidados (guest)

   • Política de dados na GUEST_VPN: inserção de serviço (service insertion) na cadeia de serviços do firewall regional em ambas as direções, de ida (lado do serviço para a WAN) e de volta (túnel para o serviço).
   • Garanta que a saúde do serviço de firewall seja monitorada; defina fail-open para o caso de uso de convidados para preservar a disponibilidade. Justificativa: A inspeção stateful requer travessia simétrica; a inserção bidirecional evita quedas de sessão. A tolerância a risco para convidados permite fail-open se o serviço estiver inoperante.

6. Anexar políticas via vSmart com implantação escalonada

   • Anexe a política de controle aos HUBS e a um subconjunto canário de SPOKES na PCI_VPN.
   • Anexe as políticas de app-route e de dados primeiro a uma região limitada. Justificativa: Limita o raio de impacto (blast radius); valida o comportamento da política antes da expansão global.

7. Validar e monitorar

   • Pré-visualize as políticas compiladas por dispositivo; confirme as ações padrão.
   • Use a simulação para testar fluxos de amostra (O365 de uma filial na CORP_VPN, tráfego web de convidados da GUEST_VPN).
   • Monitore show omp routes/tlocs (alcançabilidade de PCI), show app-route stats (caminho do O365), show policy service-path (contadores do firewall de convidados) e sessões BFD. Justificativa: Confirma que os resultados tanto do plano de controle quanto do plano de dados correspondem ao projeto, e que o direcionamento baseado em SLA opera como esperado.

8. Expandir e fortalecer (harden)

   • Adicione gradualmente os SPOKES restantes à anexação da política de controle.
   • Restrinja a política de convidados com limites de taxa (rate limits); ajuste os limites de SLA do O365 se ocorrerem oscilações de caminho. Justificativa: O ajuste iterativo reduz o risco operacional e garante uma experiência de usuário estável.

Esta sequência separa de forma clara o controle de topologia (OMP) do direcionamento e serviços do plano de dados, usa segmentação para proteger o ambiente PCI, aplica roteamento de aplicações baseado em SLA para desempenho e mantém a segurança operacional por meio de pré-visualização, simulação e anexação escalonada.

← Túneis de Plano de Dados · Todos os domínios · Segurança →

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