Summary

  • AMS-IX runs two Amsterdam route servers as AS6777 — rs1.ams-ix.net and rs2.ams-ix.net — and joining means sessioning both.
  • The specification makes one route-server behaviour mandatory, an unmodified NEXT_HOP, and treats AS_PATH and MED preservation as SHOULD-level recommendations with a stated reason.
  • The only explicit allocation of responsibility in the published material puts prefix-list consistency and configuration compliance on the participant.

A network that opts into the route server at the Amsterdam exchange stops building a BGP session per peer and builds one to a machine that re-advertises what everyone else announces. AMS-IX publishes two: rs1.ams-ix.net on 80.249.208.255 and 2001:7f8:1::a500:6777:1, and rs2.ams-ix.net on 80.249.209.0 and 2001:7f8:1::a500:6777:2, both speaking as AS6777. The conditions are concrete — connect to both servers, advertise matching prefix counts and lengths on each session, open TCP port 179 — and the AMS-IX route-server documentation states them plainly.

What that documentation does not do is bind the operator to a symmetrical set of promises. It describes behaviour. The obligations it spells out are the participant's.

The one thing the specification will not negotiate

RFC 7947 defines the exchange route server, and its firmest requirement is about an address: "the NEXT_HOP attribute MUST be passed unmodified" (Section 2.2.1, September 2016). That sentence explains why a route server is not a router in any sense that matters to a packet. The next hop a client sees is the announcing peer's address on the switching fabric, so traffic crosses the fabric peer to peer and never passes through the machine that spoke BGP on its behalf. RFC 7948, the operations companion from the same month, draws the line identically: distributing reachability information is not forwarding traffic.

Everything else in the attribute-handling section is softer, and deliberately so. The route server "SHOULD NOT prepend its own AS number" to what it relays (Section 2.2.2.1). It propagates MULTI_EXIT_DISC and "SHOULD NOT modify its value" (Section 2.2.3). Section 2.2 sets attribute transparency as the default while explicitly permitting exceptions where local configuration calls for them, and Section 2.1 allows policy filtering outright.

The RFC states its reason for stopping at SHOULD rather than MUST on AS_PATH: a real installed base of legacy clients rejects a session whose first AS is unexpected, and a mandatory rule would have stranded them. So the specification requires implementations to let first-AS validation be switched off, preferably per peer, instead of imposing the harder guarantee. That is an engineering compromise wearing a requirement level, and it matters to anyone who assumed the exchange had accepted an absolute duty to leave their path attributes alone.

What the operator puts on the record

AMS-IX publishes its side of the arrangement. It does not insert AS6777 into the AS_PATHs of routes it relays, and first-AS checks must be disabled where applicable. Export peers are selected through RPSL entries and communities: community 0:6777 blocks all exports, 6777: enables a selected peer, and new sessions default to combined IRRDB and RPKI filtering. Routes learned may serve the participant and its downstream customers, though redistribution to upstreams, external peers or another exchange's route server is prohibited.

Two sentences in that material deserve a second read. The first warns that IRRDB and RPKI data carries no validity guarantee and should not be relied on alone — the operator's own description of the filtering it applies by default. The second is the responsibility clause: "Participants are responsible for ensuring that their routing configuration complies with this policy."

RFC 7948 had already landed on the same allocation. It describes the client's responsibility "to ensure that their stated prefix list is compatible with what they announce" (Section 4.3), recommends operator-side leak mitigation, and asks for automated comparison of received routes against configured prefix lists wherever per-client inbound filtering exists. The role the documents carve out is administrative rather than custodial: the route server filters, selects and re-advertises, the operator publishes what it does, and nobody accepts an enumerated duty of verification toward each individual participant.

What I expected, and what the text says

I went looking for a documented bargain: one session to every member, in exchange for a published list of what the exchange owes you in return. The documents support only the first half. The bargain is real — the session count genuinely collapses — but it is priced in exposure rather than in service levels. One categorical MUST keeps packets off the shared speaker. Two SHOULDs, a compatibility argument and an open door for local configuration keep the operator's hands free on path selection and MED.

So the useful reading is not that AMS-IX's route server is careless. It is that the thing is designed as an administrator with a bounded mandate — permitted to make control-plane decisions, forbidden to forward a single packet, and accountable mostly through published text. That framing is mine, not the IETF's and not the exchange's; no formal position states it anywhere.

What a participant can actually check

The directory record for this route server collects the same published facts in one place, and the verification problem is what those facts leave open. A participant cannot audit the shared speaker's internal conformance by reading a policy page. It can read its own received routes and confirm that the next hop it sees is the peer rather than the route server. It can watch whether 0:6777 and 6777: produce the export behaviour the documentation describes. It can keep both sessions up and compare what each server sends, so that divergence shows up as divergence rather than as a mystery.

The documentation is undated as published, was retrieved on 12 November 2026, and its currency is unconfirmed. Live behaviour was not tested here, and whether filtering defaults and community controls behave identically on rs1 and rs2 is not established by the inspected page. One explicit responsibility statement concerning prefix-list consistency was located; the absence of a broader operator guarantee on that page is an observation about the page, not proof that no such text exists elsewhere.

The honest summary of the trade

A route server is a speaker, not a carrier, and the paperwork matches that shape: one unconditional promise that keeps traffic off the box, and two conditional ones that let the exchange keep its own hands free on the attributes that steer it. A network that needs more assurance than that will not find it in the policy text. It will find it, or fail to, in its own received routes — which is exactly where the documents say the responsibility already sits.