A BGP router from a Debian server
Turn a Debian 13 server into a BGP edge router with FRR from apt: two upstream ISPs, import filters and prepending, OSPF to the office core, routes in the Linux kernel, an nftables firewall for the router itself, measured failover, and the reload and write memory traps.
By the end you will be able to:
- Install FRR on Debian, enable only the daemons you need, and manage it with systemd and vtysh
- Configure eBGP to two upstreams with import filters, local preference and AS-path prepending
- Announce your own prefix safely, and give an internal router a default route by OSPF
- Read FRR's routes in the Linux kernel, and protect the router with nftables without breaking BGP or OSPF
- Explain why a one-sided failure costs minutes of lost traffic, and avoid the write memory and reload traps
Prerequisites: BGP Fundamentals, OSPF Fundamentals, nftables and iptables on Debian: host and router firewalls
A plain Debian server can be a BGP router. The routing software is FRRouting (FRR), the same suite the FRR containers in BGP Fundamentals run, and the engine inside VyOS. On Debian it's just a package: apt install frr. The Linux kernel forwards the packets; FRR decides where they go, by talking BGP and OSPF to its neighbours and installing the results in the kernel's routing table.
Why do it this way instead of with an appliance or VyOS? You already know how to run, monitor and back up Debian; the router is one more service on it, configured by one text file, next to the firewall you wrote yourself (nftables and iptables on Debian). It's also the last step of the router in a box path: the same box that does your office's firewall and VPN can announce its own address space.
The lab
The office owns 203.0.113.0/24 and its own AS, 64500. Its edge router, edge, is a Debian 13 machine with two upstream providers: ISP 1 (AS 64501, the primary) and ISP 2 (AS 64502, the backup). Behind it, the office's core router runs OSPF and serves a server LAN, 203.0.113.0/26. On the far side, the two ISPs peer with each other next to a web server at 198.51.100.80, which stands in for the rest of the internet.
What edge must do:
- Learn a default route from both ISPs, and prefer ISP 1.
- Announce the office's /24, and nothing else, to both, with ISP 2's copy made less attractive so incoming traffic prefers ISP 1 too.
- Refuse anything an ISP sends that it shouldn't: private and shared address space, very long prefixes, and above all the office's own addresses.
- Give the core router a default route by OSPF, and learn the server LAN from it.
- Protect itself with a firewall that still lets BGP and OSPF through.
ISP 1 has been set up to misbehave a little: besides its real routes, it announces 100.64.0.0/10 (shared address space) and 203.0.113.128/25, a piece of the office's own prefix.
- Two eBGP sessions. edge peers with both ISPs over /31 links. Each sends a default route and the web server's network; ISP 1 also leaks two routes edge must refuse.
- Announce the office prefix. edge announces 203.0.113.0/24 to both, prepended twice towards ISP 2, so incoming traffic prefers ISP 1 as well.
- OSPF inside. edge gives the core a default route by OSPF and learns the server LAN from it. Zebra installs everything in the Linux kernel.
- End to end, no NAT. The server reaches the web server through core, edge and ISP 1, with its own address. Replies come back by BGP.
- A one-sided link failure. edge's link to ISP 1 fails. edge switches at once; ISP 1 keeps sending replies into the dead link until its hold timer expires: 156.8 s in the lab.