0,7 ms a 1.1.1.1: cómo un solo ancla dejó ciega nuestra monitorización durante tres meses

Si haces ping a 1.1.1.1 y responde, ¿qué has aprendido? Durante tres meses creímos que la respuesta era "este punto de observación puede alcanzar la internet global". No es así. El 23 de agosto de 2026 medimos la misma dirección desde varios puntos de observación al mismo tiempo, y los números no eran comparables en ningún sentido útil.

Esta es una nota sobre cómo nos equivocamos, qué nos costó y cómo cualquiera puede verificar lo mismo en su propio monitoreo en unos cinco minutos.

La misma dirección, cuatro distancias muy diferentes

Cada cifra a continuación es el tiempo promedio de ida y vuelta sobre 52 muestras consecutivas de 20 paquetes ICMP cada una, tomadas el mismo día desde un punto de observación diferente en nuestra red de medición distribuida. El ancla es idéntica en cada fila.

Tres de esas filas se comportan como rutas normales de internet. Una no. Desde Kiev, 1.1.1.1 responde en menos de un milisegundo, mientras que el resolutor de Google desde la misma máquina está a 14 мс. La caja no está inusualmente cerca de internet en general. Está inusualmente cerca de esa única dirección.

Los traceroutes

Dos rutas desde el mismo host, tomadas con segundos de diferencia. Primero, hacia 1.1.1.1:

Cinco saltos, y el paquete nunca sale del área metropolitana. Ahora el mismo host hacia 8.8.8.8:

Once saltos, y puedes ver exactamente dónde el tráfico sale de la ciudad: entre el salto 6 y el salto 8, la latencia pasa de 1,3 мс a 14,5 мс. Ese salto es lo que pensábamos que estábamos monitoreando. En la ruta de 1.1.1.1, ese salto nunca ocurre.

¿Por qué la diferencia? Ambas direcciones son anycast, por lo que ambas responden desde la instancia topológicamente más cercana. En Kiev, una instancia de una de ellas está prácticamente al lado, accesible a través de peering local. Ya sea un nodo de borde que hace peering con la red local o algo en la ruta que responde por la dirección, nuestros datos no pueden decirlo, y para fines de monitoreo no importa. Lo que importa es que la ruta no atraviesa la internet global, por lo que no puede informar sobre la internet global.

El ancla incluso oculta fallos en su propia ruta

Mira de nuevo el salto 4 en el primer traceroute: 33% de pérdida de paquetes, con muestras individuales que varían de 1,7 мс a 21,9 мс. Ese es un salto genuinamente problemático. No tiene efecto en la medición, porque el ancla responde antes de que la ruta llegue tan lejos. Un sistema de monitoreo que observe este ancla informaría de una red perfectamente saludable mientras está a un salto de un enlace que pierde un tercio de sus paquetes.

Lo que nos costó

Realizamos una prueba de correlación para ver si un factor externo documentado de estrés aparecía en nuestras series de alcance. Para el punto de observación de Kiev tomamos cada día en el que se registraron alertas públicas de ataque aéreo en la ciudad y comparamos la intensidad de las alertas contra la pérdida de paquetes medida hacia el ancla.

En 69 días de este tipo, el alcance promedio fue del 99,87%. Sesenta y siete de los 69 días estuvieron en el 99,9% o mejor, incluyendo cada uno de los días con mayor actividad de alertas. El resultado fue un claro nulo.

Casi publicamos ese resultado nulo como un hallazgo sobre la resiliencia de la red. No era un hallazgo sobre la red. Era un hallazgo sobre el ancla: habíamos estado midiendo un enlace dentro de la ciudad que no tenía ninguna razón particular para fallar, y observamos correctamente que no fallaba. El instrumento no tenía sensibilidad para la pregunta que se estaba planteando.

Un resultado nulo de un instrumento que no has validado no es evidencia de ausencia. No es evidencia de nada.

Lo que cambiamos

Tres cambios, todos aburridos, ninguno inteligente.

Más de un ancla. Cada punto de observación ahora mide un ancla global, una segunda ancla global operada por otra organización y un par dentro de la misma región. Tres destinos que fallan por tres razones diferentes son mucho más difíciles de engañar que uno solo.

El primer salto, explícitamente. Cada barrido ahora también mide la puerta de enlace local. Si el primer salto está limpio y todo lo que está más allá no lo está, el problema está aguas arriba. Si el primer salto está sucio, es la última milla. Esa única medición adicional separa dos clases de fallos que un solo ancla fusiona en una "degradación" indiferenciada.

Un tamaño de muestra útil. Estábamos enviando seis paquetes por ciclo. Seis paquetes no pueden distinguir entre un 5% de pérdida y un 0% de pérdida; el paso más pequeño que puede expresar es de 17 puntos porcentuales. Ahora enviamos veinte. En el primer ciclo después del cambio, un punto de observación registró 19 de 20 paquetes hacia su ancla principal mientras que ambos otros anclas y la puerta de enlace local permanecieron limpias, lo que ubicó una pérdida del 5% en una ruta específica. La configuración anterior habría redondeado eso a "bien".

Deliberadamente no cambiamos qué ancla alimenta el umbral de alerta. Redefinir una métrica y mantener su nombre es la forma en que una historia de monitoreo silenciosamente deja de significar algo. El ancla principal se mantuvo donde estaba para que la línea base existente siga siendo comparable; las nuevas anclas se registran junto a ella y tomarán el relevo una vez que hayan acumulado suficiente historia para tener su propia línea base.

Verifica el tuyo

Desde cualquier host que monitorees, ejecuta un traceroute a cualquier dirección que tu monitoreo trate como "internet". Luego ejecuta uno a otra dirección conocida operada por alguien más. Compara el número de saltos y, más importante aún, busca el salto de latencia donde el tráfico sale de tu área metropolitana. Si la ruta de tu ancla no tiene ese salto, tu prueba de alcance es una prueba de enlace local disfrazada de etiqueta global.

La prueba cuesta dos comandos. No la ejecutamos durante tres meses, que es la única razón por la que esta nota existe.

Limitaciones

Esta es una instantánea de un día de un ancla desde un puñado de puntos de observación; la topología anycast cambia, y la misma dirección puede comportarse de manera completamente diferente el próximo mes o desde otra red. No hemos establecido por qué la ruta de Kiev termina localmente, solo que lo hace. La prueba de correlación descrita anteriormente cubre una ciudad y un ancla, y no dice nada sobre la resiliencia de la red en general: esa pregunta sigue abierta precisamente porque nuestro instrumento no pudo responderla. Esperamos poder revisarla una vez que la serie de múltiples anclas haya acumulado suficiente historia.

Todas las cifras aquí provienen de nuestra propia red de medición distribuida y son reproducibles con ping y mtr estándar desde cualquier host en las mismas redes.