BGP at Home: What Happens When You Peer with Your ISP

I have a /48 of IPv6 announced from a box in my house. That is roughly 1.2 billion billion addresses, more than the entire IPv4 internet several times over, sitting behind a single second-hand mini PC that cost less than a decent monitor. It is gloriously absurd, and getting there taught me more about how the internet actually works than a decade of reading RFCs. This is the story of how a hobbyist peers with an upstream, announces their own address space, and joins the roughly hundred thousand independent networks that route the global internet between them.

There is a particular kind of self-hoster who is no longer satisfied with port forwarding and dynamic DNS. They want their own IP addresses — a block that belongs to them, that they announce themselves, that doesn’t change when they switch ISP and doesn’t sit inside someone else’s allocation. They want, in short, to run BGP. I have done this, and I am here to tell you it is equal parts genuinely useful and gloriously over-engineered for a house.

BGP — the Border Gateway Protocol — is how the internet’s independent networks tell each other “to reach these addresses, send traffic my way”. Each of those networks is an Autonomous System with a number, an ASN. When you “peer with your ISP” you stop being a customer who receives a leased address and become a tiny network announcing your own routes. Let’s talk about what that actually takes, because almost everything written about BGP assumes you already work at an ISP.

Why bother at all

The honest answer is that for most homelabs you should not. But there are three reasons the effort pays off, and they are worth stating up front so you can decide whether to keep reading.

The first is provider independence. An IPv6 /48 that you own is yours regardless of who carries your traffic. Switch transit providers, move house, change ISP — your addresses come with you, and nothing downstream renumbers. If you have ever had to re-IP a network because the ISP changed your prefix, you understand why people pay real money to never do that again.

The second is multi-homing. Announce the same prefix to two upstreams and you get failover at the routing layer. If one transit link dies, the internet simply stops hearing your route from that path and keeps reaching you over the other. No NAT gymnastics, no DNS TTL games, no waiting for a dynamic-DNS update to propagate.

The third, and the real reason most of us do it, is understanding. Once you have run a BGP session, watched a full table land in your router, set a ROA and seen your prefix go from invalid to valid in a looking-glass, the internet stops being magic. That is worth a surprising amount.

The paperwork is the hard part

The technical config is an afternoon. The bureaucracy is the project. To do this for real you need three things, all ultimately traceable to a Regional Internet Registry (RIPE, ARIN, APNIC, LACNIC, AFRINIC), usually via a sponsoring LIR (Local Internet Registry):

• An ASN. Your network’s identity. You’ll be assigned a 32-bit number, these days something in the AS21xxxx range from RIPE. This is what other networks see as the origin of your routes.
• A provider-independent (PI) IP block. IPv4 is effectively exhausted, so realistically this means an IPv6 /48 (or a /44 if you ask nicely). Getting PI IPv4 today is expensive and scarce; IPv6 is the sane path, and it is the one I took.
• A transit provider willing to peer with a hobbyist. This is the genuine blocker. Most consumer ISPs will not run BGP with you. You typically need a business circuit, or — far more commonly for hobbyists — you rent a VPS from a provider who does offer BGP sessions and tunnel your announcement out from there.

The honest version of “peering with your ISP” for most people is “peering with a friendly transit provider or a VPS host that supports BGP”, because your average residential ISP wants nothing to do with this. Several budget VPS providers in the homelab community will happily set up a BGP session and route a prefix you bring; that is how the overwhelming majority of home ASNs actually get onto the internet.

Budget for the recurring costs before you start. A sponsoring LIR charges an annual fee to hold your ASN and PI block (typically tens to low hundreds of euros a year, depending on the LIR), and the BGP-capable VPS or transit circuit is a separate line item. This is not free, and the fees do not stop when you lose interest. Treat the standing cost as part of the decision the same way you would weigh the real cost of self-hosting before committing — the electricity-and-time honesty exercise applies just as much to recurring registry fees.

The router config is almost anticlimactic

Once you have an ASN, a block, and an upstream willing to talk, the BGP itself is short. I use BIRD (BIRD 2) on a Linux box; FRR (FRRouting) is the other common choice and is the right pick if you also want OSPF or a more Cisco-like config style. Here’s a minimal BIRD 2 config announcing an IPv6 /48 to one upstream:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# /etc/bird/bird.conf
router id 10.0.0.1;          # any unique 32-bit ID; an internal IPv4 is fine

define MY_ASN = 213000;
define MY_PREFIX = 2001:db8:dead::/48;   # your real /48 goes here

protocol device { }

protocol static {
    ipv6;
    route MY_PREFIX reject;   # pull-up route so we always have something to announce
}

protocol bgp upstream {
    local as MY_ASN;
    neighbor 2001:db8:ffff::1 as 64500;   # your transit provider's router + ASN
    ipv6 {
        import filter {
            accept;            # take everything they send (a full table)
        };
        export filter {
            if net = MY_PREFIX then accept;   # announce ONLY our own prefix
            reject;
        };
    };
}

Note the router id is just a 32-bit identifier — using an RFC 1918 internal address like 10.0.0.1 is completely normal and avoids any confusion about it being routable. The export filter is the part you do not get wrong: it ensures you announce only your own prefix and never accidentally re-announce the full table back at your provider, which is the classic way to make the news for causing a global outage. Filter on the way in and out, and never trust a default that says “accept”.

Bring it up and check the session:

1
2
3
4
5
6
7
8

$ sudo birdc show protocols all upstream
upstream    BGP        ---        up     14:22:09    Established
  Description:    Transit to AS64500
  Routes:         920431 imported, 1 exported, 920431 preferred
  Route change stats: received  rejected  filtered  ignored  accepted
    Import updates:   920500        0         0        69    920431
$ sudo birdc show route count
Total: 920431 of 920431 routes for 920431 networks

If you accept a full table, “920431 imported” is essentially the entire routing table sitting in your router’s RAM — a few hundred megabytes for IPv6, more if you also take IPv4. On a small box you almost certainly do not need it: ask your upstream for a default-route-only feed (0::/0) and let them do the heavy lifting. Take the full table only if you are multi-homed and genuinely want to make per-prefix path decisions.

RPKI, or how not to get filtered into oblivion

Announcing a prefix is no longer enough; the network expects you to prove you’re allowed to. You create a Route Origin Authorisation (ROA) in your RIR portal stating, in effect, “AS213000 is authorised to originate 2001:db8:dead::/48, maximum length /48”. This is signed and published into the RPKI, the cryptographic record of who may announce what.

Without a ROA, RPKI-validating upstreams — which is most large transit networks now — will treat your announcement as unknown (tolerated) rather than valid. Worse, if you fat-finger the ROA so it does not cover what you actually announce, your route becomes invalid and gets dropped on the floor. The sequence matters: set the ROA, wait for it to propagate (minutes to a couple of hours), then announce, and verify with a public looking-glass or an RPKI validator that your prefix shows valid from multiple vantage points. Get this wrong and your prefix simply vanishes from large chunks of the internet while everything looks fine on your own router.

Troubleshooting: what actually goes wrong

In rough order of how often they bit me:

Session stuck in Active or Connect, never Established. The TCP session to your neighbour is not coming up. Check that the neighbour address and remote ASN exactly match what your upstream configured — a mismatched local as or neighbor ... as is the usual culprit. Confirm reachability to the peer address first (ping6 the neighbour), and make sure nothing is blocking TCP port 179. With birdc show protocols all upstream BIRD will often tell you why it is stuck, including ASN mismatches.

Session is Established but you export 0 routes. Your static pull-up route is missing or your export filter never matches. Confirm the prefix exists locally with birdc show route, and check that MY_PREFIX in the filter is byte-for-byte the prefix you defined. A /48 defined but a /47 in the filter will silently export nothing.

Everything is up, you export 1 route, but you are unreachable from the outside. This is almost always RPKI. Check your prefix in a public RPKI validator and a looking-glass; if it reads invalid, your ROA’s max-length or origin ASN is wrong. Fix the ROA, wait for propagation, and re-test. The second most common cause is forgetting reverse-path or firewall rules on the box itself — the route is global, but your host is dropping the traffic.

You leaked the full table back to your upstream. If your export filter is too permissive (or you used export all), you re-announce everything you learned, telling the internet to route through your home box. Your upstream will usually have a prefix-limit that shuts the session down before this becomes everyone’s problem, but do not rely on their safety net — fix your export filter so it matches only your prefix and nothing else.

Your single-homed link dies and you assumed failover. One upstream is not multi-homing. If resilience is the goal, you need a second BGP session to a different provider announcing the same prefix; otherwise BGP buys you ownership, not redundancy.

A good habit, borrowed from chasing routing bugs the same way you’d chase a name-resolution failure: trace the path end to end and stop guessing. The discipline of following exactly what happens when a DNS lookup resolves — checking each hop instead of assuming — is the same discipline that finds a broken BGP session fast.

What you actually get, and what it costs

The benefits are real but specific:

• Provider independence. Change transit and your addresses come with you. No renumbering, ever.
• Multi-homing. Announce to two upstreams and you have automatic failover at the IP layer.
• Reverse-DNS and abuse-contact authority over your own block — genuinely useful if you run mail and want clean PTR records and a real abuse contact.

And the costs: annual LIR/RIR fees, a transit or BGP-VPS arrangement that usually isn’t free, a router with enough RAM to hold a routing table, and the standing responsibility to never fat-finger an announcement and leak routes. None of these go away when the novelty does.

Verdict: who is this actually for?

For 99% of self-hosters, no — Tailscale, a cheap VPS, and dynamic DNS solve every real problem you have for a fraction of the cost and risk, and none of them can take down a stranger’s network at 3am. If your goal is “reach my services from anywhere”, BGP is wildly the wrong tool.

But if you want to genuinely understand how the internet routes, if you value never renumbering again, or if you run a small ISP-adjacent or community-network project, getting an IPv6 /48 and a real ASN is one of the most educational things you can do in networking. Just respect that the moment your prefix is live, a mistake in your export filter is no longer a homelab problem — it’s everyone’s problem. Filter ruthlessly, set your ROAs first, take a default-only feed unless you have a reason not to, and start with IPv6. The IPv4 scarcity that makes this hard for v4 is exactly why v6 is the gift: more address space than you could ever use, announced from a box in your spare room.