Hoe BGP werkt: prefixes, AS paths, routingbeslissingen en DDoS-impact

Het probleem definiëren

BGP is een systeem van aankondigingen tussen autonome systemen.

Verschillende providers kunnen andere paden kiezen; communities, specifiekere routes en policy veranderen het resultaat.

BGP-attributen zijn geen universele commando’s. Local-pref is meestal intern, AS-path prepend werkt niet overal en MED wordt vaak genegeerd. Testen met echte upstreams is nodig.

Om BGP als control-plane van Internet te beoordelen moet je drie lagen scheiden: het BGP-signaal, het echte verkeer en de gebruikerservaring. Als je die mengt, lijkt de sessie stabiel terwijl bruikbaar verkeer een ander pad neemt of verdwijnt in een te brede filterregel.

Technische kopers zien snel of een aanbieder alleen marketingwoorden gebruikt of de grenzen van zijn architectuur kent. Bij DDoS is eerlijkheid over grenzen juist een vertrouwenssignaal.

Waarom dit belangrijk is

BGP bepaalt waar verkeer binnenkomt voordat filtering begint.

Clean delivery na mitigatie moet gedefinieerd zijn, anders ontstaan asymmetrie en routeconflicten.

Bij DDoS-mitigatie wint vaak de meest specifieke geaccepteerde route. Een IPv4-/24 kan verkeer uit een groter aggregate trekken. Nuttig, maar gevaarlijk zonder RPKI, IRR en filters.

Financiële schade ontstaat niet alleen bij totale uitval. Gedeeltelijke incidenten zijn vaak lastiger: sommige providers bereiken de dienst wel, andere niet; bepaalde landen zien hogere latency; gamesessies vallen weg; support krijgt klachten die moeilijk te reproduceren zijn.

Voor SEO en verkoop trekt deze uitleg betere leads aan. Een serieuze klant zoekt niet alleen een Tbps-cijfer, maar wil weten of routing, handoff-limieten, false positives en continuïteit echt begrepen worden.

Voor Nederlandstalige technische kopers tellen concrete grenzen meer dan capaciteitsclaims. Een artikel moet tonen hoe beslissingen worden genomen, welke aannames getest worden en hoe de dienst bij fouten terugkeert naar een veilige toestand.

Die extra voorbereiding loont omdat storingen korter worden en de klant ziet dat bescherming niet alleen uit marketingcijfers bestaat.

Mogelijke oplossingen

Klant-eBGP geeft veel controle.

Provider-operated aankondiging is eenvoudiger maar moet transparant blijven.

Protected transit trekt verkeer naar mitigatie en levert schoon terug via tunnel of cross-connect.

Default route is genoeg voor veel beschermde klanten omdat inbound verkeer het grootste risico is. Full table is nuttig bij gedetailleerde egress-control of meerdere transits.

Een technische actie heeft een procedure nodig: welke metric triggert, welk bewijs is vereist, wie of welk systeem mag handelen, maximale duur en de voorwaarde voor terugdraaiing. Zonder grenzen wordt een nuttige tool een operationeel risico.

Maak ook onderscheid tussen noodmaatregel en permanent ontwerp. Een agressieve actie kan tien minuten acceptabel zijn om capaciteit te redden, maar mag zonder review geen vaste configuratie worden. Normaal verkeer verandert per tijdstip, land, game en clientversie.

Het ontwerp heeft acceptatiecriteria nodig: verwachte latency, maximaal pakketverlies tijdens mitigatie, handoff-capaciteit, escalatiecontacten en exacte voorwaarden voor disruptieve maatregelen.

Daarnaast heeft elk ontwerp een eenvoudig testplan nodig: routes extern controleren, handoff-bandbreedte meten, latency vergelijken, escalatie testen en documenteren welke wijziging bij nood als eerste wordt teruggedraaid.

BGP-beslissingen omzetten in voorspelbare beschermde routing

Peeryx definieert wie annonceert, met welk AS, welke limieten en welk retourpad.

BGP trekt verkeer naar capaciteit; de Anti-DDoS-laag filtert; daarna komt clean delivery.

Voor gaming en hosting voorkomt dit latency- en sessieverrassingen.

Peeryx onderscheidt deze gevallen in de intake. Sommige klanten willen volle controle; anderen willen alleen beschermd prefix en clean delivery. Het ontwerp moet beheersbaar blijven.

De waarde van een gespecialiseerde provider zit in het koppelen van beslissingen aan echt transport: BGP, tunnels, cross-connect, prefixes, sessielimieten en capaciteit. Mitigatie mag niet losstaan van het pad vóór en na filtering.

Bij Peeryx moet de klant zijn architectuur simpel kunnen uitleggen: waar verkeer binnenkomt, welke laag schoonmaakt, wat upstream wordt gefilterd, wat lokaal wordt beslist en hoe legitiem verkeer terugkomt. Als dat niet helder is, is het ontwerp niet klaar.

In de praktijk vertaalt Peeryx deze onderwerpen naar simpele beslissingen: welk prefix wordt beschermd, welk verkeer is normaal, welk patroon geldt als aanval en welke actie hoort bij welke drempel.

Zo ontstaat een verkoopargument dat technisch houdbaar is: niet alleen grote mitigatiecapaciteit, maar een begrijpelijk pad voor legitiem verkeer, begrensde ingrepen tijdens de aanval en een duidelijke terugkeer naar normaal bedrijf.

Concreet voorbeeld

Een hoster met een /24 kondigt via Peeryx aan en krijgt schoon verkeer terug.

Een klant zonder ASN kan beschermde IPs gebruiken terwijl Peeryx het BGP-deel beheert.

Voor productie moet de route extern getest worden. Een BGP-session up bewijst niet dat Internet de juiste origin en het juiste pad ziet.

Voor productie horen gecontroleerde tests: een route terugtrekken, een tunnel wisselen, latency meten via meerdere providers en controleren of logs veranderen bij padwijziging. Die voorbereiding bespaart minuten tijdens een echte aanval.

Dit detail helpt ook bij providers vergelijken. Twee aanbiedingen lijken qua prijs gelijk, maar slechts één heeft heldere BGP-integratie, gedocumenteerde regels en voldoende handoff.

Veelgemaakte fouten

BGP-fouten verschijnen vaak onder belasting.

BGP-wijzigingen zijn geen onschuldige edits. Propagatie, filters en caches kunnen rollback trager maken dan verwacht.

Optimaliseren voor de installatiedag is niet genoeg. Het ontwerp moet maanden later nog begrijpelijk zijn wanneer klanten, prefixes, een tweede transit of een nieuwe PoP worden toegevoegd. Operationele documentatie is onderdeel van bescherming.

Een veelgemaakte fout is na de eerste installatie niet opnieuw testen. Elke nieuwe route, tunnel en klant kan aannames veranderen.

Wie dit niet vooraf beschrijft, moet het onder aanvalsstress bedenken. Juist daar ontstaan de duurste fouten.

• BGP zien als firewall.
• Geen clean return path definiëren.
• Prefixlimieten negeren.
• RPKI/ROA overslaan.

FAQ