Cisco 300-415: Incorporación de controladores, certificados y conectividad de control segura — 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.

Descripción general

Cisco SD-WAN utiliza un plano de control respaldado por certificados para incorporar de forma segura los controladores y los dispositivos WAN Edge, atravesar los límites de NAT y mantener conexiones de control cifradas. Un diseño correcto de la función del orquestador vBond, del ciclo de vida de los certificados, del inventario de dispositivos y de la estrategia de NAT garantiza una incorporación predecible y un control resiliente. Los equipos de operaciones deben reconocer los estados y las alarmas de las conexiones de control y tener un plan de recuperación para fallos de certificados o de conectividad.

Orquestación y conectividad de control segura

El orquestador vBond es el primer punto de contacto del plano de control para cada WAN Edge. Realiza tres funciones críticas:

• Admisión y verificación de identidad: valida la identidad del dispositivo (número de serie/chasis contra la lista autorizada) y exige la coincidencia del nombre de la organización (organization-name).
• Descubrimiento de NAT y rendezvous: aprende la tupla de dirección-puerto pública/privada y el tipo de NAT de cada par, y luego informa a ambas partes para que puedan formar conexiones de control directas.
• Intercambio de conectividad inicial: proporciona al WAN Edge las direcciones accesibles de los controladores vSmart y vManage para que pueda construir canales de control persistentes.

Propiedades y comportamientos clave:

• Accesibilidad por IP pública: vBond debe residir en una IP pública (preferible) o detrás de un NAT estático 1:1 con mapeos de entrada consistentes. Esto garantiza que pueda ser alcanzado por dispositivos en entornos NAT desconocidos o restrictivos.
• Peering persistente con controladores: vBond mantiene conexiones permanentes con los controladores vSmart para tener siempre información de rendezvous actualizada.
• No está en la ruta de datos: Después de facilitar el intercambio inicial, vBond sale del flujo; el control continuo es directamente entre los WAN Edges y vSmart/vManage.

Transporte y puertos DTLS/TLS:

• El protocolo por defecto para las conexiones del plano de control es DTLS sobre UDP 12346. TLS sobre TCP 23456 está disponible y a menudo se prefiere en centros de datos donde la inspección/proxy de TCP es estándar.
• vBond utiliza el puerto 12346 por defecto cuando se usan certificados de controlador y no se ha configurado un puerto alternativo.
• Permitir tráfico de salida y de retorno para:
  • UDP 12346 (plano de control DTLS)
  • TCP 23456 (plano de control TLS)
• El plano de datos IPsec NAT-T utiliza UDP 4500 y es independiente de las elecciones del plano de control.

Consideraciones sobre NAT:

• Los NAT de tipo full-cone y restricted suelen funcionar con DTLS hole punching; el NAT simétrico es el más desafiante. Si ambos extremos están detrás de un NAT simétrico, utilice TLS (TCP 23456), cambie la política de salida para preservar los mapeos de puertos o asegúrese de que uno de los lados tenga un NAT público/restricted.
• Un vBond detrás de NAT requiere un mapeo estático 1:1 para 12346/UDP (y 23456/TCP si se usa TLS). No se soporta PAT dinámico en vBond.
• Los enlaces NAT obsoletos (stale) pueden provocar la caída de los túneles de control. Ajuste los keepalives y asegure interfaces de egreso consistentes en la VPN 0.

Consejos de diseño:

• Ubique al menos dos instancias de vBond en regiones públicas distintas para mayor resiliencia.
• Prefiera TLS en entornos con controles de egreso estrictos o con limitación generalizada de UDP; asegure una postura consistente en todos los controladores y WAN Edges.

Identidad, certificados y validación de la organización

Todos los controladores y dispositivos WAN Edge deben presentar certificados que encadenen a la misma raíz de confianza (root), y el nombre de la organización (organization-name) debe coincidir en toda la red superpuesta (overlay).

Roles y fuentes de los certificados:

• Controladores (vManage, vSmart, vBond): Solicitan e instalan certificados de controlador firmados por la raíz elegida (CA empresarial o CA pública). vManage orquesta su ciclo de vida.
• Identidad del WAN Edge:
  • Hardware vEdge: se entrega con un certificado instalado de fábrica.
  • IOS XE SD-WAN (cEdge): utiliza Cisco SUDI para la identidad PnP; luego obtiene un certificado de controlador firmado por la misma raíz que utilizan los controladores.
• Controladores alojados en la nube: Se entregan con certificados firmados por el proveedor y una cadena de confianza conocida. Los WAN Edges deben confiar en esta cadena; si los anclajes de confianza (trust anchors) no coinciden, es necesario reemitir los certificados de control de los dispositivos para alinearlos con la CA de la nube.

Fases del ciclo de vida:

• Inscripción (Enrollment): Los CSR de los controladores se generan en vManage y son firmados por la CA seleccionada; los WAN Edges se inscriben automáticamente durante ZTP/PnP o mediante un bootstrap manual.
• Validación: Durante el handshake, los pares validan la cadena de certificados, la caducidad, el estado de revocación (si está configurado) y el nombre de la organización (organization-name).
• Renovación y revocación: vManage supervisa la caducidad y puede renovar los certificados. Los dispositivos comprometidos o retirados deben tener sus certificados revocados; elimínelos de la lista de series autorizadas para evitar que se reincorporen.

Fallos de validación comunes:

• Discrepancia en el organization-name: Fallan las conexiones de control; el estado indica una discrepancia en el nombre de la organización o que el certificado no está verificado.
• Cadenas de confianza mixtas: Los controladores y los edges firmados por raíces diferentes no pueden formar sesiones de control.
• Desfase horario (Time skew): Los certificados aparecen como aún no válidos o caducados; es obligatorio el uso de NTP en la VPN 0.
• Problemas de FQDN/SAN (TLS): Si se fuerza el uso de TLS y la validación de FQDN está habilitada, las discrepancias en SAN/CN provocarán un fallo en la conexión.

Incorporación de Dispositivos, PnP/ZTP y Controles de Inventario

La incorporación es la combinación de la validación de la identidad del dispositivo, el aprovisionamiento sin intervención (zero-touch provisioning) y la conectividad de control automática basada en certificados.

Inventario y autorización:

• Lista de series autorizadas: vManage almacena la lista de dispositivos WAN Edge permitidos. Se puede poblar mediante la sincronización con la Smart Account o cargando manualmente el archivo de números de serie autorizados en vManage cuando no se utiliza la sincronización con la Smart Account (Smart Account Sync).
• Número de serie vs. número de chasis: Ambos se utilizan para identificar de forma única y prevenir la suplantación de identidad (spoofing). Pueden requerirse tokens para vEdge durante la incorporación manual.

Flujos sin intervención (zero-touch):

• ZTP de vEdge: El dispositivo utiliza un perfil de fábrica para alcanzar el servicio ZTP, aprende cuál es el orquestador vBond e inicia una conexión DTLS/TLS hacia vBond para la verificación de identidad y el encuentro (rendezvous). Luego, establece conexiones de control habilitadas para OMP con vSmart y conectividad de gestión con vManage.
• PnP de IOS XE SD-WAN (cEdge): El dispositivo utiliza SUDI para autenticarse con Cisco Plug and Play sobre HTTPS, que devuelve la información de accesibilidad del controlador. Alternativamente, se puede usar PnP on-prem a través de la opción 43 de DHCP/DNS o un arranque inicial (bootstrap) de día 0 por USB. Tras la admisión por parte de vBond, el dispositivo es redirigido a vManage para la asignación de plantillas (template attachment).
• Una vez que las conexiones de control están activas, vManage envía las plantillas (templates) y vSmart comienza el peering OMP para distribuir rutas, políticas y claves criptográficas.

Puntos de control operativos:

• Asegurarse de que el organization-name en la configuración del sistema coincida exactamente con el del overlay.
• Verificar el enrutamiento IP de la VPN 0, el DNS (si se usan FQDN) y el NTP.
• Abrir los puertos requeridos hacia vBond/vSmart/vManage y permitir los flujos de retorno.

Una designación mínima de vBond en el orquestador:

system
 vbond 203.0.113.10 local
 organization MyCompany

Operaciones: Estados, Alarmas, Verificación y Recuperación

Controlar los estados y alarmas de la conexión de control:

• Estados típicos: down (caído), connecting/handshake (conectando/negociando), authenticated (autenticado), up (activo). Los fallos pueden mostrar error de certificado, discrepancia de organización, sin respuesta o fallo de NAT.
• Las alarmas comunes de vManage incluyen: Control Connection Down, OMP Peer Down, Certificate Expiring/Expired, Device Not in Authorized List y Organization Mismatch.

Comandos de verificación (IOS XE SD-WAN):

show sdwan control connections
show sdwan control local-properties
show sdwan omp peers
show sdwan certificate status
show sdwan software

Comandos de verificación (vEdge):

show control connections
show control local-properties
show omp peers
show certificate installed

Flujo de trabajo de resolución de problemas y recuperación:

• Identidad y org-name:
  • Confirmar que el dispositivo aparece en el inventario de vManage con el número de serie/chasis correcto.
  • Verificar el organization-name del sistema en todos los nodos.
• Hora y confianza:
  • Asegurar la alcanzabilidad de NTP en la VPN 0; volver a comprobar las fechas de validez del certificado.
  • Validar la cadena de certificados en los controladores y los edges; reemitir si las raíces difieren.
• Conectividad y NAT:
  • Confirmar la alcanzabilidad hacia vBond en UDP 12346 y TCP 23456 desde la salida del WAN Edge.
  • Si un NAT simétrico impide DTLS, forzar TLS o ajustar la política de salida para fijar los mapeos salientes.
• Reinscripción y renovación:
  • Si el certificado de un dispositivo está corrupto/caducado, revocarlo en vManage, eliminarlo de la lista autorizada, volver a añadirlo y activar la reinscripción (PnP/ZTP o instalación manual).
  • Para migraciones alojadas en la nube, alinear los anclajes de confianza (trust anchors) reemitiendo los certificados del controlador y del WAN Edge a la CA de la nube, y luego reiniciar las conexiones de control.
• Higiene operativa:
  • Mantener los clústeres de controladores en buen estado (p. ej., clúster de vManage para escalar).
  • Mantener un DNS consistente para el direccionamiento de controladores basado en FQDN; actualizar los SAN al renombrar o cambiar la IP de los controladores.

Compensaciones de NAT y puertos:

• DTLS (UDP) ofrece una menor sobrecarga y a menudo un mejor rendimiento, pero es sensible a la limitación de velocidad de UDP y al NAT simétrico. TLS (TCP) facilita el paso a través de firewalls estrictos a costa de un posible bloqueo de cabecera de línea (head-of-line blocking).
• vBond debe permanecer altamente alcanzable; comprometer su alcanzabilidad pública o sus mapeos de entrada es una causa raíz frecuente de los fallos de incorporación (onboarding).

Escenario de un Problema Práctico

Acme Retail Corp. está incorporando 600 sucursales, muchas de ellas detrás de NATs simétricos gestionados por el ISP, a una nueva red troncal (fabric) de Cisco SD-WAN. Los pilotos iniciales muestran un establecimiento intermitente del plano de control y fallos frecuentes de DTLS.

Enfoque:

1. Desplegar orquestadores vBond públicos y redundantes

   • Rationale: Ubicar dos instancias de vBond en IPs públicas distintas (regiones/ISPs separados) maximiza la alcanzabilidad inicial y acelera el descubrimiento de NAT. El direccionamiento público evita la ambigüedad introducida por los NAT del proveedor y soporta un tráfico de retorno predecible.

2. Forzar TLS para el plano de control en regiones con alto uso de NAT

   • Rationale: Las sucursales con NATs simétricos tienen dificultades con el UDP hole punching. TLS sobre TCP 23456 proporciona un paso estable a través de firewalls con estado (stateful) y CGN del ISP, reduciendo las intermitencias (flaps) relacionadas con DTLS sin afectar a OMP o a la distribución de claves.

3. Estandarizar el organization-name y los anclajes de confianza del controlador

   • Rationale: Alinear todos los controladores y WAN Edges con la misma CA raíz (la PKI empresarial seleccionada por Acme). Configurar el organization-name del sistema de forma idéntica en vManage, vSmart, vBond y en todas las plantillas de dispositivos para evitar rechazos por discrepancia de organización.

4. Precargar la lista de números de serie autorizados en vManage y automatizar PnP/ZTP

   • Rationale: Importar el inventario completo de dispositivos mediante la sincronización con Smart Account para asegurar que cada dispositivo supere las comprobaciones de identidad en vBond. Para cEdge, usar Cisco PnP con SUDI; para el hardware vEdge, asegurar que los tokens y números de serie estén presentes. Esto elimina errores manuales y acelera la puesta en marcha.

5. Reforzar la alcanzabilidad y la sincronización de tiempo en la VPN 0

   • Rationale: Definir rutas por defecto/DNS consistentes en la VPN 0 y apuntar el NTP a servidores públicos o corporativos alcanzables desde cada sucursal. Una hora correcta previene errores de certificado “aún no válido/caducado” que paralizan las negociaciones TLS.

6. Normalizar las reglas de firewall y el comportamiento de NAT

   • Rationale: Publicar una política de salida de sucursal que permita el tráfico saliente por TCP 23456 y UDP 12346 hacia las IPs de vBond/vSmart/vManage con mapeos de larga duración. Donde el ISP imponga un NAT simétrico, asegurar que al menos una ruta de controlador soporte el paso por TCP.

7. Instrumentar las operaciones con verificaciones y alarmas específicas

   • Rationale: Integrar las comprobaciones show sdwan control connections y show sdwan certificate status en el script del Día 1. En vManage, suscribirse a las alarmas de Control Connection Down y Certificate Expiring. Esto saca a la luz rápidamente los sitios mal configurados y avisa de las renovaciones antes de que caduquen.

8. Establecer un manual de operaciones (runbook) de recuperación para fallos de certificado o conectividad

   • Rationale: Definir los pasos para revocar/reemitir certificados de dispositivo en vManage, volver a cargar los números de serie si es necesario y alternar entre DTLS/TLS como mitigación. Incluir procedimientos para rotar los certificados de los controladores sin impacto en el servicio y para conmutar por error (fail over) entre instancias de vBond. Esto minimiza el MTTR durante los despliegues masivos.

Al combinar un vBond públicamente alcanzable, un plano de control TLS donde el NAT es restrictivo, una gestión de identidad rigurosa y barreras de protección operativas, Acme Retail logra una incorporación determinista a escala, preservando al mismo tiempo la seguridad y la resiliencia del plano de control de SD-WAN.

← Arquitectura y planos de la estructura de Cisco SD-WAN · Todos los dominios · OMP →

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