Résumé

  • Un échange Internet régional ne vend pas une route mais une prise sur un segment de couche 2 défini. TREX publie très complètement son segment de Tampere (VLAN 4, 195.140.192.0/24 et 2001:7f8:1d:4::/64, MTU IP 9000, TTL BGP 255) et beaucoup plus chichement celui de Turku (VLAN 7, 2001:7f8:1d:7::/64, adressage de LAN en IPv6 seulement, IPv4 par RFC 5549 ou RFC 8950) (Tampere, Turku).
  • La page d’accès VPLS de l’opérateur borne elle-même ce que l’échange garantit : le trafic entre deux membres reliés par FNE Finland emprunte la route la plus directe dans le réseau dorsal de FNE et n’entre pas dans la matrice de commutation de TREX (FNE VPLS).

Un port, pas une route

TREX Regional Exchanges Oy affiche sur sa page société le numéro d’entreprise finlandais 1780867-1 et déclare pour activité principale l’exploitation et le développement d’un point d’échange pour le trafic Internet et d’autres trafics entre clients connectés ; la gestion quotidienne de l’échange est confiée à Axu TM Oy (société). L’entreprise indique avoir installé un second point d’échange à Turku pendant l’hiver 2024-2025 (à propos), tout en conservant son siège et son adresse postale à Kuninkaankatu 30 A, Tampere (contact).

Cette géographie n’est pas un détail commercial. Un échange Internet ne vend pas un chemin : il vend une prise sur un segment de couche 2, plus l’accès à un ou plusieurs serveurs de routes qui peuplent la table BGP du membre. Tout le reste — le trajet physique jusqu’au bâtiment, la qualité du chemin, ce que le voisin fait de l’annonce reçue — appartient à d’autres contrats et à d’autres acteurs. Lire TREX revient donc à séparer deux choses que le vocabulaire du secteur confond volontiers : la topologie annoncée et la topologie effectivement empruntée.

Deux LAN, deux niveaux de détail

Le segment de Tampere est documenté comme un objet technique complet : VLAN 4, LAN de peering 195.140.192.0/24 et 2001:7f8:1d:4::/64, MTU IP de 9000, TTL BGP de 255, livraison du VLAN en natif ou encapsulée en IEEE 802.1Q (Tampere). La table d’adressage correspondante nomme les serveurs de routes TREX sur AS197032 en 195.140.192.1, 195.140.192.2, 2001:7f8:1d:4::1 et 2001:7f8:1d:4::2, identifie TREX Services sur AS29432 et attribue des adresses à des participants nommés — Domainkeskus, Elisa, CSC/Funet, FNE Finland, Glesys, Seclan, Planeetta Internet, SuomiCom, Cinia, GlobalConnect, Telia Finland, S1 Networks, Web1, Lounea, Axu TM, NetInch (adressage Tampere).

Turku, lui, tient en une page plus courte : VLAN 7, préfixe 2001:7f8:1d:7::/64, MTU 9000, TTL BGP 255, et une phrase qui change la nature du service — l’adressage du LAN de peering y est exclusivement IPv6, le peering IPv4 devant être réalisé au moyen des techniques RFC 5549 ou RFC 8950 (Turku). Autrement dit, un membre IPv4 qui veut échanger à Turku ne se contente pas d’adresser une interface : il lui faut des sessions BGP capables de transporter des prochaines sauts IPv4 dans une signalisation IPv6. C’est une exigence de configuration réelle, et elle n’est pas imposée à Tampere.

Deux serveurs de routes, un seul AS

L’opérateur décrit explicitement son dispositif : deux serveurs de routes par point d’échange, un ASN 32 bits, 197032, la valeur 23456 suggérée pour les équipements incapables de configurer un ASN 32 bits, BIRD 2 comme implémentation, et l’acceptation des routes enregistrées dans RIPE provenant des membres participants (MLPA). La page de peering ajoute la répartition des rôles : AS29432 est l’ASN d’infrastructure de TREX, AS197032 celui des serveurs de routes, le peering se fait sur le VLAN de peering de Tampere et/ou celui de Turku, et TREX dispose de deux routeurs (peering).

Cette page affiche aussi des objets route et route6 étiquetés « source: RIPE # Filtered », dont 195.140.194.0/23, 2001:67c:2b0::/48 et 2001:7f8:1d::/48 (peering). Il faut être précis sur ce point : la page appartient à TREX et restitue une vue filtrée d’objets RIPE, elle n’est pas une réponse de registre. La page de ressource RIPEstat pour AS29432 n’a pas livré de contenu lisible lors de la consultation ; les affirmations relatives à RIPE reposent donc sur l’affichage de l’opérateur, pas sur un registre inspecté directement (RIPEstat).

Ce que l’opérateur publie lui-même sur le contournement

La page la plus instructive du site n’est pas une page de peering. C’est la page d’accès par VPLS chez FNE Finland. On y lit que FNE Finland fournit une connexion distante au VLAN de peering unicast, VLAN ID 4, partout en Finlande, sur son réseau dorsal MPLS au moyen de VPLS ; et surtout que le trafic entre deux membres FNE VPLS emprunte la route la plus directe à l’intérieur du réseau dorsal de FNE et n’entre pas dans la matrice de commutation de TREX (FNE VPLS).

C’est l’opérateur lui-même qui borne son propre produit. Pour un membre accédé de cette façon, la valeur de l’échange n’est pas le trajet : c’est la liste des réseaux joignables et les deux serveurs de routes sur AS197032. Le paquet échangé entre deux membres FNE ne traverse jamais le commutateur de l’échange, et aucune mesure de capacité prise sur ce commutateur ne décrira la performance de ce membre. La page donne d’ailleurs un exemple de engagement à 100 Mbps, avec des frais d’adhésion et de transport distincts (FNE VPLS).

La page des revendeurs complète le tableau : Elisa, FNE Finland, Funet, SuomiCom et Telia Finland y figurent comme revendeurs ; un revendeur établit une connexion à 10 Gbps ou plus vers l’échange et raccorde plusieurs clients sur ce lien partagé ; l’accès par revendeur se distingue d’une adhésion complète, notamment par l’absence de port physique sur le commutateur pour les clients du revendeur (revendeurs). Trois modèles d’accès coexistent donc — port propre, port partagé chez un revendeur, tunnel VPLS chez un transporteur — et un seul se termine sur la matrice de l’échange.

Tampere : le registre et le bâtiment

PeeringDB donne pour TREX Tampere 25 pairs, 31 connexions, 17 pairs ouverts et une capacité totale de 188G, avec un horodatage de dernière mise à jour au 2025-03-03T15:26:57Z, et nomme trois installations locales : Elisa Tampere Nalkala, Glesys Tampere 1 et Tampere Hallituskatu 14 (PeeringDB ix 328). L’arithmétique mérite qu’on s’y arrête : 31 connexions pour 25 pairs implique qu’au moins six pairs détiennent plus d’une connexion, ce que le registre ne précise pas. Et 188G est une somme de capacités déclarées, pas un débit mesuré ni un taux d’utilisation.

La page de la société sur AS29432 affiche l’AS-set IRR AS29432:AS-PEERING et a été mise à jour le 2025-05-27T14:30:37Z ; l’organisation, enregistrée à Tampere, relie AS29432 et AS197032 ainsi que les deux échanges, avec un horodatage au 2025-05-27T14:28:55Z (PeeringDB réseau, PeeringDB organisation). Ces dates sont toutes antérieures aux pages de l’opérateur consultées le 2026-11-12 : les chiffres de membres et de capacité peuvent donc accuser un retard sur ce que TREX publie aujourd’hui.

Le côté physique de Tampere est raconté ailleurs, sur une page plus ancienne : Hallituskatu 14 y est décrite comme un immeuble de bureaux du centre-ville abritant de petites colocations de différents opérateurs Internet, avec des références de meet-me-room ou de panneaux pour Elisa, Cinia, DNA Finland, FNE Finland, GlobalConnect, Portlane et Telia Finland (Hallituskatu 14). La page de contact, elle, liste deux installations PeeringDB, Hallituskatu (installation 2333) et Nalkala (installation 3230), et ne mentionne ni site de Turku ni chemin de transport physique entre les deux villes (contact).

Turku : une contradiction datée

La table des membres expose séparément la participation à Tampere, la participation à Turku, la participation aux serveurs de routes et le statut de revendeur, et nomme notamment Domainkeskus AS29243, Elisa AS719, CSC/Funet AS1741, Telia Finland AS1759, GlobalConnect AS12552, S1 Networks AS199508 et Web1 AS207003 (membres). C’est cette même table qui crée le seul conflit interne du dossier : elle marque Partel AS42885 et Port 179 AS212232 avec l’indicateur Q3, défini par sa propre légende comme une connexion en attente. Or la table d’adressage de Turku attribue des adresses de peering à ces deux réseaux, aux côtés de S1 Networks AS199508, Web1 AS207003, Cuitunet AS211368 et V4LESS-AS AS215250 (adressage Turku, membres).

Cette page ne dit pas si une adresse affichée correspond à une session opérationnelle, en attente ou récemment mise en service (adressage Turku). Elle nomme les serveurs de routes de Turku sur AS197032 en 2001:7f8:1d:7::1 et 2001:7f8:1d:7::2 (adressage Turku). PeeringDB, de son côté, compte 6 pairs, 8 connexions, 6 pairs ouverts et 20G pour TREX turku, avec un horodatage au 2025-01-01T02:53:48Z et le préfixe de LAN 2001:7f8:1d:7::/64, mais n’affiche ni Partel ni Port 179 (PeeringDB ix 4621).

Une adresse attribuée et un statut « en attente » ne sont pas la même chose, et rien dans les pages consultées ne permet de trancher. Le fait daté est double : la table des membres dit Q3, la table d’adressage publie des adresses, le registre ne montre pas ces pairs. Cela ne prouve ni l’absence de session ni son fonctionnement.

Ce qu’aucune page ne mesure

Le dossier est silencieux sur les grandeurs qui décideraient d’un achat. Aucune page consultée ne publie de volume de trafic, de latence, de disponibilité, de crédit de service ou de prix de port — les seules références chiffrées étant l’exemple d’engagement à 100 Mbps chez FNE et le seuil de 10 Gbps ou plus pour un revendeur (revendeurs). Aucune adresse d’installation à Turku, aucun site de colocation et aucun chemin de transport entre les deux villes n’apparaît sur la page de service de Turku, la page de contact ou l’enregistrement d’organisation consultés (contact). Et les 188G comme les 20G sont des sommes de capacité déclarées dans un registre, jamais un débit observé.

Le test d’achat

Ce que TREX vend, et ce que l’opérateur documente correctement, c’est une prise sur un segment nommé, avec un MTU, un TTL BGP et deux serveurs de routes sur un ASN unique. Ce qu’un acheteur peut vérifier avant de signer, c’est l’existence de cette prise, l’identité des réseaux qui y sont adressés et le mode d’accès — port propre, port de revendeur ou tunnel chez un transporteur. Ce qu’il ne peut pas vérifier dans les pages publiques, c’est le trajet réel de ses paquets vers chacun de ces réseaux, et notamment s’ils passeront par la matrice de l’échange ou par le réseau dorsal de quelqu’un d’autre. La fiche du répertoire BTW est ici : TREX Regional Exchanges Oy.

Sources