Hoe een internetknooppunt werkt: peering bij AMS-IX

Als je Wikipedia opent, gaan je pakketjes van het netwerk van je provider naar het netwerk van de Wikimedia Foundation. Dat zijn twee organisaties die elkaar niets verschuldigd zijn. Toch moeten hun routers ergens aan elkaar zitten, en moeten ze afspreken wie wiens verkeer draagt. Een van de plekken waar dat gebeurt, is AMS-IX, het internetknooppunt in Amsterdam.

Hieronder zie je wat het verschil is tussen transit en peering, waarom een knooppunt in de kern een grote switch is en wat een route server doet. Ik heb de openbare ledenlijst van AMS-IX geanalyseerd en routes opgevraagd bij hun route servers. Alle metingen zijn van 17 oktober 2026, vanaf een Nederlandse verbinding.

Transit en peering: wie betaalt wie

Een netwerk dat het hele internet wil bereiken, kan dat kopen. Dat heet transit: je betaalt een grotere provider en die neemt je verkeer mee naar elke bestemming die hij kent. Daarnaast kun je met een ander netwerk afspreken dat je elkaars verkeer rechtstreeks uitwisselt. Dat is peering. AMS-IX omschrijft het als vrijwillig koppelen op basis van wederzijds voordeel, meestal zonder dat er geld over de tafel gaat.

Het belangrijke verschil zit in wat je krijgt. Een transitprovider geeft je routes naar alles. Een peer geeft je alleen routes naar zijn eigen netwerk en dat van zijn klanten. De gebruiksregels van de AMS-IX-route servers zeggen het letterlijk: routes die je daar leert, mag je aan je eigen klanten doorgeven, maar niet aan je transitproviders of aan andere peers. Zo wordt een peering geen gratis doorgang naar de rest van het internet. In het artikel over BGP zag je al dat routers routes van klanten boven die van peers verkiezen, en die weer boven routes waarvoor ze betalen.

Een internetknooppunt is een grote switch

Peering kan met een eigen kabel tussen twee routers. AMS-IX noemt dat private peering en schrijft dat die vooral tussen de grootste netwerken bestaat. Wie met honderden netwerken wil peeren, sluit één poort aan op een internetknooppunt, een Internet Exchange Point (IXP).

RFC 7947 beschrijft zo'n knooppunt als een gedeeld laag-2-netwerk, meestal Ethernet. Volgens de ledenlijst die AMS-IX publiceert, bestaat het Amsterdamse platform uit 58 switches in 15 datacenters, vooral in Amsterdam en verder in Haarlem, Rotterdam en Naaldwijk. Elke deelnemer krijgt een adres in één gezamenlijk subnet, het peering-LAN: 80.249.208.0/21 voor IPv4 en 2001:7f8:1::/64 voor IPv6. Volgens PeeringDB is de MTU 1500 bytes.

Dat subnet is alleen voor de routers van de deelnemers bedoeld. RIPEstat ziet 80.249.208.0/21 niet aangekondigd op het internet, en een ping vanaf mijn verbinding naar een adres daarin kwam niet aan.

Ruim achthonderd netwerken op één LAN

Op 17 oktober 2026 stonden er 903 netwerken in de lijst, waarvan 882 op het gewone peering-LAN. Samen hebben ze 1.056 poorten. De meest voorkomende snelheid is 10 Gbit/s (331 poorten), daarna 100 Gbit/s (226) en 400 Gbit/s (48). Opgeteld is dat ruim 69 Tbit/s aan poortcapaciteit.

Het echte verkeer ligt ver daaronder. De statistiekenpagina gaf een piek van 14,3 Tbit/s voor de afgelopen dag, gemiddeld 10,4 Tbit/s, en 15,8 Tbit/s als hoogste piek van het afgelopen jaar.

Op hetzelfde LAN zitten betekent niet dat iedereen met iedereen praat. Van de 882 noemen 628 hun beleid open: ze peeren met iedereen die dat wil. 116 zijn selective, 107 beslissen per geval en tien zijn closed.

Bijna 390.000 BGP-sessies

Om routes uit te wisselen hebben twee routers een BGP-sessie nodig, die beide beheerders apart moeten configureren. RFC 7948 rekent het voor: als elk van n routers met elke andere wil peeren, heb je n×(n−1)/2 sessies. Voor de 882 netwerken van AMS-IX, met één router per netwerk, zou dat 388.521 sessies zijn. Dat schaalt niet, en daarom draait AMS-IX route servers.

De route server: één sessie in plaats van honderden

Een route server is een BGP-spreker die routes van al zijn klanten verzamelt en doorgeeft. Volgens RFC 7948 gaat het aantal sessies van n×(n−1)/2 naar n. AMS-IX heeft er twee, rs1 en rs2, en verplicht deelnemers om met beide een sessie te maken.

Het belangrijkste detail staat in RFC 7947: een route server stuurt zelf geen verkeer door en is dus geen router. Hij geeft het NEXT_HOP-adres ongewijzigd door (dat is een MUST) en zet zijn eigen AS-nummer niet in het AS-pad (een SHOULD NOT). De data gaat rechtstreeks tussen de twee deelnemers over de switch.

Volgens de ledenlijst gebruiken 809 van de 882 netwerken de route servers, 92 procent. Op rs1 (BIRD 2.15.1) stonden op het moment van opvragen 810 van de 929 geconfigureerde sessies open, van 710 verschillende netwerken.

Een echte route: Wikipedia

www.wikipedia.org wijst vanaf mijn verbinding naar 185.15.59.224. De looking glass van AMS-IX laat zien wat rs1 daarover van Wikimedia (AS14907) heeft gekregen:

185.15.59.0/24  next_hop 80.249.209.176  as_path [14907]
communities [6777,65012] [6777,65011]
large       [6777,1000,1] [6777,1001,1]

Het AS-pad bevat alleen 14907, geen 6777 van de route server. De next hop 80.249.209.176 is volgens de ledenlijst het adres van de router van Wikimedia zelf. Pakketjes gaan dus direct naar Wikimedia. De communities heeft AMS-IX er zelf aan gehangen: volgens de documentatie betekent 6777:65012 dat er een geldige RPKI-handtekening (ROA) is, en 6777:65011 dat het prefix voorkomt in de AS-SET die Wikimedia in het IRR-register heeft opgegeven. De large communities zeggen volgens de looking glass hetzelfde nog eens.

Opvallend is wie er niets aanbiedt. De sessies van Google en Cloudflare met rs1 stonden open, maar ze stuurden nul routes. Zelf kregen ze er elk zo'n 100.000 binnen. Wie hun routes over AMS-IX wil, moet een eigen afspraak met ze maken.

Wat de route server weggooit

Een route server die alles doorgeeft, maakt van één tikfout een probleem voor honderden netwerken. Binnenkomend gooit hij volgens de documentatie privé-adresruimte (RFC 1918), bogons en de default route weg, en routes waarvan de next hop niet de router van de afzender zelf is. Bij het doorgeven houdt hij standaard ook routes tegen met een ongeldige ROA, en prefixen die niet voorkomen in wat de afzender in het IRR-register heeft opgegeven.

Daarnaast geldt per netwerk een maximum aantal prefixen. Wie er maar een paar aankondigt, krijgt sinds oktober 2013 een limiet van 100, en bij Wikimedia stond die inderdaad op 100.

In de looking glass zie je de weigeringen terug. Van de RIPE NCC lag 193.0.0.128/29 in de filter, met large community 6777:1101:1: Prefix length too long. Van SURF lagen er vier: een /27 om dezelfde reden en drie prefixen met 1200 achteraan in het AS-pad, gemarkeerd als Prefix belongs to AMS-IX administration domain. AS1200 is AMS-IX zelf. Over alle open sessies op rs1 samen telde ik 493.473 ontvangen routes, waarvan er 2.196 in de filter bleven hangen.

Zo herken je een knooppunt in traceroute

Gaat je verkeer over een internetknooppunt, dan zie je dat in traceroute aan een hop met een adres uit het peering-LAN. Ik heb twaalf traceroutes gedraaid naar netwerken die bij AMS-IX zijn aangesloten. Geen enkele kwam over 80.249.208.0/21. Mijn provider bereikt die netwerken dus via een andere weg.

Eén route ging wel over een knooppunt, maar een ander: die naar NORDUnet.

 6  185.1.94.20     22.277 ms
 7  109.105.101.22  44.840 ms

185.1.94.0/24 is volgens PeeringDB het peering-LAN van Asteroid Amsterdam, en 185.1.94.20 staat daar op naam van NORDUnet (AS2603). Het IXP-adres in je traceroute hoort niet bij het knooppunt, maar bij de router van het netwerk waar je pakketje op dat moment binnenkomt.

Zelf proberen

De ledenlijst van AMS-IX is openbaar, in het IX-F-formaat dat meer knooppunten gebruiken:

curl -4 -s "https://my.ams-ix.net/api/v1/members.json?exchange=NL" | python3 -c "
import json,sys; d=json.load(sys.stdin)
print(len({m['asnum'] for m in d['member_list']}), 'netwerken')"

903 netwerken

De looking glass heeft een JSON-API:

curl -4 -s https://lg.ams-ix.net/api/v1/routeservers/nl-rs1-v4/neighbors/80.249.209.176/routes/received \
  | python3 -c "import json,sys; [print(r['network'], r['bgp']['as_path']) for r in json.load(sys.stdin)['imported']]"

185.15.59.0/24 [14907]
185.71.138.0/24 [14907]
198.35.27.0/24 [14907]

Of een hop in je traceroute een knooppunt is, zoek je op in PeeringDB:

curl -4 -s "https://www.peeringdb.com/api/netixlan?ipaddr4=185.1.94.20" \
  | python3 -c "import json,sys; [print(x['asn'], x['name']) for x in json.load(sys.stdin)['data']]"

2603 Asteroid Amsterdam: Asteroid Amsterdam Peering LAN

Tot slot

Ik had verwacht dat een route server een soort centrale router zou zijn. Het is eerder een prikbord: hij zet zijn eigen naam niet op de route en raakt geen enkel pakketje aan. Wat me ook verraste: geen van mijn eigen traceroutes kwam over AMS-IX, terwijl daar gemiddeld meer dan 10 Tbit/s doorheen gaat. Voor mijn verbinding ligt AMS-IX blijkbaar net naast de route.