Última sesión del curso, y es distinta a todas las anteriores. Ya no hay apartados por tema, ni pistas de qué lección repasar, ni ejercicios "de subnetting" o "de DNS": hay incidencias. Cuatro casos completos — dos en Grupo Meridiano, dos en la Clínica Azahar, sobre la red que tú mismo diseñaste en la sesión anterior — contados como llegan en la vida real: un usuario que describe un síntoma a su manera, unas salidas de comandos, y nadie que te diga en qué capa está el problema. Tu trabajo es aplicar la metodología del módulo 6 (definir, reproducir, hipótesis, probar, aplicar, verificar, documentar) apoyándote en todo lo aprendido en los módulos 1 a 5. Es el examen final oficioso del curso — y el formato exacto de tu futuro día a día.

1. Cómo trabajar estos casos
2. Caso 1: el PC nuevo de Torrevieja que "tiene Internet pero no historiales"
3. Caso 2: "se ha caído Internet" en Meridiano Valencia
4. Caso 3: el servidor de historiales que va y viene
5. Caso 4: el router nuevo de Elche
6. Errores comunes al diagnosticar
7. Conclusión: fin del curso

• Cada caso tiene cuatro partes: contexto, síntomas, datos (salidas de comandos reales) y preguntas guiadas. La solución razonada viene después — y aquí, más que nunca: no la mires hasta tener tu diagnóstico escrito, con capa sospechosa y causa raíz incluidas.
• Trabaja con el método de 7 pasos de la lección 06-03. Las preguntas guiadas siguen su orden; si te atascas, vuelve a la pregunta de oro: ¿a quién afecta y qué cambió?
• Ten a mano tus planes de direccionamiento: el /24 de Meridiano Valencia (192.168.10.0/24, router .1, servidor .10, DHCP .100–.199) y tu plan VLSM de Azahar de la lección 07-05 (Alicante 172.20.40.0/26, sala de espera .64/27, Elche .96/28, Torrevieja .112/28, túneles .128/30 y .132/30). En estos casos, conocer el plan es la mitad del diagnóstico: varias pistas solo son visibles para quien sabe qué debería haber.
• Apunta qué módulos usas en cada caso. Al final verás que ninguno se resuelve con un solo módulo — esa es la gracia.

Azahar ya trabaja con el plan VLSM que diseñaste en la lección anterior. El lunes se incorpora una fisioterapeuta al consultorio de Torrevieja y el proveedor del software de historiales le instala el PC. Como el instalador "no se fiaba del DHCP", configuró la red a mano.

Martes, 9:40. Llama la fisio nueva: "puedo navegar por Internet sin problema, pero el programa de historiales dice no se puede conectar con el servidor. A mi compañera de la mesa de al lado le funciona todo".

En el PC nuevo:

En el PC de la compañera (funciona): 172.20.40.115, máscara 255.255.255.240, gateway 172.20.40.113, todo por DHCP.

1. Antes de tocar nada: ¿qué te dice el patrón "Internet sí, historiales no, y solo en este equipo"? ¿Qué descarta?
2. Compara el ipconfig del PC nuevo con tu plan de direccionamiento de Torrevieja. ¿Qué campo está mal?
3. ¿Por qué el ping al servidor falla con "Host de destino inaccesible" desde la propia IP del PC, y qué papel juega ARP en ese mensaje?
4. ¿Por qué, con ese mismo error de configuración, Internet funciona perfectamente?
5. Enuncia causa raíz, capa del modelo, solución y cómo prevenir la reincidencia.

Paso 1 — definir y acotar. Afecta a un solo equipo (la compañera trabaja) → la causa vive en ese puesto. Que algo funcione (Internet) descarta de golpe la capa física, el switch y la salida WAN del consultorio: no es "la red de Torrevieja", es este PC hablando con ese destino. El dato "lo configuraron a mano ayer" (qué cambió) apunta directo a la configuración.

Paso 2 — reproducir. Hecho en los datos: el gateway responde, el servidor no — y el mensaje no es un tímido "tiempo de espera agotado", sino "Host de destino inaccesible" emitido por el propio PC (fíjate: "Respuesta desde 172.20.40.120", su propia dirección). Eso significa que el PC ni siquiera intentó enviar el paquete lejos: decidió que no sabía entregarlo.

Paso 3 — hipótesis. Contrastando con el plan: Torrevieja es 172.20.40.112/28, máscara 255.255.255.240. El PC tiene máscara 255.255.255.0. Hipótesis: máscara errónea — el PC cree que TODO 172.20.40.0–255 es su red local.

Paso 4 — probar (entender el mecanismo). Con /24, el AND del módulo 5 le dice al PC que 172.20.40.10 está en su propia LAN → en lugar de enviárselo al gateway, lanza un ARP en el cable de Torrevieja preguntando "¿quién tiene 172.20.40.10?". Pero el servidor está en Alicante, al otro lado del túnel: en Torrevieja nadie responde a ese ARP. Sin MAC de destino no hay trama posible, y el sistema declara "Host de destino inaccesible" — por eso el arp -a no muestra ninguna entrada para .10. El gateway .113 sí responde porque casualmente está dentro de ambas versiones de la red (la real /28 y la imaginaria /24): el error queda enmascarado justo en la comprobación más habitual. E Internet funciona porque cualquier destino público (p. ej. 198.51.100.60) queda fuera incluso de la /24 imaginaria → ese tráfico sí se envía al gateway, que lo saca por NAT con total normalidad. El fallo solo afecta a los destinos 172.20.40.x remotos: historiales, impresoras de otras sedes… exactamente el síntoma.

Pasos 5 y 6 — aplicar y verificar. Se corrige la máscara a 255.255.255.240 (mejor aún: se pasa el PC a DHCP, como el resto del consultorio):

~39 ms y TTL 62 (64 − 2 routers: el de Torrevieja y el de Alicante): ahora el paquete cruza el túnel. El programa de historiales conecta. La fisio confirma.

Paso 7 — documentar. Causa raíz: máscara de subred errónea (/24 en una subred /28) en configuración manual — capa 3, configuración de direccionamiento. Prevención: los puestos de consultorio se configuran por DHCP (con reserva si el software exige IP fija), y cualquier proveedor externo recibe la hoja del plan de direccionamiento antes de instalar nada. Es, casi literalmente, el caso del NAS de la lección 05-02 — visto ahora desde la silla del que lo diagnostica.

Módulos usados: 2 (ARP), 5 (máscaras y AND), 6 (método y lectura de ping/arp).

Miércoles, 8:55. Empiezan a llegar avisos en cadena desde Valencia: "no hay Internet". Marta, Ana, administración — todos. En Bilbao, Jon confirma que allí todo funciona. Nadie recuerda ningún cambio… hasta que alguien menciona que el router de Valencia "se actualizó solo" esta madrugada (actualización automática de firmware programada por el ISP).

Ninguna web abre ("no se puede encontrar el servidor"). El correo tampoco. Y — detalle curioso que aporta un usuario observador — la intranet tampoco abre por su nombre, pero un marcador viejo que apunta a https://192.168.10.10 sí funciona.

Desde el PC de Marta:

1. El segundo ping es la bisagra del caso entero: ¿qué demuestra ping 1.1.1.1 respondiendo en 9 ms?
2. ¿Qué te dicen, combinados, los dos nslookup? Sé preciso: ¿qué componente exacto está fallando y cuál está sano?
3. ¿Cómo encaja la pista de "la intranet no va por nombre pero sí por IP"?
4. ¿En qué capa sitúas el problema y cuál es la causa raíz más probable, dado lo que cambió esta noche?
5. ¿Qué mejora permanente propondrías al documentar? (Pista: recuerda cómo terminó el caso C de la lección 06-03.)

Paso 1 — definir y acotar. Afecta a toda Valencia, a "todo Internet", con Bilbao sano → la causa está en algo común de Valencia (router, DHCP, DNS, salida WAN). Cambio conocido: firmware del router esta madrugada.

Pasos 2 y 3 — reproducir y afinar la hipótesis. Aquí está la finura del caso: "no hay Internet" resulta ser falso. ping 1.1.1.1 responde: hay cable, hay switch, hay IP, hay gateway, hay NAT y hay salida WAN — las capas 1 a 3 hasta Internet están intactas. Lo que no funciona es lo que convierte nombres en direcciones: la consulta DNS al servidor configurado (el router, 192.168.10.1) expira, pero la misma consulta a 8.8.8.8 resuelve al instante. Traducción exacta: la red está bien y el resolutor externo está bien; lo que ha muerto es el servicio DNS del router de Valencia. La pista de la intranet lo confirma por otro camino: por IP funciona (red sana, servidor sano), por nombre no (nadie resuelve intranet.grupomeridiano.example — el DNS interno es el mismo servicio del router). Y explica por qué "no hay Internet" para el usuario: sin DNS, ninguna URL abre; para un humano, eso es Internet caído.

Paso 4 — probar. En el panel del router, el servicio DNS forwarder aparece detenido tras la actualización de firmware de las 4:12 (los registros del router lo confirman — el "qué cambió" del paso 1 era la causa, como casi siempre).

Pasos 5 y 6 — aplicar y verificar. Se reinicia el servicio DNS del router (y se desactivan las actualizaciones automáticas en horario no controlado, que se reprograman a ventana de mantenimiento con aviso). Verificación con el comando que fallaba: nslookup www.proveedor-cloud.example contra el .10.1 resuelve, las webs abren, la intranet vuelve por nombre. Confirmado con dos usuarios.

Paso 7 — documentar. Causa raíz: servicio DNS del router detenido tras actualización de firmware — capa de aplicación (DNS), con la red por debajo intacta. Mejora permanente: tras el caso C del módulo 6, Meridiano dejó un único DNS (el .10.1) en el DHCP — hoy se ha pagado esa decisión: un solo servicio caído dejó "sin Internet" a la sede entera. Se añade un DNS secundario sano (p. ej. el resolutor del ISP) en las opciones del DHCP: con primario caído, los equipos habrían tardado unos segundos más… pero habrían funcionado. Y la lección de bolsillo, para siempre: ante "no hay Internet", separa conectividad de resolución — un ping a una IP y un nslookup valen más que veinte reinicios.

Módulos usados: 2 (DNS), 4 (qué valida un ping por capas), 5 (NAT seguía haciendo su trabajo), 6 (método, nslookup contrastado).

Azahar, sede de Alicante. El martes a primera hora, un proveedor de electromedicina instala en la consulta 2 un ecógrafo nuevo con conectividad de red, para archivar las imágenes. El instalador lo deja funcionando y se va. "Le he puesto la IP que usamos siempre en las instalaciones", comenta al salir.

Desde las 12:30, avisos intermitentes de las tres sedes: "el programa de historiales se queda colgado un rato y luego vuelve solo". A veces funciona minutos seguidos; a veces se corta a mitad de una ficha. Reiniciar el PC "a veces lo arregla" (y a veces no — el clásico de los problemas intermitentes).

Desde el PC de recepción de Alicante (172.20.40.21), un ping sostenido al servidor:

La tabla ARP del mismo PC, consultada dos veces con tres minutos de diferencia:

Y en el propio servidor de historiales (Linux), el registro del sistema grita:

Una captura rápida en el servidor (módulo 6, con autorización) remata la película:

1. ¿Qué significa que la MAC asociada a 172.20.40.10 cambie entre dos consultas de arp -a?
2. ¿Por qué dos respuestas al mismo ARP Request son la prueba definitiva? ¿Qué dispositivo es cada MAC?
3. Explica la intermitencia con precisión: ¿por qué funciona a ratos, y por qué "reiniciar a veces lo arregla"?
4. ¿En qué capa(s) sitúas el problema? ¿Cuál es la causa raíz — la técnica y la de proceso?
5. ¿Qué harías para resolver y para que no vuelva a pasar?

Paso 1 — definir y acotar. Afecta a todas las sedes pero a un solo servicio (historiales) y de forma intermitente → el sospechoso común es el servidor o su tramo. ¿Qué cambió hoy? La instalación del ecógrafo a media mañana; los avisos empiezan justo después. La correlación temporal es la pista maestra.

Pasos 2–4 — reproducir, hipótesis, prueba. El ping -t intermitente con la app "que va y viene" encaja. Y la tabla ARP lo delata: una IP no puede tener dos MACs — si la entrada de 172.20.40.10 cambia de aa-4c-… a 00-1f-…, hay dos dispositivos reclamando la misma dirección IP. La captura es la prueba irrefutable: a un solo "¿quién tiene .10?" responden dos equipos. La MAC aa-4c-52-… es el servidor de historiales; la 00-1f-5b-… resulta ser el ecógrafo recién instalado — con la IP estática 172.20.40.10, la misma del servidor, porque el instalador usó "la de siempre" sin consultar el plan.

El mecanismo de la intermitencia, con lo aprendido en el módulo 2: cada equipo de la red guarda en su caché ARP la pareja IP→MAC. Según quién respondió último al ARP, la caché de cada PC apunta al servidor (todo funciona) o al ecógrafo (los paquetes "para el servidor" llegan a un ecógrafo que no entiende de historiales: cuelgues y timeouts)… hasta que la entrada caduca, se vuelve a preguntar, y el ganador puede cambiar. Por eso cada equipo falla en momentos distintos, y por eso reiniciar "a veces" lo arregla: vacía la caché ARP y relanza la lotería. Nada está "roto": hay dos vecinos con el mismo número de portal, y el cartero entrega cada vez en uno.

Pasos 5 y 6 — aplicar y verificar. Se cambia la IP del ecógrafo a 172.20.40.12 (libre en el rango estático del plan) y se limpia la caché donde urge (arp -d o esperar la caducidad). Verificación: ping -t al .10 durante 15 minutos sin una sola pérdida, arp -a estable con la MAC del servidor, y el registro del servidor sin nuevos avisos de duplicado. Las tres sedes confirman.

Paso 7 — documentar. Causa raíz técnica: dirección IP duplicada (estática repetida) — un problema de capa 3 que se manifiesta y se diagnostica en la capa 2 (ARP), justo en la frontera que tanto practicamos. Causa raíz de proceso, la de verdad: un dispositivo se enchufó a la red sin consultar el plan de direccionamiento. Prevención: el plan VLSM de la 07-05 pasa a estar impreso en el armario de comunicaciones y en la documentación que se entrega a todo proveedor; las IPs estáticas se piden, no se eligen. La técnica arregla la incidencia; el proceso evita la siguiente.

Módulos usados: 2 (ARP y su caché), 5 (plan de direccionamiento), 6 (ping sostenido, captura, método).

Una tormenta deja sin línea al consultorio de Elche el domingo. El lunes a primera hora, un técnico del ISP sustituye el equipo de fibra por un router nuevo "todo en uno" y se marcha dejando "Internet funcionando". Al recoger, comenta: "ese aparato viejo del armario lo he dejado desconectado, ya no hace falta".

Lunes, 10:15, llama Elche: "Internet va perfectamente, pero no podemos abrir historiales desde ningún equipo. Y la impresora de red ha desaparecido de los PCs".

Desde un PC de Elche:

En el armario de comunicaciones: el router del ISP nuevo, con el switch del consultorio conectado a sus bocas LAN… y el router de la clínica (el que mantiene el túnel VPN con Alicante y el DHCP del plan) apagado y desenchufado en la balda: el "aparato viejo que ya no hace falta".

1. Mira el ipconfig con tu plan de Elche delante (172.20.40.96/28). ¿Qué es lo primero que chirría, antes incluso de pensar en causas?
2. ¿De dónde ha salido esa configuración 192.168.1.x? ¿Por qué los equipos la aceptaron sin queja?
3. ¿Por qué Internet funciona de maravilla mientras historiales e impresora han desaparecido? ¿Adónde van (y dónde mueren) los paquetes hacia 172.20.40.10?
4. ¿Cuál es la causa raíz y en qué capa nació el problema?
5. Propón la reparación correcta. ¿Qué problema adicional aparecería si simplemente se enchufara el router de la clínica detrás del router nuevo del ISP, tal cual?

Paso 1 — definir y acotar. Toda una sede, desde una intervención física esta mañana. El "qué cambió" es evidente; la pregunta es qué cambió exactamente. Enfoque bottom-up sin dudarlo: hubo manos en el armario.

Pasos 2 y 3 — reproducir e hipótesis. El ipconfig es la pista maestra para quien conoce el plan: un PC de Elche debe vivir en 172.20.40.97–.110, y este tiene 192.168.1.34 — una dirección que no existe en el plan de Azahar. Con el dato del armario, la película se reconstruye sola: el técnico del ISP conectó el switch del consultorio a las bocas LAN de su router nuevo, que trae de fábrica su propio DHCP (192.168.1.0/24). Los PCs, al renovar la concesión por la mañana, aceptaron la oferta del único DHCP presente — DORA no hace preguntas de lealtad: responde el primero que llega. Y el router de la clínica — el extremo del túnel VPN, el gateway 172.20.40.97, el DHCP legítimo del /28 — quedó desenchufado: para la red, Elche ya no es Elche; es "una casa más" colgada de un router doméstico.

Paso 4 — probar (confirmar el mecanismo). Internet funciona porque el router del ISP hace NAT con total solvencia: para navegar, cualquier red con salida vale — "Internet va" no valida tu red; valida cualquier red. Pero 172.20.40.10 ya no está "al otro lado del túnel", porque no hay túnel: el tracert muestra el paquete entrando en 192.168.1.1, que no tiene ninguna ruta hacia 172.20.40.0/24 → lo envía por su ruta por defecto hacia el ISP, donde un destino privado RFC 1918 muere sin remedio (módulo 4, la ruta que desaparece; módulo 5, direcciones no enrutables en Internet). La impresora "desaparecida" es el mismo fenómeno en local: sigue configurada en 172.20.40.x y ya nadie comparte subred con ella.

Pasos 5 y 6 — aplicar y verificar. Reparación correcta: restaurar la topología lógica — el router del ISP se configura en modo bridge (o se usa solo como acceso WAN), el router de la clínica vuelve a su sitio como gateway de la LAN (172.20.40.97), con el switch colgando de él y el túnel VPN renegociado con Alicante. Los equipos renuevan DHCP (ipconfig /renew) y recuperan sus direcciones del plan.

Verificación completa: ipconfig (dirección del /28 ✔), tracert 172.20.40.10 cruzando el túnel en tres saltos (gateway de Elche, router de Alicante, servidor — el patrón que ya viste en el caso B del módulo 6), historiales abriendo, impresora visible. Sobre la pregunta 5: enchufar el router de la clínica detrás del router del ISP "tal cual" crearía doble NAT (192.168.1.x fuera, 172.20.40.x dentro): la LAN volvería a funcionar, pero el túnel VPN sitio a sitio quedaría negociando desde detrás de un NAT que no controla — con la negociación IPsec sufriendo o cayendo, y cada servicio entrante necesitando reglas en dos routers (módulo 5, lección 05-03). Funciona-a-medias es la peor clase de arreglo: bridge y topología limpia.

Paso 7 — documentar. Causa raíz: cambio de topología física no autorizado (capa 1 de origen) que sustituyó gateway, DHCP y direccionamiento de la sede (consecuencias en capas 2–3). Prevención: hoja de topología pegada en el armario ("este equipo NO se desconecta"), y toda intervención de ISP con presencia o revisión posterior de Meridiano. Nota para la posteridad en la base de conocimiento: la IP fuera de plan fue el diagnóstico entero; el resto fue confirmarlo.

Módulos usados: 1 (topología), 2 (DHCP/DORA), 4 (rutas y ruta por defecto), 5 (RFC 1918, NAT y doble NAT), 6 (tracert, bottom-up).

Los cuatro casos comparten patrones de error que conviene llevarse grabados:

• Creerse el síntoma literal. "No hay Internet" era un DNS caído; "tiene Internet pero no historiales" era una máscara; "Internet va perfecto" escondía una sede entera fuera de su red. El síntoma es el punto de partida de la investigación, nunca su conclusión.
• Diagnosticar sin el plan de direccionamiento delante. En los casos 1, 3 y 4, la anomalía solo es visible comparando lo que hay con lo que debería haber. Una red sin plan documentado no se puede diagnosticar: solo se puede adivinar.
• Ignorar la pregunta "¿qué cambió?". Un instalador, un firmware nocturno, un ecógrafo, un técnico del ISP: los cuatro casos nacen de un cambio reciente. La correlación no es causalidad, pero es la mejor hipótesis inicial que existe.
• Subestimar los intermitentes. El caso 3 no se caza con un ping suelto: se caza con ping -t, dos lecturas de arp -a y una captura. Instrumentar y esperar es diagnóstico, no pasividad.
• Verificar solo la mitad. "Ya hay Internet" no cierra el caso 4; cerrarlo es historiales + impresora + túnel + DHCP correcto. Verifica contra el síntoma original y contra el plan.
• Arreglar la técnica y olvidar el proceso. Cambiar la IP del ecógrafo tarda un minuto; conseguir que el próximo proveedor pida la IP en lugar de inventársela es lo que evita el caso 5. La documentación (paso 7) es donde una incidencia se convierte en mejora.

Se acabó el gimnasio — y con él, el curso. Merece la pena mirar atrás para ver el camino completo: en el módulo 1 aprendiste qué es una red, sus tipos y topologías; en el módulo 2, los protocolos que la hacen hablar — Ethernet y ARP, IP, TCP y UDP, DNS, HTTP y compañía; en el módulo 3, el mapa OSI de siete capas que ordena todo eso; en el módulo 4, el modelo TCP/IP que corre de verdad en cada máquina, con sus rutas y sus sockets; en el módulo 5, el direccionamiento de punta a punta — binario, máscaras, subnetting, VLSM, NAT e IPv6; en el módulo 6, las herramientas de diagnóstico y el método que las gobierna; y en este módulo 7 convertiste todo aquello en soltura, primero por temas y hoy contra incidencias completas, sin etiquetas ni red de seguridad.

Fíjate en lo que ya sabes hacer, porque no es poco: leer la configuración de cualquier equipo y detectar al vuelo lo que no cuadra; diseñar el direccionamiento de una organización pequeña desde cero, plan VLSM incluido; seguir un paquete mentalmente desde el ARP inicial hasta el 200 OK final; interpretar ping, traceroute, arp, nslookup, ss y una captura de tráfico; y — lo que de verdad te distingue — diagnosticar con método, aislando la capa, encontrando la causa raíz y documentándola. En la primera lección de este módulo dijimos que si solo sabes razonar sobre la red que conoces de memoria, todavía no sabes razonar sobre redes; después de resolver los problemas de una clínica que no existía cuando empezaste el curso, ese listón está superado.

¿Y ahora qué? Tres caminos, compatibles entre sí. Practica en laboratorio: simuladores como Packet Tracer o GNS3, o un par de routers viejos y una tarde libre, te dejan romper y arreglar redes sin que nadie llame enfadado; abre Wireshark a menudo — cada captura enseña algo. Certifica lo aprendido si tu carrera lo pide: este curso te deja una base sólida para preparar certificaciones de redes de nivel inicial e intermedio. Y profundiza hacia donde te llame: la seguridad de red (firewalls, VPNs a fondo, análisis de tráfico), la administración de sistemas, o el mundo IPv6 y cloud donde todo lo aprendido se recombina. Las redes tienen esa cualidad rara: son invisibles cuando funcionan y apasionantes cuando no.

Marta y Jon seguirán abriendo la intranet cada mañana sin sospechar la coreografía de capas que lo hace posible, y en la sala de espera de Azahar nadie sabrá jamás que la Wi-Fi de pacientes vive en su propia subred por una buena razón. Pero tú sí lo sabes — y sabes exactamente por qué. Eso es haber terminado un curso de redes. Enhorabuena, y que tus tablas ARP sean siempre estables.