Let me be honest about the premise. There is no reason to run BGP in a home network. None. A home has, what, two routers if you're being ambitious, a flat set of subnets, and a single uplink to your ISP. Static routes would do the job and never page you. I ran BGP anyway, because I wanted to actually understand the protocol rather than nod along in design reviews, and there is no better teacher than breaking your own internet.
the setup
I had two small boxes I wanted to act as routers: one terminating the WAN, one sitting deeper in the lab handling a couple of VLANs and the lab storage network. I wanted traffic to find its way between subnets without me hand-maintaining a static routing table on each box every time I added a VLAN. That's the honest justification, and it's thin, but it's real enough.
I used BIRD. Quagga was the other obvious choice, but BIRD's config language is clean, it's well documented, and it doesn't try to pretend it's a Cisco. Each router gets a private AS number out of the 64512 to 65534 range, and they peer over the link between them.
Here's the shape of the config on one side. Nothing exotic:
router id 10.0.0.1;
protocol kernel {
persist;
scan time 20;
export all;
}
protocol device {
scan time 10;
}
protocol bgp peer1 {
local as 65001;
neighbor 10.0.0.2 as 65002;
import all;
export all;
}
The kernel protocol is the bit that matters and the bit I underestimated. BGP itself just exchanges routes between BIRD instances. It does nothing to your actual forwarding unless you explicitly export those learned routes into the kernel routing table. The first evening I had two routers cheerfully peered, exchanging routes, agreeing on everything, and absolutely no traffic flowing between subnets, because I hadn't told BIRD to push anything into the kernel. The protocol was working perfectly. The network was not. Those are different things, and conflating them cost me an hour.
the things it actually taught me
The first one is that BGP is a state machine, and you can watch it move. birdc show protocols all peer1 walks you through Idle, Connect, Active, OpenSent, OpenConfirm, Established. When a peering won't come up, the state tells you roughly where it's stuck. Stuck in Active usually means it can't reach the neighbour at all. Stuck flapping between Established and back means something is resetting the session, often an MTU or a firewall problem on the path. I'd read about these states a dozen times and never internalised them until I sat watching one refuse to leave Connect because I'd fat-fingered the neighbour address.
The second is that "import all; export all" is a loaded gun, and in any real deployment you'd never write it. In the lab it's fine because I trust both ends, they're both me. But it drove home why route filtering exists. Without policy, every route either side knows gets handed to the other, and the moment you connect to something you don't fully control, that's how you leak routes or accept ones you shouldn't. The reason real BGP configs are pages of filters isn't bureaucracy. It's that the default is to trust your neighbour completely, and you almost never should.
The third, and the one I'll keep, is graceful failure. I added a second path between the two boxes and pulled a cable to watch what happened. BGP noticed the session drop, withdrew the routes that depended on it, and traffic settled onto the other path. Not instantly, there's a hold timer, thirty seconds by default, but it happened on its own without me touching anything. That's the actual promise of a routing protocol over static routes: the network reconverges when topology changes, and you find out about it from a graph rather than a phone call.
was it worth it
For the home network, no. I've since torn most of it out, because the failure modes of BGP are more interesting than the failure modes of two static routes, and "more interesting" is not a property you want in the thing your household depends on for Netflix. The complexity earns its keep at scale, with many routers and many paths and policy that genuinely needs expressing. Two boxes in a cupboard is not that.
But as a way to learn the protocol it was excellent, precisely because I was the one who had to fix it when it broke. Reading about the FSM is one thing. Watching a session sit in Active because you forgot a route to the neighbour, that sticks. If you've got a couple of spare boxes and an evening, peer them, break it on purpose, and watch the states. You'll understand it far better than any diagram managed to make me.