Bring Your Own IP op een VPS met BGP: complete gids

Deze pagina is het centrale knooppunt van het volledige BYOIP-traject. Het verbindt elke stap van het verkrijgen van een ASN tot het monitoren van je BGP-aankondigingen in productie. Elke sectie verwijst naar een gewijd verdiepingsartikel met configuraties, commando's en verificatiestappen.

Als je al weet wat BGP en BYOIP zijn, ga dan direct naar Wat heb je nodig voor je eerste BGP-sessie?.

Wat betekent het om je eigen IP naar een VPS te brengen?

Bring Your Own IP (BYOIP) betekent dat je IP-adresruimte die je bezit of huurt van een Regional Internet Registry (RIR) aankondigt via het netwerk van een hostingprovider met behulp van BGP. In plaats van de IP-adressen van de provider te gebruiken, origineert je VPS routes voor je eigen prefixen. Verkeer bestemd voor die IP's bereikt je server via de upstreamverbindingen en internet exchanges van de provider.

Je behoudt de controle over de adressen. Als je van provider wisselt, verhuizen je IP's mee. Geen DNS-wijzigingen, geen reputatie-reset, geen klantgerichte downtime buiten het convergentievenster.

Waarom je eigen IP's meebrengen?

IP-reputatiecontinuïteit. E-mailafleverbaarheid, DNS-reputatie en firewall-allowlists volgen het adres, niet de server. Wisselen van provider met door de provider toegewezen IP's betekent reputatie opnieuw opbouwen vanaf nul.

Providerportabiliteit. Je prefixen zijn niet gebonden aan een enkele host. Je kunt failoveren naar een andere provider, of multi-homing over twee uitvoeren, zonder de adressen te wijzigen waarmee je klanten verbinden.

Multi-homing en redundantie. Kondig hetzelfde prefix aan vanaf meerdere locaties. BGP regelt de failover automatisch. Je dienst blijft bereikbaar, zelfs als een locatie uitvalt.

Compliance en audit. Sommige gereguleerde omgevingen vereisen documentatie over IP-adreseigendom. Een eigen toewijzing via een RIR geeft je dat bewijs.

Anycast. Kondig hetzelfde prefix aan vanaf geografisch verspreide knooppunten. Gebruikers worden naar het dichtstbijzijnde gerouteerd. Zo werken DNS-rootservers en CDN-edge-nodes.

Hoe past BGP in BYOIP?

BGP (Border Gateway Protocol) is het protocol dat routers gebruiken om bereikbaarheidsinformatie uit te wisselen tussen autonome systemen op het internet. Wanneer je je eigen IP naar een VPS brengt, draai je een BGP-daemon op je server. Die daemon bouwt een sessie op met de router van je provider en kondigt je prefixen aan. De provider propageert die aankondigingen naar zijn upstreams en peers. Binnen enkele minuten leren routers over het hele internet dat je IP-ruimte bereikbaar is via het netwerk van je provider.

Het is hetzelfde protocol dat elke ISP, cloudprovider en contentnetwerk gebruikt. Het verschil is de schaal: je kondigt een of twee prefixen aan in plaats van duizenden.

Je hoeft niet elk BGP-attribuut te begrijpen om te starten. Je moet weten hoe je een sessie configureert, een prefix aankondigt en filtert wat je accepteert. De verdiepingsartikelen in deze cocoon behandelen elk van deze punten in detail.

Wat heb je nodig voor je eerste BGP-sessie?

Zes bouwblokken, in volgorde van afhankelijkheid:

Een Autonomous System Number (ASN). Je identiteit op het BGP-internet. Je krijgt er een van een RIR (RIPE NCC in Europa, ARIN in Noord-Amerika, APNIC in Azië-Pacific) via een sponsoring LIR. Verwerking duurt 2-5 werkdagen bij RIPE NCC.
Een IP-toewijzing. Minimaal een /24 voor IPv4 of een /48 voor IPv6. Kleinere prefixen worden door de meeste netwerken gefilterd en zullen niet propageren. Je kunt IPv4-ruimte van een RIR houden (steeds schaarser en duurder) of huren van een broker. IPv6-toewijzingen zijn gemakkelijk verkrijgbaar bij alle RIR's.
IRR-route-objecten. Vermeldingen in het Internet Routing Registry die documenteren welk ASN geautoriseerd is om je prefix te origineren. Veel transitproviders bouwen hun BGP-filters op basis van IRR-data. Zonder een overeenkomend route-object wordt je aankondiging mogelijk stilzwijgend verworpen. Maak deze aan in de RIPE-database (of het equivalent van je RIR) vóór je eerste sessie.
RPKI ROA's (Route Origin Authorizations). Cryptografische objecten die je prefix aan je ASN binden. Meer dan 51% van de IPv4-routes en 57% van de IPv6-routes hebben nu geldige ROA's. Netwerken die Route Origin Validation (ROV) uitvoeren, zullen aankondigingen die niet slagen voor RPKI-controles weigeren. Maak ROA's aan in het portaal van je RIR.
Een routing-daemon. Software op je VPS die BGP spreekt. De drie hoofdopties zijn BIRD2, FRRouting (FRR) en VyOS. Zie de vergelijking hieronder.
Een provider met BGP-sessieondersteuning. Niet elke VPS-provider biedt dit aan. Je hebt een provider nodig die een BGP-sessie configureert tussen zijn router en je VPS, je prefixaankondigingen accepteert en ze upstream propageert.

Checklist vóór de start

Controleer voordat je een BGP-sessie aanvraagt bij je provider of je het volgende hebt:

Item	Waar te verkrijgen	Geschatte tijd
ASN	RIR via sponsoring LIR	2-5 werkdagen
IPv4 /24 of groter	RIR-toewijzing of huur	Dagen tot weken
IPv6 /48 of groter	RIR-toewijzing	1-2 werkdagen
IRR route/route6-objecten	RIPE-database of equivalent	Minuten (na ASN)
RPKI ROA's voor elk prefix	RIR-ledenportaal	Minuten
LOA (Letter of Authorization)	Je ondertekent hem, provider kan erom vragen	Minuten
Provider met BGP-ondersteuning	of vergelijkbaar	Varieert

Je provider heeft doorgaans je ASN nodig, de prefixen die je wilt aankondigen en mogelijk een LOA die bevestigt dat je geautoriseerd bent om ze aan te kondigen.

Hoe hangen ASN, IP-toewijzing en RPKI samen?

Deze drie vormen de vertrouwensketen waarmee het internet kan verifiëren dat je aankondigingen legitiem zijn.

Je ASN identificeert je netwerk. Elke BGP-aankondiging draagt het originerende ASN in zijn AS-path. Upstreamnetwerken gebruiken dit om routingbeleid op te bouwen.

Je IP-toewijzing is de adresruimte die je mag gebruiken. De database van het RIR registreert jou (of je sponsoring LIR) als houder.

IRR-objecten zijn de routingbeleidslaag. Een route-object in de RIPE-database zegt "AS64500 is geautoriseerd om 192.0.2.0/24 te origineren." Transitproviders raadplegen IRR-data om prefixfilters op te bouwen. Als je route-object ontbreekt of onjuist is, kunnen de geautomatiseerde filters van je transitprovider je aankondiging weigeren.

RPKI ROA's zijn de cryptografische laag. Een ROA is een ondertekend object opgeslagen in het RPKI-repository van je RIR. Het zegt hetzelfde als het IRR-route-object, maar het is cryptografisch verifieerbaar. Netwerken die ROV-validators draaien (Routinator, rpki-client, Fort, RIPE NCC RPKI Validator) halen ROA's op en voeden validatieresultaten aan hun routers. Een aankondiging zonder geldig ROA wordt steeds vaker verworpen.

De afhankelijkheidsketen ziet er zo uit:

ASN (from RIR)
  └── IP allocation (from RIR)
        ├── IRR route objects (RIPE Database)
        ├── RPKI ROAs (RIR portal)
        └── BGP session (provider router <-> your daemon)
              └── Prefix announcement (your daemon originates routes)

Zorg dat de bovenste lagen op orde zijn voordat je de BGP-configuratie aanraakt. Een aankondiging zonder overeenkomende IRR- en RPKI-records wordt gefilterd of als potentiële hijack gemarkeerd.

Welke routing-daemon moet je gebruiken: BIRD2, FRR of VyOS?

Drie opties domineren BGP op Linux VPS-omgevingen. Alle drie ondersteunen dual-stack (IPv4 + IPv6), RPKI-validatie en de functies die je nodig hebt voor BYOIP. De keuze hangt af van je voorkeur voor configuratiestijl en operationele vereisten.

Functie	BIRD2	FRRouting (FRR)	VyOS
Configuratiestijl	Eigen declaratieve taal	Cisco IOS-achtige CLI (vtysh)	JunOS-achtige CLI (set/commit)
Filtertaal	Krachtig, Turing-compleet	Route-maps + prefix-lists	Route-maps (FRR onder de motorkap)
Dual-stack	Enkel configuratiebestand, multi-tabel	Aparte address-family-blokken	Aparte address-family-blokken
RPKI-ondersteuning	Ingebouwd `rpki`-protocol	Ingebouwde rpki-module	Via FRR-integratie
Geheugengebruik	Lager (2x efficiënter dan FRR in benchmarks)	Hoger, vooral met volledige tabellen	Hoger (overhead van volledig OS)
Leercurve	Steiler als je van Cisco komt	Laag voor Cisco/IOS-gebruikers	Laag voor JunOS-gebruikers
Het best voor	IXP-routeservers, beleidsrijke setups	Vertrouwde Cisco-workflow	Volledige router-OS-ervaring

BIRD2 heeft de meest expressieve filtertaal. Je kunt complexe import/export-beleidsregels schrijven in een enkel configuratiebestand. Het verwerkt zowel IPv4 als IPv6 in één daemon-instantie. Het geheugenverbruik is ruwweg de helft van FRR bij vergelijkbare belasting. De afweging: de configuratiesyntax heeft geen equivalent in de vendorwereld. Je leert BIRDs taal of je gebruikt BIRD niet.

FRRouting (FRR) gebruikt een Cisco IOS-achtige CLI via vtysh. Als je met Cisco, Arista of het oude Quagga hebt gewerkt, voelt FRR meteen vertrouwd. Route-maps en prefix-lists werken zoals je verwacht. Het is de meest verspreide open-source routingsuite.

VyOS is een volledig netwerkbesturingssysteem dat FRR als routing-engine gebruikt. Je configureert alles via een JunOS-achtige set / commit-workflow. Het biedt een complete routerervaring: firewall, NAT, VPN, DHCP en routing in één pakket. Op Virtua Cloud kun je VyOS met één klik deployen. De afweging: het is een volledig OS, geen losse daemon. Je verliest de flexibiliteit van een algemeen Linux-server.

Welke kiezen? Als je maximale controle en efficiëntie wilt, kies BIRD2. Als je Cisco-vertrouwdheid op een Linux-server wilt, kies FRR. Als je een dedicated routerappliance wilt, kies VyOS.

Hoe beveilig je een BGP-deployment?

Beveiliging in BGP is niet optioneel. Een verkeerd geconfigureerde BGP-sessie kan routes lekken, gekaapte prefixen accepteren of je netwerk blootstellen aan traffic-injectie. Elk BGP-deployment moet deze lagen vanaf dag één bevatten.

RPKI en Route Origin Validation

Configureer je daemon om ontvangen routes te valideren tegen RPKI-data. Draai een lokale RPKI-cache (Routinator of rpki-client) of verbind met een gehoste validator. Weiger routes met RPKI-status "invalid". Dit voorkomt dat je router gekaapte prefixen accepteert.

In 2025 hebben meer dan 51% van de IPv4-routes en 57% van de IPv6-routes geldige ROA's. Alle grote transitproviders voeren ROV uit. Als je eigen prefixen geen ROA's hebben, zullen sommige netwerken je aankondigingen verwerpen.

Routefiltering

Gebruik nooit export all of import all in productie. Dat is het BGP-equivalent van chmod 777.

Aan de exportkant kondig je alleen prefixen aan die je mag origineren. Gebruik een prefix-list die expliciet overeenkomt met je toewijzingen. Aan de importkant accepteer je bij single-homing (één upstream) typisch alleen een default route. Bij multi-homing filter je imports op prefix-list en AS-path om routelekken te voorkomen.

Weiger bogon-prefixen (RFC 1918-ruimte, documentatiebereiken, niet-toegewezen blokken) bij import. Weiger prefixen langer dan /24 voor IPv4 of /48 voor IPv6. Stel max-prefix-limieten in om je te beschermen tegen een peer die per ongeluk een volledige routingtabel in je sessie dumpt.

GTSM (Generalized TTL Security Mechanism)

GTSM (RFC 5082) zorgt ervoor dat BGP-pakketten aankomen met een TTL van 255, wat betekent dat ze afkomstig zijn van een direct verbonden buur. Dit blokkeert aanvallers op afstand die BGP-pakketten proberen te injecteren. De meeste providers ondersteunen het. Schakel het aan je kant in wanneer je provider de ondersteuning bevestigt.

Firewallregels

Sta TCP-poort 179 alleen toe vanaf het BGP-router-IP van je provider. Verwerp al het andere verkeer naar poort 179. Het is een enkele nftables- of iptables-regel, maar het voorkomt ongeautoriseerde BGP-verbindingspogingen.

Veelgemaakte fouten

rp_filter die verkeer breekt. Linux reverse path filtering (rp_filter=1, de standaard op veel distributies) verwerpt pakketten die op een interface aankomen als de routingtabel van de kernel zegt dat het bron-IP op een andere interface zou moeten aankomen. Met BGP-aangekondigde prefixen op dummy-interfaces breekt dit legitiem verkeer. Stel rp_filter=0 of rp_filter=2 (loose mode) in op de betreffende interfaces. Test na elke kernelupgrade.

Verwarring tussen BIRD 1.x- en BIRD 2.x-configuratie. BIRD 2 gebruikt een compleet andere configuratiesyntax dan BIRD 1.x. Veel online tutorials (inclusief topzoekresultaten van Vultr en anderen) tonen nog steeds BIRD 1.x-syntax. Als je configuratie uit een oud tutorial in BIRD 2 plakt, weigert de daemon te starten. Controleer altijd welke versie je draait met birdc show status.

Ontbrekende IRR-objecten. Je hebt RPKI ROA's aangemaakt maar het IRR-route-object vergeten. De geautomatiseerde filterbouwer van je upstream raadpleegt IRR, vindt geen overeenkomend object en verwerpt je aankondiging stilzwijgend. Je prefix is RPKI-valid maar toch onbereikbaar. Maak altijd beide aan.

Wat kun je met BGP doen naast basisaankondigingen?

Zodra je prefix is aangekondigd en bereikbaar is, opent BGP verschillende geavanceerde toepassingen.

Anycast

Kondig hetzelfde prefix aan vanaf meerdere geografische locaties. Elke locatie draait een identieke dienst (DNS-resolver, CDN-edge, API-endpoint). Gebruikers worden naar de dichtstbijzijnde locatie gerouteerd door BGP-padselectie. Als een locatie uitvalt, valt zijn BGP-sessie, wordt het prefix van die locatie teruggetrokken en verschuift het verkeer automatisch naar de overgebleven locaties.

Anycast is hoe het DNS-rootserversysteem werkt. Je kunt hetzelfde patroon toepassen met twee of drie VPS-nodes in verschillende datacenters.

Failover en multi-homing

Kondig je prefix aan vanaf twee providers of twee locaties bij dezelfde provider. Gebruik LOCAL_PREF en MED om de primaire/back-upvoorkeur in te stellen. Wanneer de primaire uitvalt, verschuift het verkeer naar de back-up binnen het BGP-convergentievenster (doorgaans 30-90 seconden met BFD ingeschakeld).

Voor gepland onderhoud gebruik je de graceful shutdown community (RFC 8326). Je daemon signaleert peers om het prefix te deprioritiseren voordat je de sessie afsluit. Verkeer draineert naar de back-uplocatie zonder pakketverlies.

BGP-communities voor traffic engineering

Communities zijn tags die aan BGP-aankondigingen worden gehangen en beïnvloeden hoe upstreamnetwerken je routes behandelen. Veelvoorkomende toepassingen:

Blackhole-community: Signaleer je upstream om al het verkeer naar een specifiek prefix te verwerpen tijdens een DDoS-aanval.
Prepending-controle: Vraag je upstream om je AS te prependen om een pad minder gewenst te maken, zodat verkeer naar een andere upstream wordt gestuurd.
Selectieve aankondiging: Kondig aan bij peers maar niet bij transit, of andersom, om te bepalen waar je prefix propageert.
Geografische afbakening: Beperk de aankondiging tot specifieke regio's of IXP's.

Elke provider definieert zijn eigen communitywaarden. Raadpleeg de BGP-communitydocumentatie van je provider voordat je ze gebruikt.

Hoe monitor je BGP-aankondigingen?

Je moet weten wanneer er iets verandert met je prefixen. Route-hijacks, onbedoelde terugtrekkingen, RPKI-statuswijzigingen en zichtbaarheidsdalingen vereisen allemaal onmiddellijke aandacht. Ga er niet van uit dat je aankondigingen stabiel zijn omdat ze gisteren werkten.

BGPalerter is een self-hosted monitoringtool die je prefixen en ASN bewaakt. Het verbindt met openbare BGP-databronnen (RIPE RIS, RouteViews) en waarschuwt je bij:

Prefix-hijacks (een ander ASN dat je prefix origineert)
Sub-prefix-hijacks (iemand die een specifieker van je prefix aankondigt)
Routelekken
RPKI invalid-statuswijzigingen
Zichtbaarheidsdalingen (je prefix verdwijnt van een significant aantal observatiepunten)

Draai het als systemd-service op een aparte VPS dan degene die BGP doet. Als je BGP-node uitvalt, wil je nog steeds waarschuwingen ontvangen. Configureer notificaties naar Slack, e-mail of je monitoringstack.

Externe validatietools

Gebruik deze om te verifiëren dat je aankondigingen er van buitenaf correct uitzien:

bgp.tools -- Realtime weergave van je prefix, AS-path, RPKI-status en IRR-consistentie
RIPE Stat -- Door het RIR beheerd looking glass met routinggeschiedenis en RPKI-validatie
Hurricane Electric BGP Toolkit (bgp.he.net) -- AS-informatie, prefixrapporten, IRR- en RPKI-status
Looking glass-servers -- De meeste transitproviders en IXP's bieden looking glass-toegang om te controleren hoe je prefix vanuit hun perspectief verschijnt

Controleer deze na je eerste aankondiging en daarna regelmatig. Een aankondiging die er vanuit het perspectief van je daemon correct uitziet, kan verderop in de keten gefilterd of gekaapt zijn.

Het volledige traject: van nul tot gemonitord BGP

Hier is het complete pad, met links naar het artikel dat elke stap behandelt:

Een ASN verkrijgen van je RIR via een sponsoring LIR.
IP-ruimte verkrijgen. Minimaal /24 IPv4, /48 IPv6. Van je RIR of een broker.
IRR-route-objecten aanmaken in de RIPE-database voor elk prefix.
RPKI ROA's aanmaken in het portaal van je RIR voor elk prefix.
Een routing-daemon kiezen: BIRD2 , FRR of VyOS .
BGP configureren op je VPS. Sessie opzetten, prefixen aankondigen, filters toepassen.
Het deployment beveiligen. RPKI-validatie, routefiltering, GTSM, firewallregels.
Van buitenaf verifiëren. bgp.tools, RIPE Stat en het looking glass van je provider controleren.
Monitoring opzetten. BGPalerter deployen om hijacks en zichtbaarheidsproblemen te detecteren.
Geavanceerde toepassingen verkennen. Communities , anycast , failover .

Heb je een eigen ASN nodig of kun je een privaat ASN gebruiken?

Als je prefixen aankondigt aan slechts één upstream en nooit multi-homing of peering aan een IXP plant, kan een privaat ASN (64512-65534 voor 16-bit, 4200000000-4294967294 voor 32-bit) werken. Je provider verwijdert het uit het AS-path voordat hij je routes upstream propageert.

Haal je eigen publiek ASN als een van deze situaties van toepassing is:

Je plant verbinding met meerdere upstreams (multi-homing)
Je wilt peeren bij een internet exchange
Je wilt dat je ASN zichtbaar is in traceroutes en BGP looking glasses
Je wilt BGP-communities gebruiken die je ASN refereren
Je exploiteert een dienst waarbij netwerkidentiteit ertoe doet (CDN, DNS, e-mailinfrastructuur)

Het kostenverschil is minimaal. Een publiek ASN via RIPE NCC kost de vergoeding van de sponsoring LIR (doorgaans enkele honderden euro's per jaar). Voor de meeste toepassingen is een publiek ASN de juiste keuze.

Copyright 2026 Virtua.Cloud. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.