Bringing up your first BGP session on GetVPS

BGP feels arcane until you've done it once. Then it feels obvious. This walkthrough takes you from "I have an ASN and a prefix" to "my route is visible on a public looking glass," using a GetVPS session as the upstream.

What you need

1. Your own ASN. Apply via your local RIR (RIPE, ARIN, APNIC, etc.) or a sponsoring LIR. Cost varies; expect a few hundred per year.
2. Your own prefix, IPv4 or IPv6. Smallest accepted on the public internet is /24 (IPv4) or /48 (IPv6).
3. A route object in the appropriate IRR (RIPE, ARIN, RADB) tying your prefix to your ASN. Operators filter on this.
4. RPKI ROA for the prefix, signing your ASN as origin. Optional but increasingly required.
5. A GetVPS plan in a location that supports BGP sessions.

Items 1, 2, and 5 are hard requirements: without them there is no session to bring up at all. Item 3 bites later: without a route object the session comes up, but your announcement is filtered everywhere. The ROA is the one exception. The session works without it, but more networks drop or deprioritize announcements without valid RPKI every year, so sort it sooner rather than later.

Bring the session up via the self-service portal

No ticket queue. The GetVPS control panel has a BGP self-service portal that:

1. Asks for your ASN.
2. Sends a verification code to the email address on your ASN's WHOIS contact. This is how we confirm you actually control the ASN, not just claim it.
3. Once verified, lets you provision sessions against your VPS, set the prefixes you intend to announce, and download the resulting neighbour configuration.

What you'll get back from the portal:

• The neighbour IPv4 / IPv6 address
• Our ASN
• Your local BGP source addresses

Make sure the email on your ASN's WHOIS record is one you can read before you start, otherwise you can't complete verification.

Check the session source addresses

The session only establishes if the local BGP source addresses the portal handed you are actually bound on the VPS. In most cases they are simply your VPS's existing primary addresses, so check before touching anything (substitute your interface name if it isn't eth0; ip -br link lists them):

ip addr show dev eth0

If both the IPv4 and IPv6 source addresses from the portal are listed, move on. If one is missing, add it, using the exact address and prefix length the portal shows:

sudo ip addr add 198.51.100.1/24 dev eth0
sudo ip addr add 2001:db8:ffff::1/64 dev eth0

Those commands don't survive a reboot. To persist them, add the addresses to the addresses: list under the interface in whichever YAML file in /etc/netplan/ defines it. A word of caution before you apply it: this file defines your VPS's primary network interface, and a syntax or address mistake takes the machine off the network and locks you out. Use sudo netplan try rather than netplan apply; it rolls the change back automatically unless you confirm it within 120 seconds.

Install bird2

bird is the easiest modern BGP daemon. FRR is fine too; the principles are the same.

sudo apt update && sudo apt install -y bird2

Minimal config

This config:

• Speaks BGP IPv4 and IPv6 to the GetVPS router
• Imports nothing (we only want to send routes, not learn them, in this first pass)
• Exports a single static prefix you own

If bird is already configured on this machine, back up the current file first, because the next step overwrites it: sudo cp /etc/bird/bird.conf /etc/bird/bird.conf.bak.

Open /etc/bird/bird.conf and replace its contents with the following. That is the config path the Ubuntu bird2 package uses: the systemd unit starts the daemon without a -c flag, so it reads that default. If you want to confirm on your own system, systemctl cat bird shows the ExecStart line, and any explicit -c path there is the file to edit instead.

One caution before you paste this in. Until you put an address from this prefix on the VPS (the final section does exactly that), any traffic the internet sends to the prefix via GetVPS is dropped on arrival, because nothing on the VPS terminates it yet. Do not do this with a prefix that is live somewhere else; use one that isn't carrying production traffic.

router id 198.51.100.1;

protocol device {}

protocol static static_announce4 {
    ipv4;
    route 203.0.113.0/24 unreachable;
}

protocol static static_announce6 {
    ipv6;
    route 2001:db8::/48 unreachable;
}

filter announce_v4 {
    if net = 203.0.113.0/24 then accept;
    reject;
}

filter announce_v6 {
    if net = 2001:db8::/48 then accept;
    reject;
}

protocol bgp upstream4 {
    local as 65530;            # your ASN
    source address 198.51.100.1;       # the local IPv4 source the portal issued
    neighbor 198.51.100.254 as 65000;  # GetVPS upstream
    ipv4 {
        import none;
        export filter announce_v4;
    };
}

protocol bgp upstream6 {
    local as 65530;
    source address 2001:db8:ffff::1;   # the local IPv6 source the portal issued
    neighbor 2001:db8:ffff::254 as 65000;
    ipv6 {
        import none;
        export filter announce_v6;
    };
}

Replace addresses, ASNs, and the prefixes you actually own. The source address lines matter: without them bird lets the kernel pick a source, and if the portal issued you a source address that isn't the VPS's primary one, the session attempts go out from the wrong IP and sit in Active forever. Use the local source addresses the portal issued. The "unreachable" static is intentional: at this stage we just want to confirm the announcement reaches the upstream. We'll route it properly once the session is verified.

Allow BGP through the firewall

BGP runs over TCP port 179. Ubuntu ships with ufw inactive, so if you've never enabled a host firewall there's nothing to do here. If you do run ufw, allow both neighbour addresses before starting bird, or the session will sit in Active forever:

sudo ufw allow from 198.51.100.254 to any port 179 proto tcp
sudo ufw allow from 2001:db8:ffff::254 to any port 179 proto tcp

Bring it up

Before you run this: restarting bird with this config starts announcing your prefix to the entire internet. If the prefix is already announced from another site or provider, the unreachable static can pull live traffic toward GetVPS and blackhole it worldwide. Only proceed if the prefix isn't serving production traffic anywhere, or do the first run with a dedicated test prefix.

sudo systemctl restart bird
sudo birdc show protocols

You're looking for Established against both upstream4 and upstream6. If you see Active or OpenSent, the session is failing. Check:

• Local interface has the BGP source address bound
• No firewall dropping TCP/179
• Local ASN matches what you registered with us

Once Established, confirm the upstream sees your route:

sudo birdc show route protocol upstream4

Confirm propagation

Wait two minutes. Hit a public looking glass like lg.he.net or bgp.tools and search your prefix. You should see your ASN as origin, transiting GetVPS's ASN.

If not visible globally:

• Is your ROA in place? Check at bgp.tools/prefix/...
• Is your IRR route object correct?
• Are you announcing a prefix smaller than /24? It will be filtered.

Now route real traffic

Leave the unreachable statics in place. They are what generates the announcement, and because this config has no kernel or direct protocol, bird never installs them in the VPS's forwarding table, so they can't drop packets locally. Delete them and bird has nothing left to export, which means it withdraws your prefix from the internet.

To actually terminate traffic, put an address from the prefix on the loopback:

sudo ip addr add 203.0.113.1/32 dev lo
sudo ip addr add 2001:db8::1/128 dev lo

Persist that across reboots with a netplan file. Create /etc/netplan/60-bgp-loopback.yaml:

network:
  version: 2
  ethernets:
    lo:
      match:
        name: lo
      addresses:
        - 203.0.113.1/32
        - 2001:db8::1/128

Then tighten its permissions and apply it. Same caution as before: netplan try re-applies the whole netplan config, including your primary interface, so a mistake anywhere in /etc/netplan/ can cut you off. try gives you the automatic rollback:

sudo chmod 600 /etc/netplan/60-bgp-loopback.yaml
sudo netplan try

No bird change is needed. The export filters already match the whole prefix, so the announcement stays exactly as it was. On the VPS, confirm the route is still being exported:

sudo birdc show route export upstream4

Then, from a machine outside GetVPS (pinging from the VPS itself only tests the loopback), ping the new address:

ping 203.0.113.1
ping -6 2001:db8::1

If both pings answer, traffic to your prefixes is arriving over the GetVPS session and being terminated on your VPS, on both address families.

That's BGP. Demystified, mostly. The hard parts are the paperwork: get the ASN, the prefix, the IRR object, and the ROA right, and the technical config takes ten minutes.