Cae Movistar y cae tu Digi: diagnosticar la caída en Linux

«No hay ningún problema. Está resuelto y apenas se notó». Eso respondió Telefónica a Xataka Móvil la mañana del jueves 1 de octubre. Desde las diez, más o menos, Downdetector se había llenado de avisos de clientes de Movistar, O2 y Digi sin cobertura, sin datos y, en parte, sin fibra.

Digi fue tendencia en X con una pregunta: ¿por qué se me cae a mí, si no soy de Movistar? Depende de quién es dueño de la antena y de la fibra, no de quién te cobra. Y ese día conviene saber pronto si el fallo es tuyo, del DNS o del operador.

Qué pasó el 1 de octubre y qué no se sabe

Método de esta parte: Revisado, como lo defino en cómo pruebo las guías. Contrastado con la prensa del día y con documentos de Telefónica, no medido por mí. Las horas son aproximadas; no hay cronología oficial.

Por qué cae tu otro operador

La marca que pagas y la red por la que viajan tus paquetes no tienen por qué coincidir. Hay tres casos, y los dos primeros explican lo del jueves.

El acuerdo está en una nota de prensa de Telefónica de julio de 2024. A la vez, Digi levanta red propia: más de 900 nodos a 31 de marzo de 2026, según ADSLZone. Por eso cayeron «algunos» clientes de Digi y no todos.

Lo mismo vale para cualquier operador móvil virtual: alquila la red de otro y hereda sus caídas.

NEBA: la fibra de otro con tu nombre

NEBA local es el acceso mayorista a la fibra hasta el hogar de Telefónica. Su descripción técnica, en la web de la CNMC, lo dice sin rodeos: como GPON impide separar físicamente cada línea, el servicio «establece una emulación de desagregación del bucle».

En la práctica, el cliente de Digi sobre NEBA usa la fibra, la caja terminal óptica y la OLT de Telefónica. Su tráfico viaja en nivel 2, como tramas Ethernet, hasta un punto de entrega local (el PAI), donde lo recoge la red de Digi. Si algo falla antes del PAI, Digi solo puede esperar.

Diagnosticar una caída, de dentro hacia fuera

Método de esta parte: Probado. Las salidas se tomaron el 1 de octubre a las 16:54 UTC en mi servidor web, Ubuntu 24.04.5 LTS, el de la comparativa AMD o Intel. Está en un centro de datos y con la red sana: nada es de la caída. Mis IP públicas van tapadas con x.x.x.

1. ¿Llego a mi router?

La puerta de enlace es la dirección a la que el equipo manda todo lo que no es de su red. ip route la dice y ping comprueba que contesta.

$ ip route show default
default via x.x.x.254 dev eno1 proto dhcp src x.x.x.128 metric 100

$ ping -c 4 -W 2 x.x.x.254
4 packets transmitted, 4 received, 0% packet loss, time 3096ms
rtt min/avg/max/mdev = 0.442/0.544/0.600/0.060 ms

Si aquí no hay respuesta, el problema está en casa. Apunta ese metric 100: vuelve a salir en el respaldo 4G.

2. ¿Llego a Internet sin usar nombres?

Ahora, a IP públicas de dos empresas distintas, Cloudflare y Quad9, para no culpar a Internet entera de la caída de un solo servicio.

$ ping -c 4 1.1.1.1
4 packets transmitted, 4 received, 0% packet loss, time 3014ms
rtt min/avg/max/mdev = 1.519/1.593/1.653/0.056 ms

$ ping -c 4 9.9.9.9
4 packets transmitted, 4 received, 0% packet loss, time 3013ms
rtt min/avg/max/mdev = 1.445/1.545/1.645/0.087 ms

Si la puerta de enlace responde y estas no, el fallo está fuera: la línea, la OLT o el operador. Con fibra, mira también la ONT; su manual dirá qué piloto indica pérdida de señal óptica.

3. ¿Es el DNS?

Si las IP responden y las webs no cargan, sospecha del DNS. dig pregunta al resolutor del sistema y a otros, uno por uno. Salida recortada:

$ dig www.movistar.es A +noall +answer +stats
www.movistar.es.	3600	IN	A	81.47.192.13
;; Query time: 185 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

$ dig @1.1.1.1 www.movistar.es A +noall +answer +stats
www.movistar.es.	3600	IN	A	81.47.192.13
;; Query time: 105 msec

$ dig @8.8.8.8 www.movistar.es A +noall +answer +stats
www.movistar.es.	1623	IN	A	81.47.192.13
;; Query time: 3 msec

$ dig @192.0.2.1 www.movistar.es +time=2 +tries=1
;; communications error to 192.0.2.1#53: timed out
;; no servers could be reached

127.0.0.53 es systemd-resolved, el intermediario local de Ubuntu. Google contestó en 3 ms con un TTL de 1623 en vez de 3600: ya lo tenía en caché. Estos tiempos comparan cachés, no resolutores. El último dig es un resolutor que no contesta: 192.0.2.1 está reservada para documentación.

4. ¿Dónde se corta el camino?

mtr junta ping y traceroute. -r saca un informe y termina, -c 20 manda veinte paquetes por salto, -w no recorta nombres y -z añade el sistema autónomo (AS) de cada salto.

$ mtr -4 -rwz -c 20 1.1.1.1
HOST: (mi servidor)                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS16276  x.x.x.252                 0.0%    20    0.5   0.6   0.4   2.9   0.6
  2. AS???    10.23.169.28              0.0%    20    0.7   0.5   0.4   0.8   0.1
  3. AS???    10.244.4.26               0.0%    20    0.6   0.6   0.3   0.9   0.1
  4. AS???    10.244.64.44              0.0%    20    0.2   0.2   0.1   0.4   0.1
  5. AS???    10.244.120.2              0.0%    20    3.7   4.1   1.9  12.2   2.7
  6. AS16276  (router del proveedor)    0.0%    20    1.5   1.5   1.2   2.3   0.3
  7. AS???    10.200.2.195              0.0%    20    1.0   1.1   1.0   1.3   0.1
  8. AS???    ???                      100.0    20    0.0   0.0   0.0   0.0   0.0
  9. AS13335  173.245.63.189            0.0%    20   68.8   8.1   1.8  68.8  15.0
 10. AS13335  one.one.one.one           0.0%    20    3.4   1.6   1.4   3.4   0.4

La línea que asusta es la 8: 100 % de pérdida. Pero los saltos 9 y 10 tienen 0 %: ese router solo ignora las sondas. La pérdida cuenta si sigue hasta el final. El pico de 68,8 ms del salto 9, igual.

tracepath (aquí no hay traceroute) se quedó mudo contra 9.9.9.9 desde el salto 8 mientras el ping respondía: sondea con UDP y muchos routers lo descartan. Silencio en una traza no es una caída.

Queda la web concreta. curl con -w dice en qué fase se para:

$ curl -4 -sS -o /dev/null -m 15 -w 'dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s http=%{http_code}\n' https://www.movistar.es/
dns=0.000495s tcp=0.102939s tls=0.314514s total=0.949751s http=200

Los tiempos se acumulan. Si se atasca en dns, es el DNS; si en tcp, la ruta o el servidor.

Un respaldo 4G o 5G que no caiga con la fibra

Un módem USB o el móvil compartiendo datos sirven de segunda salida, con una condición: la SIM tiene que ir por otra red. Una de O2 detrás de una fibra Movistar es la misma red dos veces; una de Digi, también donde Digi usa antenas de Movistar.

En Linux, dos salidas son dos rutas por defecto y gana la de menor métrica. Esto es Revisado: el servidor no tiene módem y no lo he ejecutado.

# No ejecutado: usb0 y 192.168.8.1 son un ejemplo de módem USB
sudo ip route add default via 192.168.8.1 dev usb0 metric 600
ip route show default

El problema: el núcleo solo abandona una ruta cuando el enlace cae, y en una caída del operador el router sigue encendido y el cable conectado. Hace falta algo que mire más allá de la puerta de enlace:

#!/usr/bin/env bash
# comprobar-salida.sh: ¿la salida principal llega a Internet de verdad?
# Solo mide e informa. No toca rutas: decidir el cambio es cosa tuya.
set -u

PRINCIPAL="${1:-eno1}"            # interfaz de la fibra (en casa suele ser enp*, eth0 o wlp*)
DESTINOS=(1.1.1.1 9.9.9.9 8.8.8.8) # tres redes distintas: si cae una, no decide sola
MINIMO=2                          # cuántos tienen que responder para dar la salida por buena

ok=0
for d in "${DESTINOS[@]}"; do
  # -I fuerza la interfaz: queremos medir la fibra, no la ruta que gane ahora mismo
  if ping -4 -n -q -c 2 -W 2 -I "$PRINCIPAL" "$d" >/dev/null 2>&1; then
    ok=$((ok + 1))
  fi
done

# El enlace puede estar "UP" con la red del operador caída: por eso se mira más allá
estado=$(cat "/sys/class/net/$PRINCIPAL/operstate" 2>/dev/null || echo desconocido)

if [ "$ok" -ge "$MINIMO" ]; then
  echo "$(date -u +%FT%TZ) $PRINCIPAL enlace=$estado internet=OK ($ok/${#DESTINOS[@]})"
  exit 0
fi
echo "$(date -u +%FT%TZ) $PRINCIPAL enlace=$estado internet=CAIDA ($ok/${#DESTINOS[@]})"
exit 1

Probado en el servidor contra eno1 y, para ver el caso malo, contra lo, la interfaz de bucle local, que no sale a ningún sitio. Es una simulación, no una caída:

$ ./comprobar-salida.sh eno1; echo "exit=$?"
2026-10-01T16:58:36Z eno1 enlace=up internet=OK (3/3)
exit=0
$ ./comprobar-salida.sh lo; echo "exit=$?"
2026-10-01T16:58:45Z lo enlace=unknown internet=CAIDA (0/3)
exit=1

El cambio de ruta a partir de ahí (script, temporizador de systemd o el propio router) no lo he probado.

Vuelta atrás

• ping, dig, mtr, tracepath, curl y el script solo leen: no hay nada que deshacer.
• Si instalaste algo para esto: sudo apt remove mtr-tiny.
• La ruta de respaldo: sudo ip route del default via 192.168.8.1 dev usb0 metric 600. No sobrevive a un reinicio.
• Si cambiaste el DNS durante la caída, apunta antes el que tenías y vuelve a él.

Qué no he probado

• Nada durante la caída: las salidas son de una red sana, horas después.
• Una línea de Movistar, O2 o Digi: el servidor está en un centro de datos.
• Ni el respaldo 4G con un módem real ni NetworkManager en Ubuntu Desktop.
• El AS de Digi desde el primer salto sobre NEBA: deducido, no visto.

Si tienes servicios en casa: un Cloudflare Tunnel evita abrir puertos, pero sale por la misma fibra. Si cae la línea, cae el túnel. Y si te gustan los fallos que no están donde parecen, en fail2ban baneaba a Cloudflare la IP del log no era la del visitante. Hay más en Servidores, redes y almacenamiento.

Fuentes

• Xataka Móvil, 1/10/2026: respuesta de Telefónica y desglose de Downdetector.
• Libertad Digital y El Debate, 1/10/2026: horas, avisos e hipótesis.
• Nota de prensa de Telefónica, 9/7/2024: acuerdo con Digi.
• Servicio NEBA LOCAL, descripción técnica v1.4, Telefónica España, en la web de la CNMC.
• ADSLZone, 15/5/2026: nodos propios de Digi.

Portada: Distrito Telefónica, Madrid, por Luis García (Zaqarbal), CC BY-SA 3.0 ES, vía Wikimedia Commons. Foto de archivo.