Cisco 300-415: Operaciones, monitoreo y resolución de problemas — 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

Las operaciones, la monitorización y la resolución de problemas en Cisco SD-WAN se centran en Cisco SD-WAN Manager (antes vManage), la capa de controladores (el orquestador vBond y los controladores vSmart), los routers WAN Edge (p. ej., las series ISR 4000 y ASR 1000 con IOS XE SD-WAN) y los overlays de datos y de control que forman. El plano de control, impulsado por vSmart, construye y mantiene la topología y las políticas a través de OMP y distribuye las claves criptográficas entre los edges. Los dispositivos WAN Edge forman conexiones de control DTLS por defecto (o TLS si es obligatorio), coordinan la conectividad inicial a través de vBond (que debe ser accesible en el espacio de IP públicas para el NAT traversal) y establecen túneles de plano de datos IPsec. Una higiene operativa sólida utiliza telemetría enriquecida, runbooks fijos, control de cambios y API automatizadas para mantener la garantía de los SLA y reducir el tiempo medio de reparación (MTTR).

Monitorización, paneles de control y salud

• Paneles de control (Dashboards): Cisco SD-WAN Manager proporciona vistas en tiempo real e históricas de la salud del sitio, el estado de los dispositivos, las conexiones de control, el SLA de los túneles, la experiencia de las aplicaciones y el cumplimiento de las políticas. Los widgets por defecto destacan las conexiones de control (alcanzabilidad de vBond/vSmart/vManage), el cumplimiento del SLA del enrutamiento basado en aplicaciones (app-aware routing) y la utilización de las interfaces. Las vistas detalladas (drill-downs) correlacionan alarmas, eventos y estadísticas por dispositivo o sitio.
• Alarmas y eventos: La plataforma genera alarmas sobre cambios en la alcanzabilidad de los controladores, el estado de la sesión OMP, fallos de certificados, reinicios de dispositivos, discrepancias en las políticas y degradación del rendimiento (pérdida/latencia/jitter por encima del SLA). Los eventos incluyen códigos detallados como DCONFAIL para fallos en la conexión de control y discrepancias explícitas en el nombre de la organización durante el onboarding. Las alarmas admiten acuse de recibo, borrado y reenvío (correo electrónico/SNMP/syslog) a sistemas de operaciones centrales.
• Salud del dispositivo: Las puntuaciones de salud combinan indicadores del plano de control y de datos con el uso de CPU, memoria, registros de fallos (crash logs) y errores de interfaz. La salud de los WAN Edge debe tener una línea base establecida (baselined); los umbrales deben ajustarse para evitar la fatiga por alarmas. La sincronización horaria (NTP) es crítica; el desfase del reloj (clock skew) es una causa raíz común de fallos en la validación de certificados y de datos de tendencia engañosos.
• vAnalytics y planificación de capacidad: vAnalytics añade visibilidad profunda de las aplicaciones (clasificación basada en NBAR2 desde cflowd), líneas base de calidad de la ruta y previsiones de capacidad. Destaca los principales generadores de tráfico (top talkers), las contribuciones al tiempo de respuesta de las aplicaciones (red frente a servidor) y las ventanas de saturación de interfaz proyectadas. Para la planificación de capacidad, utilice el percentil 95 del rendimiento (throughput) en ventanas móviles de 30 días y correlaciónelo con las violaciones del SLA de los túneles; evalúe dónde un ancho de banda adicional o ajustes de políticas (QoS/AAR) producen el mejor retorno del SLA.
• Experiencia de la aplicación: Los paneles de aplicaciones vinculan los flujos con el rendimiento del túnel y el tratamiento de QoS. Si una aplicación crítica tiene un rendimiento inferior en una ruta con jitter creciente, confirme si el enrutamiento basado en aplicaciones (app-aware routing) está respetando el SLA y si las políticas de encolamiento se alinean con las marcas DSCP de extremo a extremo.

Telemetría, Syslog, SNMP y exportación de cflowd

• Telemetría por streaming: Cisco SD-WAN Manager consume telemetría basada en modelos (model-driven telemetry) de los controladores y los edges para obtener métricas de control, de interfaz y de la plataforma. El streaming reduce la sobrecarga de las consultas (polling) y aumenta la granularidad en comparación con el sondeo SNMP tradicional. Para análisis externos, IOS XE SD-WAN admite telemetría basada en modelos de tipo dial-out hacia colectores gRPC; dimensione cuidadosamente los colectores y las tasas de muestreo para evitar sobrecarga en las sucursales.
• Syslog: Los edges y los controladores pueden exportar syslog a colectores centralizados. Reenvíe los eventos significativos (p. ej., reconvergencia del control, actualizaciones de políticas OMP, regeneración de claves IPsec, fallos del sistema). Utilice syslog estructurado para un mejor análisis (parsing). Limite la tasa y filtre para mantener el rendimiento de los colectores.
• SNMP: Utilice SNMPv3 para el sondeo seguro de interfaces, CPU, memoria y sensores ambientales. Se pueden habilitar las trampas (traps) SNMP para alarmas clave (caída del control, caída de BFD, CPU alta). SNMP por sí solo es insuficiente para la telemetría de aplicaciones moderna, pero sigue siendo valioso para la integración con herramientas NMS existentes.
• cflowd (exportación de flujos basada en aplicaciones): Cisco SD-WAN utiliza cflowd (similar a NetFlow/IPFIX) para exportar registros por flujo que incluyen el ID de la aplicación (NBAR2), DSCP, bytes/paquetes, flags de TCP y metadatos de rendimiento como el tiempo de ida y vuelta (round-trip time), la pérdida y el jitter. La exportación puede dirigirse a Cisco SD-WAN Manager/vAnalytics y a colectores externos. Equilibre la visibilidad y la sobrecarga ajustando el muestreo, los tiempos de espera para flujos activos/inactivos y los destinos de exportación. Una exportación excesiva en plataformas de gama baja puede afectar a la CPU; prefiera los análisis en el lado del controlador cuando sea factible.

Resolución de problemas de control, OMP, BFD y túneles

Un flujo de trabajo consistente reduce rápidamente el dominio de la falla:

1. Establecer el alcance y la capa

• ¿Es solo en el plano de control, el plano de datos o la capa de aplicación?
• Use los dashboards de sitios y dispositivos en SD-WAN Manager para ver si están afectados múltiples dispositivos, sitios o solo una ruta/color.

2. Validar las conexiones de control

• vBond debe ser alcanzable en su IP pública; por defecto, los controladores usan el puerto 12346 para DTLS/TLS.
• El transporte de control por defecto es DTLS; muchas políticas de centros de datos requieren TLS hacia los controladores. Asegúrese de que los dispositivos intermedios (middleboxes) permitan el protocolo seleccionado.
• Verifique la sincronización de tiempo y los certificados (cadena raíz, validez, alcanzabilidad de CRL/OCSP).
• Errores comunes:
  • DCONFAIL: Falla genérica de conexión de control; las causas raíz incluyen el puerto 12346 bloqueado, falla en el cruce de NAT (NAT traversal), rechazo de certificado o enrutamiento hacia los controladores.
  • Discrepancia de organización: El org-name integrado en las credenciales/configuración del dispositivo debe coincidir con el de los controladores; de lo contrario, las sesiones OMP no se formarán.

3. Verificar OMP y políticas

• OMP transporta rutas, TLOCs y cadenas de servicios (service-chains) entre vSmart y los dispositivos de borde (edges). Confirme la adyacencia OMP con todos los nodos vSmart del clúster para evitar un estado de control asimétrico.
• Valide las rutas recibidas/anunciadas y la aceptación de políticas. Una política puede filtrar inadvertidamente TLOCs o prefijos, creando un agujero negro (blackholing) de tráfico.
• Los TLOCs se definen por la system IP, el color y la encapsulación (GRE o IPsec). Las discrepancias de color o encapsulación entre pares impiden la formación de túneles en un transporte determinado.

4. Inspeccionar BFD y SLA

• BFD monitorea la pérdida, latencia y jitter por túnel y alimenta el enrutamiento basado en la aplicación (app-aware routing). El flapping o un jitter alto activan el desvío de tráfico (steering). Confirme que los temporizadores de BFD y las clases de SLA (SLA-classes) coincidan con la intención del diseño. Temporizadores demasiado agresivos en circuitos de baja calidad provocan conmutaciones por error (failovers) innecesarias.

5. Revisar IPsec/plano de datos

• Inspeccione las estadísticas del túnel, las SAs de IPsec, encaps/decaps, replay-drops y PMTU. Los problemas de NAT-T y los agujeros negros de PMTU son comunes, especialmente a través de banda ancha (broadband).
• Valide que el modelado de QoS (shaping) se alinee con el ancho de banda contratado; la sobresuscripción infla las lecturas de pérdida/jitter y engaña al AAR.

Comandos show útiles en los dispositivos de borde IOS XE SD-WAN:

show sdwan control connections
show sdwan omp peers | routes | tlocs
show sdwan bfd sessions
show sdwan ipsec inbound-connections outbound-connections
show platform hardware qfp active datapath utilization
show interfaces counters errors
show clock detail

Compensaciones y modos de falla:

• TLS vs DTLS: TLS puede ser requerido por la política de seguridad y atraviesa mejor los proxies estrictos; DTLS ofrece una menor sobrecarga en el handshake. Elija de manera consistente en toda la red (fabric).
• Sensibilidad de BFD: Temporizadores ajustados mejoran el tiempo de reacción, pero aumentan el uso de CPU y los falsos positivos en enlaces con ruido.
• Complejidad de las políticas: Las políticas centralizadas y ricas en funciones pueden desviarse de la intención original; prefiera objetos de política jerárquicos y bien comentados, y simule antes de desplegar.

Gestión del ciclo de vida, cumplimiento y automatización

• Planificación de la actualización de software:

  • Secuencia: Actualizar el clúster de SD-WAN Manager, luego vBond, después vSmart y finalmente los WAN Edges. Mantener la compatibilidad de versiones según las notas de la versión. Los controladores deben estar en buen estado y sincronizados antes de tocar los edges.
  • Repositorios de imágenes: Utilizar el repositorio de software de SD-WAN Manager para preparar las imágenes. Las imágenes de los controladores suelen utilizar los formatos .qcow2 o .ova; los edges utilizan paquetes IOS XE SD-WAN específicos de la plataforma.
  • Modo de mantenimiento: Poner un WAN Edge en modo de mantenimiento para drenar el tráfico de forma controlada. El dispositivo retira las rutas TLOCs/OMP para que las sesiones migren a rutas/sitios alternativos antes del reinicio, minimizando el impacto en el usuario.
  • Reversión (Rollback): Mantener preparada una imagen anterior probada. Si las comprobaciones posteriores fallan, revertir a la última versión funcional conocida (last-known-good). IOS XE SD-WAN admite instalaciones en doble banco y degradaciones (downgrade) dirigidas por el controlador.
  • Programación: Utilizar ventanas de cambio con comprobaciones previas (estado de control/OMP/BFD, CPU/memoria) y posteriores (SLA de aplicaciones, número de túneles, tasas de error).

• Cumplimiento y deriva de la configuración:

  • El estado deseado se define mediante plantillas de dispositivo. SD-WAN Manager resalta la deriva (drift) entre la configuración en ejecución y la plantilla; se remedia con flujos de trabajo de reconexión (reattach) o de aceptación de la deriva cuando esté justificado (p. ej., una corrección de emergencia por CLI).
  • Los registros de auditoría (audit trails) guardan quién cambió qué y cuándo (con alcance de RBAC). Combinar con un SIEM externo a través de syslog/webhooks para un historial inmutable.
  • Conjuntos de reglas de cumplimiento: Validar que el org-name, el esquema de IP del sistema, el uso de color, los cifrados IPsec, AAA y NTP se ajusten a los estándares.

• Operaciones e informes impulsados por API:

  • Las API REST /dataservice exponen puntos finales (endpoints) de monitorización, configuración y acción. Automatizar la generación de informes (tendencias de SLA, aplicaciones principales), actualizaciones masivas, incorporación de sitios y comprobaciones de cumplimiento.
  • Utilizar tokens y cuentas con alcance de RBAC. Implementar flujos de trabajo idempotentes y validaciones previas (pre-flight) antes de invocar cambios a escala.

• Triaje de rendimiento:

  • Comenzar con el SLA del túnel (pérdida, latencia, jitter), luego la CPU/memoria del dispositivo, y después las caídas/errores de interfaz y la profundidad de las colas. Correlacionar con los KPI de las aplicaciones obtenidos de cflowd.
  • Identificar si la degradación se debe a la calidad del enlace, a congestión/QoS o al lado del servidor, comparando la experiencia de varios sitios para la misma aplicación y ruta.
  • Señales de capacidad: Un aumento en la utilización del percentil 95, caídas de paquetes en colas prioritarias y cambios de ruta frecuentes de AAR indican la necesidad de modificar las políticas o el ancho de banda.

• Respuesta a incidentes, control de cambios y RCA:

  • Los runbooks definen las acciones de primera respuesta: tomar una instantánea de los estados de control/OMP/BFD, recopilar los registros relevantes/paquetes de soporte técnico y congelar los cambios no esenciales.
  • El control de cambios impone la revisión por pares para las actualizaciones de políticas y despliegues por fases con canarios (canaries).
  • El análisis de causa raíz (RCA) combina eventos del controlador (quién/cuándo), telemetría de flujo (qué tráfico) y métricas de ruta (dónde se degradó) para aislar el problema. Ejemplos: Desajuste de ORG después de un cambio de incorporación, un filtro de política no intencionado que elimina un TLOC, un agujero negro de PMTU en la banda ancha después de un cambio en el CPE del ISP.

Escenario de problema práctico

Contoso Health opera 150 clínicas conectadas a través de una SD-WAN de doble transporte (MPLS color mpls y banda ancha color biz-internet) utilizando WAN Edges ISR 4000. Después de una ventana de mantenimiento para migrar los controladores a un nuevo centro de datos, varios sitios informan de un rendimiento deficiente del EHR y de interrupciones intermitentes.

1. Comprobar el estado del plano de control en SD-WAN Manager

• Justificación: Si el control es inestable, todos los síntomas posteriores en el plano de datos y las políticas se derivan de ello. El panel de control muestra múltiples eventos DCONFAIL y desajustes de ORG durante la misma ventana, lo que indica inconsistencias en la incorporación después del traslado del controlador.

2. Validar la alcanzabilidad y los puertos del controlador

• Justificación: El nuevo centro de datos exige TLS hacia los controladores. Confirmar que los dispositivos intermedios (middleboxes) permiten TLS a los controladores en el puerto de control predeterminado 12346 y que vBond es accesible en una IP pública para el cruce de NAT (NAT traversal). Un puerto bloqueado en un firewall regional explica los fallos agrupados de los sitios.

3. Corregir el desajuste del nombre de la organización (organization-name)

• Justificación: Los edges que fallan en la autenticación mutua con los controladores debido a un desajuste del org-name no pueden formar OMP. Comparar el org-name de la plantilla del dispositivo con los certificados del controlador; actualizar las plantillas para que coincidan y volver a conectarlas (reattach). Esto restaura la adyacencia OMP con vSmart para los sitios afectados.

4. Reconciliar la hora y los certificados

• Justificación: El traslado del DC cambió la alcanzabilidad de NTP. Los relojes desfasados provocaron que algunas validaciones de certificados fallaran. Apuntar todos los edges y controladores a un NTP redundante y verificar la convergencia de los relojes para estabilizar la autenticación y las sesiones de control.

5. Verificar las rutas OMP, los TLOCs y la aceptación de políticas

• Justificación: La migración del controlador incluyó una refactorización de políticas. Usar

undefined

y la visualización de políticas para confirmar que los prefijos críticos y todos los TLOCs se aprenden y no se filtran. Una política de datos mal ordenada estaba descartando el tráfico del servidor EHR; reordenar y aplicar (commit) para restaurar la alcanzabilidad.

6. Evaluar el comportamiento de BFD/SLA y AAR

• Justificación: La lentitud del EHR puede reflejar la calidad de la ruta. BFD muestra un aumento del jitter en la banda ancha; AAR está cambiando constantemente entre rutas (flapping). Aumentar la histéresis en la clase de SLA y asegurar que QoS priorice los flujos de EHR basados en DSCP. Esto reduce los cambios de ruta innecesarios.

7. Realizar una actualización de software dirigida con modo de mantenimiento

• Justificación: Un error conocido (bug) en la versión actual de IOS XE SD-WAN informa incorrectamente y de forma intermitente sobre el jitter en biz-internet. Preparar la corrección recomendada en el repositorio de software. Poner un subconjunto de edges en modo de mantenimiento, actualizar, validar las comprobaciones posteriores y luego desplegar de forma general. Mantener preparada la imagen de reversión (rollback).

8. Automatizar la verificación y los informes a través de la API

• Justificación: Usar las API /dataservice para exportar informes posteriores al incidente sobre el cumplimiento de SLA, el rendimiento de las aplicaciones y la estabilidad del control en todas las clínicas. La automatización garantiza una verificación consistente y genera un registro auditable para el control de cambios.

9. Documentar el RCA y reforzar los controles

• Justificación: Las causas raíz fueron la omisión de una regla de firewall en el puerto de control 12346, la deriva del org-name en las plantillas y una mala configuración de NTP, agravado por un problema de ordenación de políticas. Actualizar los runbooks de incorporación, imponer la validación previa al cambio basada en API (alcanzabilidad del controlador, comprobaciones de org-name, estado de NTP) y exigir simulaciones de políticas antes de aplicarlas (commit) para evitar que se repita.

← Integración con la nube · Todos los dominios

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