Resumen

  • Un intercambio de Internet regional no vende una ruta sino un puerto sobre un segmento de capa 2 definido. TREX publica con detalle su segmento de Tampere (VLAN 4, 195.140.192.0/24 y 2001:7f8:1d:4::/64, MTU IP 9000, TTL BGP 255) y con mucha menos generosidad el de Turku (VLAN 7, 2001:7f8:1d:7::/64, direccionamiento de LAN solo IPv6, IPv4 mediante RFC 5549 o RFC 8950) (Tampere, Turku).
  • La página de acceso VPLS del operador acota lo que el intercambio garantiza: el tráfico entre dos miembros conectados por FNE Finland toma la ruta más directa dentro de la red dorsal de FNE y no entra en la matriz de conmutación de TREX (FNE VPLS).

Un puerto, no una ruta

TREX Regional Exchanges Oy muestra en su página corporativa el número de empresa finlandés 1780867-1 y declara como actividad principal mantener y desarrollar un punto de intercambio para tráfico de Internet y de otro tipo entre clientes conectados; la gestión diaria del intercambio recae en Axu TM Oy (empresa). La empresa afirma haber instalado un segundo punto de intercambio en Turku durante el invierno de 2024-2025 (acerca de), y mantiene su sede y dirección postal en Kuninkaankatu 30 A, Tampere (contacto).

Esa geografía no es un detalle comercial. Un intercambio de Internet no vende un camino: vende un puerto sobre un segmento de capa 2, más el acceso a uno o varios servidores de rutas que llenan la tabla BGP del miembro. Todo lo demás —el trayecto físico hasta el edificio, la calidad del camino, lo que el vecino haga con el anuncio recibido— pertenece a otros contratos y a otros actores. Leer a TREX consiste, por tanto, en separar dos cosas que la jerga del sector confunde con facilidad: la topología anunciada y la topología realmente recorrida.

Dos LAN, dos niveles de detalle

El segmento de Tampere está documentado como un objeto técnico completo: VLAN 4, LAN de peering 195.140.192.0/24 y 2001:7f8:1d:4::/64, MTU IP de 9000, TTL BGP de 255, entrega de la VLAN en nativo o encapsulada en IEEE 802.1Q (Tampere). La tabla de direccionamiento correspondiente nombra los servidores de rutas de TREX en AS197032 en 195.140.192.1, 195.140.192.2, 2001:7f8:1d:4::1 y 2001:7f8:1d:4::2, identifica TREX Services en AS29432 y asigna direcciones a participantes con nombre: Domainkeskus, Elisa, CSC/Funet, FNE Finland, Glesys, Seclan, Planeetta Internet, SuomiCom, Cinia, GlobalConnect, Telia Finland, S1 Networks, Web1, Lounea, Axu TM y NetInch (direccionamiento Tampere).

Turku, en cambio, cabe en una página más corta: VLAN 7, prefijo 2001:7f8:1d:7::/64, MTU 9000, TTL BGP 255 y una frase que cambia la naturaleza del servicio —el direccionamiento de la LAN de peering es exclusivamente IPv6, y el peering IPv4 debe realizarse mediante las técnicas RFC 5549 o RFC 8950 (Turku). Dicho de otro modo: un miembro IPv4 que quiera intercambiar en Turku no se limita a direccionar una interfaz; necesita sesiones BGP capaces de transportar próximos saltos IPv4 dentro de una señalización IPv6. Es un requisito de configuración real, y no se impone en Tampere.

Dos servidores de rutas, un solo AS

El operador describe su dispositivo sin ambigüedad: dos servidores de rutas por punto de intercambio, un ASN de 32 bits, 197032, el valor 23456 sugerido para equipos incapaces de configurar un ASN de 32 bits, BIRD 2 como implementación y la aceptación de rutas registradas en RIPE procedentes de los miembros participantes (MLPA). La página de peering añade el reparto de papeles: AS29432 es el ASN de infraestructura de TREX, AS197032 el de los servidores de rutas, el peering se hace sobre la VLAN de peering de Tampere y/o la de Turku, y TREX dispone de dos routers (peering).

Esa página también muestra objetos route y route6 etiquetados «source: RIPE # Filtered», entre ellos 195.140.194.0/23, 2001:67c:2b0::/48 y 2001:7f8:1d::/48 (peering). Conviene ser preciso: la página es de TREX y reproduce una vista filtrada de objetos RIPE, no es una respuesta de registro. La página de recurso de RIPEstat para AS29432 no entregó contenido legible en la consulta; por tanto, las afirmaciones relativas a RIPE se apoyan en la visualización del operador, no en un registro inspeccionado directamente (RIPEstat).

Lo que el operador publica sobre su propio rodeo

La página más instructiva del sitio no es una página de peering. Es la de acceso por VPLS de FNE Finland. Allí se lee que FNE Finland ofrece una conexión remota a la VLAN de peering unicast, VLAN ID 4, en cualquier punto de Finlandia, sobre su red dorsal MPLS mediante VPLS; y, sobre todo, que el tráfico entre dos miembros FNE VPLS toma la ruta más directa dentro de la red dorsal de FNE y no entra en la matriz de conmutación de TREX (FNE VPLS).

Es el propio operador quien acota su producto. Para un miembro conectado de este modo, el valor del intercambio no es el trayecto: es la lista de redes alcanzables y los dos servidores de rutas en AS197032. El paquete intercambiado entre dos miembros FNE no atraviesa nunca el conmutador del intercambio, y ninguna medida de capacidad tomada en ese conmutador describirá el rendimiento de ese miembro. La página ofrece además un ejemplo de compromiso de 100 Mbps, con cargos de adhesión y de transporte separados (FNE VPLS).

La página de revendedores completa el cuadro: Elisa, FNE Finland, Funet, SuomiCom y Telia Finland figuran como revendedores; un revendedor establece una conexión de 10 Gbps o más hacia el intercambio y conecta varios clientes sobre ese enlace compartido; el acceso por revendedor se distingue de la adhesión completa, en particular por la ausencia de puerto físico en el conmutador para los clientes del revendedor (revendedores). Coexisten, pues, tres modelos de acceso —puerto propio, puerto compartido en un revendedor y túnel VPLS en un transportista— y solo uno termina en la matriz del intercambio.

Tampere: el registro y el edificio

PeeringDB asigna a TREX Tampere 25 pares, 31 conexiones, 17 pares abiertos y una capacidad total de 188G, con marca de última actualización en 2025-03-03T15:26:57Z, y nombra tres instalaciones locales: Elisa Tampere Nalkala, Glesys Tampere 1 y Tampere Hallituskatu 14 (PeeringDB ix 328). La aritmética merece atención: 31 conexiones para 25 pares implica que al menos seis pares tienen más de una conexión, extremo que el registro no precisa. Y 188G es una suma de capacidades declaradas, no un caudal medido ni una tasa de utilización.

La página de red de AS29432 muestra el AS-set de IRR AS29432:AS-PEERING y fue actualizada el 2025-05-27T14:30:37Z; la organización, registrada en Tampere, vincula AS29432 y AS197032 y los dos intercambios, con marca temporal de 2025-05-27T14:28:55Z (PeeringDB red, PeeringDB organización). Todas esas fechas son anteriores a las páginas del operador consultadas el 2026-11-12: las cifras de miembros y capacidad pueden ir por detrás de lo que TREX publica hoy.

El lado físico de Tampere se cuenta en otra página, más antigua: Hallituskatu 14 aparece descrito como un edificio de oficinas del centro que alberga pequeños colocations de distintos operadores de Internet, con referencias de meet-me-room o de paneles para Elisa, Cinia, DNA Finland, FNE Finland, GlobalConnect, Portlane y Telia Finland (Hallituskatu 14). La página de contacto, en cambio, enumera dos instalaciones de PeeringDB, Hallituskatu (instalación 2333) y Nalkala (instalación 3230), y no menciona ni sede en Turku ni camino de transporte físico entre ambas ciudades (contacto).

Turku: una contradicción con fecha

La tabla de miembros expone por separado la participación en Tampere, la participación en Turku, la participación en los servidores de rutas y la condición de revendedor, y nombra en particular Domainkeskus AS29243, Elisa AS719, CSC/Funet AS1741, Telia Finland AS1759, GlobalConnect AS12552, S1 Networks AS199508 y Web1 AS207003 (miembros). Es esa misma tabla la que crea el único conflicto interno del expediente: marca Partel AS42885 y Port 179 AS212232 con el indicador Q3, que su propia leyenda define como conexión pendiente. Sin embargo, la tabla de direccionamiento de Turku asigna direcciones de peering a esas dos redes, junto a S1 Networks AS199508, Web1 AS207003, Cuitunet AS211368 y V4LESS-AS AS215250 (direccionamiento Turku, miembros).

Esa página no dice si una dirección mostrada corresponde a una sesión operativa, pendiente o recién aprovisionada (direccionamiento Turku). Nombra los servidores de rutas de Turku en AS197032 en 2001:7f8:1d:7::1 y 2001:7f8:1d:7::2 (direccionamiento Turku). PeeringDB, por su parte, cuenta 6 pares, 8 conexiones, 6 pares abiertos y 20G para TREX turku, con marca temporal en 2025-01-01T02:53:48Z y el prefijo de LAN 2001:7f8:1d:7::/64, pero no muestra ni a Partel ni a Port 179 (PeeringDB ix 4621).

Una dirección asignada y un estado «pendiente» no son lo mismo, y nada en las páginas consultadas permite zanjarlo. El hecho con fecha es doble: la tabla de miembros dice Q3, la tabla de direccionamiento publica direcciones, el registro no muestra esos pares. Eso no prueba ni la ausencia de sesión ni su funcionamiento.

Lo que ninguna página mide

El expediente calla sobre las magnitudes que decidirían una compra. Ninguna página consultada publica volumen de tráfico, latencia, disponibilidad, crédito de servicio o precio de puerto; las únicas referencias numéricas son el ejemplo de compromiso de 100 Mbps en FNE y el umbral de 10 Gbps o más para un revendedor (revendedores). Ninguna dirección de instalación en Turku, ningún sitio de colocation y ningún camino de transporte entre las dos ciudades aparece en la página de servicio de Turku, en la de contacto o en el registro de organización consultados (contacto). Y los 188G y los 20G son sumas de capacidad declaradas en un registro, nunca un caudal observado.

La prueba de compra

Lo que TREX vende, y lo que el operador documenta correctamente, es un puerto sobre un segmento nombrado, con MTU, TTL BGP y dos servidores de rutas sobre un ASN único. Lo que un comprador puede verificar antes de firmar es la existencia de ese puerto, la identidad de las redes direccionadas allí y el modo de acceso —puerto propio, puerto de revendedor o túnel en un transportista—. Lo que no puede verificar en las páginas públicas es el trayecto real de sus paquetes hacia cada una de esas redes, y en particular si pasarán por la matriz del intercambio o por la red dorsal de otro. La ficha del directorio de BTW está aquí: TREX Regional Exchanges Oy.

Fuentes