running bgp at home, which i did not need to do

I run BGP at home now. I want to be clear up front that I did not need to. My network has, at a generous count, three subnets and a partridge. Static routes would do the job and I could go to bed. But I keep bumping into BGP at work in a hand-wavy way, the way you understand a thing well enough to nod in meetings and not well enough to fix it, and that gap had started to annoy me.

So the homelab became the lab. The goal was simple: have two routers learn each other's networks dynamically, watch the sessions come up, and break it on purpose until the failure modes stopped surprising me.

the setup

Two Linux boxes running BIRD. Not FRR, not Quagga, just BIRD, because the config is readable and the project is sensible. Each box owns a couple of internal networks and I gave them private AS numbers out of the 64512 range.

The config that actually matters is small. On the first router:

router id 10.0.0.1;

protocol bgp peer1 {
    local as 65001;
    neighbor 10.0.0.2 as 65002;
    import all;
    export all;
}

protocol direct {
    interface "eth*";
}

The second is the mirror of it: its own AS, the neighbour pointing back, the same import and export. import all; export all; is the lab-grade setting that you would never run in anger, but for learning it gets the routes moving so you can see the mechanism before you start filtering.

Bring both up, run birdc show protocols, and there it is: the session climbing through its states and settling on Established. Then birdc show route and the neighbour's networks have appeared in the table, learned, not typed. The first time that happened I sat back like I had invented something. I had not. Millions of routers do this every second. But I had finally seen it.

what it actually taught me

The protocol is the easy part. The session comes up or it does not. The education was everywhere around it.

• It is a TCP session on port 179. If the session will not establish, half the time it is a firewall, not BGP. I spent a good twenty minutes blaming my config before noticing my own nftables ruleset was eating the connection.
• Hold timers are unforgiving in a good way. Pull a cable and the route does not vanish instantly. It waits for the hold timer to expire, then withdraws. Watching that delay made the real-world failure stories from work click into place.
• Export policy is the whole game. export all is fine until it is a loop or a leak. The reason every BGP horror story you have ever read involves a bad announcement is that the protocol does exactly what you tell it, very efficiently.

Will I keep it? Probably not for routing. Static routes are still the right answer for three subnets and a partridge. But the lab is staying up, because the next thing I want to break on purpose is route reflection, and I would rather learn that here than in a meeting.

The point was never the network. The point was turning a thing I could nod about into a thing I could draw on a whiteboard. Mission accomplished, and nobody's production traffic was harmed.