Qué significa hacer troubleshooting
El troubleshooting de redes no consiste en probar comandos al azar hasta que algo vuelve a funcionar. Es un proceso para convertir un síntoma amplio —«no hay Internet», «la aplicación va lenta», «no resuelve nombres»— en una hipótesis verificable y después aislar la capa, el equipo o el servicio responsable.
Una buena investigación intenta responder tres preguntas: qué funciona, qué no funciona y qué cambió. El objetivo no es solamente restaurar servicio; también es entender por qué ocurrió para reducir recurrencias y documentar una solución reproducible.
Antes de tocar nada: alcance, impacto y cambios
Empieza delimitando el alcance. ¿Falla un único host, una VLAN, una sede, una aplicación o toda la red? ¿El problema es continuo o intermitente? ¿Afecta a IPv4, IPv6 o ambos? La respuesta reduce drásticamente el espacio de búsqueda.
Revisa también cambios recientes: despliegues, nuevas ACL, modificaciones de VLAN, firmware, DNS, DHCP, rutas o políticas de seguridad. Un cambio correlacionado en el tiempo no demuestra causalidad, pero es una pista de alto valor. Evita modificar varios elementos a la vez: si haces cinco cambios y el servicio vuelve, habrás recuperado disponibilidad pero perdido evidencia.
Método por capas y por planos
El modelo OSI es útil como mapa mental, pero no es obligatorio investigar siempre de Capa 1 a Capa 7. Puedes empezar donde el síntoma apunte y moverte hacia arriba o hacia abajo. Lo importante es comprobar hechos.
Una secuencia práctica es: enlace físico → Capa 2/VLAN → configuración IP → resolución ARP o Neighbor Discovery → routing → políticas como ACL/NAT/firewall → servicios como DNS/DHCP → aplicación. En paralelo conviene distinguir plano de datos, plano de control y plano de gestión: que puedas administrar un router no prueba que el tráfico de usuarios esté pasando correctamente.
1. Capa física y enlace
Comprueba estado de interfaz, negociación, velocidad, duplex, errores, descartes y cambios de estado. Un enlace «up» no garantiza que esté sano: CRC, errores físicos, pérdida inalámbrica o una negociación inesperada pueden degradar el tráfico sin provocar una caída total.
Después verifica la pertenencia a VLAN, el modo access/trunk, las VLAN permitidas, spanning tree y la tabla MAC cuando proceda. Un host con configuración IP perfecta seguirá aislado si está conectado a la VLAN equivocada.
2. Direccionamiento IP y vecinos
Valida dirección, prefijo, gateway y origen de la configuración. Una máscara incorrecta puede hacer que el host considere local un destino que debería alcanzar mediante router. En IPv4 observa la caché ARP; en IPv6, la tabla de vecinos y el estado de Neighbor Discovery.
Si un destino de la misma subred no responde, comprobar ARP/ND ayuda a distinguir entre un problema de resolución local y uno posterior. Si el gateway no se resuelve, todavía no tiene sentido investigar DNS externo.
3. Routing y camino de ida y vuelta
Consulta la tabla de rutas del host y de los routers relevantes. Verifica el prefijo elegido, next hop y ruta por defecto. Recuerda que routing aplica Longest Prefix Match: una ruta más específica puede desviar tráfico aunque exista una default correcta.
El camino de vuelta importa tanto como el de ida. Muchos fallos aparentan ser «intermitentes» cuando existe routing asimétrico combinado con firewalls stateful, ECMP mal entendido o rutas diferentes entre segmentos. traceroute puede aportar pistas, pero la ausencia de respuestas ICMP intermedias no demuestra por sí sola que el tráfico final esté bloqueado.
4. ACL, firewall y NAT/PAT
Cuando la conectividad básica existe pero un flujo concreto falla, revisa políticas. Una ACL puede descartar por origen, destino, protocolo o puerto; un firewall stateful puede exigir que exista un estado válido; NAT/PAT puede introducir otra tabla que correlacionar.
Usa contadores de reglas y logs cuando estén disponibles. No desactives seguridad «para probar» en producción sin un plan: es preferible crear una prueba controlada, comparar tráfico permitido y denegado y conservar evidencia.
5. Servicios: DHCP, DNS y tiempo
Separa conectividad del servicio. Si ping a una IP funciona pero un nombre no resuelve, el problema puede estar en DNS. Si un cliente no tiene parámetros válidos, revisa DHCP, el relay y el scope.
La sincronización temporal también afecta al diagnóstico: logs de equipos con relojes desalineados dificultan reconstruir la secuencia de eventos. Por eso NTP forma parte de una plataforma operable, no es un detalle cosmético.
Herramientas: del comando a la captura
Los comandos de diagnóstico sirven para obtener una vista rápida del host: interfaces, rutas, vecinos, sockets, DNS y camino. Una captura con Wireshark permite observar qué se envía realmente y qué respuestas llegan.
Complementa ambos con telemetría: SNMP, Syslog, métricas de interfaz y logs de aplicaciones. Una captura muestra paquetes durante una ventana concreta; la observabilidad histórica puede revelar cuándo empezó el problema y si coincide con saturación, cambios o errores físicos.
Latencia, pérdida, jitter y throughput
No todos los problemas son binarios. Para voz, vídeo o aplicaciones interactivas importan latencia, variación de retardo y pérdida. Para transferencias masivas suele importar más el throughput sostenido. Mide desde puntos comparables y durante suficiente tiempo para distinguir un pico aislado de una tendencia.
QoS puede modificar el comportamiento bajo congestión, pero no crea capacidad. Antes de culpar a una política QoS, confirma dónde existe la congestión y si la clasificación y marcado sobreviven al camino.
Cómo tratar los fallos intermitentes
Los fallos intermitentes exigen evidencia temporal. Registra hora exacta, origen, destino, aplicación y duración. Automatiza pruebas ligeras si es posible y correlaciona con logs, cambios de interfaz, utilización y eventos de routing.
Evita asumir que «si ahora funciona, estaba bien». Un loop transitorio, una concesión DHCP agotada, una resolución DNS cacheada o una interfaz con errores puede desaparecer antes de que empiece la investigación manual.
Flujo de diagnóstico recomendado
Un flujo reutilizable es: 1) reproducir y delimitar; 2) comparar con un caso sano; 3) validar enlace y VLAN; 4) revisar configuración IP y vecinos; 5) comprobar routing ida/vuelta; 6) validar políticas; 7) comprobar servicios; 8) capturar paquetes si la evidencia sigue siendo insuficiente; 9) aplicar un cambio mínimo; 10) verificar recuperación y documentar.
Comparar con un host sano es especialmente potente. Si dos equipos comparten red pero sólo uno falla, busca diferencias locales. Si ambos fallan, asciende hacia elementos compartidos.
Errores comunes al diagnosticar
Los errores más frecuentes son empezar por la herramienta en vez de por la hipótesis, confiar en un único ping, confundir resolución de nombres con conectividad IP, ignorar el camino de retorno, cambiar varias cosas simultáneamente y cerrar el incidente sin documentar causa y validación.
Otro error es tomar la ausencia de respuesta ICMP como prueba de caída. ICMP puede filtrarse o limitarse, mientras el servicio TCP/UDP sigue disponible. Prueba el protocolo relevante cuando sea posible.
Documentar causa, cambio y validación
Una resolución útil deja registro del síntoma, alcance, pruebas realizadas, evidencia, causa raíz o causa más probable, cambio aplicado y validación posterior. Si no se pudo demostrar una causa raíz, indícalo en lugar de inventar certeza.
La documentación convierte una incidencia en conocimiento reutilizable y permite detectar patrones. También reduce el riesgo de repetir cambios temporales que sólo ocultaron el problema.
Referencias y siguiente paso
Para fundamentos de host y router son referencias históricas importantes RFC 1122 y RFC 1812; ICMPv4 e ICMPv6 se definen en RFC 792 y RFC 4443. Para el trabajo práctico continúa con comandos de red y Wireshark.
Si durante el diagnóstico descubres que el fallo es una política, entra en el cluster de seguridad de red para ACL, IPsec y controles de Capa 2.