Cómo se localizan los fallos de Internet
Cuando una web no carga, el vídeo se queda eternamente en buffering o tu juego favorito te da lag, la sensación es la misma: “Internet se ha roto”. Pero la red no es un ser mágico; es una colección de cables, routers, centros de datos y acuerdos comerciales que pueden fallar por muchos motivos. Localizar un fallo no es cuestión de adivinar, sino de aplicar método, herramientas y, a veces, un poco de intuición. Te explico cómo lo hacen los técnicos (y cómo puedes hacerlo tú antes de enfadarte con el router).
La diferencia entre síntoma y causa
Lo primero que hay que entender es que lo que vemos es un síntoma. Que no cargue una web puede deberse a problemas en tu equipo, en tu router, en la conexión de tu barrio, en la red del proveedor, en un proveedor de tránsito intermedio, en el servicio web en sí o en los sistemas de nombres de dominio (DNS). Localizar el fallo supone separar las capas y descartar posibilidades hasta llegar al origen real.
Pasos básicos que siguen los técnicos
Los centros de operaciones de red (NOC) y los administradores siguen un esquema parecido en la mayoría de los casos:
- Detección: quejas de usuarios, alertas automáticas de monitorización o cambios observados en el ruteo.
- Aislamiento: determinar si afecta a un único equipo, a una red local, a un POP (punto de presencia) o a un área amplia.
- Localización: identificar el punto de la infraestructura donde se produce la degradación o la caída.
- Mitigación: aplicar soluciones temporales (rerouting, blackholing, reinicios) para restablecer servicio mientras se trabaja en la reparación definitiva.
- Corrección y prevención: arreglar el problema físico o lógico y documentar medidas para evitar repeticiones.
Herramientas que usan para localizar fallos
No hacen magia: usan herramientas muy concretas que permiten ver el comportamiento de la red desde distintos puntos. Algunas de las más comunes son:
- Ping: comprueba si un host responde y mide latencia. Útil para detectar pérdida de paquetes y latencias anormales.
- Traceroute / tracert / mtr: muestran la ruta que siguen los paquetes y en qué salto comienzan los problemas. MTR combina traceroute y ping en tiempo real.
- Comprobaciones HTTP/HTTPS: sondas que intentan cargar una página y verifican tiempos de respuesta y códigos de estado.
- Logs y syslogs: los routers y servidores registran eventos que ayudan a identificar reinicios, errores de hardware o caídas de interfaces.
- SNMP, NetFlow y sFlow: proporcionan datos de tráfico y estadísticas para detectar congestión o anomalías en enlaces.
- Herramientas de ruteo BGP: analizar las rutas anunciadas y retiradas permite ver si un prefijo quedado sin anuncio por BGP está inaccesible.
- Plataformas de medición distribuidas: redes de sondas que prueban la conectividad desde muchos lugares distintos (por ejemplo, proyectos públicos que recogen medidas desde diversos puntos del planeta).
Cómo interpretar un traceroute
Traceroute es la navaja suiza para empezar a localizar un fallo. Muestra una lista de «saltos» (routers) por los que pasa el paquete. Si el traceroute se queda en el salto 7 y no responde más, el problema está probablemente en ese router o después de él. Si, en cambio, el traceroute llega hasta la IP final pero el servicio HTTP falla, el problema puede ser del servidor o del propio servicio.
Algunos puntos a tener en cuenta al leer un traceroute:
- Respuestas con asteriscos (*) suelen indicar que el router no responde a ICMP, no necesariamente que esté caído.
- Saltos con latencias crecientes y pérdida de paquetes indican congestión.
- Saltos que cambian entre ejecuciones pueden descubrir rutas alternativas o inestabilidad en el ruteo.
El papel del ruteo y las rutas BGP
Internet es un conjunto de redes interconectadas. El protocolo que decide por dónde van los bloques de direcciones IP se llama BGP. Cuando un operador anuncia o retira una ruta, otros operadores actualizan sus tablas y el tráfico se encamina de otra forma. Una retirada de anuncio BGP suele aparecer como un fallo amplio: miles o millones de usuarios pierden acceso a un prefijo concreto.
Por eso los técnicos revisan tablas BGP y utilizan “looking glasses” (consolas públicas que permiten ver el estado de rutas desde distintos enrutadores) para comprobar si una red está anunciando sus prefijos correctamente. Cambios repentinos en el anuncio de rutas pueden señalar problemas de configuración o fallos en ese operador.
Cuando la causa es física: cables y hardware
No todo son bits y protocolos: muchos incidentes son literalmente cortes de cable. Puede tratarse de una obra que corta una fibra en la calle, un container mal colocado que daña un cable submarino o un fallo eléctrico en un centro de datos. ¿Cómo lo localizan?
- Instrumentos como el OTDR (Reflectómetro Óptico) permiten localizar la posición aproximada de una rotura en fibra analizando la reflexión de pulsos ópticos.
- Comprobaciones de potencia óptica y mediciones físicas confirman si el fallo es en la fibra o en el equipo activo.
- En el caso de cables submarinos, operadores y consorcios comparten información y realizan búsquedas para detectar anomalías en rutas yRTT.
Problemas de DNS y CDN
Otro clásico: la web no carga porque no se resuelve el nombre. Los problemas de DNS pueden afectar a muchos usuarios si el servidor autoritativo o los servidores de cache de un proveedor fallan. En esos casos las comprobaciones habituales son:
- Comprobar con herramientas de consulta DNS (dig, nslookup) si el nombre se está resolviendo y desde dónde.
- Ver si los servidores DNS alternativos (como los del propio ISP o públicos) devuelven la misma información.
- Comprobar la configuración de CDN: a veces la entrega de contenido se interrumpe por errores de configuración en la red de distribución o por problemas en servidores de origen.
La importancia de los informes y la monitorización externa
Las alertas automáticas que controlan latencias, pérdida de paquetes y disponibilidad son la primera línea. Pero cuando una gran parte de usuarios reportan fallos en redes sociales o en plataformas de seguimiento de incidencias, esos informes sirven para corroborar un problema real y su alcance. Los operadores cruzan datos de monitorización interna con mediciones externas y con los reportes de usuarios para acotar la ubicación del fallo.
Un ejemplo práctico para usuarios: cómo comprobar si el fallo es tuyo o general
Si algo falla en tu conexión, antes de llamar a atención al cliente puedes hacer estas comprobaciones rápidas:
- Prueba a otros dispositivos y si funcionan, el problema puede estar en el equipo original.
- Reinicia modem y router; muchas veces un simple reinicio restaura la conexión.
- Haz ping a una dirección IP pública conocida. Si responde, tienes conectividad IP y el problema puede ser DNS o el servicio concreto.
- Ejecuta un traceroute hasta la web que falla para ver en qué salto se corta la comunicación.
- Consulta si otros usuarios reportan la misma incidencia en redes sociales o plataformas de seguimiento de incidencias.
Coordinación entre operadores y comunicación
Cuando el fallo afecta a múltiples redes o a infraestructuras críticas, la solución requiere coordinación. Los equipos de NOC contactan con pares, con los centros de intercambio de tráfico (IXPs) y con proveedores de tránsito. Los incidentes complejos suelen tener un canal de comunicación dedicado para intercambiar información técnica, logs y decisiones sobre mitigación.
¿Y los ataques DDoS?
En caso de un ataque distribuido, la detección se basa en patrones de tráfico: picos inesperados, paquetes hacia múltiples puertos o intento masivo de conexión a un servicio. La mitigación puede incluir filtrar tráfico malicioso, absorberlo en centros de limpieza o redistribuir el ruteo. Localizar la “fuente” exacta de un DDoS es complicado porque suele provenir de miles de dispositivos comprometidos.
Curiosidades que suelen sorprender
- Un fallo físico en una calle puede dejar sin Internet a cientos de vecinos y, sin embargo, no registrar un pico de incidencias en las redes sociales si afecta a una zona con pocos usuarios activos en línea.
- Muchos problemas se detectan antes por bots de monitorización que por llamadas de clientes: esas sondas son esenciales para detección temprana.
- Algunas veces la “caída” es provocada por políticas de ruteo o errores de configuración; basta con que alguien anuncie mal una ruta para que el tráfico se vaya por otro lado o se pierda.
Preguntas frecuentes
¿Cómo sé si la avería es de mi casa o del proveedor?
Prueba con otros dispositivos y reinicia el router. Haz ping a una IP pública conocida; si responde, es probable que tu acceso a Internet esté bien y el problema sea de DNS o del servicio que intentas usar. Si no responde desde varios dispositivos, contacta con tu proveedor indicando los pasos que has probado.
¿Qué es un traceroute y por qué es útil?
Traceroute muestra la ruta que siguen los paquetes desde tu equipo hasta un destino, identificando cada “salto” intermedio. Es útil porque te permite ver en qué punto la comunicación se degrada o se interrumpe, lo que ayuda a localizar si el fallo está en la red local, en el proveedor o más allá.
Por qué a veces solo falla una web y no todo Internet
Porque el problema puede estar en el servidor de esa web, en su CDN, en la configuración de su DNS o en la ruta concreta hacia su infraestructura. Si tu traceroute llega hasta el destino pero la web no responde, lo más probable es que la causa esté en el propio servicio.
¿Qué papel juegan los cables submarinos?
Los cables submarinos transportan gran parte del tráfico internacional. Una rotura o problema en uno puede aumentar la latencia o desviar tráfico por rutas más largas, provocando lentitud o pérdida de conectividad entre regiones. La detección de estos incidentes suele involucrar a consorcios de operadores y mediciones de latencia y disponibilidad.
Cuándo deberías llamar al soporte técnico
Si después de reiniciar el equipo, probar con otros dispositivos y realizar comprobaciones básicas (ping, traceroute) sigues sin conectividad, o si el problema afecta a servicios críticos, es momento de contactar. Proporciona al soporte la mayor información posible: síntomas, si el fallo es constante o intermitente, y resultados de pruebas básicas.
