1969 ms a Rarotonga: una semana de congestión en el cable Manatua

En las primeras horas del 11 de abril de 2026, una sola respuesta ICMP desde Rarotonga tardó 1968 milisegundos en llegar a nuestro servidor en Minsk. A las cuatro de la madrugada del mismo día, la misma respuesta llegó en 443. A las dos de la tarde, la red había vuelto a su aburrido baseline de 440 ms y fingía que nada había pasado.

No fue un incidente aislado. Durante los últimos ocho días, cinco de nuestras sondas de medición — en Minsk, Tbilisi, Jerusalén, Sebastopol y Almaty — han estado viendo cómo el enlace a las Islas Cook se deshace lentamente en oleadas. Nuestro monitor de cables, mientras tanto, ha reportado el cable Manatua — el único enlace submarino que sirve a las quince islas — saludable todo el tiempo. Ambas cosas son ciertas al mismo tiempo, y este artículo trata de lo que eso significa.

Lo que medimos

Cada noventa minutos, cada una de nuestras sondas ejecuta un traceroute completo hacia una única dirección IP: 202.90.64.1, un router de borde dentro de Telecom Cook Islands en el límite de la red nacional. Durante los veinte días anteriores al 3 de abril, el tiempo de ida y vuelta base desde Europa o el Cáucaso hacia esa dirección fue de 430 a 490 milisegundos, estable dentro de unos pocos milisegundos de jitter. Esa es la realidad física de enrutar un paquete IP desde Minsk a una pequeña isla del Pacífico: Europa → tránsito GTT a través del Atlántico → Los Ángeles → Papeete sobre la cadena de cables Honotua y Manatua → último tramo dentro de la red de abonados de las Islas Cook. Aproximadamente 450 ms, ida y vuelta, cada vez.

Luego la cola de la distribución se engrosó.

El primer pico que registramos fue el 3 de abril, cuando una medición desde Tbilisi regresó con 973 ms en lugar de los 440 habituales. Una curiosidad. Cuatro días después, el 7 de abril, tres picos aparecieron en la misma ventana de la tarde, uno de ellos alcanzando 1928 ms desde Jerusalén. El 8 de abril, un cuarto pico con cuatro timeouts agrupados al final de la tarde. Luego tres días tranquilos — el 9 y el 10 de abril se veían exactamente como el baseline. Y entonces llegó el 11 de abril.

11 de abril, hora por hora

Ocho días de empeoramiento gradual de la tail latency comprimidos en un solo día. Lo peor vino en dos ventanas de tormenta — una en medio de la noche, otra alrededor de las siete de la mañana UTC — y entre ellas, la red se veía perfectamente normal.

Todos los valores son milisegundos de ida y vuelta hacia 202.90.64.1. Los valores por encima de 800 ms están en negrita. Cinco sondas en cinco países diferentes, y durante las ventanas de pico cuatro de ellas coincidieron simultáneamente en que algo iba mal. Esto descarta un problema local a una sonda — no es nuestro servidor de Minsk teniendo una mala mañana, no es un flap de un ISP de Tbilisi. La única manera de que cuatro sondas eurasiáticas coincidan al mismo tiempo es que el problema esté en algún lugar después de su primer salto común, y ese salto común está a quince mil kilómetros y un cable submarino de distancia.

Almaty muestra un patrón diferente — ocho timeouts de catorce mediciones a lo largo del día, pero sin picos. Ha tenido un problema menor de alcanzabilidad ICMP hacia este objetivo particular durante aproximadamente una semana, que tratamos como un problema separado y excluimos mentalmente del análisis de picos.

Misma ruta, diferente latencia

El traceroute más útil que capturamos es el que está detrás de ese número de 1969 ms. Así es como se ve — y así se veía la misma sonda veinte horas antes, en un día tranquilo.

10 de abril, Minsk → Islas Cook — 466 ms (baseline)

11 de abril, 02:59 UTC, Minsk → Islas Cook — 1969 ms (pico)

Hasta el salto 11, los dos traceroutes son casi indistinguibles. El camino es ligeramente diferente — RETN eligió una entrada por Tallin en uno y una entrada por Moscú en el otro — pero el perfil de latencia es idéntico: Minsk → Viena → Los Ángeles → Papeete, llegando a 302 milisegundos en un buen día y 304 milisegundos en uno malo. Si el tránsito de Manatua en sí se hubiera degradado, o si la red troncal del Pacífico de GTT se hubiera ralentizado, lo veríamos aquí. No lo vemos. El tránsito del cable fue normal los dos días.

La divergencia ocurre después de Papeete. En el día normal, tres saltos intermedios no responden y el objetivo responde a 454 ms — un limpio +150 ms para el último segmento, que es aproximadamente lo que esperarías para el enlace de fibra Papeete → Rarotonga más un par de dispositivos de red de abonado. En el día malo, siete saltos intermedios guardan silencio y el objetivo responde a 1969 ms — una cola de +1665 ms sin ninguna distancia física a la que culpar. Misma IP, mismo cable, mismo tránsito, mismo último salto. Día diferente.

Para confirmar que no es una historia específica de Minsk, aquí está el pico de Jerusalén del 7 de abril, 21:00 UTC, 1928 ms:

País de origen diferente, ISP eurasiático diferente, red troncal de tránsito diferente (Arelion en lugar de RETN hacia LA). Misma firma. La cola vive en algún lugar entre Papeete y el objetivo final, y no está hecha de fibra.

¿Dónde viven 1650 ms de latencia cuando no están hechos de distancia?

La distancia física de Papeete a Rarotonga por el cable Manatua es de aproximadamente 1.150 kilómetros. La luz viaja a través de la fibra óptica a unos 200.000 kilómetros por segundo — dos tercios de la velocidad de la luz en el vacío, debido al índice de refracción de la fibra. Un viaje de ida del fotón sobre 1.150 km tarda 5,75 ms, ida y vuelta 11,5 ms. Añade el procesamiento del router en cada extremo, un poco de encolado en un día tranquilo, y obtienes los 150 ms que realmente vimos el 10 de abril entre Papeete y el objetivo — dentro del overhead normal para una red de isla pequeña, donde la red troncal local está construida con switches commodity y el enlace agregado hacia el mundo exterior no es de 400 Gbps.

Lo que la física no puede explicar es 1665 ms. Eso es casi cien veces el presupuesto de velocidad de la luz para el mismo camino. Ninguna fibra en la Tierra es lo suficientemente lenta para producir eso. No es distancia. No es un corte de cable. Es encolado.

El término de manual es bufferbloat. Cuando un enlace de red se satura — porque demasiado tráfico, o muy poca capacidad, o ambos — los paquetes no se descartan. Esperan en la cola de salida del router su turno en el cable. Si la cola es grande (un megabyte o dos, lo cual es perfectamente normal en hardware commodity) y el enlace es lento (unos cientos de megabits, digamos), un paquete que llega al final de una cola llena puede quedarse allí un segundo y medio antes de ser transmitido. Eventualmente llega, ileso. Simplemente tardó una eternidad. El control de congestión de TCP no fue diseñado para esto: reacciona a las pérdidas, no a los retrasos, así que nunca retrocede eficientemente — y la cola permanece llena. La latencia colapsa en una niebla que se refuerza a sí misma.

El 11 de abril, la cola se llenó dos veces. Una vez alrededor de las 01:00 UTC y otra alrededor de las 07:00 UTC. Entre las dos tormentas, el tráfico se drenó y nuestras mediciones volvieron al baseline. Para las 10:00, la cola había desaparecido. Si la tendencia de una semana continúa — y un pico aislado, seguido por un grupo de tres picos, seguido por un muro de diez picos es una tendencia — deberíamos esperar otra ventana el 12 de abril y otra el 13.

Y mientras tanto, el cable está bien

Nuestro sistema de monitoreo de cables revisa la salud de Manatua de forma independiente. Cada pocas horas hace ping a un endpoint en el landing point directamente a través del cable y registra el tiempo de ida y vuelta y una proporción con respecto al baseline. Aquí está la misma ventana temporal, desde su punto de vista:

SELECT * FROM cable_alerts WHERE cable_id='manatua' devolvió cero filas durante toda la ventana. No emitimos ni una sola advertencia sobre el cable Manatua durante ninguno de los períodos de pico. Y teníamos razón al no hacerlo, en el sentido literal: el cable estaba transmitiendo paquetes perfectamente, a casi exactamente la misma velocidad que ayer. El problema estaba en otra parte.

Esta es la brecha que vale la pena nombrar. Cuando el monitoreo a nivel de cable hace ping a un endpoint en el landing point, ejercita la fibra y el router de borde del otro lado. No ejercita la red troncal del operador, ni el peering upstream, ni el equipo de acceso de abonado, ni la política de QoS, ni el buffer de interfaz que podría ser cuatro veces más grande de lo que debería. En muchas redes saludables y bien diseñadas, nada de eso importa — el cable submarino es la parte más estrecha y la que más falla del camino, así que probarlo es un proxy justo para todo el camino. En una isla con un único cable, no lo es. Todo entre Papeete y un usuario en Rarotonga es el backhaul de un pequeño operador, y ese backhaul es invisible para un test de ping que se detiene en el borde del cable.

Islas Cook, en cifras

Quince islas, aproximadamente 17.500 personas, la mayoría en Rarotonga. Un cable submarino — Manatua, 3.634 kilómetros, en servicio desde 2020, con aterrizajes en Rarotonga y Aitutaki y continuando hacia Niue, Samoa, Bora Bora y Papeete. Antes de Manatua, la conectividad internacional del país era satélite O3b, que en un buen día significaba unos 700 ms de latencia y en uno malo varios múltiplos de eso. Un operador nacional, Telecom Cook Islands, que en la práctica significa el único /24 al que seguimos apuntando nuestros traceroutes. Una relación de tránsito upstream, visible en cada uno de nuestros traceroutes: AS9471 Onati, desde Papeete.

No hay camino alternativo. Si Manatua cae, las Islas Cook vuelven al satélite. Si Telecom Cook Islands configura mal una cola en su uplink, unos pocos megabytes de paquetes se acumulan en el transcurso de una hora y permanecen allí hasta la mañana. No hay un segundo proveedor por el cual enrutar, ni una red troncal competidora a la que hacer failover. Así se ven los puntos únicos de fallo en la práctica en 2026.

Nada de esto es una crítica al operador. Hacer funcionar un ISP nacional para 17.000 abonados repartidos en quince islas es una proeza genuina de ingeniería, y Manatua fue el evento de infraestructura más importante en la historia moderna de las Islas Cook. Es la realidad del networking en islas pequeñas. Cuando las cosas salen mal, salen mal en el punto donde no hay redundancia — porque ahí es donde no hay redundancia.

Qué dice esto sobre cómo monitoreamos los cables

No detectamos esta semana. Nuestro propio sistema, monitoreo de salud de cables, tenía a Manatua con marcador limpio todo el tiempo. Nos decía que el cable estaba saludable y nos decía la verdad. Simplemente no era la pregunta correcta.

La pregunta correcta, para un país insular con un único cable, no es «¿está el cable transmitiendo paquetes?» sino «¿puede un paquete llegar a un endpoint del lado del abonado desde el mundo exterior y regresar en un tiempo razonable?». Estas son mediciones diferentes con modos de fallo diferentes, y la brecha entre ellas es precisamente donde vive un incidente como el de esta semana. Una estrategia de monitoreo adecuada para el Pacífico necesita ambas: salud a nivel de cable, que tenemos, y salud de endpoint a nivel de país, que aún no tenemos a la resolución que este tipo de patrón requiere.

Vamos a arreglarlo. Los pequeños países insulares con un único operador comercial — Islas Cook, Niue, Tokelau, Tuvalu, Nauru, Kiribati y algunos otros — merecen su propia pista de monitoreo a nivel de endpoint, porque tienen modos de fallo que sus cables no pueden expresar. Si lo hubiéramos tenido hace dos semanas, habríamos marcado el outlier del 3 de abril, el cluster del 7 y la ventana del 8 como una tendencia en construcción, y habríamos entrado al 11 de abril esperándolo en lugar de descubriéndolo en el reporte de la mañana.

¿Qué está causando esto realmente?

Honestamente — no lo sabemos.

Lo que podemos ver desde afuera: el cable Manatua está bien, el tránsito GTT de Europa a Papeete está bien, el problema está en algún lugar después del salto 11 dentro de la red de Onati y Telecom Cook Islands, y se manifiesta como un patrón de retraso de encolado consistente con bufferbloat en un enlace saturado. Lo que no podemos ver: si esa saturación es un problema de planificación de capacidad (los abonados finalmente superaron el uplink), una degradación parcial de la fibra en el segmento del Pacífico que redujo la banda ancha efectiva a la mitad, un cambio de enrutamiento que derivó más tráfico por una tubería, un buffer de interfaz mal configurado, una disputa de peering, o algo completamente distinto. Esas son preguntas a las que solo se puede responder desde dentro de la red del operador, y nosotros no estamos dentro.

Lo que podemos decir con confianza es que está empeorando. Un pico el 3 de abril. Tres el 7. Diez el 11. Cada ola más grande que la anterior; cada pico grande más cerca del techo de los 2.000 ms donde el propio TCP comienza a desmoronarse. Si la tendencia se mantiene — y ocho días de datos, cuatro ventanas de picos y una secuencia ordenada es una tendencia — nuestra próxima publicación será sobre el 13 o el 14 de abril, no solo sobre el 11.

Pruébelo usted mismo

Publicamos mediciones en vivo hacia este destino en la página del monitor de rutas — se actualiza a medida que llegan nuevos traceroutes, y si el patrón que describimos aquí continúa, el gráfico lo mostrará. También puedes leer la historia base que preparó estas mediciones: cómo un viaje de ida y vuelta limpio a las Islas Cook llega a 462 ms en primer lugar. Y el cable en sí tiene su propia página: Manatua, los 3.634 km de red troncal del Pacífico que, desde 2020, han sido el único enlace de fibra entre las Islas Cook y el resto del mundo.

Haremos un seguimiento con lo que traigan el 12 y el 13 de abril.