Summary

  • TREX publishes a Tampere fabric on VLAN 4 with dual-stack peering LANs and a Turku fabric on VLAN 7 whose LAN addressing is IPv6 only, each with two route servers on AS197032.
  • The operator's FNE VPLS access page states that traffic between two members reached that way takes the most direct route inside FNE's backbone and does not enter the TREX switch matrix — so in that mode the exchange is a membership and route-server service, not the forwarding path.
  • What a buyer can verify: named participants, peering addresses, route-server presence. What stays inference: who actually exchanges traffic, and how much.

Two fabrics, two design choices

The company page is short and unglamorous: trade name TREX Regional Exchanges Oy, Finnish Business ID 1780867-1, main business maintaining an exchange point for Internet and other traffic between connected customers, day-to-day management by Axu TM Oy (company information). The history page adds the second site: a Turku exchange point set up in the winter of 2024-2025 (about TREX).

Tampere is the older and heavier build. Its service page publishes VLAN ID 4, the peering LANs 195.140.192.0/24 and 2001:7f8:1d:4::/64, an IP MTU of 9000 and a BGP TTL of 255, with the VLAN delivered natively or with IEEE 802.1Q encapsulation (Tampere peering). Turku is a different animal: VLAN ID 7, the prefix 2001:7f8:1d:7::/64, and a sentence that would stop a few Finnish networks in their procurement tracks — the Turku peering LAN addressing is IPv6 only, with IPv4 peering offered through RFC 5549 or RFC 8950 (Turku peering).

That is a design decision rather than a typo. Tampere carries legacy IPv4 peering natively; Turku requires a network to bring either IPv6 capability or the newer extended-nexthop encodings before it can get IPv4 reachability at all. For a small regional fabric, it is also a filter: the operator is choosing which networks it wants to onboard.

The sentence that inverts the sales pitch

Every exchange sells reach. TREX's access documentation sells something narrower and more useful.

FNE Finland, the operator states, provides a remote connection to the Unicast Peering VLAN, VLAN ID 4, anywhere in Finland over its MPLS backbone using VPLS. Then the consequence: traffic between two FNE VPLS members takes the most direct route within FNE's backbone and does not enter the TREX switch matrix. The same page gives an example 100 Mbps commitment with membership and transport charged separately (FNE VPLS access).

Read that twice. The operator has published an access method in which the exchange is not on the member-to-member path. Two networks that both buy FNE VPLS reach each other because they share a carrier pseudowire; they reach TREX's route servers because those route servers are addressed on the same segment. The exchange is doing identity, coordination and route-server work — the things an exchange uniquely does — while the packets take a commercial carrier's path.

The disclosure is not a slip. It is clearer than most exchanges publish, and it breaks the mental model many members carry into a membership contract, in which a port at the regional exchange is a way out of the national access market. Sometimes it is. Over FNE VPLS, it is a way into a share of FNE's backbone.

Route servers are the part that cannot be bypassed

The service that stays inside the operator's own equipment is multi-lateral peering. TREX states it runs two route servers per IXP, that they use the 32-bit ASN 197032, that 23456 is suggested for equipment that cannot configure 32-bit ASNs, that they run BIRD 2 and that they accept RIPE-registered routes from participating members (route servers).

The address tables make that concrete. In Tampere the route servers sit at 195.140.192.1, 195.140.192.2, 2001:7f8:1d:4::1 and 2001:7f8:1d:4::2, alongside named participants including Domainkeskus, Elisa, CSC/Funet, FNE Finland, Glesys, Seclan, Planeetta Internet, SuomiCom, Cinia, GlobalConnect, Telia Finland, S1 Networks, Web1, Lounea, Axu TM and NetInch, with TREX Services on AS29432 (Tampere address assignments). In Turku the route servers sit at 2001:7f8:1d:7::1 and 2001:7f8:1d:7::2, with S1 Networks AS199508, Web1 AS207003, Cuitunet AS211368, V4LESS-AS AS215250, Port 179 AS212232 and Partel AS42885 listed (Turku address assignments).

The member table separates the columns that matter: Tampere participation, Turku participation, route-server participation, reseller status. It names Domainkeskus AS29243, Elisa AS719, CSC/Funet AS1741, Telia Finland AS1759, GlobalConnect AS12552, S1 Networks AS199508 and Web1 AS207003 among others (member list). The peering page ties the identifiers together — AS29432 as infrastructure, AS197032 as route servers, two routers, and route objects displayed with the label source: RIPE # Filtered, including 195.140.194.0/23, 2001:67c:2b0::/48 and 2001:7f8:1d::/48 (peering with TREX routers).

The registry is older than the website

Independent records exist and carry dates. PeeringDB's Tampere exchange record reports 25 peers, 31 connections, 17 open peers and total capacity of 188G, last updated 3 March 2025, with local facilities listed as Elisa Tampere Nalkala, Glesys Tampere 1 and Tampere Hallituskatu 14 (TREX Tampere). The Turku record reports 6 peers, 8 connections, 6 open peers and total capacity of 20G, last updated 1 January 2025 (TREX turku). The organisation and network records tie AS29432 and AS197032 to both exchanges and carry the IRR AS-set AS29432:AS-PEERING, last updated 27 May 2025 (organisation record, network AS29432).

Three cautions belong beside those numbers. Thirty-one connections for twenty-five peers means at least six peers hold more than one connection, and the record does not say which. 188G and 20G are sums of connection capacity, not traffic, and not a utilisation measure. And every one of those timestamps predates the operator pages read on 12 November 2026, so the registry describes a fabric that has had between seventeen and twenty-two months to change.

Set against each other, the two records put Turku at roughly a tenth of Tampere by the registry's own capacity sum. That compares booked connection capacity across records of different vintage. It is not a traffic ratio and should not be quoted as one.

Where the documentation thins

Tampere has depth. An older facility page describes Hallituskatu 14 as a downtown office building that houses a lot of small colocations of different Internet operators, and names meet-me-room or carrier references for Elisa, Cinia, DNA Finland, FNE Finland, GlobalConnect, Portlane and Telia Finland (Hallituskatu 14). The contact page lists the principal office at Kuninkaankatu 30 A, Tampere, and PeeringDB facilities Hallituskatu (2333) and Nalkala (3230) (contact information).

Turku has none of that. Its service page gives a VLAN and a prefix. The contact page lists no Turku facility. No Turku colocation site or inter-site transport route appears in any page read. The Turku LAN exists in the record as an address plan and a route-server address pair, and not yet as a place.

A contradiction to read as a status problem

On the member table, Partel AS42885 and Port 179 AS212232 carry the marker Q3, which the page's own legend defines as connection pending. On the Turku address-assignment table, both have peering addresses. That table does not say whether a listed address means an operational session, a pending one, or one provisioned last week (member list, Turku address assignments).

For a prospective member the practical reading is that TREX's public record distinguishes configured from connected poorly, at least at a new site. An address is not a session. The operator clearly knows the difference — the Q3 legend exists — but the two pages do not agree about which state those two networks are in.

Retrieval limits, stated once

The peering page is a rendering, not a registry: the objects carry the label source: RIPE # Filtered, and the RIPEstat resource page for AS29432 redirected without exposing readable content, so no registry field was independently inspected here (RIPEstat AS29432). The reviewed pages publish no traffic volume, latency, uptime, service credit or port price, with two exceptions — the FNE example commitment of 100 Mbps and the reseller threshold of 10 Gbps or faster.

What a port actually buys

The reseller page is the last piece of the picture. Elisa, FNE Finland, Funet, SuomiCom and Telia Finland are listed as resellers, establishing a 10 Gbps or faster connection to the IXP and connecting multiple customers over that shared link; the page distinguishes reseller access from full membership, including the absence of a physical switch port for reseller customers (resellers).

Three ways in, three different products. A full physical port in Tampere buys a switch port, a VLAN and the right to appear in the address table. A reseller connection buys the same segment through an aggregator's 10 Gbps link, without a port of your own. FNE VPLS buys the Tampere VLAN anywhere in Finland, and member-to-member packets stay in FNE's backbone.

A member deciding whether TREX shortens anything should ask three questions the public record can actually answer. Which peers are on the segment I am buying? Will they peer with me — route-server participation is not the same as a bilateral session. Which access method am I paying for, because only one of the three puts the exchange on my packets' path?

None of those answers is a route out of Finland, and TREX never promised one. (TREX Regional Exchanges Oy in the BTW directory).