Cisco 300-415: Política centralizada e ingeniería de tráfico — 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

La política centralizada en Cisco SD-WAN es el marco que permite programar el comportamiento del tráfico y la intención de enrutamiento desde los controladores vSmart a través de todo el fabric. vSmart, que gestiona el plano de control de la superposición (overlay) a través de OMP, distribuye la política de control centralizada (para rutas OMP y TLOCs) y las políticas del plano de datos, como las de datos, enrutamiento basado en aplicaciones (app-route) y cflowd. Estas políticas definen la topología (hub-and-spoke, restricción de malla), seleccionan rutas basadas en el rendimiento de las aplicaciones, dirigen flujos hacia servicios y segmentan el tráfico por VPN. Dado que las políticas pueden alterar tanto la alcanzabilidad del plano de control como el reenvío del plano de datos, un diseño cuidadoso, la vista previa y el despliegue por fases son esenciales para evitar interrupciones del servicio.

Tipos de políticas centralizadas y componentes básicos

• Política de control centralizada

  • Alcance: Plano de control (OMP) entre los dispositivos WAN Edge y vSmart.
  • Propósito: Filtrar/modificar anuncios de rutas OMP y TLOCs, establecer atributos (preferencia, etiqueta, origen, TLOC) y construir topologías (hub-and-spoke, malla parcial).
  • Dirección: De entrada (hacia vSmart desde WAN Edge) y de salida (desde vSmart hacia WAN Edge).

• Política de datos centralizada

  • Alcance: Clasificación en el plano de datos (L3/L4, campos, app-ID) en el WAN Edge, instalada por vSmart.
  • Propósito: Permitir/denegar flujos, establecer VPN, establecer TLOC, establecer DSCP/marcado, limitar el tráfico (police), replicarlo (mirror) y realizar inserción/encadenamiento de servicios.
  • Dirección: Se evalúa en el WAN Edge en relación con el lado del servicio (LAN) o el lado del túnel (WAN) dependiendo de dónde se programe; los diseños suelen apuntar al ingreso del lado del servicio para los flujos de usuario a WAN y al lado del túnel para el retorno si se requiere un comportamiento simétrico.

• Política de enrutamiento basado en aplicaciones (app-route)

  • Alcance: Selección de rutas en el plano de datos basada en la aplicación y el SLA (pérdida, latencia, jitter) medidos por BFD.
  • Propósito: Dirigir el tráfico a TLOCs/colores preferidos, definir clases de SLA basadas en sondeos, establecer rutas de respaldo (fallbacks) y realizar ingeniería de tráfico dinámica por aplicación/familia.
  • Comportamiento clave: Evalúa continuamente el rendimiento de la ruta; puede cambiar de ruta cuando el SLA se degrada.

• Política de cflowd

  • Alcance: Telemetría de flujos (similar a IPFIX/NetFlow) generada por los WAN Edges.
  • Propósito: Habilitar/deshabilitar exportadores por VPN, definir tasas de muestreo, plantillas y recolectores (vManage o externos).
  • Nota de diseño: El muestreo debe equilibrar la visibilidad con la sobrecarga de CPU/ancho de banda; la habilitación por VPN permite informes segmentados.

Las listas de políticas son objetos de coincidencia reutilizables:

• Lista de sitios (Site list): IDs de sitio utilizados para seleccionar dónde se aplican las políticas y para hacer coincidir los sitios de origen/destino de la ruta.
• Lista de VPN (VPN list): VRFs (VPNs) utilizadas para segmentar el alcance de la política y construir reglas por segmento.
• Lista de prefijos (Prefix list): Prefijos IP para hacer coincidir rutas OMP o tráfico de datos.
• Lista de prefijos de datos (Data prefix list): Objeto de prefijo especializado para la clasificación en políticas de datos.
• Lista de TLOC (TLOC list): Tuplas de IP de sistema, color y encapsulación utilizadas para hacer coincidir o establecer atributos de TLOC.
• Lista de colores (Color list): Uno o más colores de transporte (p. ej., biz-internet, mpls, public-internet) para selección de destino/afinidad de enlace.
• Lista de aplicaciones (Application list): Aplicaciones/grupos de NBAR2 para clasificar el tráfico para políticas de app-route o de datos.
• Clase de SLA (SLA class): Umbrales de latencia, pérdida y jitter vinculados a app-route para la dirección de tráfico basada en el rendimiento.

Estructura y evaluación de la secuencia de políticas:

• Las secuencias están ordenadas, y se aplica la primera coincidencia. Cada secuencia tiene:
  • Condiciones de coincidencia: Listas/campos (sitio/VPN/prefijo/TLOC/color/app, puertos L4, DSCP, protocolo).
  • Acciones: Aceptar/denegar, establecer atributos (TLOC, VPN, DSCP, preferencia, etiqueta), inserción de servicios, limitar (police), replicar (mirror).
• Acción por defecto: Se aplica si ninguna secuencia coincide. Las acciones por defecto comunes son aceptar (control/datos) para evitar caídas no deseadas; las acciones por defecto de denegación explícita se usan deliberadamente y requieren una validación cuidadosa.
• Dirección:
  • La dirección de la política de control está en vSmart (OMP de entrada/salida).
  • Las políticas de datos y de app-route operan sobre el tráfico en el WAN Edge; elija el comportamiento del lado del servicio o del lado del túnel para ajustarse al flujo que pretende afectar, y asegure la simetría del tráfico de retorno cuando hay servicios con estado (stateful) en la ruta.

Diseño de políticas del plano de control y manipulación de rutas/TLOC

La política de control es la herramienta autoritativa para dar forma a la topología del overlay porque determina qué rutas OMP y TLOCs puede enviar o recibir un sitio:

• Manipulación de rutas OMP

  • Usa políticas de control de entrada (inbound) para filtrar, etiquetar o establecer atributos en las rutas aprendidas de un sitio antes de que entren en la RIB del overlay en el vSmart.
  • Usa políticas de control de salida (outbound) para limitar qué rutas se anuncian a sitios específicos (p. ej., no anunciar prefijos aprendidos de spokes a otros spokes).
  • Acciones comunes: establecer preferencia (influye en la mejor ruta de OMP), establecer etiqueta (para coincidencias posteriores), establecer origen, establecer restricciones de sitio de origen.

• Manipulación de TLOC

  • Hacer coincidir atributos de TLOC (IP del sistema, color, encapsulación) para filtrar o preferir transportes específicos.
  • Las acciones incluyen cambiar los atributos o preferencias de TLOC preferidos para que los anuncios de ruta se inclinen hacia un color determinado (p. ej., preferir MPLS para subredes críticas).
  • Compensación: Un filtrado de TLOC demasiado agresivo puede dejar sitios aislados si el transporte restante falla. Prefiere el ajuste de atributos en lugar de una denegación general (blanket deny) a menos que tengas rutas redundantes.

• Patrones de topología

  • Hub-and-spoke: La política de control de salida desde el vSmart hacia los spokes deniega el anuncio de rutas originadas en spokes a otros spokes; los hubs reciben y anuncian todo.
  • Restricción de malla (Mesh): Similar a hub-and-spoke, pero permite pares específicos de spoke a spoke (p. ej., mallas regionales) mediante excepciones en las secuencias de la política.
  • Segmentación: Combina listas de VPN con filtrado de rutas para mantener aislados los overlays por VPN; anuncia solo prefijos predeterminados o seleccionados a los sitios restringidos.

Modos de fallo y compensaciones:

• Una política de control de salida mal aplicada con una denegación por defecto puede retirar rutas críticas, aislando sitios. Usa siempre una aceptación por defecto (default accept) y añade denegaciones específicas a menos que tu vista previa confirme explícitamente la cobertura.
• Cambiar atributos de OMP a gran escala puede desencadenar inestabilidad de rutas (route churn); escalona el despliegue por listas de sitios para reducir el impacto en el plano de control.
• La reescritura de atributos de TLOC puede llevar a un reenvío asimétrico si la ruta de retorno no se ve influenciada de manera equivalente; valida ambas direcciones.

Enrutamiento basado en aplicaciones (AAR), inserción de servicios y segmentación

El enrutamiento basado en aplicaciones (Application-aware routing, AAR) y las políticas de datos ofrecen conjuntamente una ingeniería de tráfico de grano fino:

• AAR y direccionamiento de tráfico

  • Las clases de SLA definen la pérdida/latencia/jitter aceptables; las sondas BFD por cada par de TLOC proporcionan mediciones en tiempo real.
  • La política de app-route hace coincidir aplicaciones o campos L3/L4 y selecciona listas de color/TLOC preferidas; si se viola el SLA, se realiza una conmutación por error (fail over) según la política.
  • Consejos de diseño:
    • Evita umbrales de SLA demasiado ajustados que causen inestabilidad (flapping); incluye histéresis usando multiplicadores de sonda y umbrales razonables.
    • Para aplicaciones sensibles al reordenamiento de paquetes, prefiere “mover en el siguiente flujo nuevo” en lugar de cambios a mitad de flujo, o fija los flujos usando hashing consistente donde sea compatible.
    • Cuando tanto AAR como la política de datos establecen el TLOC, da precedencia a AAR para la selección de ruta y usa la política de datos para la inserción/marcado de servicios; evita acciones superpuestas en la misma clase de tráfico.

• Encadenamiento e inserción de servicios

  • La acción “service” de la política de datos inserta tráfico a través de servicios on-premise o en colocación (firewall, IDS/IPS, nodos de servicio SD-WAN).
  • Encadena múltiples servicios en orden cuando sea necesario; asegura una inserción simétrica para servicios con estado (stateful) tanto en la ruta de ida como en la de vuelta.
  • Compensaciones: Cada salto de servicio añade latencia y dominios de fallo potenciales. Implementa comprobaciones de estado (health checks) y comportamientos de fallo abierto/cerrado (fail-open/closed) consistentes con la postura de seguridad.

• Segmentación de tráfico

  • Las VPNs proporcionan una segmentación estricta; la política centralizada se aplica por VPN usando listas de VPN.
  • El enrutamiento entre VPNs (route leaking) se puede lograr con una política de datos usando “set VPN” para flujos específicos; restringe estrictamente con coincidencias de prefijo/aplicación y audita con frecuencia.
  • Para servicios compartidos (p. ej., DNS, identidad), anuncia los prefijos de servicio desde una VPN de servicios hacia las VPNs consumidoras con una política de control en lugar de fugas amplias en el plano de datos.

Ejemplo de fragmento de app-route que ilustra el direccionamiento basado en SLA:

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

Operaciones: Adjuntar, validar y solucionar problemas

Adjuntar políticas a través de vSmart:

• Defina políticas centralizadas en vManage y adjúntelas a listas de sitios y listas de VPN. vSmart compila la política y la distribuye a los WAN Edges a través de sesiones OMP seguras con DTLS/TLS en la VPN 0.
• Defina el alcance de los cambios con cuidado; una sola instancia de política puede afectar a cientos de sitios. Use listas de sitios para implementar por etapas según la región o la función.

Simulación, vista previa e implementación por etapas de políticas:

• Vista previa (Preview): Antes de la activación, use la vista previa de vManage para inspeccionar la política compilada específica del dispositivo (lo que recibirá cada WAN Edge). Confirme la lógica de coincidencia/acción (match/action), las acciones predeterminadas y las direcciones.
• Simulación: Use la simulación de políticas para probar las coincidencias de flujos y las acciones esperadas (p. ej., qué TLOC usará una aplicación/tupla de 5 elementos determinada). Valide las asignaciones de clases de SLA y la clasificación de aplicaciones.
• Implementación por etapas:
  • 1. Adjunte a una lista de sitios canary (pocos sitios).
  • 2. Supervise los KPI del plano de control y de datos (recuentos de rutas OMP, BFD, aciertos de app-route).
  • 3. Expanda la lista de sitios de forma incremental.
• Control de versiones y reversión (rollback): Mantenga las versiones anteriores de las políticas; si se detecta un comportamiento inesperado, desactive la nueva política o revierta a la versión anterior rápidamente.

Depuración de resultados no deseados y precedencia:

• Verificación del plano de control

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

,

undefined

Confirme la presencia/ausencia de rutas y TLOCs según la intención de la política.

undefined

Verifique los contadores de la política de control y qué secuencias coincidieron.

• Síntoma: Los sitios spoke no pueden alcanzar a otros después de la implementación → revise las líneas de denegación de la política de control de salida hacia los spokes y las acciones predeterminadas.

• Verificación del plano de datos y AAR

undefined

y

undefined

Valide el estado del SLA y las decisiones de ruta.

undefined

o equivalente: Confirme los contadores de inserción de servicios y el orden de encadenamiento.

undefined

y

undefined

Verifique la ruta de reenvío real.

• Síntoma: Cambios de ruta inesperados/intermitencia (flapping) → relaje el SLA o ajuste los multiplicadores de sondeo; asegúrese de que una política de datos superpuesta no esté también estableciendo el TLOC.

• Precedencia y conflictos de políticas

  • Las decisiones de AAR suelen tener precedencia para la selección de rutas; use la política de datos principalmente para la inserción de servicios, el marcado y el control de acceso.
  • Los criterios de coincidencia superpuestos entre políticas pueden crear ambigüedad. Mantenga los dominios de coincidencia mutuamente excluyentes o introduzca ordenamiento y etiquetas para desambiguar.
  • Una acción predeterminada de aceptación puede enmascarar secuencias faltantes; agregue contadores explícitos de «solo observación» (p. ej., mirror/police low) o registros temporales para validar las coincidencias antes de aplicar denegaciones.

• Validación de cflowd

undefined

Asegúrese de que los exportadores por VPN estén activos y muestreando según lo previsto.

• CPU alta después de habilitar cflowd → aumente el intervalo de muestreo o limítelo a las VPN/aplicaciones esenciales.

Escenario de problema práctico

Northwind Traders está migrando a Cisco SD-WAN y debe aplicar una topología hub-and-spoke para las VPN de PCI, dirigir Office 365 a la mejor ruta de Internet e insertar un servicio de firewall regional para el tráfico de invitados sin afectar a las aplicaciones críticas.

Enfoque:

1. Construir listas de políticas

   • Crear listas de sitios: HUBS (centros de datos), SPOKES (sucursales).
   • Crear listas de VPN: PCI_VPN, GUEST_VPN, CORP_VPN.
   • Crear listas de aplicaciones: O365, BEST_EFFORT.
   • Crear listas de colores: PRIVATE (mpls), DIA (biz-internet, public-internet). Justificación: Las listas reutilizables permiten un alcance preciso y un despliegue por etapas seguro; la separación de las VPN apoya la segmentación.

2. Definir clases de SLA

   • GOLD: pérdida 0.5%, latencia 100 ms, jitter 20 ms.
   • SILVER: pérdida 1%, latencia 150 ms, jitter 30 ms. Justificación: Alinee los umbrales con el rendimiento realista del transporte para evitar la intermitencia de rutas (path flapping); más estrictos para O365 que para best-effort.

3. Implementar política de control para topología hub-and-spoke de PCI

   • Entrante a vSmart: etiquetar las rutas aprendidas de los SPOKES en la PCI_VPN.
   • Saliente de vSmart: hacia los SPOKES, anuncie las rutas de los HUB y las predeterminadas; deniegue el anuncio de rutas PCI originadas en SPOKE a otros SPOKES; hacia los HUBS, anuncie todo. Justificación: La topología se aplica en el plano de control, asegurando que los spokes solo aprendan rutas entre sí a través de los hubs y preservando la segmentación en la VPN de PCI.

4. Crear política de app-route para O365 y best-effort

   • Hacer coincidir O365 en la CORP_VPN con el SLA GOLD; color preferido DIA con respaldo (fallback) en PRIVATE.
   • Hacer coincidir BEST_EFFORT con SILVER; preferido PRIVATE con respaldo (fallback) en DIA. Justificación: O365 funciona mejor sobre Internet directo cuando se cumple el SLA; conmutar por error (fail back) a MPLS según sea necesario. El tráfico best-effort puede preferir MPLS por costo/política, permitiendo al mismo tiempo un respaldo (fallback) en DIA.

5. Insertar firewall regional para el tráfico de invitados

   • Política de datos en la GUEST_VPN: inserción de servicio en la cadena de servicios del firewall regional tanto en la dirección de ida (forward, del lado del servicio hacia la WAN) como en la de retorno (return, del túnel al servicio).
   • Asegúrese de que se supervise el estado del servicio de firewall; defina fail-open para el caso de uso de invitados para preservar la disponibilidad. Justificación: La inspección con estado (stateful) requiere un recorrido simétrico; la inserción bidireccional evita la caída de sesiones. La tolerancia al riesgo para invitados permite fail-open si el servicio está caído.

6. Adjuntar políticas a través de vSmart con un despliegue por etapas

   • Adjunte la política de control a los HUBS y a un subconjunto canary de SPOKES en la PCI_VPN.
   • Adjunte las políticas de app-route y de datos primero a una región limitada. Justificación: Limita el radio de impacto (blast radius); valida el comportamiento de la política antes de la expansión global.

7. Validar y supervisar

   • Haga una vista previa de las políticas compiladas por dispositivo; confirme las acciones predeterminadas.
   • Use la simulación para probar flujos de muestra (O365 desde una sucursal en CORP_VPN, tráfico web de invitados desde GUEST_VPN).
   • Supervise

undefined

(alcanzabilidad de PCI),

undefined

(ruta de O365),

undefined

(contadores del firewall de invitados) y las sesiones BFD. Justificación: Confirma que los resultados tanto del plano de control como del de datos coinciden con el diseño, y que el enrutamiento basado en SLA opera como se espera.

8. Expandir y fortalecer
   • Agregue gradualmente los SPOKES restantes a la política de control adjunta.
   • Refuerce la política de invitados con límites de velocidad (rate limits); ajuste los umbrales de SLA de O365 si se producen oscilaciones de ruta. Justificación: El ajuste iterativo reduce el riesgo operativo y garantiza una experiencia de usuario estable.

Esta secuencia separa limpiamente el control de la topología (OMP) del enrutamiento y los servicios del plano de datos, usa la segmentación para proteger PCI, aplica enrutamiento de aplicaciones basado en SLA para el rendimiento y mantiene la seguridad operativa a través de la vista previa, la simulación y la adjunción por etapas.

← Túneles del plano de datos · Todos los dominios · Seguridad →

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