Tienes el botiquín (06-01) y el microscopio (06-02). Pero las herramientas, solas, no resuelven incidencias: sin método se cae en el "diagnóstico por corazonada" — reiniciar cosas al azar, cambiar tres parámetros a la vez, arreglar el síntoma sin entender la causa (que volverá). Esta lección convierte todo lo que sabes en un método sistemático: los tres enfoques por capas y cuándo usar cada uno, un procedimiento de 7 pasos que funciona igual para un ping perdido que para una caída general, un árbol de decisión con el comando exacto de cada comprobación, y — lo más valioso — tres incidencias reales de Grupo Meridiano resueltas de principio a fin, con las salidas de cada comando, para que veas el método respirar. Es la lección que cierra el módulo 6 y, con él, la parte teórica del curso.

1. Por qué hace falta un método
2. Los tres enfoques por capas: bottom-up, top-down, divide y vencerás
3. El método sistemático en 7 pasos
4. El árbol de decisión: "no funciona la red"
5. Caso A: "Ana no tiene red"
6. Caso B: "Bilbao no llega a la intranet, pero navega"
7. Caso C: "la intranet va lenta... solo a veces"
8. Documentar: el paso que nadie hace y todos agradecen

Una incidencia de red es un espacio de búsqueda enorme: decenas de componentes (cable, switch, VLAN, IP, DHCP, rutas, VPN, DNS, firewall, servicio, aplicación) y el fallo puede estar en cualquiera. Probar al azar tiene coste exponencial; un método por capas lo reduce a un recorrido ordenado donde cada comprobación descarta un bloque entero de causas. Además, el método aporta dos cosas que la intuición no da:

• Reproducibilidad: dos técnicos con el mismo método llegan a la misma conclusión y pueden relevarse a mitad de incidencia.
• Evidencia: cada paso deja una salida de comando que prueba lo descartado — imprescindible para escalar (al ISP, al proveedor de la VPN) sin que te devuelvan el problema.

La buena noticia: el método ya casi lo tienes. Los modelos OSI y TCP/IP que estudiaste no eran teoría decorativa, eran el mapa del diagnóstico; el "embudo" del módulo 4 y el "capa 1 primero" del módulo 3 eran sus primeros esbozos.

Sobre el mapa de capas hay tres formas de recorrerlo:

El tercero es el favorito de los profesionales porque un solo ping con éxito valida de golpe las capas 1, 2 y 3 hasta ese destino: la mitad del mapa descartada con un comando. De ahí que el árbol de decisión de más abajo pivote sobre él. Y "capa 1 primero" (módulo 3) sigue vigente como excepción de oro: si hay cualquier indicio físico (LED apagado, "Medios desconectados", obras, mudanzas), empieza bottom-up aunque el síntoma parezca de aplicación — comprobar un cable cuesta 10 segundos.

Los enfoques dicen por dónde buscar; los 7 pasos dicen cómo trabajar la incidencia completa:

1. Definir el problema y su alcance. "No va la red" no es un problema definido. Pregunta hasta obtener: qué falla exactamente, desde cuándo, qué cambió y — la pregunta más rentable del diagnóstico — ¿a quién afecta?: ¿un usuario o todos? ¿una sede o ambas? ¿un servicio o todos? Cada respuesta recorta el mapa: si solo falla Ana, la causa está en su puesto o su tramo; si falla toda Valencia pero Bilbao navega, mira la electrónica o la salida de Valencia; si ambas sedes fallan contra la intranet pero navegan, mira el servidor .10.10.
2. Reproducir el fallo. Verlo con tus ojos (o con un comando) evita perseguir descripciones inexactas. Si es intermitente, deja monitorización (ping -t, captura) hasta cazarlo.
3. Formular una hipótesis. Con el alcance y lo reproducido, elige la causa más probable y el enfoque (bottom-up/top-down/divide). Una hipótesis se enuncia falsable: "el DHCP no está sirviendo direcciones", no "algo del DHCP".
4. Probar la hipótesis con la herramienta que la confirme o refute — y cambiando una sola cosa cada vez. Si la refutas, vuelve al paso 3 con lo aprendido (lo descartado también es información).
5. Aplicar la solución. A ser posible con plan de vuelta atrás (anota el valor anterior antes de cambiarlo).
6. Verificar que el problema original ha desaparecido y que no has roto otra cosa. Verifica con el usuario y con el comando que antes fallaba.
7. Documentar. Síntoma, causa raíz, solución, evidencias. Lo desarrollamos al final — es el paso que convierte una incidencia sufrida en conocimiento reutilizable.

Para el aviso genérico desde un puesto de trabajo, este es el checklist ordenado — de la capa 1 hacia arriba — con el comando exacto de cada nodo. Memorízalo: es el módulo 6 entero en un diagrama.

Dos matices de uso: si el alcance (paso 1 del método) ya te dice que afecta a todos, no empieces por el puesto de un usuario — ve a lo común (router, DHCP, DNS, servidor). Y si el destino está en la otra sede, inserta tras la gateway el nodo "¿ruta/VPN?": tracert hacia la IP remota, como en el caso B.

Paso 1 — definir y acotar. Lunes 9:05. Ana (Valencia) llama: "no tengo nada, ni intranet ni Internet". Preguntas de alcance: Marta, a dos mesas, trabaja con normalidad → afecta a un solo usuario de Valencia. ¿Cambios? El viernes por la tarde se recolocaron mesas en su zona. El alcance + el cambio físico deciden el enfoque: bottom-up.

Paso 2 — reproducir. En el PC de Ana:

Reproducido y con diagnóstico a medias incluido: hay link (si no, pondría "Medios desconectados" — la capa 1 queda descartada pese a la mudanza), pero la IP es APIPA (módulo 5): el PC pidió DHCP y nadie respondió. Sin IP válida ni gateway, es coherente que "no haya nada".

Paso 3 — hipótesis. ¿DHCP caído en el router .10.1? Contraste rápido de alcance: ipconfig /all en el PC de Marta muestra concesión renovada a las 8:47 → el DHCP funciona para otros. Hipótesis afinada: el problema está entre Ana y el DHCP; y como el DHCP corre en el router de la VLAN 10, sospecha concreta: al recablear las mesas, el PC de Ana quedó conectado a una boca del switch asignada a la VLAN 20 (invitados) — en esa VLAN su petición DORA (módulo 2) nunca llega al DHCP corporativo.

Paso 4 — probar. En el switch, la boca de la roseta nueva de Ana (puerto 14):

El puerto 14 está en la VLAN 20. Hipótesis confirmada: el viernes, el latiguillo de Ana se conectó a una boca de invitados.

Pasos 5 y 6 — aplicar y verificar. Se reasigna el puerto 14 a la VLAN 10 (o se mueve el latiguillo a una boca corporativa; se elige lo primero y se anota el valor anterior). En el PC de Ana:

IP del rango dinámico (.100–.199), gateway correcta, intranet accesible. Ana confirma. Paso 7 al final de la lección.

Paso 1 — definir y acotar. Jon (Bilbao): "no puedo abrir la intranet desde esta mañana; Internet va perfecto". Se comprueba con otro compañero de Bilbao: tampoco → toda la sede de Bilbao, solo hacia recursos de Valencia, Internet intacto. En Valencia todo funciona, incluida la intranet. Este alcance es elocuente: LAN de Bilbao sana (navegan), servidor sano (Valencia lo usa) → la sospecha nace ya en el enlace entre sedes: la VPN. Enfoque: divide y vencerás sobre la ruta.

Paso 2 — reproducir. Desde el PC de Jon (.20.7):

Lectura (06-01): el salto 1 responde — hasta su gateway todo bien — y la ruta muere justo después de 192.168.20.1, en el tramo del túnel. Asteriscos hasta el final: corte real, no un router tímido.

Paso 3 — hipótesis. O el túnel VPN está caído, o el router de Bilbao ha perdido la ruta hacia 192.168.10.0/24 (módulo 4: sin ruta, esos paquetes se van por la default hacia Internet, donde una dirección privada RFC 1918 no llega a ninguna parte — y por eso "Internet va perfecto" mientras Valencia es inalcanzable).

Paso 4 — probar. En el router de Bilbao:

Confirmado por partida doble: el túnel está DOWN desde las 6:12 y, con él caído, ha desaparecido la ruta 192.168.10.0/24 via Tunnel1 de la tabla. El registro del router muestra que a las 6:10 el ISP de Bilbao renovó la IP pública de la sede, y el extremo de Valencia seguía esperando a la IP antigua (recuerda del módulo 5 lo que NAT y las IP dinámicas complican).

Pasos 5 y 6 — aplicar y verificar. Se reinicia la negociación del túnel con la nueva IP (y se anota para el paso 7 una mejora permanente: pasar la identificación del túnel a un nombre DNS dinámico en lugar de IP fija). Verificación desde el PC de Jon:

La traza vuelve a cruzar el túnel en 3 saltos y la API responde: verificado en capa 3 y en capa de aplicación.

Paso 1 — definir y acotar. Varios usuarios de Valencia, durante dos semanas: "la intranet a veces tarda muchísimo en cargar; luego va normal". Afecta a varios usuarios, una sola aplicación, de forma intermitente. Los problemas intermitentes son los que más castigan al diagnóstico por corazonada — y donde más brilla el método.

Paso 2 — reproducir (o monitorizar hasta cazarlo). No se reproduce a voluntad, así que se instrumenta: en el PC de Marta se deja un bucle que mide la API cada minuto con curl (opción -w, que imprime tiempos por fase — la versión cronómetro del -v de 06-01), registrando a fichero. Al día siguiente, los datos:

La reproducción instrumentada vale oro: la lentitud no está en TCP, ni en TLS, ni en el servidor (sus fases son constantes): son ~4 segundos exactos de DNS, a ráfagas. La cifra redonda huele a timeout + reintento: el resolutor espera a un servidor que no contesta y, tras agotar el plazo, pregunta al siguiente.

Paso 3 — hipótesis. El DHCP de Meridiano reparte dos DNS. Hipótesis: el primero falla intermitentemente; cuando falla, cada resolución paga el timeout antes de caer al secundario. Paso 4 — probar, primero mirando la configuración y luego con el microscopio (06-02) — captura autorizada en el PC de Marta, filtro dns:

Ahí está la película completa: tres intentos al primario .10.2 (una máquina de pruebas que alguien configuró como DNS primario en el DHCP hace dos semanas... y que se apaga a ratos) sin respuesta, y a los 4 segundos el sistema pregunta al .10.1, que responde en 2 ms. Coincide al milisegundo con las ráfagas del curl -w. Hipótesis confirmada con evidencia de paquete.

Pasos 5 y 6 — aplicar y verificar. Se corrige la opción DNS del DHCP (primario .10.1, se retira .10.2), se fuerza renovación (ipconfig /renew + /flushdns en los equipos afectados o se espera al ciclo de concesión). El monitor de curl -w corre 48 h más: ninguna medición por encima de 0,06 s. Verificado — con datos, no con "parece que ya va".

El paso 7 es el más barato (10 minutos) y el de mayor retorno. Qué anotar de cada incidencia, con el caso C como ejemplo:

Por qué merece la pena, en frío:

• La próxima vez son 5 minutos: el síntoma "lentitud a ráfagas de ~4 s" quedará asociado a "timeout de DNS primario" en la base de conocimiento del equipo.
• Revela patrones: tres incidencias de VLAN mal asignada en dos meses (caso A) no son tres accidentes: son un procedimiento de recableado que falta.
• La causa raíz evita reincidencia: sin ella, el caso B se habría "resuelto" reiniciando el router — hasta la siguiente renovación de IP del ISP. Documentar obliga a distinguir arreglé el síntoma de entendí la causa.
• Protege al equipo: ante un "lleváis dos semanas con la intranet lenta", el registro demuestra qué se hizo, cuándo y con qué evidencia.

• Saltarse el paso 1 e ir directo a los comandos. Dos preguntas de alcance (¿quién? ¿desde cuándo/qué cambió?) ahorran más tiempo que cualquier herramienta.
• Cambiar varias cosas a la vez. Si tocas la VLAN, el cable y el DHCP y algo mejora, no sabes qué era — y quizá has introducido un fallo nuevo. Un cambio, una verificación.
• Confundir correlación con causa. "Reinicié el switch y volvió" no prueba que fuera el switch (quizá la concesión DHCP se renovó a la vez). La causa raíz exige evidencia, no coincidencia.
• Cerrar sin verificar con el comando que fallaba (y con el usuario). "Debería funcionar ya" no es un cierre.
• No anotar el estado previo antes de cambiar algo. Sin plan de vuelta atrás, un intento fallido se convierte en dos incidencias.
• Perseguir problemas intermitentes con pruebas puntuales. Un ping suelto a las 12:00 no caza un fallo de las 9:43. Instrumenta y espera: ping -t, bucles de curl -w, capturas programadas.
• Tratar el modelo por capas como dogma. Los enfoques son heurísticos: si hay un indicio fuerte (una obra, un cambio de ayer), salta directo a él. El método está para ordenar la búsqueda, no para frenarla.

1. Aviso a las 9:00: "no funciona la intranet". Antes de tocar un solo comando, escribe las tres preguntas de alcance que harías y, para cada combinación de respuestas siguiente, di dónde empezarías a buscar: (a) solo le falla a Marta, al resto no; (b) falla a toda Valencia y a todo Bilbao, pero todos navegan por Internet; (c) falla a todo Bilbao y solo a Bilbao.
2. En el caso A, tras ver la APIPA en el PC de Ana, un técnico propone como solución "ponerle una IP fija: 192.168.10.50, máscara /24, gateway .10.1". Comprueba que esa "solución" probablemente parecería funcionar a medias o nada — razona qué pasaría exactamente con el puerto aún en la VLAN 20 — y explica por qué, aunque hubiera funcionado, seguiría siendo una mala resolución de la incidencia según el método.
3. Diseña el plan de diagnóstico (pasos 1–4 del método, sin resolverlo) para este síntoma: "desde el portátil de la sala de reuniones de Valencia, conectado a la Wi-Fi de invitados, no se puede abrir la intranet; desde la Wi-Fi corporativa, sí". Incluye la hipótesis más probable teniendo en cuenta el diseño de red de Meridiano y qué comando la confirmaría.

1. Preguntas: ¿A quién afecta? (¿un usuario, una sede, todos?), ¿qué falla exactamente y qué funciona? (¿solo la intranet o también Internet/otros servicios?), ¿desde cuándo y qué cambió?. Respuestas: (a) un solo usuario → la causa está en el puesto de Marta o su tramo: empezar en su equipo (ipconfig /all, ping a gateway e intranet). (b) Ambas sedes fallan solo contra la intranet y todo lo demás funciona → lo único común a ese síntoma es el servidor .10.10 (o su servicio web): ir directo a él (ping 192.168.10.10 desde Valencia, y ss -tlnp en el servidor — ¿host caído o puerto cerrado?). (c) Solo Bilbao, y solo hacia Valencia → tramo entre sedes: VPN/rutas, como el caso B (tracert -d 192.168.10.10 desde Bilbao para ver dónde muere).
2. Con el puerto en la VLAN 20, la IP fija 192.168.10.50 no sirve: las VLAN separan dominios de capa 2 (módulo 3), así que los ARP de Ana preguntando por .10.1 o .10.10 no llegarían a la VLAN 10 — arp -a mostraría entradas incompletas y los pings fallarían igual (quizá con la confusión añadida de conflictos si la VLAN 20 usa otro plan). Es decir: la propuesta ni siquiera ataca la causa (puerto en VLAN errónea), solo el síntoma visible (falta de IP). Y aunque hubiera funcionado, violaría el método: no hay hipótesis confirmada ni causa raíz (¿por qué dejó de servir el DHCP a Ana?), introduce una excepción no documentada (una IP fija fuera del plan de direccionamiento y de las reservas, futura fuente de conflictos con el rango DHCP) y garantiza reincidencia en el siguiente equipo que se enchufe a esa roseta.
3. Paso 1 (definir/acotar): afecta a cualquier equipo en la Wi-Fi de invitados (comprobar con un segundo dispositivo), solo hacia la intranet (verificar que Internet sí funciona desde invitados), desde siempre o desde fecha concreta (¿alguna vez funcionó?). Paso 2 (reproducir): desde el portátil en invitados, ipconfig /all (esperable: IP de la red de invitados, no 192.168.10.x) y curl -v https://intranet.grupomeridiano.example anotando en qué fase falla. Paso 3 (hipótesis): la Wi-Fi de invitados va a la VLAN 20, aislada deliberadamente de la VLAN 10 corporativa — que los invitados no lleguen a la intranet no es una avería sino el diseño de seguridad de Meridiano funcionando (probablemente con reglas en el router que permiten invitados→Internet pero bloquean invitados→VLAN 10). Paso 4 (probar): ping 192.168.10.10 y tracert desde invitados (esperable: bloqueado o cortado en el router) y contraste inmediato del mismo curl desde la Wi-Fi corporativa (funciona). Confirmada la hipótesis, la "solución" no es técnica sino de procedimiento: quien necesite la intranet debe usar la red corporativa; si de verdad hiciera falta acceso desde invitados, sería un cambio de política a decidir y documentar, no un apaño.

Ya está completo el módulo 6: las utilidades afiladas una a una (06-01), el microscopio de los paquetes con su marco legal (06-02) y, en esta lección, el método que las gobierna — los tres enfoques por capas y cuándo usar cada uno, los 7 pasos de definir a documentar, el árbol de decisión con su comando por nodo, y tres incidencias de Meridiano (la APIPA de Ana que acabó en una VLAN, el túnel VPN que tumbó Bilbao, el DNS intermitente cazado con instrumentación y captura) resueltas de principio a fin. Fíjate en lo que ha pasado a lo largo del módulo: ARP, TTL, DORA, APIPA, VLANs, rutas, sockets, el handshake... todo lo aprendido en los módulos 1 a 5 ha dejado de ser temario para convertirse en piezas de diagnóstico. Ya tienes conocimientos y método. Lo que queda es soltura, y esa solo se gana entrenando: el módulo 7 es exactamente eso — el gimnasio del curso, con ejercicios de cada bloque y casos prácticos integrados donde consolidar todo lo que ahora sabes hacer.