A BIRD BGP configuration for BYOIP is shorter than most people expect: one static route for your prefix, one export filter that lets only that prefix out, and one BGP session to your provider. Getting those three right, and adding the safety limits around them, is what separates a clean announcement from a route leak with your ASN on it.
This guide walks through a working BIRD 2 configuration for announcing your own IPv4 /24 from a dedicated server, what each block does, how to check the session and the announcement, how to add a second provider, and the paperwork and costs on our side. It assumes you hold an ASN and a /24, or are about to; if you do not have an ASN, you can skip BGP entirely and have us announce your /24 for you.
What you need before writing a BIRD BGP configuration
- An ASN and an IPv4 /24. A /24 is the smallest IPv4 prefix most networks accept from the global table. Your ASN and prefix are registered with your regional internet registry, usually RIPE NCC in Europe.
- Route authorisation. A RPKI ROA for the /24 naming your ASN as origin, with a maximum length of /24, and ideally an IRR route object as well. Many networks drop RPKI-invalid routes, so a missing or wrong ROA is the most common reason an announcement goes nowhere. Our LOA, ROA and route object guide walks through the RIPE Database side.
- A signed LOA. A letter of authorisation from the prefix holder that lets the upstream accept and propagate your prefix.
- Session details from the provider. Your and their session addresses, their ASN, and whether they send you a default route, a full table or nothing. On Noded these are agreed when your session is set up.
- A server whose port is yours. We offer BGP sessions only on dedicated servers, not on a VPS that shares a node uplink with other customers.
The examples use documentation values: AS64500 for your ASN, 198.51.100.0/24 as your prefix, and 203.0.113.0/31 as the session link. Replace them with your own.
Install BIRD 2 on the server
Debian and Ubuntu package BIRD 2 as bird2. The configuration file is /etc/bird/bird.conf and the control socket is used by birdc:
apt install bird2
systemctl enable --now bird
birdc show statusBIRD 3 has also been released, with multithreading aimed at route servers and large tables. For one session and one prefix, BIRD 2 is the well-trodden choice; read the BIRD 3 release notes before you move a working configuration across.
A BIRD BGP configuration for one /24
This is a complete /etc/bird/bird.conf for announcing one /24 to one upstream and accepting nothing back. It extends the example on our BGP and BYOIP page with explicit filters and limits:
# /etc/bird/bird.conf (BIRD 2)
log syslog all;
router id 203.0.113.1; # your end of the session
protocol device {}
# Keeps the /24 in BIRD's table so it can be announced.
# Not exported to the kernel, so it never affects local routing.
protocol static own_prefix {
ipv4;
route 198.51.100.0/24 unreachable;
}
protocol kernel {
ipv4 { export none; }; # the server keeps its existing default route
}
filter export_own {
if net = 198.51.100.0/24 then accept;
reject;
}
protocol bgp noded {
description "AS60982 upstream";
local 203.0.113.1 as 64500; # your session IP and ASN
neighbor 203.0.113.0 as 60982; # our end, given at setup
hold time 90;
graceful restart on;
ipv4 {
import none; # accept nothing back
export filter export_own; # announce only your /24
};
}What each part does:
router idmust be unique per BGP speaker. Your session address is a sensible choice.protocol staticputs the /24 into BIRD's routing table as an unreachable route. BGP can only announce what is in that table. The kernel protocol exports nothing, so this placeholder route never lands in the server's own routing table.filter export_ownis the line that matters most. It accepts exactly your /24 and rejects everything else. Without an explicit filter, a change elsewhere in the file can make BIRD announce routes you never meant to, which is how small networks leak routes.import nonefits a single-homed server: it already has a default route through its normal gateway, so it needs nothing from the session. Always set import and export explicitly rather than relying on defaults.
If the session sends you a default route
Some setups use the BGP default route instead of a static gateway. Accept only that, cap the count, and install it into the kernel:
protocol kernel {
ipv4 {
export filter { if net = 0.0.0.0/0 && source = RTS_BGP then accept; reject; };
};
}
protocol bgp noded {
# ... same as above ...
ipv4 {
import filter { if net = 0.0.0.0/0 then accept; reject; };
import limit 10 action disable;
export filter export_own;
};
}The import limit shuts the session if the neighbour suddenly sends far more than expected. It is cheap insurance on any eBGP session.
Using the addresses on the server
The announcement brings traffic for the /24 to your end of the session; the server then has to own the addresses. For services on the host itself, add them to the loopback interface:
ip addr add 198.51.100.1/32 dev lo
ip addr add 198.51.100.2/32 dev loMake them permanent in your network configuration (netplan, ifupdown or systemd-networkd). If the server runs virtual machines or containers with addresses from the /24, put the addresses on a bridge or route them to the guests instead. Bind each service to the address it should answer on, so outgoing connections leave from your own space where that matters, for example for mail or for allow-lists at partners.
How do you check the session and the announcement?
Test the file before loading it, then load it without restarting BIRD:
bird -p -c /etc/bird/bird.conf # parse only, exits on errors
birdc configure # apply the new configuration
birdc show protocols all noded # state should read Established
birdc show route export noded # must list only 198.51.100.0/24The last command is the one to run after every change: if it lists anything besides your prefix, fix the filter before anything else. Then check from outside. Public route collectors, such as RIPE RIS through RIPEstat, and bgp.tools show whether the /24 is visible, which origin AS it carries and whether RPKI rates it valid. Propagation takes a few minutes. Our looking glass runs ping, traceroute and MTR from our locations, which is a quick way to confirm traffic toward your new addresses actually arrives.
Adding a second provider
Announcing the same /24 from two networks keeps it reachable when one fails. Each provider gets its own protocol bgp block with the same export filter. To make one path the backup, prepend your own ASN on that session so the rest of the internet prefers the shorter path:
filter export_own_prepend {
if net = 198.51.100.0/24 then {
bgp_path.prepend(64500);
accept;
}
reject;
}With two upstreams, replies can leave on a different interface than the request arrived on. Set reverse-path filtering to loose mode (net.ipv4.conf.all.rp_filter = 2), or the kernel may drop valid traffic. Both providers need your LOA, and your ROA covers both because it authorises your ASN, not a provider. Our multi-homing guide covers the design choices.
What BYOIP and a BGP session cost on Noded
BGP sessions and BYOIP are order options on our dedicated servers, in any of our 11 countries, and every location announces from AS60982. AS60982 announces IPv4 only; IPv6 BYOIP is not offered. Prices are in euros, excluding VAT, from our live catalogue:
| Item | What you get | Price |
|---|---|---|
| Dual Xeon E5, 16 cores / 32 threads | 128 GB RAM, 240 GB SSD, 1 Gbps unmetered port | €209 a month |
| Dual Xeon E5, 28 cores / 56 threads | 128 GB RAM, 240 GB SSD, 1 Gbps unmetered port | €229 a month |
| Dual Xeon E5, 44 cores / 88 threads | 256 GB RAM, 240 GB SSD, 1 Gbps unmetered port | €299 a month |
| Own ASN + /24 subnet | A BGP session between your ASN and AS60982, as in this guide | €50 one-time |
| Own /24 subnet | We announce your /24 from AS60982; no ASN or BIRD needed | €25 one-time |
| /24 from our address space | 253 usable IPv4 addresses, announced from AS60982 | €200 a month |
| /29, /28 or /27 subnet | 5, 13 or 29 usable addresses from our space | €8, €26 or €58 a month |
Each BYOIP option covers one /24. Every dedicated server includes 100 Gbps of always-on Layer 3/4 DDoS protection, and the full range of configurations is on the dedicated servers page.
Questions people ask
Do I need my own ASN to announce my IP block?
No. With the "Own /24 subnet" option we announce your /24 from AS60982 and you need no BGP speaker at all. Your ROA then has to name AS60982 as the origin. Run BIRD only when you want your own ASN and routing policy.
Why does my BIRD session show Established but my prefix is not visible?
Check birdc show route export first: if the /24 is not listed, the static route or filter is wrong. If it is listed, look at RPKI and IRR: an origin AS that does not match the ROA makes the route invalid, and many networks drop it.
Can I announce a prefix smaller than a /24?
You can configure it, but most networks filter IPv4 prefixes longer than /24, so it will not be reachable from much of the internet. Plan around a full /24.
Can I run BGP on a VPS?
Not on ours. A BGP session carries your routing, so we offer it only on dedicated servers whose CPU, NIC and port are yours alone. For a few extra addresses on a VPS, add IPv4 at checkout instead.
Should I use BIRD 2 or BIRD 3?
For a single session and one prefix, either works; BIRD 2 is the packaged default on many distributions and has the most examples. Check the BIRD 3 release notes before migrating an existing file.
Bringing your space to Noded
Order a dedicated server, pick "Own ASN + /24 subnet" at checkout, and send the signed LOA with your ROA in place. We agree the session addresses with you, you paste them into the configuration above, and birdc show protocols should read Established within minutes. Make birdc show route export part of every change you make, and keep your ROA in step with every provider that announces the prefix. The operator behind AS60982 is X ZONE IT SRL, an EU company, and all eight IPv4 /24s that AS60982 announces carry valid RPKI ROAs. Our RPKI explainer covers why that matters for your prefix too.