Resumen

  • Una traza publicada por Cogent alcanzó una dirección de loopback de TDC en Dinamarca en 175,604 ms y otra de NTT en 181,747 ms; la comparación por Colt tardó 22 ms.
  • Las pruebas aportadas después mostraron que GTT podía entregar la misma ruta a TDC en Europa: unos 20 ms desde Londres, 12 ms desde Ámsterdam y entre 2 y 4 ms desde Copenhague.
  • El denunciante dijo que TDC creó una ruta directa con el AS británico, al parecer en LINX. El arreglo resolvió el problema observado, pero carece de redundancia y podría devolver el tráfico a Norteamérica durante una avería.

En los problemas de enrutamiento, el primer mapa suele ser demasiado convincente. Los nombres de los saltos sugieren una historia, las latencias la adornan y el ojo encuentra enseguida al operador que aparece en medio. Eso ocurrió en un hilo del Routing Working Group de RIPE sobre una conexión entre Cambridge y una red de TDC en Dinamarca.

El recorrido mostrado desde Cogent salió de Londres, pasó por Liverpool, saltó a Montreal, llegó a GTT en Nueva York y regresó a TDC. La respuesta final del loopback 93.178.170.33 fue de 175,604 ms. Una segunda prueba, presentada como originada en el looking glass londinense de NTT, enseñó saltos en Ashburn y Washington antes de terminar en 181,747 ms.

Una tercera ruta funcionaba como control: Colt llegaba a la misma dirección en tres saltos mostrados y 22 ms, sin abandonar Europa. La diferencia rondaba los 150 ms. Parecía natural concluir que el punto de interconexión entre GTT y TDC obligaba al viaje americano.

La conclusión era natural y, según las pruebas posteriores, incompleta.

La prueba que desmontó la primera explicación

Un participante consultó el looking glass de GTT hacia 93.178.170.33. Desde Londres, GTT entregaba el tráfico a TDC y terminaba en aproximadamente 20 ms. Desde Ámsterdam, el resultado estaba alrededor de 12 ms. Desde Copenhague, entre 2 y 4 ms.

GTT sí disponía de un camino europeo funcional hacia TDC para la dirección examinada. Ya no era posible explicar las trazas lentas diciendo que la interconexión europea no existía. Había que descender un nivel: qué anuncio había recibido cada red, dónde lo había aprendido y por qué su política lo prefería.

Ese cambio de pregunta es más importante que el dibujo transatlántico. Un traceroute muestra una secuencia de respuestas y tiempos desde una posición concreta. No revela por sí solo el contrato de tránsito, las comunidades BGP, las rutas que nunca se anunciaron ni las alternativas rechazadas por la política local.

El contraejemplo de GTT separó disponibilidad de selección. Que exista una ruta corta no significa que Cogent la conozca o pueda usarla para el prefijo correspondiente. Que dos operadores estén presentes en Londres tampoco significa que intercambien esas rutas allí.

La dirección observada no era el servicio

Peter Keller abrió el hilo el 29 de julio de 2026. Explicó que un usuario de Cambridge sufría latencia persistente hacia un destino alojado en AS3292, la red danesa de TDC. El proveedor administrado por el edificio acababa de cambiar de conectividad internacional. Keller veía una correlación temporal, pero no podía confirmar quién era el nuevo proveedor.

Las mediciones públicas se dirigieron al loopback 93.178.170.33. RIPEstat lo sitúa actualmente en 93.178.128.0/18, originado por AS3292, y denomina a AS3292 TDC Holding. La dirección servía para probar caminos hasta la red de TDC; el hilo no dice que fuese la dirección de la aplicación afectada.

La diferencia importa porque evita atribuir a la prueba más de lo que contiene. Tampoco conocemos el protocolo de la aplicación, el sentido del tráfico que dominaba la experiencia ni si las rutas de ida y vuelta eran iguales. Una traza en una dirección no certifica la inversa.

Los nombres DNS de los routers añaden otra cautela. Son etiquetas mantenidas por los operadores y pueden quedar desactualizadas. La documentación de RIPE Atlas advierte además que la resolución regional apoyada en DNS inverso y geolocalización puede equivocarse. En este caso, las etiquetas y los saltos de RTT eran coherentes con un cruce atlántico, pero esa coherencia no convierte cada código de ciudad en una coordenada física demostrada.

El dato firme es más acotado: dos muestras resultaban mucho más lentas que una alternativa europea hacia el mismo punto de red.

Un prefijo convirtió la anomalía en una decisión

La investigación avanzó cuando otro operador publicó la vista de Cogent desde Alemania para 93.178.128.0/18. La ruta seleccionada mostraba el camino AS 3257 3292 3292 3292 3292. Cogent estaba aprendiendo el prefijo a través de GTT, AS3257, y veía varias repeticiones de AS3292. La salida también contenía un siguiente salto canadiense y la comunidad 174:22003.

La tabla no demostraba la intención de nadie, pero identificaba el mecanismo observable. Cogent no estaba inventando un trayecto geográfico al azar: estaba utilizando el anuncio que había aceptado y preferido. La cuestión operativa pasó a ser quién controlaba el anuncio que llegaba a Cogent y qué relación de peering faltaba para acortarlo.

El 4 de septiembre, Keller comunicó el resultado de sus conversaciones con el responsable de peering de TDC y un ingeniero. Según su relato, el AS británico no identificado anunciaba el prefijo relevante solo a Cogent, pese a disponer de otros tres tránsitos. Cogent, por su parte, no aceptaba establecer peering con TDC en Europa.

La combinación explica cómo una red puede comprar diversidad sin utilizarla para un prefijo concreto. Cuatro proveedores en una factura no equivalen a cuatro rutas de salida o entrada. Si solo uno recibe el anuncio, la supuesta redundancia comercial no aparece en el plano de control.

Tampoco basta con mirar un mapa de fibra de Cogent o GTT. La infraestructura puede estar en Europa y, aun así, la relación necesaria para ese prefijo puede no existir. BGP opera sobre anuncios y preferencias, no sobre el camino que un observador considera geográficamente sensato.

No hay en el expediente una declaración pública de Cogent o TDC que confirme el diagnóstico. Por ello debe atribuirse a Keller y a sus conversaciones. También debe descartarse una afirmación más tentadora: algunos participantes sugirieron que la política limitada respondía al precio, pero no presentaron pruebas de una motivación financiera.

La excepción directa resolvió el presente

Keller contó que TDC organizó una ruta directa con el AS británico. El 7 de septiembre añadió que ambas redes estaban presentes en el London Internet Exchange y que, por lo que le habían explicado, la conexión parecía haberse realizado allí. El hilo no publica la sesión ni la configuración; LINX es una inferencia informada, no un hecho comprobado de manera independiente.

El efecto sí fue comunicado con claridad: el problema quedó resuelto.

También quedó clara la limitación. La ruta era no redundante. Una interrupción podía volver a enviar temporalmente el tráfico por Norteamérica.

Así, el remedio cambió el estado normal, pero no eliminó el estado anterior. Lo convirtió en la ruta de reserva. Mientras la sesión directa esté activa, los usuarios ven baja latencia y el incidente parece cerrado. Cuando la sesión, el puerto, el transporte o el anuncio desaparezcan, la red volverá a revelar si se corrigió el diseño o solo se ocultó su peor resultado.

No hay contradicción entre celebrar la reparación y exigir el siguiente paso. Una ruta bilateral puede ser la intervención más rápida y eficaz. TDC podía actuar sin esperar una revisión general de políticas en Cogent. La red británica podía aceptar una vecindad precisa. El coste era crear un nuevo punto único de dependencia.

Falta medir el día de la caída

El registro operativo necesario no es un ensayo. Debe identificar el prefijo británico, enumerar a qué tránsitos se anuncia de verdad y describir qué rutas acepta la sesión directa. Después debe señalar una alternativa europea independiente: no otra sesión que comparta el mismo puerto, transporte o fallo.

Por último, necesita una prueba de retirada. Las mediciones deben salir de los extremos afectados, realizarse en ambos sentidos y conservar la ruta AS y el RTT antes, durante y después de retirar el camino principal. Solo entonces el equipo sabrá si una avería produce una degradación tolerable o restaura los 176–182 ms.

La secuencia pública del hilo merece atención porque corrigió su propia intuición. El primer traceroute señaló un síntoma. Las pruebas de GTT falsaron una causa demasiado sencilla. La vista BGP localizó el anuncio elegido. El contacto con TDC encontró una palanca y aplicó un arreglo. El único elemento que falta es la conducta comprobada del respaldo.

Esa ausencia no invalida la solución. Define la próxima decisión.

Alcance de las fuentes

Los tiempos y caminos son salidas publicadas por participantes del hilo. El diagnóstico y la eficacia de la ruta directa son el relato de Keller tras hablar con TDC, no un informe conjunto de los operadores. RIPEstat confirma la identidad actual del prefijo y de los AS; no reconstruye por sí solo el estado histórico de julio. Las referencias geográficas se interpretan con cautela por las limitaciones conocidas del DNS inverso.

Fuentes