Border Gateway Protocol (BGP) wordt vaak omschreven als het routingprotocol van het internet. Dat klopt, maar het kan de indruk wekken dat ieder bedrijfsnetwerk BGP moet gebruiken. Dat is niet zo. BGP wordt relevant wanneer een organisatie directe controle wil over de manier waarop haar IP-netwerken verbinding maken met meerdere carriers, datacenters, cloudomgevingen of andere externe netwerken.
Daar verandert een relatief eenvoudig routingconcept in een infrastructuurbeslissing. Een hostingprovider, SaaS-platform, contentnetwerk of onderneming kan BGP gebruiken om de afhankelijkheid van één upstreamprovider te verminderen, verkeerspaden te beïnvloeden en alternatieve routes beschikbaar te houden wanneer connectiviteit uitvalt. Diezelfde controle introduceert ook operationeel risico. Een routingpolicy kan technisch geldig zijn en er toch voor zorgen dat gezonde infrastructuur moeilijk of helemaal niet bereikbaar is.
Voor een netwerk- en colocatieprovider zoals 3W Infra ligt BGP dicht bij de dagelijkse operatie. 3W Infra levert Layer 2- en Layer 3-connectiviteit vanuit het eigen Autonomous System (AS) en is redundant verbonden met meerdere upstreamnetwerken. Daardoor is externe routingpolicy onderdeel van het netwerkbeheer en geen optionele enterprise-feature.
Dat verschil is belangrijk. Redundante servers, stroomvoorzieningen, routers en datacenters bieden niet automatisch internetbeschikbaarheid als externe routing nog steeds afhankelijk is van één carrier, één fysiek pad, één borderrouter of een onvoldoende begrepen routingpolicy.
BGP is daarom minder een protocolkeuze dan een vraag hoeveel routingcontrole een organisatie nodig heeft - en of zij die controle veilig kan beheren.
BGP-routingcontrole, Autonomous Systems en internetbereikbaarheid
Border Gateway Protocol wisselt informatie over bereikbaarheid uit tussen onafhankelijk beheerde netwerken die Autonomous Systems worden genoemd. Ieder Autonomous System wordt geïdentificeerd door een Autonomous System Number, oftewel ASN.
Een organisatie die BGP gebruikt kan een IPv4- of IPv6-prefix aan twee transitproviders adverteren. Deze providers verspreiden de route verder en dragen uiteindelijk bij aan de gedistribueerde verzameling routes die doorgaans de globale routingtabel wordt genoemd.
Het belangrijke woord is gedistribueerd. Er is geen centrale internetrouter die een objectief optimaal pad berekent.
BGP kiest routes op basis van policy.
Daarmee verschilt het fundamenteel van interne routingprotocollen zoals OSPF of IS-IS. Die protocollen zijn normaal gesproken gericht op het vinden van paden door infrastructuur die door dezelfde organisatie wordt beheerd. BGP is ontworpen om routes uit te wisselen over administratieve grenzen waar ieder netwerk andere technische en commerciële prioriteiten kan hebben.
External BGP, of eBGP, behandelt deze relaties tussen autonome systemen. Internal BGP, of iBGP, kan extern geleerde routes tussen routers binnen hetzelfde AS distribueren.
Voor een onderneming met twee edge-routers en twee providers klinkt dat eenvoudig. Op grotere schaal nemen de implicaties snel toe.
BGP-padselectie, AS_PATH, latency en routingpolicy
Een van de meest hardnekkige misverstanden over BGP is dat het verkeer via het geografisch kortste of laagste-latencypad over het internet stuurt.
Dat doet het niet.
Het AS_PATH-attribuut registreert de Autonomous Systems waar een routeadvertentie doorheen is gegaan. Kortere AS-paden krijgen vaak de voorkeur, maar AS_PATH is slechts één onderdeel van de routeselectie. Operators kunnen die voorkeur overschrijven met attributen zoals local preference en leveranciers van netwerkapparatuur kunnen aanvullende beslisregels toepassen.
Dat betekent dat een route door minder autonome systemen toch een hogere latency, meer congestie of slechtere prestaties in de praktijk kan hebben.
Voor infrastructuurarchitecten verandert dit de manier waarop netwerkprestaties moeten worden beoordeeld. Een traceroute en een AS-pad laten zien waar pakketten naartoe gaan. Ze verklaren op zichzelf niet waarom dat pad werd gekozen of of het goed presteert.
Een operator kan bewust de voorkeur geven aan een bepaalde transitcarrier omdat deze betere bereikbaarheid naar een belangrijke markt biedt. Een ander pad kan goedkoper zijn. Een derde kan voornamelijk voor storingsscenario's worden behouden.
BGP geeft het netwerkteam de mogelijkheid om die voorkeuren uit te drukken. Het bepaalt niet wat de onderneming belangrijk vindt.
BGP-multihoming, carrierdiversiteit en fysieke padredundantie
De meest voor de hand liggende enterprise-toepassing van BGP is multihoming.
Een organisatie maakt verbinding met meerdere providers en adverteert haar prefixes via beide. Als één upstream uitvalt, kan verkeer een andere netwerkroute gebruiken.
Maar twee BGP-sessies creëren niet noodzakelijk twee onafhankelijke faaldomeinen.
Beide carriers kunnen via dezelfde duct het gebouw binnenkomen. Cross-connects kunnen uiteindelijk samenkomen op dezelfde metrofiber. Twee logische uplinks kunnen op dezelfde fysieke router termineren. Afzonderlijke borderrouters kunnen afhankelijk zijn van dezelfde stroomdistributie. Meerdere internetproviders kunnen verderop vanaf het datacenter zelfs dezelfde upstreaminfrastructuur delen.
Hier houden networking en colocatie op afzonderlijke ontwerpoefeningen te zijn.
Als internetbeschikbaarheid belangrijk is, moet carrierdiversiteit samen worden beoordeeld met fysieke paddiversiteit, routerplaatsing, cross-connectrouting, fiberinvoer, datacentertopologie en inter-site connectiviteit.
Hetzelfde principe geldt over meerdere faciliteiten. Het verplaatsen van de secundaire router naar een ander datacenter biedt weinig bescherming als beide locaties afhankelijk blijven van dezelfde interconnectie of hetzelfde upstream-faaldomein.
In de regio Amsterdam opereert 3W Infra bijvoorbeeld vanuit maincubes, Equinix AM11 en Iron Mountain, met een DWDM-ring over redundante, onderhoudsbeschermde dark fiber tussen de drie faciliteiten. Het netwerk kan L2-connectiviteit tussen locaties en L3-connectiviteit via het eigen AS leveren.
De waarde van die architectuur zit niet simpelweg in drie adressen. Het gaat om het bewust kunnen bepalen welke afhankelijkheden gedeeld mogen worden en welke onafhankelijk moeten blijven.
Layer 2 versus Layer 3 voor netwerkontwerp over meerdere datacenters
Een multi-datacenterarchitectuur creëert vaak nog een beslissing: hoeveel van het netwerk moet tussen locaties worden uitgerekt?
Een Layer 2-interconnectie kan workloadmobiliteit eenvoudiger maken. Systemen in verschillende faciliteiten kunnen binnen hetzelfde Ethernet-domein of subnet blijven. Dat kan nuttig zijn voor bepaalde clusterplatforms, migraties, legacy-applicaties en specifieke storagedesigns.
Het kan ook faaldomeinen uitbreiden.
Broadcastgedrag, spanning-tree-aannames, accidentele loops, MAC-learningproblemen en applicatieafhankelijkheden kunnen nu datacentergrenzen overschrijden. Een configuratieprobleem dat eerder één rack beïnvloedde, kan nu een metronetwerk raken.
Layer 3-grenzen maken foutisolatie doorgaans duidelijker. Iedere locatie kan een eigen routed netwerk hebben, waarbij BGP of een intern routingprotocol de bereikbaarheid tussen de locaties regelt.
De afweging is dat applicaties routed grenzen moeten kunnen verdragen. Adressering, service discovery, load balancing en failover moeten daarop worden ontworpen.
Er is geen universeel antwoord. Een stretched L2-domein kan volkomen redelijk zijn voor een gecontroleerde migratie. Het permanent als architecturale standaard gebruiken is een andere beslissing.
De Amsterdamse interconnectie van 3W Infra ondersteunt 10G-, 25G-, 40G- en 100G-Layer 2-links naast Layer 3-connectiviteit. Daardoor is dit onderscheid een architectuurkeuze en geen beperking van de faciliteit.
Inbound versus outbound BGP-failover en traffic engineering
BGP-redundantie wordt ook complexer omdat inbound en outbound verkeer verschillend worden aangestuurd.
Voor outbound verkeer heeft de organisatie aanzienlijke invloed. Local preference kan bepalen welke upstream de voorkeur krijgt. Routingpolicy kan specifieke bestemmingen naar verschillende carriers sturen.
Inbound verkeer is minder deterministisch.
De organisatie adverteert routes en probeert te beïnvloeden hoe externe netwerken haar bereiken. AS_PATH prepending, selectieve advertenties en provider-specifieke BGP-communities kunnen helpen, maar de uiteindelijke beslissing ligt bij netwerken buiten de controle van de organisatie.
Dit is belangrijk tijdens failover.
Een netwerkteam kan bevestigen dat routers outbound verkeer direct naar de back-upprovider omschakelen, terwijl inbound verkeer via het defecte of gedegradeerde pad blijft aankomen totdat routewithdrawals zijn gepropageerd.
Voor stateful applicaties, firewalls en DDoS-mitigatiesystemen introduceert asymmetrische routing nog een extra complexiteitslaag. Verkeer dat via het ene pad binnenkomt en via een ander pad terugkeert kan vanuit BGP-perspectief volledig geldig zijn en tegelijkertijd een stateful beveiligingsarchitectuur doorbreken.
De routingpolicy moet daarom samen met de applicatie- en beveiligingslagen worden ontworpen, niet achteraf.
BGP-beveiliging, RPKI, routefiltering en bescherming tegen route hijacks
BGP is ontworpen rond samenwerking tussen netwerken. Historisch werd grotendeels vertrouwd dat een netwerk dat een route adverteerde ook bevoegd was om die route te adverteren.
Die aanname heeft duidelijke zwakke punten.
Een route leak kan per ongeluk prefixes verspreiden naar plaatsen waar ze niet thuishoren. Een route hijack kan ervoor zorgen dat adressen van een ander netwerk vanuit de verkeerde oorsprong worden geadverteerd. Beide situaties kunnen verkeer omleiden of blackholen.
RPKI en Route Origin Authorizations verbeteren dit door netwerken cryptografisch te laten verifiëren of een bepaald AS bevoegd is om een prefix te origineren. Ze verminderen een belangrijke categorie routingfouten, maar maken BGP niet inherent betrouwbaar.
Operators hebben nog steeds gedisciplineerde routefiltering nodig.
Daaronder vallen controle over welke prefixes klanten en peers mogen adverteren, maximale prefixlimieten, prefix- en AS-pathfilters waar relevant, routevalidatie en het voorkomen dat interne fouten externe incidenten worden.
BGP-beveiliging is daarom deels protocolbeveiliging en deels changemanagement.
Een syntactisch geldige routingpolicy kan operationeel nog steeds rampzalig zijn.
BGP-monitoring, netwerkobservability en routingautomatisering
BGP wordt steeds vaker via automatisering beheerd, maar automatisering vergroot het effect van de kwaliteit van de policy.
Als een engineer handmatig een slechte route-map op één router uitrolt, kan het probleem lokaal blijven. Als een automatiseringssysteem dezelfde fout over iedere edge-router in meerdere locaties verspreidt, heeft consistentie de storing simpelweg consistent gemaakt.
Voordat routingpolicy wordt geautomatiseerd, hebben teams zicht nodig op wat die policy werkelijk doet.
Dat betekent meer verzamelen dan alleen interfacestatus.
Operators hebben BGP-sessiestatus, geadverteerde en ontvangen prefixes, AS-paden, routewijzigingen, next-hopbereikbaarheid, verkeersvolumes, packet loss en latency nodig. Configuratiestatus moet worden geversioneerd. Fysieke afhankelijkheden moeten naast logische afhankelijkheden worden gedocumenteerd.
In een multi-datacenteromgeving komen assetmanagement en netwerkobservability bovendien samen. Wanneer een BGP-sessie verdwijnt, kan de oorzaak een routingprobleem zijn, een optic, een patchkabel, een cross-connect, een defecte line card, stroomuitval naar een router of gepland werk dat niemand met de alert heeft gecorreleerd.
Goede monitoring verkleint het zoekgebied. Nauwkeurige operationele registraties verkleinen het verder.
Dit is een reden waarom de grens tussen netwerkbeheer en fysieke datacenteroperaties belangrijker is dan architectuurdiagrammen meestal suggereren. 3W Infra combineert bijvoorbeeld netwerkontwerp en monitoring met fysieke Remote Hands-capaciteiten in zijn Amsterdamse locaties, waaronder rackinstallatie, bekabeling, optics en cross-connectwerkzaamheden.
BGP-operationele verantwoordelijkheid, ASN-beheer en routingonafhankelijkheid
Het beheren van een eigen ASN, prefixes en BGP-policy kan zinvolle onafhankelijkheid van één carrier bieden. Het creëert ook blijvende operationele verantwoordelijkheden.
Iemand moet prefixregistraties, routingpolicies, filters, ROA's, monitoring, upstreamrelaties en incidentprocedures onderhouden. Iemand moet begrijpen wat er gebeurt wanneer één provider wordt teruggetrokken, een andere degradeert, een prefix verkeerd wordt geadverteerd of een routervervanging het routinggedrag verandert.
Voor hostingproviders en grote SaaS-platforms kan die verantwoordelijkheid volledig gerechtvaardigd zijn. Internetrouting is dan onderdeel van het product.
Voor een kleinere onderneming kan provider-managed routing de verstandigere architectuur zijn, zelfs wanneer intern BGP theoretisch meer controle zou bieden.
Het technisch sterkste ontwerp is niet altijd het beste bedrijfsontwerp.
Voordat BGP wordt ingevoerd, is de nuttige vraag niet simpelweg of meerdere carriers beschikbaar zijn. Bepaal welke faaldomeinen werkelijk onafhankelijk worden, wie tijdens een incident eigenaar is van routingpolicy, hoe fysieke interconnecties zich verhouden tot logische redundantie en of de organisatie de resulterende topologie kan observeren en beheren wanneer een deel ervan zich anders gedraagt dan het diagram suggereert.
FAQ met strategische inzichten
Wanneer wordt BGP een business-continuityvraag in plaats van een routingkeuze?
Wanneer internetbereikbaarheid afhankelijk is van meerdere providers, locaties of externe paden, beïnvloedt BGP-policy direct de servicecontinuïteit, klanttoegang en incidentherstel.
Waarom kan multihoming een organisatie toch kwetsbaar laten?
Meerdere upstreams voegen opties toe, maar de veerkracht blijft zwak wanneer carriers, fiberroutes, routers, stroomfeeds of inter-site links verborgen fysieke afhankelijkheden delen.
Hoe moeten executives denken over Layer 2 versus Layer 3 over datacenters?
Layer 2 kan migratie en legacy-afhankelijkheden vereenvoudigen, terwijl Layer 3 doorgaans duidelijkere foutgrenzen, sterkere routingcontrole en beter schaalbare multi-site operaties creëert.
Waarom is inbound BGP-failover moeilijker te controleren dan outbound routing?
Organisaties kunnen inbound paden beïnvloeden, maar externe netwerken maken de uiteindelijke routingbeslissing, waardoor convergence, asymmetrie, beveiligingscontroles en klantimpact minder voorspelbaar zijn.
Waar creëert BGP-automatisering het grootste operationele risico?
Automatisering wordt gevaarlijk wanneer zwakke policy, onvolledige validatie of slechte observability ervoor zorgt dat één routingfout zich snel over meerdere routers en locaties verspreidt.
Wanneer is het commercieel gerechtvaardigd om een eigen ASN en BGP-policy te beheren?
Dat is zinvol wanneer routingonafhankelijkheid, providerdiversiteit, traffic engineering en continuïteit wezenlijke invloed hebben op omzet, klantervaring of strategische controle over netwerkoperaties.
Wat onderscheidt echte netwerkveerkracht van een diagram vol redundante links?
Uitvoering. 3W Infra combineert BGP-expertise, multi-carrierconnectiviteit, Amsterdamse interconnectie, dark-fiberinfrastructuur en Remote Hands om logische routing op fysieke veerkracht af te stemmen.
Bespreek uw BGP-redundantiestrategie met 3W Infra
Wilt u bespreken hoe BGP-policy, carrierdiversiteit, fysieke padscheiding en multi-site connectiviteit samen zouden moeten werken? Neem contact op met de netwerkexperts van 3W Infra via [email protected].
