Cisco 300-415: Calidad de servicio y servicios de multidifusión — 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

Los servicios de Calidad de Servicio (QoS) y multicast en Cisco SD-WAN están diseñados para preservar la experiencia de las aplicaciones a través de diversos transportes, al tiempo que permiten una distribución escalable y basada en políticas del tráfico en tiempo real y de grupo. QoS asegura la prioridad, el modelado (shaping) y el uso justo del ancho de banda por aplicación y por túnel de superposición (overlay); multicast permite una replicación eficiente y controlada por políticas de los flujos para los receptores en diferentes sitios. Juntos, convierten la intención (la voz/video deben estar protegidos contra la pérdida y la fluctuación (jitter); las aplicaciones críticas para el negocio deben cumplir con los SLAs) en un comportamiento consistente en el plano de datos, coordinado por el plano de control de SD-WAN (vSmart) y aplicado en los dispositivos WAN Edge.

Arquitectura de QoS, Colas, Planificación, Modelado, Control de Tasa y Asignación de Ancho de Banda

La QoS en Cisco SD-WAN es jerárquica y consciente del transporte:

• Clasificación: Identificar flujos por campos (L3/L4), DSCP, firmas de aplicación (NBAR2 en IOS XE SD-WAN), o por contexto de VPN y prefijo.
• Marcado: Establecer o preservar el DSCP desde el lado del servicio, reescribirlo según sea necesario para las restricciones de la WAN y mapearlo a las colas de egreso mediante mapas de QoS.
• Encolado y planificación (scheduling): Las interfaces de egreso implementan múltiples colas de hardware/software con una cola de baja latencia y prioridad estricta (LLQ) para el tráfico en tiempo real y planificadores ponderados (WFQ/WRR/CBWFQ) para otras clases.
• Modelado (Shaping): Suavizar el tráfico de egreso a una tasa configurada (por interfaz, por subinterfaz o por túnel) para evitar los policers del proveedor y absorber las ráfagas.
• Control de tasa (Policing): Limitar la tasa y, opcionalmente, remarcar o descartar el tráfico no conforme en el ingreso o egreso; se usa con moderación para evitar degradaciones de servicio (brownouts) en las aplicaciones.
• Asignación de ancho de banda: Reservar un ancho de banda mínimo (garantías) por clase y limitar los máximos cuando sea apropiado; asegurar que la LLQ tenga un límite estricto y explícito para prevenir la inanición (starvation) de otras colas.

Guía de diseño y consideraciones:

• Modele a una tasa segura por debajo del policer efectivo del ISP. Para circuitos de Internet variables, un 90–95% del ancho de banda nominal es un punto de partida práctico; ajústelo utilizando las caídas y la latencia observadas bajo carga.
• La profundidad de la cola (buffering) debe equilibrar el retardo frente a la pérdida. Dimensiónela aproximadamente a una fracción del producto ancho de banda-retardo; si es demasiado pequeña, induce caídas por cola llena (tail drop); si es demasiado grande, infla la latencia para las clases inferiores.
• Use la LLQ solo para flujos cortos de voz/control de video de tasa constante; no coloque flujos de video de gran tasa de bits en la LLQ; asígnelos a una cola ponderada de alta prioridad con un límite de ancho de banda claro.
• Prefiera el modelado (shaping) sobre el control de tasa (policing) en el egreso. Aplique policers para contratos de tasa explícitos o para el tráfico de ingreso no confiable.
• En enlaces físicos compartidos que transportan múltiples overlays, habilite QoS por túnel (PTQ) para que cada túnel seguro basado en BFD reciba su propio planificador/modelador, evitando que un único overlay ocupado monopolice el enlace.
• La política específica del transporte (consciente del color/TLOC) permite mapas de QoS, modeladores y garantías de clase distintos por cada underlay (por ejemplo, un modelado más estricto y un conjunto de DSCP reducido en Internet frente a clases más ricas en MPLS).

QoS por túnel y especificidades del transporte:

• PTQ virtualiza la planificación de egreso por cada túnel IPsec/DTLS/TLS para que las garantías y los límites se apliquen por ruta, no solo por interfaz. Esto es esencial cuando un Edge forma múltiples túneles sobre la misma interfaz (p. ej., regiones duales de vSmart/vBond o múltiples pares remotos).
• Asigne diferentes mapas de QoS por color (biz-internet, mpls, lte) para respetar las listas blancas de DSCP del proveedor y evitar remarcados inesperados (p. ej., colapsar las clases AF a la clase por defecto en banda ancha).

Clasificación y Marcado con DSCP, Mapas de QoS y Gestión de Congestión

La clasificación confiable comienza en el borde de la VPN de servicio:

• Límites de confianza: Si el dominio de acceso LAN no es consciente de QoS, clasifique y marque en el WAN Edge usando el ID de aplicación L7 o tuplas L3/L4. Si la LAN es capaz de manejar QoS, audite y preserve el DSCP mientras lo normaliza a un mapa de QoS de la WAN.
• Estrategia de DSCP: EF para voz interactiva, AF41/42 para video, AF31/AF21 para datos críticos, clases CS3/AF para señalización, CS0/DF para mejor esfuerzo (best effort), y CS1 (o LE) para tráfico de baja prioridad (scavenger). Alinéelo con los valores aceptados por el proveedor.
• Mapa de QoS: Mapee el DSCP a una cola y, opcionalmente, reescríbalo en el egreso; mantenga un mapeo uno a uno o muchos a uno que respete los límites del underlay.

Ejemplo corto de verificaciones operacionalmente útiles:

show sdwan app-route stats sla-class VOICE
show policy qos-queue   (vEdge)
show policy-map interface <wan-intf>  (IOS XE SD-WAN)

Gestión de congestión y dimensionamiento de colas:

• Comience con una LLQ pequeña y limitada para EF (por ejemplo, 10% de la tasa modelada) y aplique policing dentro de la LLQ para prevenir el desbordamiento por flujos mal marcados.
• Asigne el ancho de banda restante usando pesos de WRR/CBWFQ alineados con la prioridad del negocio (p. ej., 30% datos críticos, 20% video, 35% mejor esfuerzo, 5% scavenger).
• Considere habilitar el descarte temprano (WRED) para las clases de tráfico masivo (bulk) cuando la plataforma lo soporte para evitar la sincronización global; no habilite el descarte temprano en la LLQ o en colas de control pequeñas.

Modos de fallo a vigilar:

• El remarcado del proveedor colapsa el DSCP, colocando el tráfico en tiempo real en la clase de mejor esfuerzo; el resultado es jitter y pérdida de paquetes durante los picos. Verifique con capturas de paquetes y los perfiles de QoS del proveedor.
• Modeladores (shapers) mal dimensionados conducen a caídas por cola llena (tail drops) persistentes; la inanición de la LLQ ocurre si no está limitada o si el video inunda la LLQ.
• La falta de PTQ en una interfaz compartida causa que los overlays “vecinos ruidosos” consuman ancho de banda y degraden los túneles críticos.

Priorización de aplicaciones, intención de negocio y cumplimiento de SLA

Cisco SD-WAN expresa la intención de la aplicación a través de políticas centralizadas en el controlador vSmart, que gestiona el plano de control del overlay y distribuye las políticas a los WAN Edges. El enrutamiento basado en aplicaciones (Application-Aware Routing o AAR) dirige el tráfico basándose en la pérdida, latencia y jitter medidos por cada transporte y por cada túnel usando BFD. Para la optimización de SaaS, Cloud OnRamp puede incorporar la pérdida y latencia basadas en HTTP hacia la aplicación, además de las métricas de BFD hacia un sitio de gateway.

Mejores prácticas:

• Definir listas de aplicaciones y clases de SLA por criticidad de negocio:
  • VOZ: EF, objetivo <150 ms unidireccional, <30 ms de jitter, <1% de pérdida; dirigir solo por rutas que cumplan estos umbrales.
  • VIDEO: AF4x, jitter/pérdida ligeramente más permisivos que para voz; preferir rutas de alto ancho de banda y baja pérdida.
  • DATOS CRÍTICOS: AF3x/AF2x; limitar la pérdida y latencia según lo requiera la aplicación.
• Usar políticas centralizadas para el enrutamiento basado en aplicaciones (AAR) para preferir rutas que cumplan el SLA por clase; recurrir a rutas secundarias cuando ocurra una degradación.
• Combinar AAR con QoS por transporte: una ruta seleccionada debe tener recursos reservados para la clase; de lo contrario, el tráfico puede cumplir el SLA de la ruta pero aun así ser encolado o descartado en la salida (egress).
• Para SaaS a través de un sitio de gateway, validar ambos:
  • Pérdida/latencia HTTP hacia el endpoint de SaaS.
  • Pérdida/latencia BFD hacia el sitio de gateway.
• Forzar la preservación de DSCP de extremo a extremo; en la salida, reescribir solo donde los underlays lo exijan, y restaurar las marcas si el extremo remoto confía en ellas.

Verificaciones operativas:

show sdwan app-route statistics
show sdwan bfd sessions
show application traffic-flow   (vManage analytics)

Errores comunes:

• Umbrales de SLA muy estrictos causan inestabilidad de rutas (path flapping); introducir histéresis y temporizadores de espera (hold timers).
• La falta de ancho de banda para una clase en la ruta elegida lleva a una congestión autoinfligida; alinear las elecciones de AAR con la capacidad de QoS por transporte.
• Clasificación errónea (p. ej., voz descubierta como best effort) debido a cargas útiles cifradas o a la falta de firmas NBAR; usar la confianza en DSCP o coincidencias explícitas de L4 como alternativa (fallback).

Fundamentos de Multicast y Diseño de Multicast en la Superposición (Overlay)

El multicast sobre SD-WAN desacopla el plano de control de multicast de la LAN de las restricciones de la red subyacente (underlay):

• Fundamentos:
  • Los receptores señalan su interés con IGMPv2/v3 hacia el router LAN de primer salto (el WAN Edge en la VPN de servicio).
  • Se recomienda PIM Sparse Mode en la VPN de servicio; los puntos de encuentro (rendezvous points o RPs) orquestan las uniones iniciales.
• Plano de control de la superposición (overlay):
  • Los routers WAN Edge originan rutas de servicio multicast hacia el controlador vSmart a través de OMP.
  • El controlador vSmart, actuando en el rol de replicador de multicast/anuncio de RP, propaga la información del RP a través de la superposición y reenvía las uniones para los grupos solicitados hacia la fuente o el PIM-RP, según se especifica en el mensaje de unión PIM original.
  • vSmart selecciona uno o más WAN Edges como replicadores del plano de datos. El Edge del lado de la fuente envía una única copia al replicador, que luego la replica a los Edges receptores, minimizando el uso de ancho de banda en enlaces con restricciones.
• Plano de datos:
  • La replicación ocurre como paquetes unicast cifrados a través de los túneles de la superposición; se preservan los límites de la VPN de servicio (el multicast es por VPN/VRF).
  • El multicast entre VPNs no es automático; si se requiere, utilice encadenamiento de servicios (service-chaining) explícito o gateways a nivel de aplicación.

Consideraciones de diseño y compensaciones:

• Ubique el RP lógicamente cerca de las fuentes o de los datacenters centrales. En una superposición SD-WAN, confíe en vSmart para anunciar el RP a los receptores, asegurando uniones consistentes.
• Habilite el multicast solo en las VPNs donde sea necesario; mantenga el tráfico de control de los receptores (IGMP) con limitación de tasa (rate-limited) para proteger la CPU.
• En enlaces de bajo ancho de banda, centralice la replicación en un hub/replicador con amplia capacidad para evitar la replicación de N×flujos en los circuitos de acceso.
• Valide el MTU para evitar la fragmentación de flujos de alta tasa de bits; considere aplicar modelado (shaping) a las clases de video de forma independiente de las colas del plano de control.

Modos de fallo:

• La ausencia de un IGMP querier en la LAN provoca el envejecimiento de los grupos y la pérdida de flujos; asegúrese de que el WAN Edge o un switch de la LAN actúe como querier.
• Un RP incorrecto o el filtrado en una política centralizada interrumpe las uniones; confirme la alcanzabilidad del RP a través de la superposición.
• El tráfico de control multicast excesivo de paquetes pequeños puede confundirse con un ataque DDoS; limite la tasa y monitoree las colas de control.
• Límites de VPN de servicio mal especificados causan la no entrega; el multicast no cruza VPNs a menos que se diseñe explícitamente para ello.

Fundamentos de troubleshooting:

show ip igmp groups
show ip pim neighbor / rp mapping
show sdwan omp services
show sdwan multicast status
show interface | include drops

Correlacione las caídas en las colas (queue drops) con los KPIs de la aplicación; para multicast, asegúrese de que las uniones IGMP se vean en el Edge, que existan las rutas de servicio OMP y que el replicador elegido sea alcanzable a través de un túnel saludable.

Escenario de Problema Práctico

NorthRiver Health opera 120 clínicas con transportes duales (MPLS e Internet). Las quejas mencionan voz entrecortada, video de telemedicina pixelado y multicast de IPTV intermitente en las salas de espera.

Enfoque:

1. Establecer límites de confianza y clasificar el tráfico

• Justificación: La clasificación precisa es un prerrequisito para la priorización. Preservar el DSCP de los dominios LAN que lo cumplen; donde no exista, clasificar por aplicación (NBAR2) y tuplas L4, mapeando voz a EF, video a AF41 y EMR crítico a AF31.

2. Crear mapas de QoS y modeladores (shapers) específicos para cada transporte

• Justificación: MPLS respeta AF/EF, mientras que Internet a menudo no lo hace. Configurar mapas de QoS por color: el conjunto completo de clases en MPLS; clases consolidadas en Internet preservando EF y AF4. Modelar (shape) MPLS al 95% del CIR e Internet al rendimiento sostenible medido para evitar los ‘policers’ del proveedor.

3. Habilitar QoS por túnel en las interfaces WAN compartidas

• Justificación: Múltiples superposiciones comparten el mismo enlace físico. El PTQ (Per-Tunnel QoS) evita que un túnel sitio-a-nube congestionado deje sin recursos a los túneles de voz/video sitio-a-datacenter, al asignar planificadores y mínimos por túnel.

4. Reservar y limitar la LLQ para la voz; ponderar el video y los datos críticos

• Justificación: La voz requiere latencia/jitter acotados; limitar la LLQ al 10% para evitar la inanición de otras colas. Asignar un 25–30% al video AF4 con un máximo estricto. Asignar un 25% al tráfico EMR AF3, y el resto a mejor esfuerzo (best effort) y scavenger.

5. Implementar una política AAR centralizada en vSmart con clases de SLA

• Justificación: vSmart distribuye una política centralizada que coloca el tráfico de voz/video/EMR en rutas que cumplen los objetivos de SLA usando BFD para medir pérdida/latencia/jitter. Añadir histéresis para evitar oscilaciones (flaps). Para los módulos EHR SaaS a través de un gateway, incluir la pérdida/latencia HTTP hacia el SaaS y BFD hacia el sitio del gateway.

6. Desplegar multicast en la superposición (overlay) con selección de replicador por vSmart

• Justificación: La distribución eficiente de IPTV requiere una replicación controlada. Habilitar multicast en la VPN de IPTV, configurar PIM-SM y el RP, y dejar que vSmart anuncie el RP y seleccione un Edge del datacenter como replicador para proteger los circuitos de baja velocidad de las clínicas de la replicación N-vías.

7. Validar e iterar con telemetría

• Justificación: Confirmar el comportamiento bajo carga. Usar:
  • show sdwan app-route statistics para verificar la selección de ruta por SLA.
  • show policy qos-queue / show policy-map interface para evaluar la utilización y las caídas en las colas.
  • show ip igmp groups y show sdwan omp services para las uniones multicast y las rutas de servicio. Ajustar las tasas de los modeladores (shapers) y los pesos de las colas para eliminar las caídas por cola llena (tail drops) en voz/video, manteniendo una latencia aceptable para los datos críticos.

8. Mecanismos de protección y manejo de anomalías

• Justificación: Prevenir la recurrencia y detectar regresiones. Aplicar ‘policers’ de ingreso en segmentos LAN no confiables para limitar el tráfico mal marcado, limitar la tasa de IGMP para proteger la CPU del plano de control, y configurar alertas sobre incumplimientos de SLA de AAR y contadores de caídas de cola para activar una remediación proactiva.

Esta secuencia asegura que NorthRiver Health convierta la intención de negocio en una QoS consistente y consciente del transporte, y en una entrega de multicast fiable. La voz obtiene un tratamiento estricto y acotado; el video y el EMR reciben un ancho de banda priorizado y ponderado; las rutas se seleccionan mediante mediciones de SLA en tiempo real; y el multicast se replica eficientemente sin sobrecargar los enlaces de las sucursales.

← Seguridad · Todos los dominios · Integración con la nube →

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