Cisco 300-410: Calidad de Servicio y Protección del Plano de Control — Guía de estudio

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Forma parte de la Cisco CCNP Enterprise 300-410 ENARSI — 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 Calidad de Servicio (QoS) y la Protección del Plano de Control (CoPP/CPPr) garantizan conjuntamente que las aplicaciones críticas para el negocio y la propia red permanezcan estables bajo carga y ataques. QoS diferencia el tráfico, prioriza los flujos sensibles al retardo y gestiona la congestión en enlaces con recursos escasos. CoPP/CPPr protege la CPU del router y la pila de gestión de sobrecargas accidentales y eventos maliciosos. Un diseño correcto depende de un marcado de extremo a extremo consistente, límites de confianza disciplinados, un acondicionamiento apropiado (policing/shaping), colas de tamaño adecuado, prevención proactiva de la congestión, un tratamiento cuidadoso de los túneles/cifrado y una validación continua mediante contadores correlacionados con el comportamiento de la aplicación.

Clasificación, Confianza y Marcado de Extremo a Extremo

La clasificación y el marcado del tráfico determinan cómo se encolarán y potencialmente se descartarán los paquetes en cada salto.

• Clasificación y correspondencia

  • Hacer corresponder con listas de acceso, precedencia de IP/DSCP, CoS (802.1p), firmas de aplicación NBAR o cabeceras internas de túneles (con qos pre-classify).
  • Mantener el determinismo: hacer corresponder con campos de Capa 3/4 cuando sea posible; usar NBAR solo cuando sea necesario debido a las implicaciones en la CPU en algunas plataformas.

• Límites de confianza

  • Definir dónde la red acepta los marcados existentes. Típico: no confiar en los hosts finales; confiar en los teléfonos empresariales y en los enlaces ascendentes (uplinks) a dominios de QoS conocidos.
  • En el borde, remarcar el tráfico no confiable a los valores DSCP definidos por la política; confiar solo en los dispositivos que usted gestiona y autentica.
  • En los puertos del switch hacia los puntos finales, eliminar la confianza (no trust dscp/cos) a menos que verifique explícitamente el tipo de dispositivo.

• Marcado

  • DSCP (6 bits) es el marcado principal de extremo a extremo en redes IP. La precedencia de IP (3 bits) es heredada (legacy) y se mapea a los bits superiores de DSCP.
  • CoS (802.1p, 3 bits) marca las tramas de Capa 2 a través de troncales VLAN; mapear DSCP↔CoS de manera consistente en los límites L2/L3.
  • En los núcleos MPLS, la Clase de Tráfico (TC, anteriormente EXP) de 3 bits transporta la QoS; mapear DSCP a TC en el ingreso y TC de vuelta a DSCP en el egreso para preservar la semántica a través del núcleo VPN o TE.

• Consistencia del marcado

  • Reservar EF para el portador de voz (bearer de voz, bajo jitter), CS3/AF31/AF32 para señalización de llamadas, AF4x para video interactivo, AF2x/AF1x para datos críticos, CS0/BE para mejor esfuerzo (best effort) y CS1 para scavenger.
  • Documentar una única política de QoS empresarial; asegurar que los proveedores de WAN la respeten y mapeen según lo contratado.
  • Evitar el remarcado a mitad de camino a menos que se traduzca entre dominios; de lo contrario, se arriesga a una inversión de prioridad y a una mayor complejidad en la resolución de problemas.

Ejemplo (marcado en el borde de ingreso):

undefined

Modos de fallo y contrapartidas:

• Confiar en el borde equivocado conduce al abuso de prioridades; los flujos de bajo valor pueden dejar sin recursos (starve) a las colas críticas.
• Mapeos inconsistentes de DSCP↔CoS rompen la QoS en las transiciones L2/L3.
• El uso excesivo de NBAR en plataformas de software puede elevar el uso de la CPU; prefiera correspondencias estáticas.

Acondicionamiento, Encolamiento y Prevención de Congestión

El acondicionamiento de tráfico modela el tráfico a las tasas que la red puede sostener y aplica políticas de control donde se requieren límites estrictos.

• Policing vs. shaping

  • El policing impone una tasa usando cubos de tokens (token buckets); el exceso se descarta u opcionalmente se remarca. Preserva la capacidad del enlace pero aumenta la pérdida y puede desencadenar el retroceso (backoff) de TCP y reintentos de la aplicación.
  • El shaping almacena en búfer y libera a una tasa objetivo (típicamente a un CIR del proveedor) suavizando las ráfagas y reduciendo los descartes aguas abajo; añade retardo y jitter proporcionales a la profundidad de la cola.

• Parámetros de ráfaga

  • Los policers de una sola tasa y dos parámetros usan la tasa de información comprometida (CIR) con una ráfaga comprometida (Bc) y opcionalmente Be (ráfaga en exceso).
  • Un Bc demasiado pequeño en relación con el RTT y el MTU causa descartes a nivel de fragmentación y un rendimiento ineficaz; dimensione Bc a al menos 1–2 veces el producto ancho de banda-retardo para el shaping, y a varios MTU para el policing.

• CBWFQ y LLQ

  • Class-Based Weighted Fair Queuing garantiza un ancho de banda mínimo a las clases. Configure el ancho de banda en kbps o como porcentaje bajo el shape.
  • Low-Latency Queue (LLQ) añade un servicio de prioridad estricta a una clase (priority), controlado (policed) a la tasa configurada para evitar la inanición (starvation). Solo el portador (bearer) de voz/video en tiempo real debería estar en la LLQ.
  • Los límites de cola (queue-limit) establecen el máximo de paquetes almacenados en búfer por clase; un valor demasiado alto aumenta la latencia, uno demasiado bajo aumenta los descartes. Equilibre con la tolerancia de la aplicación.

• WRED vs. tail drop

  • Tail drop descarta solo cuando las colas están llenas; esto puede causar sincronización global de TCP y grandes oscilaciones.
  • Weighted Random Early Detection (WRED) comienza los descartes probabilísticos antes de que la cola se llene; WRED basado en DSCP permite que las clases de mayor prioridad toleren colas más profundas con una menor probabilidad de descarte temprano.
  • WRED beneficia a los flujos TCP; para tráfico predominantemente UDP (voz) añade pérdida sin el beneficio del retroceso (backoff). No habilite WRED en la LLQ.

Ejemplo (shaping padre con CBWFQ/LLQ y WRED hijo):

undefined

Puntos clave de diseño:

• Siempre aplique shaping al cuello de botella más bajo aguas abajo que usted controle; deje que su encolamiento decida, no el mecanismo de descarte del proveedor.
• Dimensione la LLQ basándose en el códec y el volumen de llamadas; incluya un 5–10% de sobrecarga (overhead) para cabeceras y la variabilidad de VAD.
• Habilite WRED solo donde dominen los flujos TCP multiplexados; ajuste los pesos de forma conservadora para evitar descartes prematuros.

QoS en túneles y enlaces WAN

Los túneles y el cifrado ocultan las cabeceras internas y cambian el MTU, lo que afecta a la clasificación y la fragmentación.

• GRE/DMVPN e IPsec

  • Sin un manejo especial, la clasificación solo ve las cabeceras externas. Utilice qos pre-classify en las interfaces de túnel para que el dispositivo clasifique según la 5-tupla interna y el DSCP antes de la encapsulación/cifrado.
  • Preserve o copie el DSCP a la cabecera externa para mantener el comportamiento de QoS de la red durante el tránsito.
  • Ajuste el MTU y el MSS para evitar la fragmentación y los fallos de PMTUD; para IPsec, puede ser necesaria la fragmentación después del cifrado (fragmentation after-encryption) en ciertas plataformas y proveedores.

• QoS por túnel y diseño jerárquico

  • En mGRE/DMVPN, aplique QoS jerárquico (shape por túnel y luego LLQ/CBWFQ por clase) para garantizar un reparto equitativo entre los spokes.
  • Cuando los circuitos del proveedor imponen un CIR con policers estrictos, aplique shaping a un valor igual o ligeramente inferior al CIR para evitar los tail drops del proveedor.

Ejemplo (QoS en un túnel hub/spoke de DMVPN): interface Tunnel30 ip address 10.0.30.1 255.255.255.0 tunnel mode gre multipoint qos pre-classify ip mtu 1400 ip tcp adjust-mss 1360 service-policy output PM-WAN-PARENT ! crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac crypto ipsec profile DMVPN-PROFILE set transform-set TS ! ! Dependiente de la plataforma: crypto ipsec fragmentation after-encryption

Errores comunes y mitigaciones:

• La falta de qos pre-classify provoca que todo el tráfico caiga en la class-default después del cifrado, dejando sin recursos a los flujos de tiempo real.
• Un MTU/MSS incorrecto causa blackholing de segmentos grandes y un rendimiento errático de las aplicaciones; valide el MTU de la ruta de extremo a extremo.
• Aplicar políticas complejas a velocidad de línea (line rate) en túneles de software puede sobrecargar la CPU; prefiera la descarga a hardware (hardware offload) cuando esté disponible.

Protección del Plano de Control (CoPP/CPPr) y Validación Operacional

CoPP protege la CPU del router clasificando y limitando la tasa del tráfico de control y gestión en la ruta del plano de control. CPPr añade una granularidad más fina utilizando las subinterfaces host, transit y CEF-exception.

• Fundamentos de CoPP

  • Asociar las políticas al plano de control, no a las interfaces de datos.
  • Los tipos de coincidencia (match) comúnmente soportados son ip dscp, ip precedence y access-group. No utilice la palabra clave log en las entradas de ACL a las que hace referencia CoPP.
  • Separar los protocolos de enrutamiento críticos (BGP, OSPF, RSVP/LDP cuando aplique) del tráfico de gestión de mejor esfuerzo (HTTP) y del tráfico de control masivo (exportaciones de NetFlow a la CPU en casos de excepción). Proporcione CIRs generosos para los protocolos críticos.

• Detalles de CPPr

  • control-plane host gobierna el tráfico que termina en el router (p. ej., SSH, SNMP, sesiones de enrutamiento).
  • control-plane transit maneja el tráfico de excepción desviado (punted) desde el hardware (p. ej., TTL excedido, MTU excedido).
  • control-plane cef-exception gestiona los desvíos (punts) relacionados con CEF.
  • Aplicar políticas diferentes por subinterfaz para evitar daños colaterales cuando una clase se comporta de forma anómala.

• Ejemplo de CoPP con exclusiones y asociación correcta: ip access-list extended ACL-TELNET-EXEMPT deny tcp host 10.1.1.1 any eq 23 deny tcp host 172.16.1.1 any eq 23 permit ip any any ip access-list extended ACL-BGP permit tcp any any eq 179 permit tcp any eq 179 any ip access-list extended ACL-HTTP permit tcp any any eq 80 permit tcp any any eq 443 ! class-map match-any CM-BGP match access-group name ACL-BGP class-map match-any CM-HTTP match access-group name ACL-HTTP class-map match-any CM-TELNET match access-group name ACL-TELNET-EXEMPT ! policy-map PM-COPP class CM-BGP police cir 256000 conform-action transmit exceed-action transmit class CM-HTTP police cir 64000 conform-action transmit exceed-action drop class CM-TELNET police cir 100000 conform-action transmit exceed-action drop class class-default police cir 32000 conform-action transmit exceed-action drop ! ! Asegurarse de que la política está en el plano de control y no en las interfaces de datos: no interface GigabitEthernet0/0 service-policy input PM-COPP control-plane service-policy input PM-COPP

Notas:

• Limitar la tasa de BGP de forma demasiado agresiva puede causar la pérdida de keepalives, reinicios de sesión e inestabilidad de rutas (route churn). Si debe aplicar police, establezca un CIR suficiente y considere exceed-action transmit para evitar caídas durante los picos.

• Excluya fuentes de gestión de confianza específicas utilizando deny en la ACL antes del permit; aplique la ACL como una coincidencia (match) bajo la clase correspondiente.

• Complementos del plano de gestión

  • IPv6 RA Guard bloquea los Router Advertisements no autorizados (rogue) en los puertos L2, pero no puede proteger cuando el RA está tunelizado; aplique la protección en los puntos finales del túnel o use autenticación cuando sea posible.
  • IPv6 Source Guard utiliza la tabla de binding para permitir solo direcciones de origen válidas; descarta el tráfico de fuentes IPv6 desconocidas/no asignadas en los puertos de acceso, reduciendo el tráfico de excepción que consume CPU.
  • El fortalecimiento del dispositivo (hardening) (deshabilitar servicios no utilizados, usar ACLs en las vty, limitar las comunidades SNMP) reduce la exposición del plano de control.

• Validación y contadores

  • Use show policy-map interface <int> y show policy-map control-plane para verificar los contadores de paquetes, las caídas y las acciones de police. Ejecute primero show policy-map control-plane cuando aparezcan síntomas de sobrecarga de la CPU (p. ej., lentitud en SSH, SNMP intermitente).
  • En plataformas con reenvío por hardware, correlacione con show platform hardware qfp active statistics drop o contadores de ASIC equivalentes para caídas de WRED/tail drops.
  • Para las colas, verifique la profundidad de la cola, las caídas de tail/WRED y el policing de la cola de prioridad usando show policy-map interface y show queueing interface.
  • Busque síntomas en las aplicaciones:
    • Jitter en la voz, pérdida de paquetes o audio entrecortado sugiere que la LLQ es demasiado pequeña o que la frontera de confianza (trust boundary) es incorrecta.
    • SSH lento o con desconexiones, pero con pings normales, puede indicar que CoPP está aplicando policing al tráfico de gestión.
    • SNMP intermitente se correlaciona con caídas en la clase de gestión o con desvíos (punts) de excepción de CEF que exceden los límites.
    • Es de esperar un colapso del rendimiento de TCP bajo carga con un aumento de las caídas de WRED; si solo hay tail drop, busque flujos sincronizados en forma de diente de sierra (sawtooth).

Escenario de Problema Práctico

Acme Engineering opera una red DMVPN con un único hub sobre banda ancha de Internet con IPsec+mGRE. Los usuarios reportan VoIP entrecortada hacia la sede central (HQ), sondeos SNMP intermitentes a los routers de las sucursales y conexiones SSH lentas o que se desconectan del hub durante las horas pico.

1. Establecer fronteras de confianza (trust boundaries) y remarcar en el borde

• Justificación: Los teléfonos y los enlaces ascendentes de confianza son los únicos dispositivos autorizados para establecer EF/CS3; todo el resto del tráfico de acceso se remarca a BE. Esto evita el abuso de prioridad que podría dejar sin recursos a las clases de tiempo real.

2. Implementar QoS jerárquico en el túnel DMVPN

• Justificación: Aplicar un modelador (shaper) padre al túnel con la tasa medida del proveedor (p. ej., 20 Mbps) para evitar el policing del proveedor. Bajo el padre, usar LLQ para la voz EF, clases de ancho de banda para video y datos críticos, WRED para las clases dominadas por TCP, y fair-queue para la clase por defecto. Esto localiza la gestión de la congestión antes de que el operador descarte paquetes.

3. Habilitar qos pre-classify y ajustar MTU/MSS

• Justificación: qos pre-classify asegura que la política coincida con la IP/puerto/DSCP internos antes de la encapsulación GRE/IPsec. ip mtu 1400 y ip tcp adjust-mss 1360 evitan la fragmentación/agujeros negros (blackholing) debido a la sobrecarga de la encapsulación. La fragmentación post-cifrado (after-encryption) se configura para adaptarse al comportamiento del proveedor.

4. Eliminar la política CoPP aplicada a la interfaz y asociarla al plano de control

• Justificación: CoPP debe proteger la CPU independientemente de la interfaz de ingreso. Desasocie cualquier service-policy de entrada de las interfaces físicas y aplique PM-COPP al control-plane para gobernar de forma centralizada el tráfico desviado (punted) y el que termina en el host.

5. Crear clases de CoPP distintas con CIRs seguros; excluir las fuentes de confianza

• Justificación: Colocar BGP en su propia clase con un CIR suficiente para los keepalives y las ráfagas; configurar conform/exceed transmit para evitar reinicios de sesión. Aplicar police a HTTP/HTTPS con tasas bajas para limitar la gestión web hacia la CPU. Para las excepciones de Telnet/SSH, denegar las IPs de gestión de confianza en la ACL para que la política no les limite la tasa, mientras se sigue controlando a todas las demás fuentes.

6. Validar e iterar basándose en los contadores y los síntomas

• Justificación: Usar show policy-map control-plane para confirmar que las caídas de tráfico de gestión se corresponden con los problemas observados en SSH/SNMP; ajustar los CIRs hasta que cesen las caídas. Usar show policy-map interface Tunnel30 para verificar la utilización de LLQ y asegurar que no ocurra policing por desbordamiento de la prioridad bajo un volumen de llamadas normal. Monitorear las caídas de WRED y tail drop en las clases críticas; si la calidad de la voz sigue siendo mala sin caídas en LLQ, aumentar ligeramente el porcentaje de LLQ; si ocurren caídas, dimensionar la LLQ y el shaper padre con mayor precisión según el códec y el ancho de banda.

Al aplicar una frontera de confianza correcta, modelar el tráfico (shaping) antes del cuello de botella, clasificar antes de la encapsulación y proteger el plano de control con políticas CoPP/CPPr con el alcance adecuado, Acme Engineering restaura la calidad de la voz y estabiliza el acceso de gestión sin sacrificar el rendimiento general.

← Enrutamiento y Distribución Multicast · Todos los dominios · VPN →

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