Cisco 300-415: Arquitetura e Planos da Fabric Cisco SD-WAN — 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 é um fabric baseado em intenção, construído a partir de componentes e planos distintos que separam as funções de gerenciamento, orquestração, controle e dados. A arquitetura escala de algumas filiais para milhares, independentemente do transporte de underlay, mantendo controle determinístico e segurança. Esta seção explica as funções do vManage, vSmart, vBond e WAN Edge; os planos e protocolos que os interconectam; as opções de plataforma; o endereçamento e a segmentação; os padrões de topologia de overlay; os conceitos de multilocação (multitenancy) e agrupamento; e as principais decisões de design e modos de falha que você deve considerar.

Componentes e Planos do Fabric

• WAN Edge: O roteador do plano de dados na filial, campus, colocation ou na borda da nuvem. Ele forma túneis de dados seguros, executa políticas, roda o BFD para verificar a atividade do caminho, troca rotas OMP com os controladores e encaminha o tráfego do usuário.
• vSmart Controller: O cérebro do plano de controle. Ele constrói e mantém a topologia de overlay, distribui informações de rota e política via OMP, e orquestra a conectividade do WAN Edge e a distribuição de chaves criptográficas para permitir o peering IPsec seguro entre as bordas.
• vBond Orchestrator: O primeiro ponto de contato para novos dispositivos. Ele autentica a identidade do dispositivo, auxilia na travessia de NAT e coordena a conexão de cada WAN Edge com o vSmart. Ele mantém conexões persistentes com os controladores vSmart e geralmente reside em um espaço de IP público alcançável para um onboarding universal.
• vManage: O plano de gerenciamento e orquestração (NMS). Ele fornece a entrada de intenção, templates de configuração, gerenciamento de imagens, telemetria, automação do Cloud OnRamp e APIs. O vManage não participa do plano de controle de encaminhamento.

Planos e protocolos:

• Plano de gerenciamento: O vManage usa canais seguros (NETCONF/gRPC sobre TLS) para monitorar e configurar dispositivos e controladores.
• Plano de orquestração: O vBond usa DTLS/TLS para autenticar dispositivos, compartilhar a alcançabilidade dos controladores e atravessar o NAT. Com certificados de controlador e sem porta alternativa configurada, o vBond escuta em UDP/TCP 12346.
• Plano de controle: O vSmart usa OMP para trocar prefixos, TLOCs e políticas com os dispositivos WAN Edge. As conexões de controle usam DTLS por padrão; o TLS também é suportado e comumente exigido por firewalls rigorosos ou regimes de conformidade.
• Plano de dados: Os dispositivos WAN Edge constroem túneis IPsec (ou GRE, quando apropriado) entre TLOCs para transporte criptografado, com sondagem BFD por túnel para detecção de falhas em menos de um segundo e roteamento ciente da aplicação.

Ciclo de vida ao ingressar:

1. O WAN Edge contata o vBond, se autentica e recebe as listas de controladores.
2. O WAN Edge estabelece sessões de controle DTLS/TLS com o vSmart (e com o vManage para gerenciamento).
3. O vSmart distribui informações de chaves criptográficas; o WAN Edge então forma túneis IPsec com outros WAN Edges conforme exigido pela política e topologia.

Implicações de resiliência:

• A perda do vManage afeta apenas a configuração e a visibilidade; o encaminhamento de dados continua.
• A perda do vBond afeta o onboarding de novos dispositivos; os dispositivos existentes não são afetados.
• A perda de todos os controladores vSmart isola o plano de controle; os túneis de dados persistem, mas as alterações de rota/política são interrompidas e um estado de controle obsoleto pode degradar as operações com o tempo.
• O failover de caminho orientado por BFD e múltiplos TLOCs fornecem continuidade ao plano de dados durante interrupções no underlay ou no transporte.

Identidade, Endereçamento e Segmentação

A identidade e o endereçamento são centrados no overlay:

• Organization name: Uma string que abrange todo o fabric e deve ser idêntica em todos os dispositivos e controladores; uma divergência impede a adjacência do plano de controle.
• System IP: Um identificador único de 32 bits por dispositivo, semelhante a uma loopback, usado em tuplas TLOC e no endereçamento do plano de controle. Não está vinculado a nenhuma interface física.
• Site ID: Um identificador numérico que agrupa dispositivos em uma localidade. Por padrão, dispositivos que compartilham um mesmo Site ID não formam túneis de dados diretos para evitar hairpins e loops dentro de um site.
• Certificates: Dispositivos e controladores usam identidade X.509. Os WAN Edges de hardware utilizam a secure device identity (SUDI) para provisionamento zero-touch; todos os dispositivos devem se registrar e ser autorizados no vManage antes de ingressar no fabric.

VPNs principais:

• VPN 0 (Transport): Transporta a conectividade de underlay e as interfaces TLOC em direção a MPLS, DIA, banda larga ou LTE. Rotas estáticas/padrão, NAT, DHCP e PPPoE terminam aqui. TLOC = {system IP, cor, encapsulamento}, onde a cor caracteriza o transporte (por exemplo, mpls, biz-internet, public-internet) e o encapsulamento é IPsec ou GRE.
• VPN 512 (Management): Gerenciamento de dispositivos out-of-band e alcançabilidade dos controladores. No IOS XE SD-WAN, isso mapeia para uma VRF de gerenciamento; no vEdge, é explicitamente a VPN 512. Controladores e WAN Edges estabelecem sessões de gerenciamento usando protocolos protegidos por TLS.
• Service VPNs (1–511, exceto 512): Transportam serviços de usuário e podem rodar OSPF, EIGRP, BGP, roteamento estático ou bridging. Políticas (centralizadas e localizadas) direcionam os fluxos inter-VPN e intra-VPN, QoS e segurança.

Elementos úteis de configuração base:

sdwan
 system-ip 10.255.0.11
 site-id 101
 organization-name ACME-Global

Modos de falha a serem observados:

• System IPs ou Site IDs duplicados criam anomalias de controle ou supressão indesejada de túneis.
• Divergência no Organization-name impede adjacências OMP.
• A expiração ou revogação de um certificado rompe a confiança do controlador ou do dispositivo.
• Uma rota padrão de gerenciamento mal posicionada na VPN 512 isola um dispositivo dos controladores; uma rota padrão de transporte mal posicionada na VPN 0 isola os TLOCs.

Plataformas, Modelos de Implantação e Design de Controladores

Plataformas de WAN Edge:

• Cisco IOS XE SD-WAN: Suportado nas plataformas ISR 4000 Series e ASR 1000 Series (e na família Catalyst 8000). Prefira o IOS XE SD-WAN para obter maior velocidade no desenvolvimento de novas funcionalidades a longo prazo e serviços unificados para filiais.
• vEdge: Plataformas de hardware/virtuais mais antigas baseadas em Viptela ainda são suportadas em muitas implantações; o planejamento da migração deve considerar as lacunas de funcionalidades e os cronogramas do ciclo de vida.
• Virtual WAN Edge: Executa em hypervisors e servidores, incluindo Cisco UCS e Cisco ENCS 5000 Series, e em nuvens públicas (AWS, Azure, GCP). Use o Cloud OnRamp para automatizar implantações de IaaS; os pré-requisitos incluem a inscrição na imagem do marketplace da nuvem (por exemplo, AWS AMI) e a preparação de um template de dispositivo no vManage.

Independência do underlay e diversidade de transporte:

• Cada TLOC se vincula a um transporte com uma cor associada; a política pode preferir, balancear ou excluir transportes por aplicação, SLA ou função do site.
• O IPsec é o padrão em underlays não confiáveis; o GRE pode ser usado sobre MPLS privado onde a criptografia não é necessária ou é restrita.
• O BFD fornece métricas de atividade (liveliness) e de SLA por túnel (perda, latência, jitter) para orientar o roteamento sensível à aplicação (application-aware routing).

Clusterização, escala, alta disponibilidade e localização de controladores:

• vManage: Implante como um cluster de três ou mais nós para alta disponibilidade (HA) e resiliência; co-aloque com armazenamento de alto desempenho (high-throughput) para telemetria e repositório de imagens. Faça backups com frequência.
• vSmart: Implante múltiplos controladores em diferentes domínios de falha e geografias; todos os WAN Edges estabelecem sessões de controle com mais de um vSmart. As instâncias do vSmart escalam horizontalmente; planeje uma capacidade N+1 para suportar a perda de um controlador.
• vBond: Implante pelo menos dois orquestradores em espaço de endereço público (ou com NAT estático e mapeamento de porta consistente). O vBond mantém sessões permanentes com o vSmart e sessões transitórias com os WAN Edges durante o processo de onboarding.
• Localização (Placement): Os controladores podem ser hospedados em seus data centers ou na nuvem pública. Garanta alcançabilidade de entrada (inbound) determinística da internet para o vBond e saída (egress) suficiente para os WAN Edges. Se dispositivos intermediários (middleboxes) exigirem exceções para inspeção de TLS, prefira sessões de controle TLS em vez de DTLS.

Notas operacionais:

• O transporte padrão do plano de controle é DTLS; mude para TLS ao atravessar firewalls rigorosos ou domínios de conformidade que permitem apenas controle criptografado baseado em TCP. Garanta que as portas apropriadas sejam permitidas de ponta a ponta.
• Quando um WAN Edge se conecta à rede, ele estabelece sessões DTLS/TLS com o vSmart e túneis IPsec com os edges pares com base na alcançabilidade e política do OMP. Garanta o uso de NAT keepalives e a abertura de pinholes UDP em circuitos de banda larga para evitar quedas silenciosas de túnel.

Topologias de Overlay, Multilocação e Trade-offs de Design

Padrões de topologia são realizados por meio de políticas de controle centralizadas (anúncios de rotas e TLOCs) e políticas de dados localizadas:

• Full mesh: Menor latência entre todos os sites; excelente resiliência; maior carga de escala no plano de controle e de dados devido a muitas sessões IPsec/BFD.
• Hub-and-spoke: Escala simples com menos túneis; o hub se torna um ponto de estrangulamento de largura de banda e resiliência sem um design de hub duplo; maior latência de caminho para tráfego spoke-a-spoke.
• Hub regional: Equilibra latência e escala ao delimitar malhas completas (full meshes) regionalmente e fazer o backhaul inter-regional via hubs; requer políticas cuidadosas para evitar o efeito “tromboning”.
• Hub duplo (ativo/ativo ou ativo/standby): Melhora a resiliência e pode distribuir a carga; aumenta a complexidade do controle (ECMP, critérios de desempate, prevenção de loops) e consome mais recursos do hub.

Multilocação e agrupamento:

• Multilocação verdadeira: Provedores de serviço podem habilitar o modo multilocatário (multi-tenant) nos controladores para hospedar múltiplas organizações lógicas com planos de controle, administradores e políticas isolados no mesmo cluster de controladores.
• Segmentação por locatário ou unidade de negócio: Use VPNs de serviço para impor a separação de tráfego, vazamento de rotas (route-leaking) onde necessário e políticas/QoS por VPN.
• Agrupamento de dispositivos: Use grupos de dispositivos, listas de sites, listas de VPNs e listas de prefixos/TLOCs do vManage para direcionar políticas, atualizações e templates por função, região ou papel.

Trade-offs de design:

• Latência vs. controle de políticas: A topologia full mesh minimiza a latência, mas complica a aplicação e a observação de políticas; a hub-and-spoke simplifica o controle, mas adiciona latência para fluxos leste-oeste.
• Resiliência vs. escala operacional: Mais TLOCs, transportes e hubs aumentam a disponibilidade e a escolha de caminhos, mas multiplicam as sessões IPsec/BFD e a escala de controle. Use regionalização e sumarização para manter os tamanhos do OMP e da FIB sob controle.
• Diversidade da underlay vs. custo: Adicionar banda larga e LTE melhora a alcançabilidade e a resistência a brownouts; o custo, o comportamento do NAT e o jitter variável podem complicar os SLAs. Use classes de SLA derivadas do BFD e roteamento ciente da aplicação (app-aware routing) para restringir o tráfego sensível.
• Riqueza da política centralizada vs. opacidade na solução de problemas: Cadeias complexas de correspondência/ação (match/action) fornecem controle granular, mas podem obscurecer a lógica de encaminhamento. Mantenha a política modular, versionada e bem documentada; teste em uma malha (fabric) de homologação.
• Segurança vs. desempenho: O uso obrigatório de IPsec em todos os transportes fortalece a confidencialidade, mas introduz sobrecarga de CPU e considerações sobre MTU/fragmentação. Prefira aceleração de criptografia por hardware e um ajuste consistente de MSS/PMTUD.

Modos de falha comuns e mitigações:

• Política assimétrica impedindo a formação de túneis: Valide as políticas de TLOC e de controle simetricamente; confirme as rotas de TLOC do OMP.
• Pinholes de NAT expirando em UDP: Prefira o controle via TLS ou configure keepalives de NAT; considere o uso de NAT estático para os controladores.
• Uso indevido de Site ID colapsando túneis intra-site: Garanta Site IDs únicos por local físico; use políticas de restrição de cor (color-restrict) do BFD para a intenção intra-campus em vez de forçar a fusão de sites.
• Hubs com escassez de recursos para os spokes: Monitore a CPU/criptografia do hub e a contagem de sessões BFD; escale horizontalmente os hubs ou introduza hubs regionais; use QoS e policers para proteger o tráfego de controle.

Cenário de Problema Prático

A Apex Manufacturing está expandindo para a AWS enquanto opera 600 filiais globais em transportes duplos (MPLS e DIA). Eles precisam estender a SD-WAN para a AWS com latência mínima para as aplicações regionais, manter a conformidade usando TLS para o controle e garantir a alta disponibilidade (HA) dos controladores.

1. Posicione dois orquestradores vBond no espaço de IP público e três controladores vSmart em duas nuvens diferentes.

• Justificativa: O vBond must be publicamente alcançável para auxiliar na travessia de NAT (NAT traversal); múltiplas instâncias do vSmart fornecem alta disponibilidade (HA) do plano de controle e proximidade geográfica. O vBond mantém sessões permanentes com o vSmart e sessões transitórias com os WAN Edges, acelerando o onboarding e a reconexão.

2. Converta todas as conexões de controle para TLS e permita o tráfego TCP na porta 12346 através dos firewalls corporativos.

• Justificativa: O DTLS padrão pode ser bloqueado por middleboxes rigorosos. O TLS garante a alcançabilidade do plano de controle através de proxies TCP e domínios de inspeção sem sacrificar a criptografia ou a integridade.

3. Implante o vManage como um cluster de três nós em uma região de nuvem central com backups diários.

• Justificativa: O plano de gerenciamento deve permanecer disponível para operações de política, imagem e telemetria. O cluster preserva o estado e escala o acesso via API/GUI; os backups protegem contra a perda de dados operacionais.

4. Use o Cloud OnRamp for IaaS para instanciar roteadores WAN Edge virtuais na AWS, um por VPC, em sub-redes conectadas a um transit gateway.

• Justificativa: O Cloud OnRamp automates a assinatura da AMI, a implantação e o registro de certificados. Os dispositivos WAN Edge terminam os TLOCs da SD-WAN e anunciam as rotas da VPC via OMP, integrando as cargas de trabalho da nuvem à malha (fabric) com o mesmo conjunto de políticas.

5. Atribua IPs de sistema (system IPs) de um bloco de overlay reservado e Site IDs únicos por região de nuvem (ex: 9001–9010), e defina um nome de organização (organization name) consistente em toda a malha.

• Justificativa: System IPs e Site IDs únicos evitam a supressão de túneis e a ambiguidade no plano de controle. A uniformidade do nome da organização é obrigatória para as adjacências OMP e a confiança de certificados.

6. Configure a VPN 0 para transportes duplos nos edges da AWS (internet pública e, quando disponível, Direct Connect via uma cor privada) e habilite o BFD com classes de SLA para roteamento ciente da aplicação (app-aware routing).

• Justificativa: A diversidade de transportes melhora a alcançabilidade e a resistência a brownouts. O BFD fornece métricas de perda/latência/jitter para direcionar o tráfego de aplicações para o TLOC com melhor desempenho de acordo com o SLA.

7. Exponha a VPN 512 apenas para as sub-redes de gerenciamento e restrinja o roteamento para os controladores por meio de rotas estáticas explícitas e ACLs.

• Justificativa: Minimiza a superfície de ataque no plano de gerenciamento e evita vazamentos de rota que poderiam isolar dispositivos ou expor excessivamente os serviços do controlador.

8. Implemente uma topologia de hub regional usando os edges da AWS como hubs para suas respectivas regiões, com hubs duplos on-premise por continente para failover, e habilite caminhos diretos de internet spoke-a-spoke para tráfego sensível à latência.

• Justificativa: Hubs regionais localizam os fluxos para reduzir a latência e conter a escala de controle; hubs duplos fornecem redundância. Túneis diretos spoke-a-spoke controlados preservam a baixa latência para aplicações em tempo real sem sobrecarregar os hubs.

9. Aplique políticas de controle centralizadas para sumarizar as rotas das filiais nos hubs regionais, restrinja os anúncios de TLOCs às regiões pretendidas e imponha a segmentação com VPNs de serviço para o tráfego de produção, OT (Tecnologia Operacional) e convidados.

• Justificativa: A sumarização reduz a instabilidade (churn) de rotas OMP e o uso de memória. Anúncios de TLOC com escopo definido evitam a formação não intencional de túneis inter-regionais. A segmentação baseada em VPN mantém os limites de conformidade com vazamento de rotas (route-leaking) explícito apenas onde necessário.

10. Monitore a saúde do BFD e do plano de controle; configure alertas para a perda de um vSmart ou vBond e pré-provisione capacidade N+1.

• Justificativa: A detecção precoce da degradação do controle previne instabilidade generalizada. A capacidade N+1 garante que a malha (fabric) suporte a falha de um controlador sem esgotar as sessões, protegendo tanto a convergência do plano de controle quanto a resiliência do plano de dados.

Todos os domínios · Onboarding de Controladores →

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