Cisco 300-415: Arquitectura y planos de la estructura de Cisco SD-WAN — 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.

Resumen

Cisco SD-WAN es un fabric basado en la intención, construido a partir de componentes y planos distintos que separan las funciones de gestión, orquestación, control y datos. La arquitectura escala desde unas pocas sucursales hasta miles, independientemente del transporte underlay, mientras mantiene un control y una seguridad deterministas. Esta sección explica los roles de vManage, vSmart, vBond y WAN Edge; los planos y protocolos que los interconectan; las opciones de plataforma; el direccionamiento y la segmentación; los patrones de topología overlay; los conceptos de multitenencia y agrupación; y las principales consideraciones de diseño y modos de fallo que debe tener en cuenta.

Componentes y Planos del Fabric

• WAN Edge: El router del plano de datos en la sucursal, campus, coubicación o borde de la nube. Forma túneles de datos seguros, ejecuta políticas, utiliza BFD para verificar la vitalidad de las rutas, intercambia rutas OMP con los controladores y reenvía el tráfico de los usuarios.
• vSmart Controller: El cerebro del plano de control. Construye y mantiene la topología overlay, distribuye información de rutas y políticas a través de OMP, y orquesta la conectividad de los WAN Edge y la distribución de claves criptográficas para permitir el peering IPsec seguro entre los bordes.
• vBond Orchestrator: El primer punto de contacto para los dispositivos nuevos. Autentica la identidad del dispositivo, asiste en el NAT traversal y coordina la conexión de cada WAN Edge con vSmart. Mantiene conexiones persistentes con los controladores vSmart y normalmente reside en un espacio de IP públicas accesibles para un onboarding universal.
• vManage: El plano de gestión y orquestación (NMS). Proporciona la entrada de la intención, plantillas de configuración, gestión de imágenes, telemetría, automatización de Cloud OnRamp y APIs. vManage no participa en el plano de control de reenvío.

Planos y protocolos:

• Plano de gestión: vManage utiliza canales seguros (NETCONF/gRPC sobre TLS) para monitorizar y configurar dispositivos y controladores.
• Plano de orquestación: vBond utiliza DTLS/TLS para autenticar dispositivos, compartir la alcanzabilidad de los controladores y atravesar NAT. Con certificados de controlador y sin un puerto alternativo configurado, vBond escucha en UDP/TCP 12346.
• Plano de control: vSmart utiliza OMP para intercambiar prefijos, TLOCs y políticas con los dispositivos WAN Edge. Las conexiones de control utilizan DTLS por defecto; también se soporta TLS y es comúnmente requerido a través de firewalls estrictos o regímenes de cumplimiento.
• Plano de datos: Los dispositivos WAN Edge construyen túneles IPsec (o GRE cuando sea apropiado) entre TLOCs para el transporte cifrado, con sondeos BFD por túnel para la detección de fallos en menos de un segundo y el enrutamiento consciente de la aplicación.

Ciclo de vida al unirse:

1. El WAN Edge contacta a vBond, se autentica y recibe las listas de controladores.
2. El WAN Edge establece sesiones de control DTLS/TLS con vSmart (y con vManage para la gestión).
3. vSmart distribuye la información de las claves criptográficas; el WAN Edge entonces forma túneles IPsec con otros WAN Edges según lo requiera la política y la topología.

Implicaciones de resiliencia:

• La pérdida de vManage solo afecta a la configuración y la visibilidad; el reenvío de datos continúa.
• La pérdida de vBond afecta al onboarding de nuevos dispositivos; los dispositivos existentes no se ven afectados.
• La pérdida de todos los controladores vSmart aísla el plano de control; los túneles de datos persisten, pero los cambios de rutas/políticas se detienen y un estado de control obsoleto puede degradar las operaciones con el tiempo.
• La conmutación por error de rutas impulsada por BFD y múltiples TLOCs proporcionan continuidad en el plano de datos durante interrupciones del underlay o del transporte.

Identidad, Direccionamiento y Segmentación

La identidad y el direccionamiento están centrados en el overlay:

• Nombre de la organización: Una cadena de texto para todo el fabric que debe coincidir en todos los dispositivos y controladores; una discrepancia impide la adyacencia del plano de control.
• System IP: Un identificador único de 32 bits por dispositivo, similar a una loopback, utilizado en las tuplas TLOC y en el direccionamiento del plano de control. No está vinculado a ninguna interfaz física.
• Site ID: Un identificador numérico que agrupa dispositivos en una ubicación. Por defecto, los dispositivos que comparten un Site ID no forman túneles de datos directos para evitar hairpins y bucles dentro de un sitio.
• Certificados: Los dispositivos y controladores utilizan identidades X.509. Los WAN Edges de hardware aprovechan la identidad segura del dispositivo (SUDI) para el aprovisionamiento zero-touch; todos los dispositivos deben registrarse y ser autorizados en vManage antes de unirse al fabric.

VPNs clave:

• VPN 0 (Transporte): Transporta la conectividad del underlay y las interfaces TLOC hacia MPLS, DIA, banda ancha o LTE. NAT, DHCP, PPPoE y las rutas estáticas/por defecto terminan aquí. TLOC = {system IP, color, encapsulación} donde el color caracteriza el transporte (por ejemplo, mpls, biz-internet, public-internet) y la encapsulación es IPsec o GRE.
• VPN 512 (Gestión): Gestión de dispositivos fuera de banda (out-of-band) y alcanzabilidad de los controladores. En IOS XE SD-WAN, esto se mapea a un VRF de gestión; en vEdge es explícitamente la VPN 512. Los controladores y los WAN Edges establecen sesiones de gestión utilizando protocolos asegurados con TLS.
• VPNs de servicio (1–511 excepto 512): Transportan servicios de usuario y pueden ejecutar OSPF, EIGRP, BGP, enrutamiento estático o bridging. Las políticas (centralizadas y localizadas) dirigen los flujos inter-VPN e intra-VPN, QoS y la seguridad.

Elementos útiles de configuración base:

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

Modos de fallo a vigilar:

• System IPs o Site IDs duplicados crean anomalías de control o supresión no deseada de túneles.
• Una discrepancia en el nombre de la organización impide las adyacencias OMP.
• La expiración o revocación de un certificado rompe la confianza del controlador o del dispositivo.
• Una ruta por defecto de gestión mal ubicada en la VPN 512 aísla un dispositivo de los controladores; una ruta por defecto de transporte mal ubicada en la VPN 0 aísla los TLOCs.

Plataformas, modelos de despliegue y diseño de controladores

Plataformas de WAN Edge:

• Cisco IOS XE SD-WAN: Soportado en las plataformas ISR 4000 Series y ASR 1000 Series (y la familia Catalyst 8000). Prefiera IOS XE SD-WAN para una velocidad de desarrollo de funcionalidades a largo plazo y servicios de sucursal unificados.
• vEdge: Plataformas de hardware/virtuales anteriores basadas en Viptela todavía soportadas en muchos despliegues; la planificación de la migración debe considerar las brechas de funcionalidades y los plazos del ciclo de vida.
• Virtual WAN Edge: Se ejecuta en hipervisores y servidores, incluyendo Cisco UCS y Cisco ENCS 5000 Series, y en nubes públicas (AWS, Azure, GCP). Use Cloud OnRamp para automatizar los despliegues de IaaS; los prerrequisitos incluyen la suscripción a la imagen del marketplace en la nube (por ejemplo, la AMI de AWS) y la preparación de una plantilla de dispositivo en vManage.

Independencia del underlay y diversidad de transportes:

• Cada TLOC se vincula a un transporte con un color asociado; la política puede preferir, balancear o excluir transportes por aplicación, SLA o rol del sitio.
• IPsec es el predeterminado en los underlays no confiables; se puede usar GRE sobre MPLS privado donde el cifrado no es necesario o está restringido.
• BFD proporciona métricas de vitalidad (liveliness) y de SLA por túnel (pérdida, latencia, jitter) para impulsar el enrutamiento consciente de la aplicación (application-aware routing).

Clustering, escalabilidad, alta disponibilidad y ubicación de los controladores:

• vManage: Despliegue como un clúster de tres nodos o más para alta disponibilidad (HA) y resiliencia; ubíquelo junto a un almacenamiento de alto rendimiento para la telemetría y el repositorio de imágenes. Realice copias de seguridad con frecuencia.
• vSmart: Despliegue múltiples controladores en diferentes dominios de fallo y geografías; todos los WAN Edges establecen sesiones de control con más de un vSmart. Las instancias de vSmart escalan horizontalmente; planifique una capacidad N+1 para soportar la pérdida de un controlador.
• vBond: Despliegue al menos dos orquestadores en el espacio de direcciones públicas (o con NAT estático y mapeo de puertos consistente). vBond mantiene sesiones permanentes con vSmart y sesiones transitorias con los WAN Edges durante el proceso de incorporación (onboarding).
• Ubicación: Los controladores pueden alojarse en sus centros de datos o en la nube pública. Asegure una alcanzabilidad de entrada determinista desde internet para vBond y un egreso suficiente para los WAN Edges. Si los middleboxes exigen excepciones de inspección TLS, prefiera las sesiones de control TLS sobre DTLS.

Notas operativas:

• El transporte del plano de control por defecto es DTLS; cambie a TLS al cruzar firewalls estrictos o dominios de cumplimiento que solo permiten control cifrado basado en TCP. Asegúrese de que los puertos apropiados estén permitidos de extremo a extremo.
• Cuando un WAN Edge se une, establece sesiones DTLS/TLS con vSmart y túneles IPsec con los edges pares basándose en la alcanzabilidad y la política de OMP. Asegure los keepalives de NAT y los pinholes de UDP en los circuitos de banda ancha para evitar caídas silenciosas de los túneles.

Topologías de superposición (overlay), multitenencia y compromisos de diseño

Los patrones de topología se realizan a través de políticas de control centralizadas (anuncios de rutas y TLOCs) y políticas de datos localizadas:

• Malla completa: La latencia más baja entre todos los sitios; resiliencia excelente; la carga más alta a escala en el plano de control y de datos debido a las numerosas sesiones IPsec/BFD.
• Hub y spoke: Escalado simple con menos túneles; el hub se convierte en un cuello de botella de ancho de banda y resiliencia sin un diseño de hub dual; mayor latencia de ruta para el tráfico de spoke a spoke.
• Hub regional: Equilibra la latencia y la escala al limitar las mallas completas a nivel regional y usar los hubs para el tráfico de retorno (backhaul) entre regiones; requiere una política cuidadosa para prevenir el efecto trombón.
• Hub dual (activo/activo o activo/en espera): Mejora la resiliencia y puede distribuir la carga; aumenta la complejidad del control (ECMP, desempate, prevención de bucles) y consume más recursos del hub.

Multitenencia y agrupación:

• Multitenencia verdadera: Los proveedores de servicios pueden habilitar el modo multitenencia en los controladores para alojar múltiples organizaciones lógicas con planos de control, administradores y políticas aislados en el mismo clúster de controladores.
• Segmentación por inquilino o unidad de negocio: Use VPNs de servicio para forzar la separación del tráfico, la fuga de rutas (route-leaking) donde sea necesario y políticas/QoS por VPN.
• Agrupación de dispositivos: Use grupos de dispositivos de vManage, listas de sitios, listas de VPN, listas de prefijos/TLOCs para aplicar políticas, actualizaciones y plantillas por función, región o rol.

Compromisos de diseño:

• Latencia vs. control de políticas: La malla completa minimiza la latencia pero complica la aplicación y observación de políticas; el modelo hub y spoke simplifica el control pero añade latencia a los flujos este-oeste.
• Resiliencia vs. escala operativa: Más TLOCs, transportes y hubs aumentan la disponibilidad y las opciones de ruta, pero multiplican las sesiones IPsec/BFD y la escala del control. Use la regionalización y la sumarización para mantener bajo control los tamaños de OMP y FIB.
• Diversidad del underlay vs. costo: Añadir banda ancha y LTE mejora la alcanzabilidad y la resistencia a caídas de rendimiento (brownouts); el costo, el comportamiento de NAT y el jitter variable pueden complicar los SLAs. Use clases de SLA derivadas de BFD y enrutamiento consciente de la aplicación para restringir el tráfico sensible.
• Riqueza de la política centralizada vs. opacidad en la solución de problemas: Las cadenas complejas de coincidencia/acción (match/action) proporcionan un control granular pero pueden ocultar la lógica de reenvío. Mantenga la política modular, versionada y bien documentada; pruébela en un fabric de preproducción.
• Seguridad vs. rendimiento: El uso obligatorio de IPsec en todos los transportes refuerza la confidencialidad, pero introduce una sobrecarga de CPU y consideraciones de MTU/fragmentación. Prefiera la aceleración criptográfica por hardware y un ajuste consistente de MSS/PMTUD.

Modos de fallo comunes y mitigaciones:

• Política asimétrica que impide la formación de túneles: Valide las políticas de TLOC y de control de forma simétrica; confirme las rutas TLOC de OMP.
• Expiración de los agujeros (pinholes) de NAT en UDP: Prefiera el control por TLS o configure keepalives de NAT; considere el uso de NAT estático para los controladores.
• Uso incorrecto del ID de sitio que colapsa los túneles dentro del sitio: Asegúrese de que los ID de sitio sean únicos para cada ubicación física; use políticas de restricción de color de BFD para la intención dentro del campus en lugar de forzar la fusión de sitios.
• Hubs con escasez de recursos para los spokes: Supervise la CPU/cripto del hub y el número de sesiones BFD; escale horizontalmente los hubs o introduzca hubs regionales; use QoS y policers para proteger el tráfico de control.

Escenario de un problema práctico

Apex Manufacturing se está expandiendo a AWS mientras opera 600 sucursales globales con transportes duales (MPLS y DIA). Necesitan extender la SD-WAN a AWS con una latencia mínima hacia las aplicaciones regionales, mantener el cumplimiento normativo usando TLS para el control y asegurar la alta disponibilidad (HA) de los controladores.

1. Ubicar dos orquestadores vBond en el espacio de IP públicas y tres controladores vSmart distribuidos en dos nubes.

• Justificación: vBond debe ser accesible públicamente para ayudar en el NAT traversal; múltiples instancias de vSmart proporcionan alta disponibilidad del plano de control y proximidad geográfica. vBond mantiene sesiones permanentes con vSmart y sesiones transitorias con los WAN Edges, acelerando la incorporación (onboarding) y la reconexión.

2. Convertir todas las conexiones de control a TLS y permitir el puerto TCP 12346 a través de los firewalls corporativos.

• Justificación: El DTLS por defecto puede ser bloqueado por dispositivos intermedios (middleboxes) estrictos. TLS asegura la alcanzabilidad del plano de control a través de proxies TCP y dominios de inspección sin sacrificar el cifrado o la integridad.

3. Desplegar vManage como un clúster de tres nodos en una región de nube central con copias de seguridad diarias.

• Justificación: El plano de gestión debe permanecer disponible para las operaciones de políticas, imágenes y telemetría. La clusterización preserva el estado y escala el acceso a la API/GUI; las copias de seguridad protegen contra la pérdida de datos operativos.

4. Usar Cloud OnRamp for IaaS para instanciar routers WAN Edge virtuales en AWS, uno por VPC, en subredes conectadas a un transit gateway.

• Justificación: Cloud OnRamp automatiza la suscripción a la AMI, el despliegue y la inscripción de certificados. Los dispositivos WAN Edge terminan los TLOCs de la SD-WAN y anuncian las rutas de la VPC a través de OMP, integrando las cargas de trabajo de la nube en el fabric con el mismo conjunto de políticas.

5. Asignar IPs de sistema de un bloque reservado del overlay e IDs de sitio únicos por región de nube (p. ej., 9001–9010), y establecer un nombre de organización consistente en todo el fabric.

• Justificación: Las IPs de sistema y los IDs de sitio únicos evitan la supresión de túneles y la ambigüedad en el plano de control. La uniformidad del nombre de la organización es obligatoria para las adyacencias OMP y la confianza de los certificados.

6. Configurar la VPN 0 para transportes duales en los edges de AWS (internet público y, cuando esté disponible, Direct Connect a través de un color privado) y habilitar BFD con clases de SLA para el enrutamiento consciente de la aplicación.

• Justificación: La diversidad de transportes mejora la alcanzabilidad y la resistencia a caídas de rendimiento (brownouts). BFD proporciona métricas de pérdida/latencia/jitter para dirigir el tráfico de aplicaciones hacia el TLOC con el mejor rendimiento según el SLA.

7. Exponer la VPN 512 solo a las subredes de gestión y restringir el enrutamiento hacia los controladores mediante rutas estáticas explícitas y ACLs.

• Justificación: Minimiza la superficie de ataque en el plano de gestión y evita fugas de rutas que podrían dejar dispositivos aislados o sobreexponer los servicios del controlador.

8. Implementar una topología de hub regional usando los edges de AWS como hubs para sus respectivas regiones, con hubs duales locales (on-prem) por continente para la conmutación por error (failover), y habilitar rutas directas a internet de spoke a spoke para el tráfico sensible a la latencia.

• Justificación: Los hubs regionales localizan los flujos para reducir la latencia y contener la escala del control; los hubs duales proporcionan redundancia. Los túneles directos controlados de spoke a spoke preservan la baja latencia para las aplicaciones en tiempo real sin sobrecargar los hubs.

9. Aplicar políticas de control centralizadas para sumarizar las rutas de las sucursales en los hubs regionales, restringir los anuncios de TLOCs a las regiones previstas y forzar la segmentación con VPNs de servicio para el tráfico de producción, OT e invitados.

• Justificación: La sumarización reduce la rotación de rutas (route churn) de OMP y el uso de memoria. Los anuncios de TLOCs con alcance limitado evitan la formación no intencionada de túneles entre regiones. La segmentación basada en VPN mantiene los límites de cumplimiento normativo con fuga de rutas (route-leaking) explícita solo donde es necesario.

10. Supervisar la salud de BFD y del plano de control; configurar alertas para la pérdida de un vSmart o vBond y preaprovisionar capacidad N+1.

• Justificación: La detección temprana de la degradación del control previene la inestabilidad generalizada. El N+1 asegura que el fabric pueda soportar un fallo de controlador sin agotamiento de sesiones

Todos los dominios · Incorporación de controladores →

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