El MTR desde nuestro nodo de Copenhague traza el camino salto a salto hacia tu destino y mide continuamente la latencia y la pérdida de paquetes en cada salto. Esto es más informativo que un traceroute de un solo disparo porque muestra patrones de pérdida y latencia sostenidos en lugar de una única medición. Desde Copenhague, las rutas hacia Hamburgo típicamente resuelven en 3–5 saltos a unos 17 ms. Las rutas hacia Estocolmo suelen resolverse en 4–6 saltos a unos 20 ms. Las rutas hacia Ámsterdam típicamente pasan por tránsito alemán o sueco en 5–7 saltos.

La posición de Copenhague entre Escandinavia y Alemania significa que los trazados MTR desde aquí a menudo revelan si el tráfico está tomando una ruta hacia el norte a través de Estocolmo o una ruta hacia el sur a través de Hamburgo para llegar a Europa Central. Para servidores en Fráncfort o Ámsterdam, ambas rutas existen y Glesys AS42708 puede preferir una dependiendo de los acuerdos de peering en un momento dado. Un salto de alta latencia seguido de latencia normal en los saltos posteriores es casi siempre limitación de tasa ICMP en ese router, no pérdida real de paquetes.

El MTR desde Dinamarca es especialmente útil para comparar el routing hacia Escandinavia frente a Europa Central desde el mismo origen. Si alojas en Fráncfort y quieres entender cómo los usuarios daneses llegan a tu servidor, el trazado MTR muestra exactamente qué proveedores de tránsito transportan el tráfico y dónde se introduce la latencia. Esto es más accionable que saber solo que el ping desde Dinamarca es de 35 ms: puedes ver qué salto supone ese retardo y si hay una ruta más directa disponible.

Copenhague es el hub de Internet principal de Dinamarca y funciona como un cruce de routing entre Escandinavia, la región báltica y Europa Central. Netnod opera un IX en Copenhague junto con su infraestructura de Estocolmo, y el Danish Internet Exchange (DIX) ofrece una alternativa de peering gestionada por la comunidad. Juntos, hacen de Copenhague una ubicación bien conectada para redes que necesitan hacer peering con los ISP nórdicos y bálticos sin enrutar primero por Fráncfort o Ámsterdam.

Dinamarca conecta la península escandinava con el continente europeo a través de su enlace terrestre vía Jutlandia hacia Alemania. Esta geografía significa que Copenhague tiene rutas de baja latencia tanto hacia Estocolmo (unos 20 ms) como hacia Hamburgo (unos 17 ms), lo que le confiere alcance natural en ambas direcciones. Los enlaces trans-Øresund hacia Malmö mantienen la latencia hacia el sur de Suecia muy por debajo de 10 ms. Varios cables submarinos conectan Dinamarca con el Reino Unido, Noruega y los países bálticos, proporcionando diversidad de rutas para el tráfico internacional.

Nuestro nodo sonda en Copenhague corre en AS42708, operado por Glesys AB. Glesys es un proveedor nórdico de hosting e infraestructura con presencia de centros de datos en Estocolmo, Gotemburgo y Copenhague. La ubicación de Glesys en Copenhague en su instalación del municipio de Glostrup da al nodo sonda buena conectividad upstream hacia el ecosistema de hosting nórdico en general. AS42708 anuncia rutas vía Netnod y tiene acuerdos de tránsito que cubren destinos tanto nórdicos como de Europa Central.

El mercado de hosting danés incluye tanto operadores locales como proveedores internacionales. TDC (AS3292) es el operador nacional incumbente y opera una parte significativa del backbone danés. Telia (AS1299) y Telenor (AS2119) proporcionan capacidad de tránsito adicional. El tráfico de alto consumo de banda ancha —streaming de video, cargas de trabajo en la nube— a menudo enruta vía Equinix Copenhagen, donde las CDNs y los proveedores de nube mantienen nodos de caché o edge locales para servir a los usuarios daneses sin obtener el contenido de centros de datos más lejanos.

Para operadores que atienden a usuarios daneses, Copenhague es la ubicación de prueba natural. Un servidor alojado en Copenhague o con peering en DIX o Netnod CPH debería alcanzar a la mayoría de los usuarios residenciales daneses en menos de 15 ms. Un servidor en Fráncfort añade 35–45 ms para los usuarios daneses antes de tener en cuenta cualquier variación en el último tramo. La presencia de CDN edge en Copenhague o en la cercana Malmö marca una diferencia significativa en aplicaciones sensibles a la latencia que sirven al mercado danés.