Cisco 200-301: Servicios IP, NAT y Calidad de Servicio — Guía de estudio

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Forma parte de la Cisco CCNA 200-301 — 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 interconectan las redes y las mantienen observables, alcanzables y predecibles bajo carga. Esta sección cubre la entrega de servicios principales (DHCP, DNS, NTP), la visibilidad y señalización (SNMP, syslog, NetFlow, telemetría), la traducción de direcciones (NAT) y la gestión del tráfico (QoS), para luego vincularlos con la redundancia de primer salto y la validación operativa. Las decisiones de diseño enfatizan el comportamiento determinista, el mínimo privilegio y la degradación gradual durante las fallas.

Servicios IP principales: DHCP, DNS y NTP

DHCP

• Componentes y flujo: Un cliente utiliza DORA (Discover, Offer, Request, Acknowledgment - Descubrimiento, Oferta, Solicitud, Confirmación). Los pools de servidores (ámbitos o scopes) definen rangos de direcciones, máscaras, puertas de enlace (Opción 3), DNS (Opción 6), temporizadores y opciones de proveedor (por ejemplo, la Opción 150 para TFTP para teléfonos IP).
• Relé (Relay): Cuando el servidor no está en la subred del cliente, una interfaz de Capa 3 retransmite los broadcasts usando ip helper-address para enviar la solicitud como unicast al servidor. El DHCP snooping inserta la Opción 82 (circuit-id/remote-id) para que el servidor pueda tomar decisiones basadas en la ubicación.
• Ámbitos y exclusiones: Cree pools lo suficientemente grandes para los clientes esperados más el crecimiento. Reserve direcciones estáticas mediante reservas por MAC o exclúyalas de la asignación dinámica con ip dhcp excluded-address.
• Concesiones (Leases): Equilibre la rotación (churn) frente a la reutilización de direcciones; las concesiones más cortas aceleran la recuperación, pero aumentan el tráfico DHCP.
• Modos de fallo comunes:
  • Falta la dirección del helper o es incorrecta, o ACLs que bloquean UDP 67/68.
  • No hay un ámbito coincidente, el pool está agotado o hay subredes superpuestas.
  • Opción de puerta de enlace predeterminada incorrecta que causa fallos de alcanzabilidad tras el arranque.
  • Configuración errónea de la confianza en DHCP snooping que descarta las respuestas del servidor.
• Comandos útiles:
  • show ip dhcp binding, show ip dhcp pool, show ip dhcp conflict
  • debug ip dhcp server events
• Ejemplo mínimo de relé:
  • interface Vlan10 ip address 10.10.10.1 255.255.255.0 ip helper-address 192.0.2.10

DNS

• Flujo de resolución: Un resolutor stub comprueba la caché del host y el archivo hosts, y luego consulta a un resolutor recursivo. El servidor recursivo consulta iterativamente a los servidores raíz, de TLD y autoritativos, almacena en caché las respuestas según su TTL y devuelve una contestación. Los fallos pueden ser NXDOMAIN (el nombre no existe) o SERVFAIL (problema al resolver).
• Guía de diseño: Use resolutores recursivos redundantes; prefiera anycast para la localidad y la disponibilidad; ajuste los TTL para equilibrar la agilidad y la eficiencia de la caché. Aplique listas blancas (allowlists) de DNS para segmentos sensibles.
• Modos de fallo comunes:
  • UDP/TCP 53 bloqueado o asimétrico, manejo de EDNS defectuoso o problemas de MTU/fragmentación.
  • Dominios de búsqueda mal configurados que causan una resolución de FQDN incorrecta.
  • Caché obsoleta/envenenada; fallo en la validación de DNSSEC.
• Conceptos básicos de configuración del dispositivo: ip domain-lookup, ip name-server 198.51.100.53, show hosts.

NTP

• La sincronización de tiempo permite la correlación (logs, flujos, seguridad) y la medición precisa del retardo/jitter. La jerarquía utiliza valores de estrato (stratum) (1 está conectado directamente a un reloj de referencia; 16 está desincronizado).
• Los clientes, servidores y pares (peers) forman un árbol de tiempo estable; autentique NTP con claves para evitar la suplantación (spoofing).
• IP SLA y jitter: Se requiere una sincronización de tiempo precisa (por ejemplo, con NTP) al medir el retardo unidireccional y para garantizar cálculos de jitter válidos entre nodos.
• Modos de fallo comunes: Servidores inalcanzables, rutas asimétricas/desviación (skew), confusión con el horario de verano/zona horaria o aceptación inadvertida de servidores no autenticados.
• Comandos útiles:
  • ntp authenticate; ntp authentication-key 1 md5 ; ntp trusted-key 1; ntp server 192.0.2.20 key 1
  • show ntp status, show ntp associations

Visibilidad y control: SNMP, Syslog, NetFlow y telemetría

SNMP

• Versiones: v2c (basado en comunidad) vs. v3 (autenticación/privacidad). Prefiera v3 con authPriv para integridad y confidencialidad.
• Sondeo (polling) vs. traps/informs: Realice sondeos para métricas regulares; envíe traps/informs sobre cambios de estado. Los informs incluyen fiabilidad mediante acuse de recibo.
• Seguridad y escala: Restrinja los managers mediante ACLs; limite la tasa de traps; minimice los OIDs costosos; evite las comunidades por defecto public/community.

Syslog

• Niveles: 0 emergencia, 1 alerta, 2 crítico, 3 error, 4 advertencia, 5 notificación, 6 informativo, 7 depuración.
• Habilite las marcas de tiempo y los números de secuencia; envíe a recolectores redundantes; establezca la facilidad (facility)/nivel por cada característica para evitar el ruido.
• Ejemplo:
  • service timestamps log datetime msec
  • logging host 192.0.2.30
  • logging trap informational

NetFlow

• Captura metadatos de conversación (5-tupla, contadores, marcas de tiempo). v5 es fijo; v9/IPFIX se basan en plantillas y son extensibles.
• Diseño: Exporte al menos a dos recolectores; muestree según sea necesario para reducir el uso de CPU; asegure la sincronización de tiempo (NTP) para un análisis preciso.
• Ejemplo clásico:
  • ip flow-export destination 192.0.2.40 2055
  • ip flow-export version 9
  • interface GigabitEthernet0/0 ip flow ingress

Telemetría dirigida por modelos

• Transmisión (streaming) basada en push de datos seleccionados y modelados en YANG sobre transportes eficientes (por ejemplo, gRPC). Beneficios: menor latencia, uso de CPU predecible y mejor escalabilidad que el sondeo periódico de SNMP.
• Contrapartidas: Requiere recolectores que entiendan los modelos; seguridad del transporte y QoS para el propio flujo de datos.

Modos de fallo comunes y mitigaciones

• El registro o sondeo excesivo que causa picos de CPU: ajuste los niveles, agrupe en lotes o muestree.
• Desviación de tiempo: Corrija NTP para evitar eventos desordenados y un mal ensamblaje de flujos.
• Firewall/ACLs que bloquean el plano de gestión: dedique una gestión fuera de banda (OOB) o una VRF, y aplique control plane policing.

NAT y traducción de direcciones

Conceptos

• Terminología:
  • Inside local: Dirección privada original.
  • Inside global: Dirección traducida visible externamente.
  • Outside local/global: Dirección del host externo como se ve desde dentro/fuera.
• Tipos:
  • NAT estático (Static NAT): Mapeo fijo uno a uno; alcanzabilidad de entrada estable.
  • NAT dinámico (Dynamic NAT): Muchos a muchos a través de un pool; solo para salida hasta que se asigna una traducción.
  • PAT (sobrecarga): Muchos a uno o muchos a pocos usando puertos TCP/UDP; el más común para el egreso a Internet.

Razonamiento de diseño y contrapartidas

• NAT estático para servidores que necesitan acceso de entrada; PAT para clientes para conservar IPs públicas.
• NAT rompe la transparencia de extremo a extremo; algunos protocolos requieren ALGs (FTP, SIP). Prefiera el reconocimiento de aplicaciones en los bordes o use protocolos tolerantes a la traducción.
• Alta disponibilidad: FHRP mueve el gateway por defecto, pero el estado de NAT es por dispositivo; sin NAT con estado (stateful NAT), el failover reinicia los flujos. Coloque NAT en firewalls/routers de alta disponibilidad (HA) que soporten replicación de estado o dirija el egreso de forma determinista.

Ejemplos de configuración

• PAT usando la interfaz WAN:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

• NAT estático para un servidor:

undefined

Verificación y solución de problemas

undefined

,

undefined

undefined

• Problemas comunes: Falta de ‘inside’/‘outside’ en las interfaces, no hay ruta hacia el pool, pools superpuestos, ACL no coincidente, agotamiento de puertos en PAT, enrutamiento asimétrico a través de múltiples salidas o necesidades de hairpinning no abordadas.

Fundamentos de QoS: clasificación, marcado, encolado y gestión de congestión

Clasificación y marcado

• Clasificar por ACLs, precedencia IP/DSCP, CoS o NBAR. Marcar en el borde; preservar las marcas donde sean de confianza.
• DSCP y CoS:
  • DSCP EF (46) para el portador de voz (bearer); CS3/AF31–AF33 para señalización; AF41–AF43/CS4 para video interactivo.
  • Los valores de CoS en troncales 802.1Q requieren un mapeo a DSCP en las fronteras de L3.
• Límites de confianza (Trust boundaries):

  • Confíe solo en dispositivos que puedan ser responsabilizados (por ejemplo, un teléfono IP de Cisco). En un puerto de acceso con un teléfono, use la confianza basada en el dispositivo y preserve las prioridades downstream:

undefined

-

undefined

undefined

undefined

undefined

Encolado y gestión de congestión

• CBWFQ: Planificación ponderada por garantías de ancho de banda.
• LLQ: Añade una cola de prioridad estricta a CBWFQ para clases sensibles a la latencia (voz, video interactivo).
• PQ: Prioridad estricta pura; puede dejar sin servicio a otro tráfico si no se le aplica policing. Se prefiere LLQ porque aplica policing al tráfico prioritario por diseño.
• WRED: Descarte aleatorio temprano para evitar la sincronización global de TCP; no aplicar a colas de prioridad.

Policing y shaping

• Policing: Impone una tasa descartando/remarcando el exceso; baja latencia pero aumenta la pérdida y el jitter.
• Shaping: Almacena ráfagas en un búfer para ajustarlas a una tasa específica; añade retardo pero reduce los descartes downstream. Aplique shaping en enlaces de egreso más lentos antes de las políticas jerárquicas.

• Ejemplo de política LLQ:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Objetivos para voz y video

• Voz: Retardo unidireccional <150 ms, jitter <30 ms, pérdida <1%. Use LLQ para los portadores (bearers), proteja la señalización por separado.
• Video: El video interactivo necesita control de ancho de banda y jitter; el streaming es más tolerante a la pérdida pero consume mucho ancho de banda. Considere colas separadas y control de admisión.

Validación y medición

• Use IP SLA para generar tráfico sintético RTP/UDP y medir retardo, jitter y pérdida; asegure la precisión del tiempo con NTP.

undefined

para verificar contadores y descartes por clase.

Resiliencia: Impacto de FHRP y validación operativa

FHRP

• HSRP/VRRP proporcionan una puerta de enlace predeterminada virtual para sobrevivir a fallos del primer salto; GLBP añade balanceo de carga de la puerta de enlace.
• Diseño: Ajuste los temporizadores para equilibrar convergencia y estabilidad; use el seguimiento de objetos (object tracking) para conmutar por error ante la pérdida del enlace ascendente/WAN, no solo por la caída de la interfaz.
• Impacto en el servicio: Durante la conmutación por error, la actualización de ARP y el rehashing pueden causar una breve pérdida; los flujos en tiempo real sin simetría de ruta o estado de NAT replicado pueden reiniciarse. Mantenga la ruta de egreso consistente para el tráfico prioritario.

Validación operativa y resolución de problemas

• DHCP: Confirme las direcciones helper y la utilización del pool; capture paquetes para ver el proceso DORA; revise las tablas de DHCP snooping.
• DNS: Valide con nslookup/dig; verifique la redundancia de los resolvers; inspeccione las reglas del firewall y el comportamiento de MTU/EDNS.
• NAT: Verifique las traducciones durante los flujos activos; asegúrese de que existan rutas hacia la red local interna (inside local) y el pool; pruebe el NAT estático de entrada desde el exterior.
• NTP: Asegure un stratum sincronizado y un desfase (offset) bajo; requiera autenticación.
• QoS: Valide la confianza (trust); revise los contadores de la service-policy bajo una carga realista; ejecute pruebas de voz con IP SLA; vigile las caídas por el policer en el tráfico prioritario.
• Visibilidad: Confirme el funcionamiento de SNMPv3 y la entrega de traps; verifique que las marcas de tiempo de syslog sean correctas; alinee los exportadores de NetFlow con los colectores; asegúrese de que los flujos de telemetría sean estables.

Escenario de problema práctico

Acme Manufacturing experimenta intermitencias en las llamadas de teléfonos IP y fallos esporádicos de DHCP en una sucursal después de añadir un segundo ISP y habilitar PAT en un nuevo router.

1. Estabilizar el enrutamiento y la disponibilidad de la puerta de enlace con FHRP

• Configure HSRP en la SVI de la VLAN de la sucursal en ambos routers, establezca preempt y prioridades, y realice un seguimiento de los enlaces ascendentes de la WAN.
• Justificación: Una puerta de enlace predeterminada virtual oculta la conmutación por error del router a los dispositivos finales; el seguimiento de objetos (object tracking) mueve la puerta de enlace fuera de un router que ha perdido la conectividad ascendente.

2. Normalizar el comportamiento de NAT y prevenir el egreso asimétrico

• Implemente PAT solo en el router HSRP activo; asegúrese de que el router en espera (standby) no anuncie una ruta predeterminada a menos que esté activo, o implemente PBR para fijar el egreso de la VLAN de voz a un único router.
• Justificación: El egreso asimétrico rompe el PAT con estado (stateful) y los ALGs para SIP/RTP; un egreso consistente mantiene las traducciones y la estabilidad de las llamadas.

3. Corregir la fiabilidad del relay de DHCP

• En ambas puertas de enlace SVI, configure ip helper-address hacia los servidores DHCP centrales; verifique la confianza (trust) de DHCP snooping hacia el enlace ascendente y la desconfianza (untrust) hacia los puertos de acceso; excluya los rangos de IP estáticas.
• Justificación: Un relay adecuado asegura que el proceso DORA llegue a los servidores; el snooping previene servidores no autorizados (rogue) mientras permite las respuestas del servidor; las exclusiones evitan conflictos.

4. Establecer la hora precisa y habilitar la medición

• Configure clientes NTP en ambos routers con servidores autenticados, verifique el stratum y luego configure operaciones de IP SLA udp-jitter hacia el gestor de llamadas de la sede principal (HQ).
• Justificación: La hora precisa es fundamental para los cálculos de retardo unidireccional y jitter; IP SLA valida que la QoS puede soportar el tráfico de voz.

5. Implementar una política de QoS del borde a la WAN con límites de confianza (trust boundaries)

• Confíe en CoS en los puertos de acceso solo cuando se detecte un teléfono IP de Cisco; remarque el DSCP para voz a EF y para señalización a CS3; aplique LLQ con un 10% para voz, ancho de banda para video y fair-queue por defecto. Aplique shaping al CIR del proveedor antes de aplicar la política si la interfaz física es más rápida que la velocidad contratada.
• Justificación: Una confianza (trust) adecuada evita que los hosts inflen la prioridad; LLQ garantiza una baja latencia; el shaping evita caídas de paquetes en el borde del proveedor.

6. Mejorar la visibilidad y reforzar la seguridad del plano de gestión

• Habilite SNMPv3 hacia el NMS, syslog hacia colectores redundantes con marcas de tiempo, y exportadores de NetFlow v9 hacia herramientas de análisis; añada control-plane policing para SNMP y el registro de eventos (logging).
• Justificación: La observabilidad confirma las mejoras y detecta regresiones; una gestión segura reduce la superficie de ataque mientras mantiene la telemetría.

7. Validar y luego simular un fallo

• Use show policy-map interface para confirmar que los contadores de tráfico prioritario se incrementan durante las llamadas de prueba; observe las líneas base de jitter de IP SLA; ejecute traceroute y pruebe la conmutación por error forzando un cambio de estado de HSRP.
• Justificación: La validación operativa bajo carga verifica la intención del diseño; la conmutación por error controlada demuestra la resiliencia y revela cualquier caso extremo de NAT o convergencia.

← Enrutamiento Dinámico y Conectividad IP · Todos los dominios · Diseño y Operaciones de LAN Inalámbricas →

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