Cisco 300-415: Túneles del plano de datos, BFD y enrutamiento basado en aplicaciones — 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 separa el plano de control del plano de datos y construye una superposición (overlay) cifrada y dirigida por políticas sobre transportes dispares. El controlador vSmart gestiona el plano de control de la superposición y la conectividad de los WAN Edge, distribuyendo rutas, claves de seguridad e intenciones a través de OMP. Los routers WAN Edge forman túneles de plano de datos IPsec seguros hacia otros WAN Edges, mientras que las conexiones de control a vSmart, vBond y vManage usan DTLS por defecto (o TLS). La vitalidad y la calidad de la ruta se miden continuamente con BFD, que alimenta las políticas de Application-Aware Routing (AAR) para dirigir las aplicaciones por los túneles con mejor rendimiento según las clases de SLA basadas en pérdida, latencia, jitter o MOS.

Fundamentos de la superposición y el plano de datos

• Plano de control frente a plano de datos

  • Plano de control: Los WAN Edges establecen conexiones de control DTLS/TLS seguras con vBond (para la traducción de NAT y la orquestación), vSmart (para el intercambio de políticas y rutas a través de OMP) y vManage (para la gestión, configuración de dispositivos y almacenamiento de certificados). En el estado de preparación (staging), los dispositivos forman conexiones de control pero no establecen túneles de datos.
  • Plano de datos: Los WAN Edges forman túneles IPsec directamente hacia otros WAN Edges para el tráfico de usuario. El plano de datos es responsable del reenvío y aplica las decisiones de ingeniería de tráfico comunicadas a través de las políticas del plano de control.

• Túneles de plano de datos IPsec y TLOCs

  • Un Transport Locator (TLOC) identifica de forma única una conexión de transporte WAN y se define por la tupla {system-IP, color, encapsulation}. La encapsulación es IPsec o GRE; en la mayoría de las implementaciones y en IOS XE SD-WAN (cEdge), se utiliza IPsec.
  • Los colors (colores) son etiquetas semánticas para los tipos de underlay y las propiedades de NAT (por ejemplo, mpls, biz-internet, public-internet, lte, private1–private6). Los colors públicos suelen implicar la traducción de NAT con la ayuda de vBond.
  • Se forman túneles entre cada par de TLOCs alcanzables, a menos que se restrinja. Con dos sitios, cada uno con un WAN Edge y dos TLOCs públicos, y sin atributos restrict, se forman cuatro túneles IPsec (malla completa entre pares de colors).
  • La extensión de TLOC permite que dos WAN Edges redundantes en un sitio compartan transportes a través de un enlace cruzado (cross-link), lo que permite la redundancia de transporte sin duplicar los circuitos físicos por chasis.

• Etiquetas de transporte y de servicio

  • vSmart utiliza OMP para anunciar rutas y TLOCs y para asignar etiquetas que se transportan en la cabecera de la superposición (overlay). Las etiquetas de transporte identifican los TLOCs remotos para demultiplexar el tráfico a través de la superposición. Las etiquetas de servicio identifican la VPN de servicio de destino o un servicio encadenado (chained service). Estas etiquetas son internas de la superposición SD-WAN y no son etiquetas del underlay MPLS.

• Compromisos operativos y modos de fallo

  • El uso de colors incorrectos en los transportes (por ejemplo, marcar MPLS como public-internet) puede causar una formación de túneles subóptima o fallos en la traducción de NAT.
  • El atributo restrict evita el crecimiento no deseado de la malla completa; omitirlo en los colors de internet puede llevar a una escala de túneles excesiva y a una sobrecarga de sondeo innecesaria.
  • Problemas con los certificados o la hora del reloj impiden la conectividad del plano de control (DTLS/TLS). Sin la convergencia del plano de control con vSmart, no se intercambian claves del plano de datos y los túneles IPsec no se forman.

Medición de la vitalidad y calidad de la ruta con BFD

• Funcionamiento de BFD

  • Cisco SD-WAN ejecuta BFD en cada túnel del plano de datos para proporcionar detección de vitalidad (liveness) y medición de calidad casi en tiempo real. BFD utiliza hellos periódicos y ligeros para detectar el estado activo/inactivo (up/down) (apagones o blackouts) y sondeos activos para medir la latencia, el jitter y la pérdida (degradaciones o brownouts).
  • Temporizadores e intervalos clave
    • Intervalo de hello: comúnmente 1000 ms (configurable por color o globalmente).
    • Multiplicador: comúnmente 6 (configurable), lo que resulta en un tiempo de detección de intervalo de hello × multiplicador (por ejemplo, ~6 segundos).
    • Intervalo de sondeo de aplicación (app-probe) para el muestreo de rendimiento de AAR: típicamente 1 segundo (configurable), con promedios móviles calculados sobre una ventana corta para suavizar los picos transitorios.
  • Métricas de BFD
    • Latencia: tiempo de ida y vuelta (round-trip time) de los sondeos en cada túnel.
    • Jitter: variación en la latencia entre sondeos.
    • Pérdida: porcentaje de sondeos no devueltos.
    • MOS: derivado de la latencia, el jitter y la pérdida para evaluar la idoneidad para la voz.

• Manejo de brownouts frente a blackouts

  • Blackout (apagón): una sesión BFD caída (sin conectividad) desencadena la eliminación inmediata de la ruta para el reenvío. El tráfico se desvía según la preferencia del siguiente túnel disponible sin esperar la evaluación de AAR.
  • Brownout (degradación): la sesión BFD permanece activa, pero las métricas medidas violan los umbrales del SLA. AAR puede dirigir flujos de aplicaciones específicos a túneles alternativos que cumplan con los SLAs, incluso mientras el túnel original continúa transportando otro tráfico.

• Guía de diseño y compromisos

  • Temporizadores agresivos aceleran la conmutación por error (failover), pero aumentan la sobrecarga de CPU y ancho de banda, especialmente en mallas grandes. Equilibre los intervalos de hello y de sondeo en función de la escala y la estabilidad del transporte.
  • Las características de ruta asimétricas (por ejemplo, satélite o celular) exigen umbrales de SLA más relajados y multiplicadores potencialmente más altos para evitar la inestabilidad (flapping).
  • Para aplicaciones de voz e interactivas, prefiera intervalos de sondeo de aplicación (app-probe) más rápidos y habilite la histéresis/hold-down para reducir la oscilación durante la congestión transitoria.

Enrutamiento consciente de la aplicación: Diseño de políticas y SLA

• Identificación y clasificación de aplicaciones

  • Los WAN Edges utilizan DPI (NBAR2 en IOS XE SD-WAN) para clasificar aplicaciones por firmas, heurísticas de protocolo y, donde estén disponibles, metadatos como TLS SNI y QUIC ALPN. Para el tráfico cifrado sin metadatos identificables, el motor recurre a los atributos del flujo (tupla de 5 elementos) y a mapeos configurados (puertos, DSCP).
  • La clasificación generalmente ocurre en los primeros paquetes y se almacena en caché para la consistencia de la sesión. Mantenga las firmas actualizadas para conservar la precisión.

• Clases de SLA y política de medición

  • Defina clases de SLA con umbrales de pérdida, latencia, jitter y, opcionalmente, MOS. Cada clase de SLA hace referencia a un perfil de sondeo de rendimiento (app-probe) que controla el intervalo de muestreo y el comportamiento de suavizado de BFD.
  • Ejemplos típicos de SLA:
    • Voz: latencia ≤ 150 ms, jitter ≤ 30 ms, pérdida ≤ 1 %, MOS ≥ 4.0.
    • Transaccional: latencia ≤ 200 ms, pérdida ≤ 1 %.
    • Masivo: sin SLA estricto; prefiere rutas de mayor ancho de banda y menor costo.

• Comportamiento de la preferencia de ruta

  • La política de AAR vincula las listas de aplicaciones a las clases de SLA y especifica un preferred-color y un backup-color (o listas de TLOC). La lógica de decisión es:
    1. Si la ruta preferida cumple con el SLA, se envía el tráfico por la ruta preferida.
    2. Si la preferida viola el SLA pero la de respaldo lo cumple, se dirige el tráfico a la de respaldo.
    3. Si ninguna ruta cumple con el SLA, se utiliza la mejor ruta disponible por preferencia o costo (degradación controlada).
  • La dirección del tráfico en condiciones de brownout es por flujo; los flujos existentes pueden moverse dependiendo de la política (la dirección de nuevos flujos es el comportamiento predeterminado; el movimiento a mitad de flujo puede estar restringido para TCP a menos que se diseñe la resiliencia de la sesión).

• Elementos de construcción de políticas

  • Construya listas de aplicaciones (grupos de DPI), clases de SLA (pérdida/latencia/jitter/MOS) y listas de TLOC (colors) en vManage. Luego, cree una secuencia de política de AAR que mapee lista de aplicaciones → clase de SLA → colores preferidos/de respaldo.
  • Combine con políticas de datos de tráfico si necesita establecer DSCP, aplicar zonas o insertar encadenamiento de servicios (service chaining) antes de las decisiones de AAR.
  • Use la política de control (control-policy) por separado para influir en la aceptación/anuncio de rutas; no confunda AAR (data-policy) con la política de control (control-policy). Las listas de sitios definen el ámbito donde se aplica el AAR.

• Compromisos de diseño

  • Unos SLA demasiado estrictos pueden causar oscilación. Introduzca histéresis o temporizadores de penalización para evitar cambios de ruta frecuentes.
  • Considere el costo: coloque las rutas celulares con medición de consumo solo como respaldos de último recurso; habilite límites de datos donde estén disponibles.
  • Coordine con QoS: el AAR elige la ruta; el QoS por ruta y el encolamiento deben seguir protegiendo las clases críticas durante la congestión.

Verificación y resolución de problemas

• Comprobaciones rápidas de estado

  • Plano de control:
    • cEdge: show sdwan control connections
    • vEdge: show control connections
  • Túneles del plano de datos:
    • cEdge: show sdwan tunnels
    • vEdge: show ipsec outbound-connections / show ipsec inbound-connections
  • Sesiones BFD y calidad:
    • cEdge: show sdwan bfd sessions; show sdwan app-route stats
    • vEdge: show bfd sessions; show app-route stats

• Fragmentos de comandos de ejemplo

  show sdwan tunnels
  show sdwan bfd sessions
  show sdwan app-route stats sla-class <name>
  show sdwan app-route statistics flows
  show sdwan omp tlocs

  show control connections
  show omp routes | include <prefix>
  show ipsec sa detail

• Qué buscar

  • El estado del túnel es up, pero la pérdida/latencia/jitter de BFD excede el SLA: brownout—se espera un desvío por AAR. Valide que la ruta de respaldo cumpla con el SLA y que la política se vincule a la lista de aplicaciones correcta.
  • Flapping en la sesión BFD: reduzca la agresividad o investigue caídas/colas en el underlay; verifique el MTU y la fragmentación (manejo del DF-bit) para evitar la pérdida de sondeos.
  • No se forman túneles sobre un color: verifique la semántica de color (NAT/público/privado), la configuración de NAT en la interfaz y que vBond sea accesible para el NAT traversal. Confirme la hora y los certificados si no hay conexiones de control.
  • Escala de full-mesh y sondeos inesperada: aplique restrict en los colors de internet o use listas de TLOC para limitar el alcance de la conectividad.
  • Clasificación incorrecta de DPI: actualice las firmas de NBAR2 y confirme que no haya anulaciones de puertos L4 en conflicto. Para aplicaciones cifradas, considere la clasificación basada en SNI/ALPN o el marcado DSCP upstream.

• Razonamiento operativo

  • Valide siempre primero la conectividad del plano de control (vBond para orquestación/NAT, vSmart para OMP/políticas, vManage para configuración/certificados). Sin vSmart, las claves del plano de datos no se distribuyen y no se forma ninguna SA de IPsec.
  • Correlacione las decisiones de AAR con las mediciones de BFD y las clases de SLA. Si se selecciona una ruta contraria a lo esperado, inspeccione el estado de cumplimiento del SLA en el momento de la decisión, no solo los promedios actuales.
  • Para diseños con doble DC, evite rutas LAN duplicadas armonizando el AS del overlay en los WAN Edges del DC al redistribuir OMP↔BGP a través de una interconexión de DC.

Escenario de problema práctico

Contoso Health opera 300 clínicas con transportes duales en cada sitio: MPLS (mpls color) y banda ancha (biz-internet color). Los usuarios reportan mala calidad de voz intermitente, mientras que las aplicaciones de datos funcionan bien. El objetivo es preferir MPLS para la voz, conmutar por error a la banda ancha durante los brownouts y garantizar una conmutación por error rápida en caso de blackout sin oscilaciones.

1. Validar el estado del overlay y la formación del plano de datos

• Justificación: Confirmar los prerrequisitos. Use show sdwan control connections para asegurar que DTLS/TLS hacia vSmart/vBond/vManage esté estable y show sdwan tunnels para verificar una malla completa de túneles MPLS y de banda ancha. Si faltan túneles sobre biz-internet, revise la asignación de color y el NAT; vBond debe ser accesible en el espacio público para ayudar en el NAT traversal.

2. Calibrar los temporizadores de BFD y de sondeo

• Justificación: Establezca el hello de BFD en 1000 ms y el multiplicador en 6 para una detección de actividad (liveness) equilibrada (~6 s) y una escala razonable. Configure el intervalo de sondeo de aplicaciones (app-probe) en 1 s para una detección oportuna de brownouts. Temporizadores excesivamente agresivos pueden causar sobrecarga de CPU y flapping; si son demasiado relajados, impiden la capacidad de respuesta para la voz.

3. Definir clases de SLA

• Justificación: Cree una clase de SLA Voice-SLA con latencia ≤ 150 ms, jitter ≤ 30 ms, pérdida ≤ 1% y MOS ≥ 4.0. Cree una Data-SLA con latencia ≤ 200 ms y pérdida ≤ 1%. Estos umbrales reflejan la sensibilidad de la voz y el rendimiento típico de la WAN; el MOS consolida la experiencia del usuario a través de múltiples métricas.

4. Construir listas de aplicaciones

• Justificación: Use DPI (NBAR2) para definir una App-List-Voice para el tráfico multimedia de SIP/RTP/Teams/Zoom y una App-List-Data para aplicaciones transaccionales. Incluya patrones TLS SNI/QUIC ALPN para las plataformas modernas de voz/video. Cuando la clasificación sea incierta, recurra a los marcados DSCP EF/AF41 aplicados en el borde de la LAN.

5. Construir la política de AAR

• Justificación: Asigne App-List-Voice a Voice-SLA con preferred-color mpls y backup-color biz-internet. Asigne App-List-Data a Data-SLA con preferred-color biz-internet y backup-color mpls para preservar el ancho de banda de MPLS. Esto asegura que la voz use MPLS cuando esté en buen estado y cambie a la banda ancha solo durante brownouts o blackouts, mientras que los datos prefieren el internet, que es más rentable.

6. Añadir histéresis y hold-down

• Justificación: Configure un temporizador de reversión (revert timer) para que la voz regrese a MPLS solo después de un cumplimiento sostenido del SLA (por ejemplo, 30–60 s). Esto evita la oscilación durante picos transitorios de jitter. De manera similar, aplique una penalización o dampening a la banda ancha si viola repetidamente el SLA en un corto período de tiempo.

7. Coordinar QoS y MTU

• Justificación: En ambos transportes, asegúrese de que las colas EF y el shaping se alineen con las velocidades del circuito. Un desajuste puede inflar el jitter/pérdida que ven los sondeos de BFD y el RTP de voz. Valide el path MTU y deshabilite el DF-bit donde la fragmentación sea inevitable, evitando caídas de sondeos que se enmascaran como pérdida.

8. Verificar e iterar

• Justificación: Use show sdwan app-route stats sla-class Voice-SLA para confirmar el cumplimiento/incumplimiento del SLA por túnel. Observe los flujos en vivo con show sdwan app-route statistics flows para asegurar que la voz se dirija a MPLS y cambie a la banda ancha solo cuando MPLS viole el SLA. Durante las pruebas, congestione intencionalmente MPLS para validar el comportamiento de brownout y luego mida el tiempo de reversión.

Siguiendo estos pasos, Contoso Health se asegura de que BFD proporcione una detección rápida de blackouts, que AAR reaccione a los brownouts usando clases de SLA precisas y que DPI clasifique correctamente las aplicaciones de voz. La combinación produce una calidad de voz predecible, un uso eficiente de los transportes y un comportamiento de conmutación por error controlable en toda la fabric de SD-WAN.

← Configuración de WAN Edge y gestión de plantillas · Todos los dominios · Política centralizada e ingeniería de tráfico →

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