BGP on a Dedicated Server: Autonomous System for Independence and Redundancy

03.04.2026
18:15


BGP is not about having a “serious infrastructure.” It solves specific problems: one upstream goes down and everything with it, you need IP addresses that belong to you and follow you wherever you go, or you want actual control over where traffic flows.

If you have one server and one connection — you don’t need BGP. No point reading further, and that’s an honest answer. If your situation is more complex — let’s break down how it works and what you’ll need to set it up.

What is BGP and What Does an Autonomous System Have to Do With It

When two devices in the same network exchange data — that’s internal routing, handled through OSPF, RIP, and similar protocols. BGP operates one level up: between separate networks, each managed independently.

Such an independently managed network is called an autonomous system — AS. Each AS has a unique number, an ASN. A provider is an AS. A large company with its own network is also an AS. The entire internet consists of tens of thousands of such systems negotiating routes with each other through BGP.

An ordinary server doesn’t care about any of this. The provider assigns an IP from its pool, announces it to the network, traffic arrives. You just work. BGP only becomes relevant when this setup stops being enough.

How a BGP Session Works

A BGP session is a TCP connection on port 179 between two routers. These are called peers or neighbors. The session isn’t established automatically like in OSPF: you explicitly configure the peer’s IP and AS number in the config.

Once the session is established, route exchange begins. The provider tells you where to look. You tell the provider which IP addresses are yours. The provider propagates this information further across the internet.

There are two modes:

eBGP — when the session runs between different autonomous systems. The classic case: your server and the provider.

iBGP — when you need to synchronize routing information within a single AS between multiple routers. Relevant with complex topologies, when you have more than one point of presence.

When BGP Is Actually Necessary

There are four scenarios where you can’t do without it.

Your own IP address block. PI addresses (Provider Independent) are addresses that belong to you, not the provider. You can obtain them from a regional registry: RIPE NCC for Europe, ARIN for North America, APNIC for Asia. But obtaining them isn’t enough — they still need to be announced to the internet. Without a BGP session with some provider, these addresses are invisible to anyone. The minimum announcement size is /24 for IPv4, which is 256 addresses. Blocks smaller than this are simply filtered out and rejected by most operators.

Two providers simultaneously (multihoming). One connection goes down — traffic automatically shifts to the other, clients notice nothing. This isn’t the same as a backup connection with a static route: there’s always a pause during switchover there, and manual intervention is often required. BGP handles the switchover in seconds, transparently.

Control over where traffic flows. Outbound through the cheaper connection. Inbound from Europe through the provider that’s closer to your audience there. This is configured through BGP attributes: LOCAL_PREF, MED, AS_PATH prepending. Without BGP, influencing inbound traffic is practically impossible.

Anycast. The same IP address is announced from multiple servers in different locations. Users land on the nearest one. This is exactly how major DNS resolvers and CDN networks operate.

What You Need to Get Connected

An autonomous system number. Obtained from a regional registry. At RIPE NCC, the annual fee for an End User is around 50 EUR plus a one-time registration fee. New ASNs are 32-bit. Processing time — typically 5–10 business days from payment.

Your own IP address block. The same PI addresses from the same registry. Minimum /24 for IPv4 (256 addresses) or /48 for IPv6. If you don’t have your own block, some providers offer PA addresses (Provider Aggregatable) — these are addresses from their pool, it’ll work, but you’ll need to return them and update everything if you change providers.

A BGP session with the provider. On THE.Hosting dedicated servers, BGP setup is available as an additional service. Details — contact support: support@the.hosting or Telegram @thehosting.

A software router on the server. Two options most commonly used:

BIRD 2 — lightweight, fast at processing large routing tables, good documentation. The default choice if there are no specific requirements.

FRRouting (FRR) — supports more routing protocols, syntax similar to Cisco IOS. Convenient for those familiar with Cisco equipment.

Setup: BIRD 2 on Debian/Ubuntu

Installation:

apt update && apt install bird2 -y

Basic config /etc/bird/bird.conf for a single BGP session with a provider:

log syslog all;
router id 203.0.113.1;

ipv4 table master4;

protocol kernel {
    ipv4 {
        export filter { accept; };
    };
}

protocol device {
    scan time 10;
}

protocol bgp upstream {
    local 203.0.113.1 as 65001;
    neighbor 203.0.113.254 as 12345;

    ipv4 {
        import all;
        export filter {
            if net = 198.51.100.0/24 then accept;
            reject;
        };
    };
}

Replace 203.0.113.1 with your server’s IP, 65001 with your ASN, 203.0.113.254 and 12345 — with the provider’s IP and ASN. The export filter passes only your block — everything else is dropped.

Start and check session status:

systemctl enable bird && systemctl start bird
birdc show protocols
birdc show protocols upstream

If the session is established, you’ll see:

Name       Proto      Table      State  Since         Info
upstream   BGP        ---        up     2026-04-03    Established

Accepted routes table:

birdc show route

FRR Setup

apt install frr -y
sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons
systemctl restart frr

Configuration via vtysh:

router bgp 65001
 bgp router-id 203.0.113.1
 neighbor 203.0.113.254 remote-as 12345
 !
 address-family ipv4 unicast
  network 198.51.100.0/24
  neighbor 203.0.113.254 activate
 exit-address-family

Comparison With Alternatives

BGP isn’t always necessary. Here’s an honest comparison:

Static routes with the provider. Works well as long as there’s one provider and no automatic failover requirements. Configured in five minutes. When the connection goes down — you go down with it.

Failover IP. One backup address, switchover on request or automatically via the provider’s API. Simpler than BGP, cheaper than BGP, but there’s no routing control whatsoever.

Provider PA addresses. No need to register an AS or buy a PI block. You’re still dependent on a specific provider — when you leave, the addresses stay with them.

BGP is justified if: availability requirements exceed 99.9%, traffic is 1 Gbps or more and routing matters, you have multiple points of presence, or you need your own IP addresses long-term.

Common Setup Mistakes

Announcing someone else’s IP block. BGP technically lets you announce anything — the system doesn’t automatically verify ownership. Providers protect themselves through RPKI and IRR filters, but these aren’t configured everywhere. Before you start: register your block in the RIPE or ARIN database and create a ROA record in RPKI. This takes an hour but protects both you and other networks.

Accepting a full table without sufficient memory. The full BGP routing table is around 900,000 entries for IPv4, and it keeps growing. Storing it in BIRD or FRR requires at least 2–4 GB of RAM just for routing. If you don’t need the full table — just ask your provider to send only the default route.

No filter on outgoing announcements. Without an explicit filter, the router may start announcing everything it knows to the provider — including routes from other neighbors. This is BGP route leaking, and the consequences can be unpleasant for other networks. Always configure an explicit export filter: pass only your block, drop everything else.

Aggressive timers. Standard keepalive is 60 seconds, holdtime is 180 seconds. On an unstable connection, the session will drop regularly. Timers can be reduced (e.g., 10/30), but ones that are too short will cause constant flapping. Tune to the specific connection.

Frequently Asked Questions

Can you get by without your own ASN? Private ASNs (range 64512–65534) work for BGP sessions within a single provider’s network. For announcing to the public internet, a registered ASN is required — without it, no one will take your routes seriously.

How long does it take to get an ASN and PI addresses from RIPE? With properly prepared documents — 5–10 business days. The main delay is usually in filling out the application, not in the review. Make sure your organization is correctly registered with RIPE NCC as an End User.

BIRD or FRR — which to choose? If you only need BGP and need speed with large routing tables — BIRD 2. If your infrastructure already has Cisco equipment or your team is familiar with that syntax — FRR is more convenient. There’s no meaningful difference in reliability.

Will BGP work on a VPS? Rarely. On most VPS platforms, the hypervisor doesn’t allow the guest machine to manage routing at the provider’s network level. BGP in practice requires a dedicated server. On THE.Hosting dedicated servers, BGP session setup is available as an additional service — contact support for details.

Why is RPKI validation needed? RPKI allows cryptographic proof that you actually have the right to announce your IP block. Without a ROA record, some providers will refuse to accept your routes — and more providers are doing this every year. Setup is done in the RIPE NCC member portal and takes about 20 minutes.

BGP on a THE.Hosting dedicated server is available on request — write to support at support@the.hosting or Telegram @thehosting.

Choose a dedicated server