Cisco 300-415: Integración con la nube, SaaS y múltiples nubes — Guía de estudio

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

Forma parte de la Cisco SD-WAN 300-415 ENSDWI — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Cisco, o realiza tests cronometrados en ExamRoll.io.

Información general

Cisco SD-WAN extiende la conectividad segura y basada en políticas a la nube pública y SaaS aprovechando Cloud OnRamp for IaaS y Cloud OnRamp for SaaS. La solución utiliza el mismo plano de control de SD-WAN en la nube que en las instalaciones (on-premises): los dispositivos WAN Edge establecen conexiones de control DTLS o TLS con los controladores vSmart y construyen túneles de plano de datos IPsec hacia otros routers WAN Edge, mientras que vSmart distribuye rutas y políticas usando OMP y gestiona la distribución de claves criptográficas. El orquestador vBond arranca la adyacencia inicial del plano de control, y vManage proporciona automatización centralizada, visualización y operaciones del ciclo de vida. Esta sección detalla los patrones de diseño multinube, los prerrequisitos de despliegue, las construcciones de seguridad y enrutamiento, la optimización de SaaS y las consideraciones operativas, con énfasis en los modos de fallo y las contrapartidas.

Cloud OnRamp for IaaS y despliegue de Virtual WAN Edge

Cloud OnRamp for IaaS automatiza el aprovisionamiento de routers WAN Edge virtuales en AWS, Microsoft Azure y Google Cloud. vManage aprovecha las API del proveedor de la nube para instanciar objetos de computación, redes y seguridad, luego adjunta plantillas de dispositivos SD-WAN e incorpora los edges virtuales en el overlay.

Elementos y requisitos clave:

• Plataformas Virtual WAN Edge: Cisco CSR 1000v (cEdge) y vEdge Cloud. Estas también pueden alojarse en hipervisores que se ejecutan en Cisco UCS o Cisco ENCS 5000 Series para la nube privada.
• Imágenes de controladores: vManage, vSmart y vBond admiten el despliegue on-premises o en IaaS con formatos de imagen estándar como .ova y .qcow2, lo que permite tener controladores basados en la nube cuando se desea elasticidad y SLAs gestionados.
• Marketplace e imágenes: Antes del despliegue, suscríbase/acepte los términos para las imágenes del router en el marketplace de cada nube (por ejemplo, AMI en AWS, plan de Azure Marketplace, imagen de GCP). No aceptar los términos resulta en errores de API o fallos silenciosos de aprovisionamiento.
• Plantillas de dispositivo: Adjunte una plantilla de dispositivo específica del sitio en vManage antes de iniciar el despliegue en la nube para asegurar que la alcanzabilidad del plano de control de VPN0, los parámetros del sistema/OMP, la segmentación y el direccionamiento IP/de interfaz se apliquen automáticamente.
• Arranque/control: Los edges de la nube recién desplegados deben poder alcanzar los controladores SD-WAN a través de VPN0. Si los controladores son públicos, asegure la conectividad de salida a los FQDN y puertos de vBond/vSmart/vManage (HTTPS/TLS/DTLS). Si son privados, proporcione transporte privado a través de Direct Connect/ExpressRoute/Interconnect o una VPN de sitio a sitio.

Consideraciones sobre grupos de seguridad, tablas de rutas y NAT:

• Permitir plano de control y de datos: Permita el egreso hacia vBond y vSmart usando TLS/DTLS y hacia los edges pares usando IPsec. Si hay NAT, asegúrese de que NAT-T (UDP 4500) esté permitido. Reglas de grupos de seguridad asimétricas o la falta de permisos para puertos efímeros pueden causar DCONFAIL (fallo de conexión DTLS) o túneles de plano de datos inestables.
• Tablas de rutas/UDRs: Asocie las subredes de VPC/VNet apropiadas con tablas de rutas que envíen el tráfico hacia las interfaces internas del WAN Edge para las VMs spoke y hacia el gateway de la nube (IGW/NAT/edge) para Internet. Tablas de rutas mal asociadas o rutas por defecto pueden causar un agujero negro (blackhole) para el tráfico de la sucursal o de retorno.
• MTU/fragmentación: La encapsulación IPsec reduce el MTU efectivo. Considere ajustar el MSS (MSS clamp) de la interfaz o el MTU para evitar la fragmentación a través de los fabrics de la nube y las NIC virtuales.

Modos de fallo y mitigaciones:

• Privilegios insuficientes de IAM/RBAC: vManage no puede crear instancias, NICs o adjuntar grupos de seguridad. Valide los roles de IAM, las asignaciones de roles de Azure o los ámbitos de la cuenta de servicio de GCP.
• Suscripción a la imagen no aceptada: El despliegue falla en la creación de la instancia. Acepte previamente los términos del marketplace y fije la versión deseada.
• Certificado y reloj: Las instancias en la nube con la hora desfasada no pueden validar los certificados del controlador. Verifique con show control local-properties y la sincronización NTP.
• Configuración incorrecta de la plantilla: Un gateway/DNS incorrecto en VPN0 impide la resolución del controlador; use las herramientas de prueba de alcanzabilidad desde la consola de la instancia y las herramientas de conectividad de vManage.

Patrones de Conectividad e Integración de Tránsito en AWS, Azure y Google Cloud

AWS

• Patrones: Transit VPC usando WAN Edges como NVAs; o AWS Transit Gateway (TGW) nativo con WAN Edges terminando IPsec/BGP en VPCs conectadas al TGW. Cloud OnRamp for IaaS puede desplegar una VPC hub por región con pares de borde para alta disponibilidad (HA).
• Enrutamiento: Usar las tablas de rutas de la VPC para dirigir los prefijos de las subredes spoke hacia las ENIs de los WAN Edge. Al usar TGW, propagar las rutas de los spokes a los dominios de enrutamiento del TGW y anunciar los prefijos de las sucursales desde el WAN Edge vía BGP. Evitar el solapamiento de CIDR entre VPCs/sucursales para prevenir agujeros negros (blackholes).
• Grupos de seguridad y NACLs: No se requiere permitir VXLAN para SD-WAN, pero sí permitir los puertos de IPsec y del plano de control. Las reglas sin estado (stateless) de las NACL deben coincidir en ambas direcciones.

Azure

• Patrones: VNets en topología hub-and-spoke con WAN Edges en la VNet hub; Azure Route Server o peering BGP con NVA para enrutamiento dinámico; o integración con Azure Virtual WAN con conexiones IPsec desde los hubs SD-WAN a los hubs de VWAN.
• Enrutamiento: Las Rutas Definidas por el Usuario (UDRs) en las subredes spoke apuntan a las NICs de los WAN Edge como siguiente salto. Para Virtual WAN, preferir BGP para el intercambio dinámico de rutas y la segmentación usando múltiples conexiones.
• Grupos de Seguridad de Red: Reflejar la intención de los grupos de seguridad de AWS; asegurar los sondeos de estado (health probes) y las reglas del LB si se usa Azure Load Balancer para la alta disponibilidad (HA) de los bordes.

Google Cloud

• Patrones: NVAs de WAN Edge en un proyecto anfitrión de Shared VPC o en un despliegue por proyecto; usar HA VPN o Cloud Router para BGP con Cloud Interconnect o en las instalaciones (on-premises); dirigir el tráfico de los spokes mediante rutas personalizadas hacia las NICs de los WAN Edge.
• Enrutamiento: Las VPCs son globales; aprovechar las rutas estáticas personalizadas con una instancia de siguiente salto o una puerta de enlace de siguiente salto. Para enrutamiento dinámico, usar Cloud Router con BGP hacia el WAN Edge donde sea compatible. Asegurar que las reglas de firewall permitan IPsec/plano de control.

Compensaciones en la integración de tránsito e híbrida:

• El tránsito nativo (TGW/VWAN) simplifica la escalabilidad y el enrutamiento este-oeste, pero puede introducir costos adicionales por GB y por conexión (attachment); el tránsito basado en NVA proporciona funciones avanzadas de SD-WAN y control de políticas a expensas de los límites de rendimiento y la escalabilidad de los dispositivos.
• Los hubs multirregionales centralizados reducen la latencia a los servicios en la nube y SaaS, pero duplicar los hubs por región aumenta la sobrecarga de gestión. Usar la automatización de Cloud OnRamp para despliegues consistentes.

Cloud OnRamp para SaaS, Estrategia de Salida y Conectividad Híbrida

Cloud OnRamp for SaaS optimiza las rutas de las aplicaciones hacia los proveedores de SaaS midiendo continuamente el rendimiento desde las sucursales y los hubs regionales/en la nube hasta los puntos de entrada de SaaS, y luego aplicando la ruta de mejor experiencia a través de App-Aware Routing.

• Medición y toma de decisiones: La funcionalidad sondea múltiples salidas (DIA local, hub regional, hub en la nube) para medir pérdida, latencia y jitter, seleccionando la ruta preferida por aplicación (por ejemplo, Microsoft 365, WebEx, Salesforce). Las políticas son distribuidas por vSmart.
• DNS y breakout: Alinear la resolución de DNS con la política de breakout. Si los dominios de SaaS se resuelven de manera diferente por región, una resolución de DNS inconsistente puede anular la selección de la ruta. Considere usar un DNS local en la salida elegida para asegurar un mapeo anycast óptimo.
• Encadenamiento de servicios de seguridad: Combinar el breakout local con seguridad integrada (umbrella, FW en la nube o encadenamiento de servicios en colocación) cuando el cumplimiento normativo requiera inspección. Evaluar el equilibrio entre latencia y profundidad de la inspección.

Opciones de salida a Internet pública:

• DIA local en los bordes de la sucursal para la latencia más baja hacia SaaS; requiere una postura de seguridad local.
• Salida a través de un hub regional o en la nube cuando las sucursales tienen circuitos limitados o mandatos de seguridad centralizada; protegerse contra el retorno asimétrico usando políticas de SD-WAN y NAT simétrico donde sea necesario.

Conectividad privada a la nube:

• AWS Direct Connect, Azure ExpressRoute y Google Cloud Interconnect ofrecen un ancho de banda determinista y menor jitter para cargas de trabajo IaaS privadas. Integrar con los WAN Edges usando peering privado y BGP, y luego redistribuir en OMP. Tenga en cuenta que la mayoría de las aplicaciones SaaS todavía prefieren las rutas de Internet pública; la conectividad privada es adecuada para servicios privados, no para flujos genéricos de SaaS.
• Compensaciones del modelo híbrido: Los enlaces privados añaden costo y complejidad, pero mejoran el rendimiento hacia los backends con estado (stateful) o las zonas de gravedad de datos. Mantener diseños de doble ruta (privada + Internet) con failover basado en el rendimiento.

Hubs regionales en la nube y topología de nube a sucursal:

• Ubicar pares de hubs SD-WAN en las regiones de la nube más cercanas a los usuarios y a los puntos de entrada críticos de SaaS. Las superposiciones (overlays) IPsec de sucursal a hub en la nube reducen el efecto trombón a través de la sede central (HQ) y permiten un failover multirregional rápido.
• Diseño consciente de los segmentos: Usar VRFs a través de OMP para segmentar el tráfico de usuarios, PCI e invitados; aplicar políticas de salida distintas por cada segmento.

Identidad, automatización, visibilidad y ciclo de vida en la nube

Prerrequisitos de IAM y aprovisionamiento en la nube:

• AWS: Proporcione a vManage un rol de IAM o claves de acceso con permisos para EC2, VPC, IAM PassRole, CloudFormation y etiquetado. Limite el alcance al privilegio mínimo por recurso y región. Las acciones denegadas causan pilas parciales y objetos huérfanos.
• Azure: Cree una entidad de servicio con el rol Contributor en la suscripción/grupo de recursos de destino y el rol Network Contributor necesario en las VNets. Acepte los términos del marketplace para las imágenes a través de la CLI o el portal antes de la automatización.
• GCP: Utilice una cuenta de servicio con roles como compute.admin, compute.networkAdmin y iam.serviceAccountUser. Habilite las API requeridas. Los alcances insuficientes bloquean la creación de NIC o rutas.

Visibilidad operativa:

• Los dashboards de vManage muestran las conexiones de control, la convergencia de rutas OMP, el rendimiento de las aplicaciones y las puntuaciones de Cloud OnRamp for SaaS. Utilice superposiciones de color para comparar las opciones de egreso y validar los resultados de las políticas.
• Registro y solución de problemas: En el WAN Edge, verifique los certificados y el control con:

show control local-properties
show control connections
show omp peers

DCONFAIL indica problemas de transporte o de ACL/grupos de seguridad; las capturas de paquetes en las vNIC y los registros de flujo de la nube ayudan a identificar puertos bloqueados o rutas asimétricas.

Ciclo de vida y escalabilidad:

• Escale los controladores agrupando vManage en clúster y desplegando múltiples instancias de vSmart y vBond en diferentes dominios de error/regiones. Los controladores basados en la nube se benefician de la elasticidad de IaaS y de la alta disponibilidad (HA) gestionada.
• Gestión de imágenes y plantillas: Prepare las actualizaciones de software en vManage, realice comprobaciones previas y luego actualice los clústeres de forma continua utilizando ventanas de mantenimiento. Para los edges en la nube, emplee actualizaciones continuas de instancias con comprobaciones de estado y políticas de drenaje. Etiquete los recursos para mapearlos de vuelta a los sitios y plantillas.
• Copia de seguridad y recuperación ante desastres (DR): Exporte la configuración, las plantillas y las listas de dispositivos de vManage de forma rutinaria. Para despliegues en la nube, haga snapshots o utilice imágenes doradas; asegúrese de que los datos de usuario (certificados, claves) se conserven o se puedan volver a inscribir.

Escenario de problema práctico

Acme BioPharma está migrando aplicaciones de I+D a AWS y Azure mientras experimenta un bajo rendimiento de Microsoft 365 desde sus sucursales en Norteamérica. Requieren un diseño de hub SD-WAN dual-cloud con optimización de SaaS, seguridad centralizada en los hubs de la nube y acceso privado determinista a las cargas de trabajo del laboratorio.

1. Definir hubs regionales en la nube en us-east-1 (AWS) y East US (Azure).

• Fundamento: Ubica los hubs cerca de la mayoría de los usuarios y de los puntos de ingreso de SaaS, reduciendo la latencia y ofreciendo redundancia geográfica.

2. Preparar los prerrequisitos de automatización en la nube.

• Fundamento: En AWS, suscribirse a la AMI del CSR 1000v y crear un rol de IAM con permisos para EC2, VPC y CloudFormation, incluyendo iam:PassRole. En Azure, aceptar el plan del marketplace y crear una entidad de servicio con el rol Contributor en el grupo de recursos del hub. Sin esto, Cloud OnRamp no puede instanciar las VNets/VPCs y las VM de router.

3. Desplegar pares de hubs de Cloud OnRamp for IaaS con plantillas de vManage.

• Fundamento: Usar vManage para automatizar dos instancias de WAN Edge por región en diferentes AZs/dominios de error. Adjuntar plantillas de dispositivo que configuren VPN0, los ID de sistema, OMP, enrutamiento basado en aplicaciones (app-aware routing) y BGP para el tránsito en la nube. La automatización garantiza compilaciones consistentes y evita interrupciones inducidas por errores de configuración.

4. Integrar con el tránsito en la nube (AWS TGW y VNet de hub de Azure).

• Fundamento: Conectar las redes spoke a AWS TGW y configurar las tablas de rutas de TGW para propagar las subredes spoke a la VPC del hub SD-WAN, mientras se anuncian los prefijos de las sucursales desde los WAN Edges hacia TGW a través de BGP. En Azure, aplicar UDRs en los spokes para apuntar los prefijos predeterminados o específicos a las NIC del WAN Edge. Esto proporciona una conectividad escalable de spoke a sucursal y de spoke a spoke.

5. Establecer conectividad privada para I+D hacia los hubs.

• Fundamento: Activar Direct Connect hacia us-east-1 y ExpressRoute hacia East US con peering privado, terminando en los hubs WAN Edge con BGP. Los enlaces privados ofrecen menor jitter y mayor determinismo para las cargas de trabajo del laboratorio; OMP redistribuye las rutas aprendidas en todo el fabric.

6. Habilitar Cloud OnRamp for SaaS para Microsoft 365 y aplicaciones de colaboración.

• Fundamento: Activar el sondeo de rendimiento desde las sucursales y ambos hubs; aplicar una política de selección de ruta en vSmart para preferir el egreso con mejor rendimiento (DIA local si es superior, si no, el hub más cercano con buen rendimiento). Esto optimiza dinámicamente la experiencia del usuario a medida que fluctúan las condiciones de Internet.

7. Implementar seguridad y segmentación.

• Fundamento: Crear VRFs para I+D, corporativo e invitados. Encadenar el tráfico con destino a Internet a través de firewalls en la nube coubicados en los hubs para el tráfico corporativo y de I+D, mientras se permite a los invitados acceso directo a Internet con Umbrella DNS. Los grupos de seguridad en AWS/Azure permiten el control DTLS/TLS y el plano de datos IPsec, restringiendo la gestión a las IP corporativas.

8. Validar y poner en operación.

• Fundamento: Usar vManage para confirmar la estabilidad de las conexiones de control, las rutas OMP y las puntuaciones de ruta de SaaS. Ejecutar show control local-properties en cada edge del hub para verificar la validez del certificado y la sincronización de tiempo. Habilitar los registros de flujo de la nube para detectar denegaciones inesperadas. Implementar actualizaciones continuas a través de vManage y hacer snapshots de las instancias en la nube para mantener una higiene consistente del ciclo de vida.

Este enfoque produce hubs multicloud resilientes, acceso optimizado a SaaS y conectividad privada controlada a cargas de trabajo sensibles, al tiempo que aprovecha la política centralizada y la observabilidad de Cisco SD-WAN para reducir el riesgo operativo.

← Calidad de servicio y servicios de multidifusión · Todos los dominios · Operaciones →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →