Cuando el tifón Sinlaku envió un cable de 200 km a un rodeo de 12 000 km: anatomía de un reenrutamiento BGP durante una tormenta Cat 5

Poco después del amanecer UTC del 14 de abril de 2026, nuestro monitoreo detectó algo que, a primera vista, parecía un fallo de cable submarino. El tiempo de ida y vuelta entre Saipán y Guam — dos islas separadas por unos 200 kilómetros de agua del Pacífico — saltó de 8,35 ms a 109,98 ms. Un pico de latencia 13 veces mayor en un cable cuyo piso físico es de apenas 2,6 ms, y justo durante la ventana en que el supertifón Sinlaku de categoría 5 cruzaba directamente sobre las Islas Marianas del Norte. La hipótesis obvia era la hipótesis obvia: la tormenta había roto el cable.

No fue así. El cable estaba perfectamente. Lo que se rompió fue algo más sutil — y, de algún modo, más interesante.

El rodeo de 12 000 km

El cable Mariana-Guam, encendido en 1997 y operado por PTI Pacifica, es el único cable submarino que conecta el Estado Libre Asociado de las Marianas del Norte con el resto del mundo. Sus 268 kilómetros de fibra trazan un arco corto desde Tanguisson Point, en la costa noroeste de Guam, subiendo por Rota, Tinian y Saipán, y transportan cada byte de internet no satelital para alrededor de 55 500 personas.

Nuestra sonda en Saipán — el ancla RIPE Atlas 6923, alojada con el transportista de tránsito pacífico OneQode (AS140627) — medía cada treinta minutos el tiempo de ida y vuelta a un punto final en Guam Exchange (AS152735, prefijo 103.142.152.0/24). Este es el traceroute previo al cambio, capturado el 13 de abril:

Ocho saltos. Seis de ellos dentro de la red de PTI Pacifica. De extremo a extremo: 8,35 milisegundos. Es aproximadamente la física de la luz atravesando dos veces 835 km de fibra óptica — la firma esperada de un trayecto directo Saipán → Tanguisson → destino.

Esta es la misma medición catorce horas después, cuando Sinlaku ya había pasado:

Un salto de más. Pero un solo tramo — de Guam a Los Ángeles y de vuelta al núcleo de OneQode — había añadido 109 milisegundos. El paquete ya no se quedaba en la isla. Cruzaba el Pacífico, entraba en tránsito estadounidense, pasaba a Arelion (AS1299), volvía a cruzar el Pacífico, aterrizaba otra vez en Guam y, recién entonces, vía PTI, tomaba el cable Mariana-Guam para la última etapa hasta el destino. Distancia total de ida y vuelta, en fibra: unos 12 000 kilómetros, para lo que debía ser un viaje de 200 km.

La asimetría lo reveló

Si el cable se hubiese roto, ambas direcciones se habrían degradado. Medimos la dirección inversa — desde Tanguisson Point en Guam hacia Saipán — y la respuesta fue inequívoca:

Guam-hacia-Saipán atravesaba el cable Mariana-Guam directamente, igual que el día anterior. El cable funcionaba exactamente como fue diseñado. La anomalía existía solo en una dirección y solo para los clientes de un único ISP. No era daño físico; era un cambio de enrutamiento.

Lo que el tifón realmente hizo

El tifón Sinlaku alcanzó intensidad de categoría 5 el 12 de abril de 2026: el Joint Typhoon Warning Center registró vientos sostenidos pico de aproximadamente 300 km/h (promedio de un minuto) y la Agencia Meteorológica de Japón midió una presión central de 897 hPa. Por varias métricas, fue el ciclón tropical más intenso jamás registrado tan temprano en un año calendario. Hacia las 14:30 UTC del 14 de abril, su ojo pasó directamente sobre Tinian y Saipán.

El viento al tocar tierra había disminuido a unos 230 km/h — todavía categoría 4. Saipán registró rachas sostenidas de 209 km/h y 135 mm de lluvia en un solo día. Alrededor de 43 000 personas en todo el Estado Libre Asociado de las Marianas del Norte perdieron el suministro eléctrico. Cada pieza de infraestructura de telecomunicaciones en la superficie de esas islas — torres celulares, enlaces de microondas, plantas eléctricas de estaciones de aterrizaje, equipos de peering en los racks de los ISP — recibió el mismo castigo que los edificios que las albergaban.

Y esto es lo que nuestras mediciones muestran que el tifón no hizo. Estos son los otros cinco grandes cables submarinos del Pacífico que nuestra infraestructura supervisa mediante sondas con visibilidad sobre la zona afectada:

Todos los demás cables pacíficos en la región afectada siguieron operando dentro de su varianza habitual. Sinlaku, una tormenta lo bastante poderosa como para tumbar una parte significativa del entorno construido de dos islas, no produjo degradación medible en cinco de los seis cables que nuestras sondas podían ver. La ingeniería estructural de las estaciones de aterrizaje modernas — cámaras de playa enterradas, edificios costeros reforzados, rutas submarinas profundas muy por debajo del alcance de la tormenta — funcionó como estaba previsto.

La sincronía

Lo que falló estaba sobre el suelo, y el orden temporal importa. Tres observaciones de RIPE Atlas anclan la cronología:

La propia sonda de PTI Pacifica en la isla cayó de la malla de RIPE Atlas 13 horas antes de que cambiara el camino de OneQode — el primer indicio de problemas en la infraestructura de PTI del lado de Saipán. Cuando el forwarding de OneQode cambió, PTI llevaba ya medio día parcialmente inalcanzable desde la red Atlas. El ojo de la tormenta llegó diez horas después del reenrutamiento: el daño BGP precedió a los vientos más fuertes. Lo que provocó las caídas del 13 de abril fueron las bandas exteriores del ciclón, el clima precursor y, presumiblemente, la pérdida de alimentación de red para cualquier equipo que no estuviera respaldado por UPS robustos.

Lo que muestra la tabla BGP pública

Consultamos el archivo del RIPE Routing Information Service para los dos prefijos implicados. El RIS almacena las actualizaciones BGP vistas por una malla global de colectores, y su registro para esta ventana es revelador:

Ninguno de los dos prefijos perdió su origen durante la ventana. Ambos siguieron siendo anunciados al resto de internet con normalidad. Lo que el RIS captó es mucho más modesto: breves estallidos de turbulencia en los caminos intermedios y un puñado de retiradas cortas desde unos pocos peers, coherentes con sesiones de peering aisladas que oscilan. Un lector casual de la tabla BGP pública para el 13–15 de abril no habría visto nada alarmante. Ambas redes, vistas desde fuera, permanecieron accesibles.

Y ese es precisamente el punto. El reenrutamiento no fue un evento BGP global. Fue uno local — ocurriendo en la frontera entre dos ISPs en una sola isla, e invisible a la tabla de rutas pública. OneQode había perdido su sesión de peering directo con PTI Pacifica en Saipán. Ido el camino local, los routers de OneQode retrocedieron a su siguiente mejor camino para alcanzar el espacio de direcciones de Guam: la ruta por defecto a través de su transitista Arelion, en Los Ángeles. Los paquetes seguían llegando a su destino. Simplemente cruzaban el Pacífico dos veces para lograrlo.

La topología no es la geografía

Esta es la parte que la mayoría de ingenieros de red ya conoce, pero que cada tormenta reenseña: la topología de internet es un grafo económico apoyado sobre uno físico, y los dos no tienen por qué coincidir. Un paquete que va de Saipán a Guam no viaja "por el camino más corto" en sentido métrico; viaja por donde, en ese instante, prefieren las políticas BGP de las redes que atraviesa. Esas políticas reflejan contratos de peering, facturas de tránsito, preferencias de ruta y cientos de pequeñas decisiones de ingeniería tomadas años atrás en salas tranquilas en otra parte. La mayor parte del tiempo esas decisiones coinciden con la geografía, porque el peering más barato suele ser el más cercano. Cuando el peering más barato se cae, toma el relevo el segundo más barato, y a veces el segundo vive a 11 000 kilómetros.

El Pacífico lo hace especialmente evidente. El internet de una isla es tan robusto como la cantidad de relaciones de peering locales distintas que mantienen sus ISPs. Si solo hay un peering entre los dos operadores principales, y va por un único equipo en un único edificio, cualquier fallo puntual en esa capa — un tejado arrancado, un generador apagado, un enlace caído — obliga a un "trombón" transoceánico. El cable submarino nunca fue el eslabón débil. De hecho, el cable es la parte de la infraestructura más pensada precisamente para el tipo de tormenta que trajo Sinlaku.

La alerta atascada 33 horas

La alerta 2026041403 en nuestro sistema saltó a las 05:01:55 UTC del 14 de abril y permaneció en estado active/critical durante 33 horas. Fue un auténtico momento "barco en la botella": el evento para el que nos habíamos construido, cazado, y luego la alerta atascada. Depuramos el ciclo de vida en caliente y desplegamos dos correcciones sobre nuestro detector de anomalías mientras la tormenta todavía soplaba.

La primera corrección abordaba una condición de puerta sutil: nuestra lógica de auto-resolución exigía un ping de ida y vuelta exitoso para sacar la alerta del estado activo. Para objetivos con ICMP bloqueado — donde el trace funciona pero el ping no — esa condición era insatisfacible, y las alertas nunca se cerraban. La reemplazamos por COALESCE(ping_rtt_ms, trace_rtt_ms): ahora la evidencia solo-trace también cuenta. Una alerta atascada ajena (Batam–Sarawak) se auto-resolvió en la siguiente pasada.

La segunda corrección era específica de la firma de Sinlaku. La alerta captura el RTT de referencia en el momento de la detección y compara las mediciones actuales contra ese número congelado. La línea base móvil en la tabla de health-checks se adapta a cambios persistentes en unas quince horas: quince horas después del cambio, la línea móvil había pasado de 25 ms a 100 ms. Pero la línea base congelada de la alerta (25,57 ms) seguía clavada. El cociente actual/congelado seguía reportando un pico del 330 % — sin forma evidente de auto-cerrar — pese a que en el nuevo régimen todo estaba perfectamente estable. Añadimos un chequeo de baseline-shift: si la alerta tiene más de 24 horas, la medición actual está a menos del 20 % de la línea móvil, y la línea móvil es a su vez al menos 1,5× la congelada, rebajamos de critical a monitoring y registramos el ratio de deriva. La alerta 74 se rebajó limpiamente, con deriva 3,95.

La lección de fondo es que la detección de anomalías debe distinguir dos modos de fallo: un cable se rompe y la latencia salta para siempre hasta la reparación física; o un cambio de topología establece una nueva normalidad y la supervisión debe reconocerla. Escribíamos código suponiendo que solo existía el primer modo. Sinlaku nos dio el segundo.

Lo que enseñan las islas

En los días posteriores a la tormenta, cada media hora para la que nuestra infraestructura tiene datos, la nueva normalidad de 110 ms para Saipán → Guam se mantiene firme. La sonda de PTI Pacifica sigue fuera de línea. OneQode sigue enrutando vía Los Ángeles. Si esto vuelve a un peering local la semana que viene, el mes que viene o nunca, depende de con qué rapidez pueda reconstruirse la infraestructura a ras de suelo de una pequeña isla del Pacífico — y de si alguien entre los implicados decide que la topología de un único peering era el problema a arreglar.

El cable sigue ahí. Su ida y vuelta más rápida sigue siendo 8,35 ms. En el sentido en que Guam emite hacia Saipán, eso es lo que siguen viendo nuestras mediciones. En el sentido en que Saipán emite hacia Guam, a través de un ISP concreto, la cifra por ahora es 110 ms. Dos islas, a 200 kilómetros una de la otra, un cable submarino entre ellas — y, para unos cuantos millones de paquetes por segundo, en una dirección, un rodeo de 12 000 km al que ninguno de ellos se apuntó.

Nuestras sondas siguen observando.

Los datos de este artículo proceden de nuestras propias mediciones de RIPE Atlas (ancla 6923 y sonda 65653 en Saipán), de las observaciones cable_health_checks de nuestras sondas en Minsk, Tiflis, Jerusalén, Sebastopol y Almatý, y del archivo público del RIPE Routing Information Service sobre actualizaciones BGP de los prefijos 103.142.152.0/24 y 103.151.64.0/24. Las cifras de trayectoria del ciclón proceden de los boletines de JTWC y JMA. Revisa el dossier del cable Mariana-Guam o abre el calculador de rutas para ver la latencia en vivo entre dos ciudades.