0% del curso completado
Troubleshooting de direccionamiento IPv4 (1.3)
📋 En esta lección
Cierre del módulo: los cinco errores de direccionamiento que causan el 90% de las averías de conectividad IP, cómo se manifiestan y cómo cazarlos en minutos. Trabajamos con casos reales completos — síntoma, diagnóstico, causa — porque así es como aparecen en la vida real y en el examen.
El método: la escalera de ping + leer la configuración
Del Módulo 2 tienes el diagnóstico físico (show interfaces, cables, dúplex). Asumamos aquí que la capa 1-2 está sana: el enlace está up/up y aun así "no hay red". El 90% de las veces será uno de estos cinco sospechosos:
- Dirección APIPA (DHCP no respondió)
- Gateway mal configurado o fuera de la subred
- Máscara incorrecta (inconsistente entre dispositivos)
- Dirección IP duplicada
- Subredes solapadas o el propio DNS
La herramienta de trabajo es la escalera de ping de la lección anterior (loopback → propia IP → gateway → exterior → nombre) combinada con leer la configuración real (ipconfig /all, show ip interface brief). Vamos caso a caso.
Caso 1: la dirección 169.254.x.x
Síntoma: "No tengo nada de red." ipconfig muestra 169.254.201.77, máscara 255.255.0.0, sin gateway.
Lectura inmediata: APIPA — el equipo pidió DHCP y nadie contestó. El problema no está en el PC: está entre el PC y el servidor DHCP.
Diagnóstico en orden:
- ¿Más usuarios afectados? Si toda la planta tiene APIPA → servidor DHCP caído o sin direcciones libres en el pool. Si es solo este puesto → sigue.
- ¿El puerto del switch está en la VLAN correcta? (
show interfaces status) — un puerto en la VLAN equivocada pide DHCP a una subred donde no hay servidor. - ¿El DHCP está en otra subred? Entonces el router intermedio necesita DHCP relay (
ip helper-address, lección 8.1). Si alguien lo quitó o cambió la IP del servidor sin actualizarlo, todos los clientes de esa VLAN quedan huérfanos.
Caso 2: gateway equivocado
Síntoma: el usuario llega a los recursos de su propia subred (impresora local, NAS del departamento) pero no a Internet ni a otras sedes.
Lectura: la comunicación local no usa el gateway; todo lo demás sí. Conectividad local intacta + exterior roto = el gateway es el sospechoso número uno.
Posibilidades, de más a menos frecuente:
- Gateway mal tecleado en configuración estática (10.1.10.1 vs 10.1.10.254).
- Gateway fuera de la subred del host (host 10.1.10.44/24 con gateway 10.1.20.1): el sistema operativo no puede ni intentarlo — para alcanzar ese gateway necesitaría… un gateway.
- El gateway existe pero está caído:
pinga la IP del gateway lo confirma. Si el gateway es un router con HSRP (lección 7.6), comprueba la IP virtual, no la física.
Caso 3: máscara inconsistente
El más traicionero, porque falla a medias.
Síntoma: el host A (10.1.10.44 con máscara /25 por error, en una red /24) habla perfectamente con unos compañeros y no ve a otros.
Por qué: para A, "su red" termina en 10.1.10.127. A los hosts .1-.126 los busca por ARP directamente — funciona. A los .128-.254 los cree remotos y les envía el tráfico al gateway; el gateway los devuelve a la LAN (con suerte, mediante redirect ICMP) o el retorno asimétrico rompe cosas sutilmente.
La pista delatora: conectividad parcial dentro de la propia subred — funciona con la mitad baja del rango y no con la alta (o viceversa). Eso es firma de máscara, no de cable. Compara la máscara del host con la del gateway (ipconfig vs show ip interface brief): deben ser idénticas en toda la subred.
Caso 4: IP duplicada
Síntoma: conectividad intermitente que "va y viene", avisos del sistema operativo ("conflicto de dirección IP"), o un dispositivo que funcionaba deja de responder cuando otro se enciende.
Por qué: dos dispositivos con la misma IP responden ambos al ARP; la caché ARP de los vecinos alterna entre las dos MACs y el tráfico llega a uno u otro según el momento.
Cazarla:
! En el router, ¿qué MAC tiene ahora esa IP?:
Router# show arp | include 10.1.10.50
Internet 10.1.10.50 3 001a.2b3c.4d5e ARPA Gi0/0
! En el switch, ¿en qué puerto vive esa MAC?:
Switch# show mac address-table address 001a.2b3c.4d5e
Con el puerto localizado, ya sabes qué cable seguir. La causa raíz casi siempre es una IP estática dentro del rango del pool DHCP — alguien configuró a mano una dirección que el DHCP también reparte. La cura de fondo: respetar el plan de direccionamiento (los estáticos fuera del pool, lección 4.4) o crear reservas DHCP.
Caso 5: "no funciona Internet" (pero sí funciona)
Síntoma: ping 8.8.8.8 responde; ping google.com → "no se pudo encontrar el host".
Lectura: IP, gateway, routing y NAT están perfectos. Lo roto es la resolución de nombres: DNS mal configurado, servidor caído o filtrado. Para el usuario es "no hay Internet"; para ti es capa de aplicación.
nslookup google.com confirma y da el detalle (¿a qué servidor pregunta?, ¿responde?). El diagnóstico DNS completo — registros, cachés, herramientas — es la lección 8.2.
La tabla de decisión
| Síntoma observado | Sospechoso | Verificación |
|---|---|---|
| IP 169.254.x.x | DHCP no llega | ¿Más afectados? ¿VLAN del puerto? ¿ip helper-address? |
| Local OK, exterior no | Gateway | ipconfig vs realidad; ping al gateway; ¿dentro de la subred? |
| Conectividad parcial dentro de la subred | Máscara inconsistente | Comparar máscara host vs gateway |
| Intermitente, conflictos, "va y viene" | IP duplicada | show arp + show mac address-table; ¿estática dentro del pool? |
| IPs sí, nombres no | DNS | nslookup; revisar DNS configurado |
| Nada, ni el loopback | Pila TCP/IP del host | Driver, reinicio, hardware local |
💡 💡 Cambia una cosa cada vez
La tentación bajo presión es tocar tres cosas a la vez ("reinicio, cambio el cable y pongo IP fija"). Si funciona, no sabrás cuál era la causa — y volverá. Hipótesis → un cambio → verificar → siguiente. La disciplina de laboratorio es exactamente la que te salvará en producción, y la metodología completa la sistematizamos en el Módulo 12.
Lab propuesto (Packet Tracer)
Monta esta avería y resuélvela: red 10.0.0.0/24 con router (10.0.0.1), switch, cuatro PCs. Configura: PC1 correcto por DHCP; PC2 con gateway 10.0.1.1 (fuera de subred); PC3 con máscara /25; PC4 con la misma IP estática que reparte el DHCP a PC1. Predice qué fallará en cada uno antes de probar, y verifica con la escalera de ping. Si tus predicciones aciertan las cuatro, el módulo está dominado.
Relación con otros conceptos
- La escalera de ping viene de la lección 4.5; el diagnóstico físico previo (up/up, contadores), de la 2.4.
- El DHCP relay (
ip helper-address) y el servidor DHCP en IOS son la lección 8.1; el diagnóstico DNS a fondo, la 8.2. - ARP como herramienta de caza de duplicados viene de la lección 2.3 (
show arp,show mac address-table). - La metodología estructurada general de troubleshooting — aplicable a cualquier avería, no solo IP — cierra el curso en la lección 12.1.
Resumen
Cinco patrones cubren casi todo el troubleshooting de direccionamiento: APIPA (169.254 = DHCP no llegó: mira VLAN, pool y relay), gateway (local OK + exterior KO: verifica valor, subred y estado), máscara inconsistente (conectividad parcial dentro de la propia subred: compara máscaras), IP duplicada (intermitencia + conflictos: caza con ARP y tabla MAC; causa típica, estáticas dentro del pool) y DNS (IPs sí, nombres no). Método siempre: escalera de ping para aislar el tramo + leer la configuración real + un solo cambio cada vez.