Cisco 300-415: Integração com Nuvem, SaaS e Multi-Cloud — 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 estende a conectividade segura e orientada por políticas para a nuvem pública e SaaS, utilizando o Cloud OnRamp for IaaS e o Cloud OnRamp for SaaS. A solução usa o mesmo plano de controle SD-WAN na nuvem que o on-premises: os dispositivos WAN Edge estabelecem conexões de controle DTLS ou TLS com os controllers vSmart e constroem túneis de plano de dados IPsec para outros roteadores WAN Edge, enquanto o vSmart distribui rotas e políticas usando o OMP e gerencia a distribuição de chaves criptográficas. O orquestrador vBond inicializa a adjacência inicial do plano de controle, e o vManage fornece automação, visualização e operações de ciclo de vida centralizadas. Esta seção detalha padrões de design multinuvem, pré-requisitos de implantação, construções de segurança e roteamento, otimização de SaaS e considerações operacionais, com ênfase em modos de falha e trade-offs.

Cloud OnRamp for IaaS e Implantação do WAN Edge Virtual

O Cloud OnRamp for IaaS automatiza o provisionamento de roteadores WAN Edge virtuais na AWS, Microsoft Azure e Google Cloud. O vManage utiliza as APIs do provedor de nuvem para instanciar objetos de computação, rede e segurança, depois anexa templates de dispositivo SD-WAN e integra os edges virtuais ao overlay.

Elementos e requisitos chave:

• Plataformas de WAN Edge virtual: Cisco CSR 1000v (cEdge) e vEdge Cloud. Estes também podem ser hospedados em hypervisors executando em Cisco UCS ou Cisco ENCS 5000 Series para nuvem privada.
• Imagens de controller: vManage, vSmart e vBond suportam implantação on-premises ou em IaaS com formatos de imagem padrão como .ova e .qcow2, permitindo controllers baseados em nuvem quando desejado para elasticidade e SLAs gerenciados.
• Marketplace e imagens: Antes da implantação, assine/aceite os termos para as imagens do roteador no marketplace de cada nuvem (por exemplo, AMI na AWS, plano do Azure Marketplace, imagem do GCP). A não aceitação dos termos resulta em erros de API ou falhas silenciosas de provisionamento.
• Templates de dispositivo: Anexe um template de dispositivo específico do site no vManage antes de iniciar a implantação na nuvem para garantir que a alcançabilidade do plano de controle da VPN0, os parâmetros de sistema/OMP, a segmentação e o endereçamento de interface/IP sejam aplicados automaticamente.
• Bootstrap/controle: Edges de nuvem recém-implantados devem alcançar os controllers SD-WAN pela VPN0. Se os controllers forem públicos, garanta a conectividade de saída para os FQDNs e portas do vBond/vSmart/vManage (HTTPS/TLS/DTLS). Se forem privados, forneça transporte privado via Direct Connect/ExpressRoute/Interconnect ou VPN site-to-site.

Considerações sobre security groups, tabelas de rotas e NAT:

• Permitir plano de controle e de dados: Permita egresso para o vBond e vSmart usando TLS/DTLS e para os edges pares usando IPsec. Se houver NAT, garanta que o NAT-T (UDP 4500) seja permitido. Regras de security group assimétricas ou a falta de permissões para portas efêmeras podem causar DCONFAIL (falha de conexão DTLS) ou túneis de plano de dados instáveis.
• Tabelas de rotas/UDRs: Associe as sub-redes da VPC/VNet apropriadas às tabelas de rotas que enviam tráfego para as interfaces internas do WAN Edge para as VMs spoke e para o gateway da nuvem (IGW/NAT/edge) para a Internet. Tabelas de rotas associadas incorretamente ou rotas padrão podem causar blackhole no tráfego da filial ou de retorno.
• MTU/fragmentação: O encapsulamento IPsec reduz o MTU efetivo. Considere o MSS clamp na interface ou o ajuste do MTU para evitar fragmentação nas fabrics da nuvem e nas NICs virtuais.

Modos de falha e mitigações:

• Privilégios insuficientes de IAM/RBAC: O vManage não consegue criar instâncias, NICs ou anexar security groups. Valide as roles do IAM, as atribuições de função do Azure ou os escopos da conta de serviço do GCP.
• Assinatura da imagem não aceita: A implantação falha na criação da instância. Aceite previamente os termos do marketplace e fixe a versão desejada.
• Certificado e relógio: Instâncias na nuvem com o tempo dessincronizado não conseguem validar os certificados do controller. Verifique com show control local-properties e a sincronização NTP.
• Configuração incorreta do template: Gateway/DNS incorreto na VPN0 impede a resolução do controller; use o teste de alcançabilidade do console da instância e as ferramentas de conectividade do vManage.

Padrões de Conectividade e Integração de Trânsito na AWS, Azure e Google Cloud

AWS

• Padrões: Transit VPC usando WAN Edges como NVAs; ou AWS Transit Gateway (TGW) nativo com WAN Edges encerrando IPsec/BGP em VPCs anexadas ao TGW. O Cloud OnRamp for IaaS pode implantar uma VPC de hub por região com pares de edge para alta disponibilidade (HA).
• Roteamento: Use as tabelas de rotas da VPC para direcionar os prefixos de sub-rede spoke para as ENIs do WAN Edge. Ao usar o TGW, propague as rotas spoke para os domínios de rota do TGW e anuncie os prefixos das filiais a partir do WAN Edge via BGP. Evite a sobreposição de CIDR entre VPCs/filiais para prevenir blackholes.
• Security groups e NACLs: Permitir VXLAN não é necessário para SD-WAN, mas permita as portas de IPsec e do plano de controle. As regras stateless das NACLs devem corresponder em ambas as direções.

Azure

• Padrões: VNets em topologia hub-and-spoke com WAN Edges na VNet de hub; Azure Route Server ou peering BGP com NVA para roteamento dinâmico; ou integração com o Azure Virtual WAN com conexões IPsec dos hubs SD-WAN para os hubs VWAN.
• Roteamento: User Defined Routes (UDRs) nas sub-redes spoke apontam para as NICs do WAN Edge como o próximo salto (next hop). Para o Virtual WAN, prefira BGP para troca dinâmica de rotas e segmentação usando múltiplas conexões.
• Network Security Groups: Espelhe a intenção dos security groups da AWS; garanta as sondas de saúde (health probes) e as regras de LB se estiver usando o Azure Load Balancer para HA do edge.

Google Cloud

• Padrões: NVAs de WAN Edge em um projeto host de VPC Compartilhada (Shared VPC) ou implantação por projeto; use HA VPN ou Cloud Router para BGP com Cloud Interconnect ou on-premises; direcione o tráfego spoke por meio de rotas personalizadas para as NICs do WAN Edge.
• Roteamento: As VPCs são globais; utilize rotas estáticas personalizadas com instância de próximo salto ou gateway de próximo salto. Para roteamento dinâmico, use o Cloud Router com BGP para o WAN Edge onde for suportado. Garanta que as regras de firewall permitam IPsec/plano de controle.

Trade-offs da integração de trânsito e híbrida:

• O trânsito nativo (TGW/VWAN) simplifica a escala e o roteamento leste-oeste, mas pode introduzir custos adicionais por GB e por anexo; o trânsito baseado em NVA oferece recursos avançados de SD-WAN e controle de políticas ao custo de limites de throughput e do escalonamento do appliance.
• Hubs multirregionais centralizados reduzem a latência para serviços de nuvem e SaaS, mas duplicar hubs por região aumenta a sobrecarga de gerenciamento. Use a automação do Cloud OnRamp para implantações consistentes.

Cloud OnRamp para SaaS, Estratégia de Saída (Egress) e Conectividade Híbrida

O Cloud OnRamp for SaaS otimiza os caminhos das aplicações para provedores de SaaS medindo continuamente o desempenho das filiais e dos hubs regionais/de nuvem até os pontos de entrada do SaaS, e então impondo o caminho de melhor experiência via App-Aware Routing.

• Medição e tomada de decisão: O recurso sonda múltiplas saídas (DIA local, hub regional, hub de nuvem) para perda, latência e jitter, selecionando o caminho preferencial por aplicação (por exemplo, Microsoft 365, WebEx, Salesforce). As políticas são distribuídas pelo vSmart.
• DNS e breakout: Alinhe a resolução de DNS com a política de breakout. Se os domínios SAS resolverem de forma diferente por região, um DNS inconsistente pode anular a seleção de caminho. Considere o uso de DNS local na saída escolhida para garantir o mapeamento anycast ideal.
• Encadeamento de serviços de segurança (service chaining): Combine o breakout local com segurança integrada (umbrella, cloud FW ou service chaining em colocation) quando a conformidade exigir inspeção. Faça o trade-off entre latência e profundidade da inspeção.

Opções de saída (egress) para a Internet pública:

• DIA local nos edges da filial para a menor latência para SaaS; requer uma postura de segurança local.
• Saída por hub regional ou de nuvem quando as filiais têm circuitos restritos ou mandatos de segurança centralizada; proteja-se contra o retorno assimétrico usando políticas de SD-WAN e NAT simétrico onde necessário.

Conectividade privada para a nuvem:

• AWS Direct Connect, Azure ExpressRoute e Google Cloud Interconnect oferecem largura de banda determinística e menor jitter para cargas de trabalho IaaS privadas. Integre com os WAN Edges usando peering privado e BGP, e depois redistribua no OMP. Observe que a maioria das aplicações SaaS ainda prefere caminhos de Internet pública; a conectividade privada é adequada para serviços privados, não para fluxos SaaS genéricos.
• Trade-offs híbridos: Links privados adicionam custo e complexidade, mas melhoram o desempenho para backends stateful ou zonas de gravidade de dados (data gravity). Mantenha designs de caminho duplo (privado + Internet) com failover baseado em desempenho.

Hubs de nuvem regionais e topologia nuvem-para-filial:

• Posicione pares de hubs SD-WAN nas regiões de nuvem mais próximas dos usuários e dos pontos de entrada críticos de SaaS. Os overlays IPsec de filial-para-hub de nuvem reduzem o efeito trombone via matriz (HQ) e permitem um failover multirregional rápido.
• Design ciente de segmentos: Use VRFs através do OMP para segmentar o tráfego de usuários, PCI e convidados; aplique políticas de saída distintas por segmento.

Identidade, Automação, Visibilidade e Ciclo de Vida na Nuvem

Pré-requisitos de IAM e provisionamento na nuvem:

• AWS: Forneça ao vManage uma IAM role ou chaves de acesso com permissão para EC2, VPC, IAM PassRole, CloudFormation e tagging. Defina o escopo de privilégio mínimo por recurso e região. Ações negadas causam stacks parciais e objetos órfãos.
• Azure: Crie um service principal com a função Contributor na assinatura/grupo de recursos de destino e a função Network Contributor necessária nas VNets. Aceite os termos do marketplace para as imagens via CLI ou portal antes da automação.
• GCP: Use uma conta de serviço (service account) com papéis como compute.admin, compute.networkAdmin e iam.serviceAccountUser. Habilite as APIs necessárias. Escopos insuficientes bloqueiam a criação de NICs ou rotas.

Visibilidade operacional:

• Os dashboards do vManage exibem conexões de controle, convergência de rotas OMP, desempenho de aplicações e as pontuações do Cloud OnRamp for SaaS. Use sobreposições de cores para comparar opções de egresso e validar os resultados das políticas.
• Logs e solução de problemas: No WAN Edge, verifique os certificados e o controle com:

show control local-properties
show control connections
show omp peers

DCONFAIL indica problemas de transporte ou de ACL/security group; capturas de pacotes nas vNICs e logs de fluxo da nuvem (cloud flow logs) ajudam a identificar portas bloqueadas ou caminhos assimétricos.

Ciclo de vida e escala:

• Escale os controladores clusterizando o vManage e implantando múltiplas instâncias de vSmart e vBond em diferentes domínios de falha/regiões. Controladores baseados em nuvem se beneficiam da elasticidade de IaaS e da alta disponibilidade (HA) gerenciada.
• Gerenciamento de imagens e templates: Prepare as atualizações de software no vManage, realize verificações prévias e, em seguida, atualize os clusters usando janelas de manutenção. Para os edges na nuvem, utilize atualizações contínuas de instâncias (rolling updates) com verificações de saúde (health checks) e políticas de drenagem (drain policies). Etiquete (tag) os recursos para mapeá-los de volta aos sites e templates.
• Backup e DR: Exporte rotineiramente a configuração, os templates e as listas de dispositivos do vManage. Para implantações na nuvem, use snapshots ou imagens douradas (golden images); garanta que os dados do usuário (certificados, chaves) sejam preservados ou possam ser registrados novamente.

Cenário de Problema Prático

A Acme BioPharma está migrando aplicações de P&D (Pesquisa e Desenvolvimento) para a AWS e o Azure, enquanto enfrenta um desempenho ruim do Microsoft 365 em suas filiais na América do Norte. Eles precisam de um design de hub SD-WAN dual-cloud com otimização de SaaS, segurança centralizada nos hubs da nuvem e acesso privado determinístico às cargas de trabalho do laboratório.

1. Definir hubs de nuvem regionais em us-east-1 (AWS) e East US (Azure).

• Justificativa: Localiza os hubs perto da maioria dos usuários e dos pontos de ingresso de SaaS, reduzindo a latência e oferecendo redundância geográfica.

2. Preparar os pré-requisitos de automação na nuvem.

• Justificativa: Na AWS, inscreva-se na AMI do CSR 1000v e crie uma IAM role com permissões de EC2, VPC e CloudFormation, incluindo iam:PassRole. No Azure, aceite o plano do marketplace e crie um service principal com a função Contributor no grupo de recursos do hub. Sem isso, o Cloud OnRamp não consegue instanciar VNets/VPCs e as VMs de roteador.

3. Implantar pares de hub do Cloud OnRamp for IaaS com templates do vManage.

• Justificativa: Use o vManage para automatizar duas instâncias de WAN Edge por região em AZs/domínios de falha separados. Anexe templates de dispositivo que configurem a VPN0, os IDs de sistema, o OMP, o roteamento ciente de aplicação (app-aware routing) e o BGP para o trânsito na nuvem. A automação garante construções consistentes e evita interrupções induzidas por erros de configuração.

4. Integrar com o trânsito na nuvem (AWS TGW e VNet de hub do Azure).

• Justificativa: Anexe redes spoke ao AWS TGW e configure as tabelas de rotas do TGW para propagar as sub-redes spoke para a VPC do hub SD-WAN, enquanto anuncia os prefixos das filiais a partir dos WAN Edges para o TGW via BGP. No Azure, aplique UDRs (User Defined Routes) nos spokes para apontar prefixos padrão ou específicos para as NICs do WAN Edge. Isso fornece alcançabilidade escalável de spoke para filial e de spoke para spoke.

5. Estabelecer conectividade privada para P&D com os hubs.

• Justificativa: Ative o Direct Connect para us-east-1 e o ExpressRoute para East US com emparelhamento privado (private peering), terminando nos hubs WAN Edge com BGP. Links privados oferecem menor jitter e maior determinismo para as cargas de trabalho do laboratório; o OMP redistribui as rotas aprendidas por todo o fabric.

6. Habilitar o Cloud OnRamp for SaaS para o Microsoft 365 e aplicações de colaboração.

• Justificativa: Ative a sondagem de desempenho (performance probing) a partir das filiais e de ambos os hubs; aplique uma política de seleção de caminho no vSmart para preferir o egresso de melhor desempenho (DIA local se for superior, caso contrário, o hub de melhor desempenho mais próximo). Isso otimiza dinamicamente a experiência do usuário conforme as condições da Internet flutuam.

7. Implementar segurança e segmentação.

• Justificativa: Crie VRFs para P&D, corporativo e convidados (guest). Encaminhe o tráfego destinado à Internet através de firewalls na nuvem localizados nos hubs para o tráfego corporativo e de P&D, enquanto permite acesso direto à Internet para convidados com o Umbrella DNS. Os security groups na AWS/Azure permitem o controle DTLS/TLS e o plano de dados IPsec, restringindo o gerenciamento aos IPs corporativos.

8. Validar e operacionalizar.

• Justificativa: Use o vManage para confirmar a estabilidade das conexões de controle, as rotas OMP e as pontuações de caminho do SaaS. Execute show control local-properties em cada edge de hub para verificar a validade do certificado e a sincronização de tempo. Habilite os logs de fluxo da nuvem (cloud flow logs) para detectar negações inesperadas. Implemente atualizações contínuas (rolling upgrades) via vManage e faça snapshots das instâncias na nuvem para manter uma higiene de ciclo de vida consistente.

Essa abordagem resulta em hubs multi-cloud resilientes, acesso otimizado a SaaS e conectividade privada controlada para cargas de trabalho sensíveis, ao mesmo tempo em que aproveita a política centralizada e a observabilidade do Cisco SD-WAN para reduzir o risco operacional.

← Qualidade de Serviço e Serviços Multicast · Todos os domínios · Operações →

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