Bring Your Own IP to a VPS with BGP: Complete Guide

This is the hub page for the full BYOIP journey. It connects every step from obtaining an ASN to monitoring your BGP announcements in production. Each section links to a dedicated deep-dive article where you will find configs, commands, and verification steps.

If you already know what BGP and BYOIP are, jump to What do you need before your first BGP session?.

What does it mean to bring your own IP to a VPS?

Bring Your Own IP (BYOIP) means announcing IP address space that you own or lease from a Regional Internet Registry (RIR) through a hosting provider's network using BGP. Instead of using the provider's IP addresses, your VPS originates routes for your own prefixes. Traffic destined for those IPs reaches your server through the provider's upstream links and internet exchanges.

You keep control of the addresses. If you move to a different provider, your IPs move with you. No DNS changes, no reputation reset, no customer-facing downtime beyond the convergence window.

Why bring your own IPs?

IP reputation continuity. Email deliverability, DNS reputation, and firewall allowlists follow the address, not the server. Switching providers with provider-assigned IPs means rebuilding reputation from zero.

Provider portability. Your prefixes are not tied to any single host. You can fail over to another provider, or run multi-homed across two, without changing the addresses your customers connect to.

Multi-homing and redundancy. Announce the same prefix from multiple locations. BGP handles failover automatically. Your service stays reachable even when one site goes down.

Compliance and auditing. Some regulated environments require IP address ownership documentation. Owning your allocation through a RIR gives you that paper trail.

Anycast. Announce the same prefix from geographically distributed nodes. Users are routed to the nearest one. This is how DNS root servers and CDN edges work.

How does BGP fit into BYOIP?

BGP (Border Gateway Protocol) is the protocol that routers use to exchange reachability information between autonomous systems on the internet. When you bring your own IP to a VPS, you run a BGP daemon on your server. That daemon establishes a session with your provider's router and announces your prefixes. The provider propagates those announcements to their upstreams and peers. Within minutes, routers across the internet learn that your IP space is reachable through your provider's network.

This is the same protocol that every ISP, cloud provider, and content network uses. The difference is scale: you are announcing one or two prefixes instead of thousands.

You do not need to understand every BGP attribute to get started. You need to know how to configure a session, announce a prefix, and filter what you accept. The deep-dive articles in this cocoon cover each of those in detail.

What do you need before your first BGP session?

Six building blocks, in dependency order:

An Autonomous System Number (ASN). Your identity on the BGP internet. You get one from a RIR (RIPE NCC in Europe, ARIN in North America, APNIC in Asia-Pacific) through a sponsoring LIR. Processing takes 2-5 business days at RIPE NCC.
An IP allocation. At minimum a /24 for IPv4 or a /48 for IPv6. Smaller prefixes are filtered by most networks and will not propagate. You can hold IPv4 space from a RIR (increasingly scarce and expensive) or lease it from a broker. IPv6 allocations are readily available from all RIRs.
IRR route objects. Entries in the Internet Routing Registry that document which ASN is authorized to originate your prefix. Many transit providers build their BGP filters from IRR data. Without a matching route object, your announcement may be silently dropped. Create these in the RIPE Database (or your RIR's equivalent) before your first session.
RPKI ROAs (Route Origin Authorizations). Cryptographic objects that bind your prefix to your ASN. Over 51% of IPv4 routes and 57% of IPv6 routes now have valid ROAs. Networks performing Route Origin Validation (ROV) will reject announcements that fail RPKI checks. Create ROAs in your RIR's portal.
A routing daemon. Software on your VPS that speaks BGP. The three main options are BIRD2, FRRouting (FRR), and VyOS. See the comparison below.
A provider with BGP session support. Not every VPS provider offers this. You need a provider that will configure a BGP session between their router and your VPS, accept your prefix announcements, and propagate them upstream.

Pre-flight checklist

Before requesting a BGP session from your provider, make sure you have:

Item	Where to get it	Time estimate
ASN	RIR via sponsoring LIR	2-5 business days
IPv4 /24 or larger	RIR allocation or lease	Days to weeks
IPv6 /48 or larger	RIR allocation	1-2 business days
IRR route/route6 objects	RIPE Database or equivalent	Minutes (after ASN)
RPKI ROAs for each prefix	RIR member portal	Minutes
LOA (Letter of Authorization)	You sign it, provider may request it	Minutes
Provider with BGP support	or similar	Varies

Your provider will typically need your ASN, the prefixes you plan to announce, and possibly an LOA confirming you are authorized to announce them.

How do ASN, IP allocation, and RPKI fit together?

These three form the trust chain that lets the internet verify your announcements are legitimate.

Your ASN identifies your network. Every BGP announcement carries the originating ASN in its AS-path. Upstream networks use this to build routing policy.

Your IP allocation is the address space you are authorized to use. The RIR's database records you (or your sponsoring LIR) as the holder.

IRR objects are the routing policy layer. A route object in the RIPE Database says "AS64500 is authorized to originate 192.0.2.0/24." Transit providers query IRR data to build prefix filters. If your route object is missing or wrong, your transit provider's automated filters may reject your announcement.

RPKI ROAs are the cryptographic layer. A ROA is a signed object stored in your RIR's RPKI repository. It says the same thing as the IRR route object, but it is cryptographically verifiable. Networks running ROV validators (Routinator, rpki-client, Fort, RIPE NCC's RPKI Validator) fetch ROAs and feed validation results to their routers. An announcement without a valid ROA is increasingly likely to be dropped.

The dependency chain looks like this:

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)

Get the top layers right before you touch BGP configuration. An announcement without matching IRR and RPKI records will either be filtered or flagged as a potential hijack.

Which routing daemon should you use: BIRD2, FRR, or VyOS?

Three options dominate BGP on Linux VPS environments. All three support dual-stack (IPv4 + IPv6), RPKI validation, and the features you need for BYOIP. The choice comes down to config style preference and operational requirements.

Feature	BIRD2	FRRouting (FRR)	VyOS
Config style	Custom declarative language	Cisco IOS-like CLI (vtysh)	JunOS-like CLI (set/commit)
Filter language	Powerful, Turing-complete filters	Route-maps + prefix-lists	Route-maps (FRR under the hood)
Dual-stack	Single config file, multi-table	Separate address-family blocks	Separate address-family blocks
RPKI support	Built-in `rpki` protocol	Built-in rpki module	Via FRR integration
Memory usage	Lower (2x more efficient than FRR in benchmarks)	Higher, especially with full tables	Higher (full OS overhead)
Learning curve	Steeper if coming from Cisco	Low for Cisco/IOS users	Low for JunOS users
Best for	IXP route servers, policy-heavy setups	Familiar Cisco-style workflow	Full router OS experience

BIRD2 has the most expressive filter language. You can write complex import/export policies in a single config file. It handles both IPv4 and IPv6 in one daemon instance. Memory footprint is roughly half of FRR for equivalent workloads. The tradeoff: its config syntax has no equivalent in the vendor world. You learn BIRD's language or you do not use BIRD.

FRRouting (FRR) uses a Cisco IOS-like CLI through vtysh. If you have worked with Cisco, Arista, or legacy Quagga, FRR feels familiar immediately. Route-maps and prefix-lists work the way you expect. It is the most widely deployed open-source routing suite.

VyOS is a full network operating system that uses FRR as its routing engine. You configure everything through a JunOS-style set / commit workflow. It provides a complete router experience: firewall, NAT, VPN, DHCP, and routing in one package. On Virtua Cloud, you can deploy VyOS with one click. The tradeoff: it is a full OS, not just a daemon. You give up the flexibility of a general-purpose Linux server.

Which one to pick? If you want maximum control and efficiency, choose BIRD2. If you want Cisco-like familiarity on a Linux server, choose FRR. If you want a dedicated router appliance, choose VyOS.

How do you secure a BGP deployment?

Security in BGP is not optional. A misconfigured BGP session can leak routes, accept hijacked prefixes, or expose your network to traffic injection. Every BGP deployment should include these layers from day one.

RPKI and Route Origin Validation

Configure your daemon to validate received routes against RPKI data. Run a local RPKI cache (Routinator or rpki-client) or connect to a hosted validator. Reject routes with RPKI state "invalid." This prevents your router from accepting hijacked prefixes.

As of 2025, over 51% of IPv4 routes and 57% of IPv6 routes have valid ROAs. All major transit providers perform ROV. If your own prefixes lack ROAs, some networks will drop your announcements.

Route filtering

Never run export all or import all in production. These are the BGP equivalent of chmod 777.

On the export side, only announce prefixes you are authorized to originate. Use a prefix-list that explicitly matches your allocations. On the import side, if you are single-homed (one upstream), you typically accept a default route only. If multi-homed, filter imports by prefix-list and AS-path to prevent route leaks.

Reject bogon prefixes (RFC 1918 space, documentation ranges, unallocated blocks) on import. Reject prefixes longer than /24 for IPv4 or /48 for IPv6. Set max-prefix limits to protect against a peer accidentally dumping a full routing table into your session.

GTSM (Generalized TTL Security Mechanism)

GTSM (RFC 5082) ensures BGP packets arrive with a TTL of 255, meaning they originated on a directly connected neighbor. This blocks remote attackers from injecting BGP packets. Most providers support it. Enable it on your side when your provider confirms support.

Firewall rules

Allow TCP port 179 only from your provider's BGP router IP. Drop everything else destined for port 179. This is a single nftables or iptables rule, but it prevents unauthorized BGP connection attempts.

Common pitfalls

rp_filter breaking traffic. Linux reverse path filtering (rp_filter=1, the default on many distributions) drops packets arriving on an interface if the kernel's routing table says the source IP should arrive on a different interface. With BGP-announced prefixes on dummy interfaces, this breaks legitimate traffic. Set rp_filter=0 or rp_filter=2 (loose mode) on the relevant interfaces. Test after every kernel upgrade.

BIRD 1.x vs BIRD 2.x config confusion. BIRD 2 uses a completely different config syntax from BIRD 1.x. Many online tutorials (including top search results from Vultr and others) still show BIRD 1.x syntax. If you copy-paste config from an old tutorial into BIRD 2, the daemon will refuse to start. Always check which version you are running with birdc show status.

Missing IRR objects. You created RPKI ROAs but forgot the IRR route object. Your upstream's automated filter builder queries IRR, finds no matching object, and silently drops your announcement. Your prefix is RPKI-valid but still unreachable. Always create both.

What can you do with BGP beyond basic announcements?

Once your prefix is announced and reachable, BGP opens up several advanced use cases.

Anycast

Announce the same prefix from multiple geographic locations. Each site runs an identical service (DNS resolver, CDN edge, API endpoint). Users are routed to the closest site by BGP path selection. If one site fails, its BGP session drops, the prefix is withdrawn from that location, and traffic shifts to the remaining sites automatically.

Anycast is how the DNS root server system works. You can run the same pattern with two or three VPS nodes in different data centers.

Failover and multi-homing

Announce your prefix from two providers or two locations with the same provider. Use LOCAL_PREF and MED to set primary/backup preference. When the primary fails, traffic shifts to the backup within the BGP convergence window (typically 30-90 seconds with BFD enabled).

For planned maintenance, use the graceful shutdown community (RFC 8326). Your daemon signals peers to deprioritize the prefix before you take the session down. Traffic drains to the backup site without packet loss.

BGP communities for traffic engineering

Communities are tags attached to BGP announcements that influence how upstream networks handle your routes. Common uses:

Blackhole community: Signal your upstream to drop all traffic to a specific prefix during a DDoS attack.
Prepending control: Ask your upstream to prepend your AS to make a path less preferred, steering traffic to a different upstream.
Selective announcement: Announce to peers but not to transit, or vice versa, controlling where your prefix propagates.
Geographic scoping: Limit announcement to specific regions or IXPs.

Each provider defines their own community values. Check your provider's BGP community documentation before using them.

How do you monitor BGP announcements?

You need to know when something changes with your prefixes. Route hijacks, accidental withdrawals, RPKI state changes, and visibility drops all require immediate attention. Do not assume your announcements are stable because they worked yesterday.

BGPalerter is a self-hosted monitoring tool that watches your prefixes and ASN. It connects to public BGP data sources (RIPE RIS, RouteViews) and alerts you on:

Prefix hijacks (another ASN originating your prefix)
Sub-prefix hijacks (someone announcing a more specific of your prefix)
Route leaks
RPKI invalid state changes
Visibility drops (your prefix disappears from a significant number of vantage points)

Run it as a systemd service on a separate VPS from the one doing BGP. If your BGP node goes down, you still want alerts. Configure notifications to Slack, email, or your monitoring stack.

External validation tools

Use these to verify your announcements look correct from the outside:

bgp.tools -- Real-time view of your prefix, AS-path, RPKI state, and IRR consistency
RIPE Stat -- RIR-operated looking glass with routing history and RPKI validation
Hurricane Electric BGP Toolkit (bgp.he.net) -- AS information, prefix reports, IRR and RPKI status
Looking glass servers -- Most transit providers and IXPs offer looking glass access to check how your prefix appears from their perspective

Check these after your first announcement and periodically afterward. An announcement that looks correct from your daemon's perspective may still be filtered or hijacked further upstream.

The full journey: from zero to monitored BGP

Here is the complete path, with links to the article that covers each step:

Get an ASN from your RIR through a sponsoring LIR.
Obtain IP space. At minimum /24 IPv4, /48 IPv6. From your RIR or a broker.
Create IRR route objects in the RIPE Database for each prefix.
Create RPKI ROAs in your RIR's portal for each prefix.
Choose a routing daemon: BIRD2 , FRR , or VyOS .
Configure BGP on your VPS. Set up the session, announce your prefixes, apply filters.
Secure the deployment. RPKI validation, route filtering, GTSM, firewall rules.
Verify from outside. Check bgp.tools, RIPE Stat, and your provider's looking glass.
Set up monitoring. Deploy BGPalerter to watch for hijacks and visibility issues.
Explore advanced use cases. Communities , anycast , failover .

Do you need your own ASN, or can you use a private one?

If you announce prefixes to only one upstream and never plan to multi-home or peer at an IXP, a private ASN (64512-65534 for 16-bit, 4200000000-4294967294 for 32-bit) can work. Your provider strips it from the AS-path before propagating your routes upstream.

Get your own public ASN if any of these apply:

You plan to connect to multiple upstreams (multi-homing)
You want to peer at an internet exchange
You want your ASN visible in traceroutes and BGP looking glasses
You want to use BGP communities that reference your ASN
You operate a service where network identity matters (CDN, DNS, email infrastructure)

The cost difference is minimal. A public ASN through RIPE NCC costs the sponsoring LIR's fee (typically a few hundred euros per year). For most use cases, a public ASN is the right choice.