Hoe BGP het internet bij elkaar houdt (en soms laat verdwalen)
Tussen jouw laptop en de server van deze blog zitten twee netwerken van twee verschillende bedrijven. Dat ze elkaar kunnen vinden, regelt geen centrale instantie. Het gebeurt via het Border Gateway Protocol: tienduizenden netwerken die elkaar voortdurend vertellen welke adressen ze kunnen bereiken, en die elkaar daarbij grotendeels op hun woord geloven.
Hieronder zie je hoe een route ontstaat, hoe een pakketje hem volgt en hoe het twee keer spectaculair misging. De metingen in dit stuk komen van 24 september 2026, vanaf een Nederlandse verbinding.
≈ 79.466 AS'en · 1.078.182 IPv4-prefixen in de wereldwijde tabel
CIDR Report, 24-09-2026
Een netwerk van netwerken
Het internet bestaat uit autonome systemen (AS'en): netwerken met één eigen routeringsbeleid en een eigen nummer, het ASN. Volgens het CIDR Report zijn er zo'n 79.500 AS'en zichtbaar in de wereldwijde routeringstabel, samen goed voor ongeveer 1,08 miljoen IPv4-prefixen.
Het netwerk in de visual is een vereenvoudigd voorbeeld. De transitproviders en hun nummers bestaan echt, de lijnen ertussen heb ik getekend. Je eigen provider heeft hier het documentatienummer AS64500.
Een AS en zijn prefix
wallieweb.nl wijst naar 52.236.137.214, een adres bij Microsoft Azure. Wie is daarvan de eigenaar? Dat vraag je op in een routeringsregister:
whois -h whois.radb.net 52.236.137.214 geeft route: 52.224.0.0/11 met origin: AS8075. Microsoft kondigt dat hele blok van ruim twee miljoen adressen als één prefix aan. Er bestaat ook een RPKI-ROA voor: een cryptografisch ondertekende verklaring dat AS8075 dit prefix mag aankondigen.
Aankondigen: het AS-pad groeit
AS8075 stuurt zijn buren een BGP-UPDATE over een TCP-sessie op poort 179: "52.224.0.0/11 is via mij bereikbaar". Een transitprovider die dat doorgeeft, zet zijn eigen nummer vooraan in het AS_PATH. Lumen maakt er 3356 8075 van, Arelion daarna 1299 3356 8075.
Dat pad is een grove afstandsmaat, en het voorkomt lussen: ziet een router zijn eigen ASN al in het pad staan, dan gooit hij de route weg.
Kiezen: welk pad wint?
Je provider krijgt hetzelfde prefix nu via drie buren binnen. BGP kiest er één. In het echt kijkt een router eerst naar LOCAL_PREF, de eigen voorkeur, en dat is meestal een zakelijke keuze: routes van klanten boven routes van peers, en die weer boven routes waar je voor betaalt. Pas daarna telt de lengte van het AS-pad. Deze visual slaat dat zakelijke deel over en kiest gewoon het kortste pad.
Hier wint de directe peering met Microsoft: 8075, één AS ver.
Doorsturen: het pakketje volgt
Nu gaat er data over de lijn. Elke router zoekt het doeladres op in zijn forwarding-tabel en stuurt het pakketje naar de volgende hop. traceroute -a wallieweb.nl laat dat zien: na een paar hops binnen de provider komt het pakketje op ier03.ams21.ntwk.msn.net, al in AS8075. Er zitten maar twee AS'en tussen, de overdracht gebeurt in Amsterdam en de rondreistijd tot daar is ongeveer 25 ms.
Daarna geeft het datacenter van Azure geen antwoord meer op traceroute. Dat is normaal, veel cloudnetwerken filteren die pakketjes.
Verdwaald (1): de YouTube-kaping
Op 24 februari 2008 wilde Pakistan YouTube in eigen land blokkeren. Pakistan Telecom (AS17557) kondigde om 18:47 UTC 208.65.153.0/24 aan, bedoeld voor intern gebruik. Upstream PCCW (AS3491) stuurde die aankondiging de wereld in.
YouTube zelf kondigde 208.65.152.0/22 aan. Een router kiest altijd het meest specifieke prefix dat bij het adres past, de longest prefix match, hoe lang het AS-pad ook is. Een /24 wint van een /22, dus ging wereldwijd YouTube-verkeer naar Pakistan. YouTube kondigde om 20:07 zelf de /24 aan en om 20:18 twee /25's. Om 21:01 UTC trok PCCW de routes van AS17557 in: ruim twee uur na het begin.
Verdwaald (2): Facebook zet zichzelf uit
Op 4 oktober 2021 rond 15:40 UTC ging het andersom mis. Tijdens onderhoud aan de backbone van Facebook (AS32934) haalde een opdracht die de capaciteit moest controleren alle backbone-verbindingen tussen hun datacenters onderuit. Facebooks DNS-servers trekken hun BGP-aankondigingen automatisch in zodra ze de datacenters niet meer bereiken. Dat deden ze nu allemaal tegelijk.
Prefixen als 129.134.30.0/23 en 185.89.218.0/23 verdwenen uit de tabel. De DNS-servers draaiden nog, maar niemand kon ze bereiken. Resolvers als 1.1.1.1 gaven SERVFAIL voor facebook.com. Facebook, Instagram en WhatsApp lagen zo'n zes uur plat. Rond 21:00 UTC kwamen de routes terug.
Speel zelf
Terug naar het netwerk van Microsoft. Knip de peering door en zie hoe BGP een omweg via een transitprovider vindt. Knip daarna ook 3356–8075 door. Laat dan de kaper (AS64511) een /24 uit het blok van Microsoft aankondigen: het verkeer volgt de specifiekere route, ook als die langer is.
Zet tot slot het RPKI-filter aan. De ROA zegt dat alleen AS8075 dit adresblok mag aankondigen, dus een netwerk dat route origin validation doet, markeert de /24 van AS64511 als invalid en gooit hem weg. In 2008 bestond RPKI nog niet. Dat de specifiekere route won, bleef overigens hetzelfde.
Wat RPKI niet oplost
RPKI controleert alleen de origin: welk AS het prefix als laatste in het pad heeft staan. Een kaper die een pad vervalst en 64511 8075 aankondigt, zet het juiste origin-nummer achteraan en komt daar dus langs. Daarvoor zijn aanvullende technieken in de maak, zoals ASPA, dat vastlegt welke upstreams een AS heeft. En zoals Facebook liet zien: niet elke storing is een aanval. Een ingetrokken route is net zo effectief als een gekaapte.
Nog een detail uit 2008. Volgens de RIPE NCC zagen maar 21 van de peers van hun Routing Information Service de /25's van YouTube, tegenover 105 voor de /24. Veel netwerken accepteren niets kleiner dan een /24, om de tabel beheersbaar te houden. Dat is geen regel in het protocol, gewoon een afspraak waar vrijwel iedereen zich aan houdt.
Zelf proberen
Wie is de eigenaar van een adres, en welk prefix wordt aangekondigd?
whois -h whois.radb.net 52.236.137.214
whois -h whois.cymru.com " -v 52.236.137.214"
Welke AS'en passeert je verkeer? Op macOS toont -a het ASN per hop:
traceroute -a wallieweb.nl
Op Linux werkt traceroute -A wallieweb.nl of mtr -z wallieweb.nl. Wil je zien hoe de rest van de wereld een prefix ziet, zoek het dan op bij bgp.tools of bgp.he.net. Daar staan de upstreams, de peers en de RPKI-status. Via de RIPEstat-API zie je bijvoorbeeld dat AS8075 op het moment van schrijven 1.208 IPv4-prefixen aankondigt en 281 buren heeft.
Tot slot
Wat me bij het uitzoeken het meest verraste: het internet draait op een protocol dat standaard gelooft wat de buren zeggen. BGP is van 1989, de huidige versie BGP-4 van 1994. Dat het meestal goed gaat, danken we vooral aan netwerkbeheerders die filters bijhouden, ROA's publiceren en elkaar mailen als er iets vreemds in de tabel verschijnt. En als je traceroute ooit ineens via een vreemd land loopt, weet je nu waar je moet kijken.