Summary

  • InterLAN-IX's public exchange record carries 132 networks in a member-list import stamped 2026-11-10T00:04:49Z: the institutional layer of this exchange is structured, current and checkable by anyone with a browser.
  • The exchange says it provides partners two route servers. What those two servers originate, under which autonomous system, with what origin attestation, is absent from both the exchange's own description and the third-party records read here.

The two facts sit eleven lines apart in the same file and describe completely different things. One is an exchange telling the world how many networks are in its member list. The other is an exchange telling the world that it runs two route servers on their behalf.

Nothing in between says who the route servers are.

What 132 actually counts

PeeringDB's exchange record for InterLAN-IX — record id 270, organisation id 591 — is a small JSON object with a large amount of information in it. Name: InterLAN-IX. Long name: InterLAN Internet Exchange Romania. City: Bucharest. Country: RO. Continent: Europe. Media: Ethernet. And then the two fields that matter here: ixf_net_count at 132, and ixf_last_import at 2026-11-10T00:04:49Z.

Read that timestamp against the clock. The import of the exchange's member list into PeeringDB happened under two minutes before this record was pulled. Whatever else is true about InterLAN-IX, it is not an exchange that has forgotten to maintain its public paperwork. Somebody there has automated the export, and the pipeline runs.

One hundred and thirty-two is a count of networks in that import. It is not a count of prefixes, sessions, ports, members or customers. It is not a measure of how much traffic crosses the fabric. It tells you how many network entries the exchange's own member list carried at 00:04:49 on 10 November 2026, and that is all it tells you. The distinction sounds pedantic until you watch what happens when someone compares it to a prefix count from a different record and concludes that a number is missing.

Two route servers, described in one sentence

The exchange's own site is where the service gets described, and it describes it in Romanian, briefly: „Pentru a facilita schimbul de trafic, InterLAN-IX pune la dispoziția partenerilor săi două route-servere care permit interconectarea directă cu majoritatea celor conectați.” To make traffic exchange easier, InterLAN-IX provides its partners with two route servers that allow direct interconnection with most of those connected.

That is a good sentence. It tells a prospective member exactly what operational value the exchange adds beyond a patch panel: don't build a full mesh of sessions with every other member, take a session with the pair and let the exchange redistribute what everyone else announces. It is also, on the page as read, the whole of the technical description. No addresses. No autonomous system number. No peering-LAN prefix. No statement about what the servers accept, what they drop, or what they do with a route whose origin looks wrong.

A route server, for the reader who does not live in a router, is a machine the exchange operates rather than a member. It holds sessions with many members and passes their announcements to the others, so that a small network in Cluj can reach a large one in Bucharest without negotiating a session for every pair. The exchange becomes, in the routing sense, part of the path — not carrying the packets, but deciding which announcements are visible.

That is why the identity of the route-server AS is not a detail. When a member accepts a route from the pair, it is accepting a claim about where a prefix lives. The claim originates with whichever autonomous system the servers use, passes through whatever filters and origin validations the exchange applies, and lands in the member's table. The member can see the path. It cannot see the paperwork.

The autonomous system that turns out to be somebody else

Search for an autonomous system belonging to this exchange and AS39737 comes up. It is the kind of identifier that circulates in peering notes and gets copied between them, which is precisely why it deserves an actual look rather than an assumption.

The BGP directory page for AS39737 says: AS39737 Prime Telecom srl. Country of origin: Romania. Internet exchanges: 6. Prefixes announced, all: 414. IPv4: 392. IPv6: 22.

That is not an exchange. That is a Romanian operator with 414 announced prefixes and sessions at six exchanges — the profile of a network that buys and sells connectivity for a living, which is exactly what most members of a national exchange are. There is no line on that page connecting the AS to InterLAN-IX, and no line claiming InterLAN-IX runs it.

So the identifier that looks like the answer is a member-shaped answer. It is one operator's own routing footprint, published by a third party, sitting next to an exchange that publishes member counts. The two records do not describe the same object, use different units, and were produced by different organisations. Set them side by side and nothing reconciles, because nothing is supposed to.

That non-reconciliation is worth naming plainly, because the alternative reading — 132 networks here, 414 prefixes there, someone has lost 282 of something — is the kind of arithmetic that makes a real article look like a bad one.

Where the trail stops

The route-server addresses for InterLAN-IX did not come back in a form this piece could read. Nor did the peering-LAN prefix. Nor did the RIPE Database objects that would show what AS39737's aut-num actually authorises, or whether any Resource Public Key Infrastructure attestation covers the announcements in question.

State that once and state it honestly: this is a limit of what was retrievable here, not a finding that InterLAN-IX's route servers are unattested, permissive or badly filtered. An exchange can run rigorous origin validation and still be invisible to a reader who cannot reach the objects that record it. Absence of a readable record in one article is not evidence about a registry.

What survives the limit is still worth publishing, because it is the shape of the problem rather than the answer to it. The exchange has done the institutional layer properly: a structured record, a fresh import, a clear statement of service. The layer beneath it — the one that answers which system authorises this announcement — is not reachable from the pages a member is most likely to read. A peering coordinator who wants that answer has to go and ask, and the asking is the whole point.

What a member is actually buying

Peering is sold as a shortcut to better latency and lower transit bills, and it usually is. But every session carries a second transaction that nobody invoices: the member accepts an origin claim it cannot independently reconstruct from the exchange's public materials. When the fabric is small, domestic and long-standing, that acceptance feels safe. It is still an acceptance.

The directory record for InterLAN-IX Only for Strategic Circle and the exchange's own site describe an operator with a national footprint, an Ethernet fabric and a pair of route servers that most connected parties use. That is a real service, competently described as far as the description goes.

The description just stops one layer too early. A count of 132 networks tells you the room is full. It does not tell you who signed for the routes that cross it.