Cisco 350-401: Servicios IP, Multicast y Calidad de Servicio — Guía de estudio

By Laurynas Brazys · 15 August 2026 · #cisco #350-401 #certification #exam-prep #study-guide

Forma parte de la Cisco CCNP Enterprise 350-401 ENCOR — 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 IP, multicast y QoS forman el núcleo operativo de una red empresarial. Servicios fundamentales como DHCP, DNS, NTP y la telemetría de gestión habilitan a los endpoints y a los operadores; NAT impone límites de direccionamiento y seguridad; QoS preserva la experiencia del usuario para aplicaciones en tiempo real; multicast escala la distribución de uno a muchos; y la monitorización activa con IP SLA y el seguimiento de objetos (object tracking) cierra el ciclo para la resiliencia. Esta sección explica el razonamiento de diseño y operativo para cada uno, destacando los modos de fallo y las contrapartidas.

Servicios IP Fundamentales y Telemetría

DHCP: Proporcionar direcciones y opciones de forma centralizada, garantizando al mismo tiempo la escalabilidad y corrección del relay.

• Manejo de relay y opciones: Use ip helper-address en la interfaz de primer salto para enviar por unicast las difusiones (broadcasts) de los clientes al servidor DHCP. Incluya solo los helpers UDP necesarios (p. ej., 67/68 DHCP, 53 DNS, 69 TFTP, 161 SNMP) para limitar el ruido. La Opción 43 suministra a los APs CAPWAP las direcciones de los WLC; la Opción 82 (información de relay) añade identificadores de circuito para políticas y reservas por puerto. Confíe o elimine la Opción 82 de forma meditada: los switches de la capa de acceso suelen insertarla y los dispositivos ascendentes (upstream) no deberían sobrescribirla.
• Modelos de asignación: Pool dinámico con reservas para MACs de infraestructura o IDs de cliente, asignaciones estáticas para infraestructura crítica y concesiones (leases) cortas para pools de alta movilidad o VPN. Considere la utilización de la subred y el split-scope o el failover de DHCP para la resiliencia.
• Resolución de problemas: Valide primero la alcanzabilidad L2 y las VLANs, luego la alcanzabilidad del relay y el llenado del campo giaddr. En Cisco IOS, use show ip dhcp binding, show ip dhcp server statistics y debug ip dhcp server events con precaución. Los fallos comunes incluyen la falta de direcciones helper en una SVI, la Opción 82 descartada por un firewall o un pool agotado.

DNS: Despliegue resolutores redundantes y con capacidad anycast cerca de los usuarios. Fuerce registros split-horizon para servicios internos. Almacene en caché cerca de los clientes para reducir la latencia. Asegure con validación DNSSEC y restrinja la recursión a subredes internas.

NTP: La consistencia horaria protege los logs, Kerberos y los certificados. NTPv4 añade extensiones de seguridad y utiliza multicast IPv6 site-local para el descubrimiento en LANs. Diseñe con al menos dos fuentes upstream (públicas o de estrato 1/2 de la empresa) y distribuya a través de servidores internos de estrato 3. Prefiera la autenticación (claves simétricas o NTS) y evite que cada nodo consulte NTP directamente en Internet; apunte la infraestructura a servidores NTP locales.

Plano de gestión y telemetría:

• SNMP: Prefiera SNMPv3 por su autenticación/privacidad; minimice los intervalos de sondeo (polling); agrupe los OIDs por rol. Limite SNMP con ACLs y Control Plane Policing (CoPP) para proteger contra sobrecargas y abusos. Los traps/informs deben tener una tasa limitada (rate-limited).
• Syslog: Use transporte fiable donde sea compatible y envíe al menos a dos recolectores. Normalice la severidad (0–7) y estampe la hora vía NTP. Implemente el análisis (parsing) para eventos clave (caídas y levantadas de enlaces, cambios de ruta, seguridad).
• NetFlow/IPFIX: Exporte solo los campos necesarios; use muestreo (sampling) en enlaces de alto rendimiento. Asegure la capacidad del recolector y los controles de privacidad. Prefiera IPFIX por su extensibilidad neutral respecto al proveedor.
• Telemetría dirigida por modelos: Transmita (stream) datos modelados en YANG (gNMI/NETCONF dial-in/out) a intervalos fijos; es de menor latencia y más eficiente que el SNMP masivo (bulk). Alinee la recolección con los SLI/SLOs (p. ej., descartes, profundidad de cola, CPU, memoria, cambios de rutas).

NAT: Estático, Dinámico, PAT y Validación

NAT impone la independencia de direccionamiento, las políticas y la migración de IPs solapadas. Elija la construcción más simple que cumpla el requisito.

• NAT estático: Uno a uno, determinista. Usar para servicios entrantes, gateways de VoIP y pares IPsec que requieren una identidad estable. Contrapartida: consume IPs públicas.
• NAT dinámico (pool): Mapeo de muchos a menos con selección efímera de un pool para clientes solo de salida. El enrutamiento de retorno debe apuntar al dispositivo NAT; la asimetría rompe las sesiones.
• PAT (overload): Mapeo de muchos a uno usando puertos TCP/UDP únicos en una sola IP (o unas pocas IPs). Extremadamente eficiente pero puede agotar los puertos bajo una alta concurrencia de conexiones; distribuya PAT entre múltiples direcciones en perímetros de alta escala.
• Hairpin y twice NAT: Necesario cuando los hosts internos deben alcanzar servicios internos a través de la dirección pública o necesitan remapear tanto el origen como el destino. Valide cuidadosamente la política y la correspondencia de rutas.
• Orden de operaciones y VRFs: Asegure que NAT ocurra en la etapa correcta en relación con ACLs, ZBFW y PBR. Para diseños con VRF, aplique reglas de NAT por VRF y confirme la fuga de rutas (route-leaking) para el tráfico de retorno.
• Alta disponibilidad: El NAT con estado (stateful) es obligatorio para un failover sin interrupciones; de lo contrario, use NAT estático determinista en ambos pares con redundancia de primer salto y acepte la pérdida de sesión para flujos dinámicos/PAT.
• Validación y resolución de problemas: show ip nat translations y statistics, confirme los contadores de aciertos (hit counters) en las ACLs, verifique las rutas hacia/desde el exterior del NAT. Use debug con moderación; las capturas de paquetes suelen ser más seguras. Vigile el agotamiento de puertos, los pools solapados y el enrutamiento asimétrico.

Ejemplo corto:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

QoS: Clasificación, Marcado, Colas y Gestión de Congestión

La QoS de extremo a extremo preserva el rendimiento bajo contención; diseñe el límite de confianza y el comportamiento de reenvío de manera consistente a través del acceso, la distribución, la WAN y el centro de datos.

• Clasificación y marcado: Clasifique en el borde; confíe solo en dispositivos capaces. El límite de confianza típico es el puerto del switch de acceso a un teléfono IP (confíe en CoS/DSCP del teléfono, no del PC conectado) y a los dispositivos de infraestructura. Use NBAR o ACL para clasificar cuando falten las marcas. Vuelva a marcar el tráfico no conforme en el borde.
• DSCP y CoS: DSCP EF (46) para el portador de voz, CS3 para la señalización de llamadas, AF41 para video interactivo, AF31/AF32 para datos críticos, CS1 para scavenger. Asigne DSCP a comportamientos por salto (per-hop behaviors) y a CoS de L2 para los enlaces troncales.
• Colas y planificación (scheduling): Use LLQ para tráfico de prioridad estricta (EF) con un límite de ancho de banda vigilado (policed) para evitar la inanición (starvation). Use CBWFQ para clases aseguradas con garantías de ancho de banda mínimo. Valide las asignaciones de colas de hardware a DSCP por plataforma.
• Modelado (shaping) y vigilancia (policing): Modele a la salida (egress) a un CIR contratado para suavizar las ráfagas (especialmente hacia la WAN). Vigile a la entrada (ingress) para hacer cumplir los límites de inquilino (tenant) o de clase; entienda que la vigilancia (policing) añade pérdidas y un posible desorden si no se tiene cuidado.
• Prevención de congestión: WRED descarta paquetes tempranamente basándose en la profundidad promedio de la cola y el DSCP, protegiendo los flujos interactivos a expensas del tráfico masivo elástico. No habilite WRED en colas de prioridad estricta. El descarte de cola (tail-drop) se mantiene para las clases donde WRED no ofrece beneficios o el hardware no lo soporta.
• SLAs de voz/video: Latencia unidireccional ≤150 ms, jitter ≤30 ms, pérdida ≤1% para voz; el video interactivo es ligeramente más tolerante a la pérdida pero igualmente sensible a la variación del retardo. Diseñe el ancho de banda de EF a partir de las tasas de los códecs más las cabeceras, VAD y un margen de crecimiento; restrinja la LLQ para proteger a otras clases. Para TelePresence/video interactivo, asigne AF41 con un ancho de banda mínimo adecuado y modelado (shaping) en enlaces de baja velocidad.
• Verificación: Use

undefined

para confirmar los contadores de clase, los descartes y el cumplimiento del modelado. Monitoree la profundidad de la cola de la interfaz y los motivos de los descartes; ajuste el ancho de banda y los umbrales basándose en la utilización medida, no en las afirmaciones de tasa de enlace máxima.

Ejemplo corto de LLQ:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Multicast: Reenvío, PIM, RPs y Diseño a través de Campus y WAN

El multicast escala el tráfico de uno a muchos de manera eficiente y requiere un acoplamiento estrecho con el enrutamiento unicast para las comprobaciones de Reverse Path Forwarding (RPF).

• IGMP: Los hosts se unen y abandonan grupos a través de IGMP (v2 está ampliamente desplegado, v3 añade filtrado de origen para SSM). Habilite IGMP snooping en los switches; asegúrese de que exista un IGMP querier por VLAN para mantener el estado del grupo incluso sin un router multicast en el segmento.
• Modos de PIM:
  • PIM Sparse Mode (PIM-SM): Modelo de atracción (pull); solo envía tráfico a los receptores interesados. Un RP es la raíz del árbol compartido (*,G). Por defecto, el RP solo es necesario para iniciar nuevas sesiones; los receptores pueden cambiar al árbol de origen (S,G) para obtener rutas óptimas una vez que el tráfico fluye.
  • PIM Source-Specific Multicast (SSM): Sin RP; los receptores especifican (S,G) a través de IGMPv3. Simplifica el plano de control y mitiga los riesgos de muchos a muchos. Ideal para IPTV y fuentes estrictamente controladas.
  • PIM Bidirectional: Eficiente para comunicaciones de muchos a muchos con bajo estado y sin registro de origen (p. ej., datos del mercado financiero), pero sin cambio a la ruta más corta (shortest-path switch-over); diseñe en consecuencia.
• Estrategias de RP:
  • RP estático para dominios pequeños.
  • BSR/Auto-RP para descubrimiento dinámico.
  • Anycast-RP con MSDP para compartir el registro de origen entre múltiples RPs usando una única dirección anycast, mejorando la resiliencia y la localidad.
• Fallas de RPF y cambio a SPT: Las fallas de RPF se deben a la asimetría de rutas unicast o a prefijos filtrados; verifique con

undefined

y

undefined

. Los umbrales de SPT rigen cuándo pasar del árbol compartido al árbol de origen; establézcalos en función del volumen de tráfico y la simetría de la ruta del núcleo.

• Diseño de campus: Use PIM-SM en el núcleo enrutado, IGMP snooping con queriers en el borde de acceso y Anycast-RP en los nodos del núcleo alineados. Prefiera SSM donde los hosts soporten IGMPv3; de lo contrario, implemente el mapeo de SSM en el router de primer salto.
• Diseño de WAN: Sobre MPLS, use mVPN del proveedor si está disponible; de lo contrario, ejecute PIM a través de la VRF de la WAN o encapsule con GRE/DMVPN y habilite PIM dentro de los túneles. Asegure la alcanzabilidad del RP entre dominios y confirme la aceptación de multicast por parte del proveedor o planifique superposiciones (overlays). Para la distribución basada en Internet, prefiera SSM con GRE/IPsec para evitar dependencias de RP a través de dominios no confiables.

Ejemplo corto de PIM/RP:

undefined

undefined

undefined

undefined

undefined

Monitorización activa, conmutación por error automatizada y resolución de problemas

IP SLA y el seguimiento (tracking) automatizan las acciones correctivas y validan los SLA en tiempo real.

• IP SLA: ICMP-echo para la alcanzabilidad, UDP jitter para la calidad de voz/video, conexión HTTP/TCP para la disponibilidad de aplicaciones. Para multicast, las operaciones de UDP jitter pueden probar la entrega a un grupo específico (S,G) o (*,G).
• Seguimiento de objetos y disparadores (triggers): Seguir los resultados de IP SLA, los estados de las interfaces o las rutas. Vincular el seguimiento a HSRP/VRRP, rutas estáticas o PBR. Usar applets de EEM para secuencias complejas (registrar, reconfigurar, notificar).
• Ejemplo:

undefined

undefined

undefined

undefined

undefined

undefined

• Monitorización de la disponibilidad del servicio: Combinar contadores SNMP (descartes, errores), estadísticas de colas de QoS, NetFlow/IPFIX para la utilización de clases y syslog para la correlación de anomalías. La sincronización de tiempo debe ser estricta o la correlación de múltiples fuentes fallará.
• Modos de fallo comunes y contrapartidas:
  • DHCP: Opción 82 eliminada por los firewalls; superposición de ámbitos divididos (split-scope); servidores DHCP no autorizados (rogue)—habilitar DHCP snooping.
  • DNS: Política asimétrica o EDNS0 bloqueado; fallo de anycast sin retirada (withdrawal) conduce a agujeros negros (blackholes)—monitorizar la salud de BGP si se usa anycast.
  • NTP: Bucles de peering y “false tickers”; desplazamientos de tiempo no autenticados causan fallos en los certificados—forzar la autenticación y umbrales de cordura (sanity thresholds).
  • NAT: El enrutamiento asimétrico a través de bordes redundantes rompe las sesiones; agotamiento de puertos PAT—escalar horizontalmente los pools o usar hashing por flujo con ECMP consciente de los dispositivos con estado (stateful).
  • QoS: Una LLQ sobreaprovisionada priva de recursos a otras clases; un DSCP mal mapeado en una plataforma conduce a colas inesperadas—validar los mapas de QoS específicos de la plataforma.
  • Multicast: Fallos de RPF por filtros de ruta; la pérdida de alcanzabilidad del RP detiene nuevas uniones (joins); IGMP snooping sin un querier hace que las membresías expiren—habilitar un querier o la presencia de un router PIM en la VLAN.
  • Sobrecarga del plano de control: El sondeo (polling) excesivo o las tormentas de traps desestabilizan el enrutamiento—aplicar CoPP y límites de tasa de telemetría.

Escenario de problema práctico

Acme BioTech debe soportar formación por video multicast de sitio a sitio, VoIP y acceso a Internet en la nube desde dos centros de datos redundantes conectados a través de MPLS con una VPN de Internet como respaldo. Los usuarios informan de congelaciones intermitentes del video durante las formaciones y una degradación ocasional de la calidad de las llamadas durante los eventos de conmutación por error.

Enfoque:

1. Normalizar y asegurar el tiempo en toda la infraestructura.

• Configurar NTPv4 en todos los dispositivos de red hacia servidores locales de stratum-2 con autenticación. Justificación: Un tiempo consistente asegura análisis de QoS válidos, correlaciona syslog/NetFlow y previene anomalías en los certificados que podrían interrumpir las API de gestión durante la conmutación por error.

2. Estabilizar DHCP y DNS para los endpoints de infraestructura y los teléfonos.

• Asegurar ip helper-address en las SVI de acceso, habilitar la inserción de la Opción 82 en el acceso y la confianza en la distribución, y proporcionar la Opción 150 para el TFTP de los teléfonos donde sea aplicable. Validar que los resolutores de DNS sean alcanzables desde todas las VLAN. Justificación: Un direccionamiento y resolución de nombres estables eliminan los re-registros espurios de teléfonos y los fallos de descubrimiento de AP/controladores que pueden derivar en problemas de QoS.

3. Implementar QoS con un límite de confianza (trust boundary) claro y modelado de tráfico (shaping) en la WAN.

• Confiar en las marcas de los teléfonos IP y los endpoints de TelePresence; remarcar los PC a default. Aplicar LLQ para EF al 10% con un policer, AF41 para video interactivo al 20% con WRED, y modelar el egreso al CIR de MPLS en los bordes de la WAN. Justificación: Preserva la voz y el video interactivo bajo contención y evita los descartes por el ‘policing’ del proveedor al ajustarse a la tasa contratada.

4. Optimizar multicast para el campus y la WAN.

• Desplegar PIM-SM en el core con Anycast-RP entre los dos centros de datos usando MSDP, habilitar IGMP v3 en las VLAN de acceso y preferir SSM (232/8) para los flujos de formación donde las fuentes son conocidas. Justificación: Anycast-RP mantiene el inicio de las sesiones entre los centros de datos; SSM elimina la dependencia del RP para los flujos de formación principales y simplifica el tránsito por la WAN.

5. Validar NAT y la simetría de la ruta en el borde de Internet.

• Usar NAT con estado (stateful) en el par de HA para PAT de salida, NAT estático determinista para servicios de entrada, y asegurar que HSRP se alinee con el par con estado activo. Justificación: Evita la pérdida de sesión y la asimetría durante la conmutación por error que podrían afectar a los medios de los softphones hacia los servicios en la nube.

6. Desplegar IP SLA con seguimiento de objetos para automatizar la conmutación por error al respaldo de Internet.

• Configurar sondas IP SLA de UDP jitter hacia el SBC de la nube e ICMP hacia el PE de MPLS; seguir los resultados para ajustar las rutas estáticas o influir en la preferencia local de BGP. Justificación: Mide la calidad real del servicio, no solo la alcanzabilidad; desencadena una conmutación por error controlada antes de que los usuarios noten la degradación.

7. Instrumentar la telemetría y proteger el plano de control.

• Transmitir contadores de profundidad de cola y descartes a través de telemetría basada en modelos (model-driven telemetry) a los recolectores, habilitar NetFlow/IPFIX en los bordes de la WAN y restringir SNMP a las IP del NMS con SNMPv3. Aplicar CoPP con una clase explícita para el tráfico de gestión. Justificación: Proporciona visibilidad procesable al tiempo que garantiza que el plano de control permanezca estable bajo la carga de monitorización.

8. Probar, observar y ajustar.

• Ejecutar una formación multicast programada con llamadas VoIP sintéticas mientras se capturan show policy-map interface, show ip mroute y los descartes de cola. Ajustar los anchos de banda de LLQ y AF41 basándose en la utilización medida y el comportamiento del proveedor. Justificación: El ajuste empírico alinea las asignaciones de QoS con los patrones de tráfico reales y las características del ‘policing’ del proveedor.

Esta secuencia aborda la estabilidad del reloj, los servicios fundamentales, el encolado y control de tasa, el comportamiento correcto del plano de control de multicast, la simetría de NAT, la conmutación por error automatizada y la observabilidad—produciendo en conjunto un rendimiento de voz y video consistente a través de las rutas de MPLS e Internet.

← Enrutamiento Unicast y Control de Rutas · Todos los dominios · Infraestructura Inalámbrica y Movilidad →

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