Your Homelab Can Speak BGP to the World — Announce Your Own IP Prefixes

BGP turns 37 in 2026 without showing its age. The protocol that routes every packet between the 75,000 autonomous systems on the public Internet has remained fundamentally unchanged since RFC 4271 (January 2006), and its longevity rests on one simple principle: each network announces the IP prefixes it knows how to reach, and the best path wins. What changed is that you no longer need to be an ISP to play.

DN42, a parallel internet launched in 2011 and maintained by a community of enthusiasts, crossed 1,800 active ASNs and 12,000 announced prefixes by early 2026. BIRD 2.16, the routing daemon used by DE-CIX, LINX, and the world’s largest Internet exchanges, runs on a Raspberry Pi with 50 MB of RAM. Your homelab can announce a /48 IPv6 prefix on DN42 in an evening, and the path to anycasting your own DNS services or multihoming between two VPS instances is shorter than you think.

Why BGP Belongs in Your Homelab

Home routing usually stops at a default route — anything not on the local network goes to the ISP’s box. BGP breaks that model with three concepts that fundamentally change how you think about a network:

• Your network becomes an autonomous entity. An ASN (Autonomous System Number) identifies your network as a peer, not a consumer of connectivity. It’s the difference between renting your address space and owning it.
• You control your addressing plan. A /48 IPv6 gives you 65,536 /64 subnets, each capable of hosting 18 billion billion addresses. You stop borrowing prefixes from your ISP — you own yours.
• Routing becomes dynamic. If a link goes down, BGP automatically withdraws the route and switches to the backup path, with no intervention and no homegrown failover script required.

These aren’t theoretical concepts. Projects like DN42, ChaosVPN, and NeoNetwork make them accessible without buying a real ASN or an IP block from a RIR (RIPE, ARIN, APNIC). The entry cost is a €5/month VPS or a machine at home that runs 24/7.

DN42 — The Miniature Internet That Gives You a Real ASN

DN42 isn’t a simulator. It’s an operational network with its own ASNs (range 4242420000–4242423999), its own IPv4 prefixes (172.20.0.0/14) and IPv6 prefixes (fd00::/8, from the ULA range), its own whois, RPKI, root DNS servers, and Internet exchanges (IXs). The resemblance to the public Internet is deliberate — DN42 replicates real BGP mechanics without the consequences of a misconfigured announcement.

The onboarding process takes about 30 minutes:

1. Fork the registry at git.dn42.dev/dn42/registry and create your objects: a mntner for authentication, a person for contacts, an aut-num for your ASN, and an inet6num for your /48.
2. Choose a free ASN in the 4242420000-4242423999 range — the explorer lists available numbers.
3. Sign your commit with a PGP or SSH key, open a pull request, and a maintainer validates your objects in 24 to 48 hours.

Once the registry accepts your objects, you are a full autonomous system on DN42. All that’s left is establishing BGP sessions.

Finding Peers on DN42

Peering on DN42 happens over WireGuard tunnels (the de facto standard since 2022) or GRE. The automated registry at dn42.peering.managedo.de matches you with open peers, and bird-lg or Burble’s public looking glass lets you verify your prefixes are visible. Start with two or three peers — a single peer makes your entire network dependent on their availability.

BIRD 2 or FRRouting — Picking Your BGP Daemon

Two implementations dominate the open-source landscape, and the choice depends on your operational philosophy.

BIRD — The IX Router Used by the World’s Largest Exchanges, in 50 MB of RAM

BIRD (Bird Internet Routing Daemon), developed at CZ.NIC, is the routing daemon powering the largest Internet exchanges on the planet. Version 2.16.1 (March 2026) supports BGP, OSPF, RIP, RPKI, BFD, and MPLS. Its configuration is a declarative DSL that reads like code:

# /etc/bird/bird.conf
router id 172.20.1.1;

protocol device {
    scan time 10;
}

protocol kernel kernel_v6 {
    ipv6 { export all; };
}

protocol static static_v6 {
    ipv6;
    route fd00:1921:abcd::/48 unreachable;
}

protocol bgp dn42_peer1 {
    local as 4242421234;
    neighbor fd00:abcd::1 as 4242425678;
    ipv6 {
        import filter {
            if net ~ [fd00::/8+] then accept;
            reject;
        };
        export filter {
            if net = fd00:1921:abcd::/48 then accept;
            reject;
        };
    };
}

BIRD’s strength lies in its memory footprint — 50 MB at steady state with a few hundred routes — and its programmable filtering. The filter blocks are a mini-language with variables, control structures, and functions, enabling complex routing policies without external files. The interactive birdc interface gives direct access to session state, the routing table, and per-prefix details.

Caveat: BIRD’s documentation is dense and its learning curve is steep. Filter syntax errors are reported with a line number, but the error message is often terse.

FRRouting — The Swiss Army Knife of Software Routers

FRRouting (forked from Quagga in 2017, itself forked from GNU Zebra in 1996) takes a different approach: each protocol runs in a separate daemon (bgpd, ospfd, zebra for the RIB), and the configuration uses a Cisco IOS-like syntax. Version 10.2 (February 2026) consolidated the integrated configuration in /etc/frr/frr.conf via the mgmtd daemon.

! /etc/frr/frr.conf
router bgp 4242421234
  neighbor fd00:abcd::1 remote-as 4242425678
  neighbor fd00:abcd::1 description "DN42 Peer 1"
  address-family ipv6 unicast
    neighbor fd00:abcd::1 activate
    network fd00:1921:abcd::/48
    neighbor fd00:abcd::1 route-map DN42-OUT out
  exit-address-family

route-map DN42-OUT permit 10
  match ipv6 address prefix-list MY-PREFIXES

ipv6 prefix-list MY-PREFIXES permit fd00:1921:abcd::/48

FRRouting’s advantage is its ecosystem: if you manage MikroTik, VyOS, Cisco, or Juniper routers professionally, the syntax will feel familiar. The interactive CLI vtysh unifies access to all daemons and retains command history like a shell.

The downside: eight daemons to orchestrate (zebra, bgpd, ospfd, staticd, mgmtd, etc.), a higher memory footprint (~150 MB), and an « integrated » config model that can surprise users accustomed to per-daemon config files.

Verdict: BIRD for a lightweight environment, a single config file, and expressive filtering. FRRouting for a heterogeneous fleet where industrial CLI familiarity matters most.

Anycast and Multihoming — BGP’s Two Killer Features for the Home Network

Once your BGP sessions are active and your prefixes are visible, two use cases emerge naturally.

Anycast: One Service, Multiple Locations, One IP

Anycast means announcing the same prefix from multiple geographic locations. The BGP network routes each packet to the closest instance (closest in terms of the shortest AS-PATH), and if one site goes down, the prefix is automatically withdrawn from the global table — traffic shifts to the remaining site with no DNS change required.

On DN42, anycast is the most immediate practical win:

• Recursive DNS: announce fd00:1921:abcd::53/128 from two VPS instances and your resolver becomes redundant with no floating IP and no keepalived.
• NTP: an anycast NTP server provides a reliable time source even when one node is down.

The BIRD configuration for an anycast service is a single /128 in the export filter:

# In the BGP session's export filter
if net = fd00:1921:abcd::53/128 then accept;

Same prefix announced from two separate servers — BGP handles the rest.

Multihoming: Connecting Your Homelab to Two Providers

Multihoming is BGP’s reason for existing in the real world: connecting a network to two ISPs (or two VPS providers) and failing over automatically when one goes down. In a homelab, the typical scenario is one server at Hetzner and one at OVH, both announcing your /48. If Hetzner experiences an outage — which happens — the prefix withdraws from their BGP sessions and traffic converges to OVH in under 90 seconds.

Full domestic multihoming (two ISP boxes, a real RIPE ASN, and a provider-independent /48) costs roughly €80/year in RIPE fees plus €50/month for a sponsoring LIR. DN42 lets you test the mechanics at zero cost before committing.

Announcing Your /48 IPv6 on DN42 — The Full Recipe

Here’s a working BIRD configuration to announce a /48 IPv6 prefix on DN42, end to end. It assumes a WireGuard tunnel already established with your peer.

Prerequisites: BIRD 2.x installed (apt install bird2 on Debian/Ubuntu), a working WireGuard tunnel with a link-local IPv6 address, an ASN and a /48 validated in the DN42 registry.

File /etc/bird/bird.conf:

log syslog all;
log "/var/log/bird.log" all;

router id 10.0.0.1;   # a unique local IPv4 address — doesn’t affect v6 routing

protocol device {
    scan time 10;
}

# Inject the /48 into the local routing table
protocol static my_prefix {
    ipv6;
    route fd00:1921:abcd::/48 unreachable;
}

# Export to the kernel table so the server itself routes the prefix
protocol kernel kernel_v6 {
    ipv6 {
        import none;
        export all;
    };
}

# BGP session with the DN42 peer
protocol bgp dn42_peer1 {
    local as 4242421234;
    neighbor fd00:abcd::1%wg0 as 4242425678;
    ipv6 {
        import filter {
            # Only accept DN42 prefixes
            if net ~ [fd00::/8+] then accept;
            reject;
        };
        export filter {
            # Only export our /48
            if net = fd00:1921:abcd::/48 then accept;
            reject;
        };
    };
}

Verification:

# BGP session state
birdc show protocols

# Routes received and announced
birdc show route protocol dn42_peer1

# Full routing table
birdc show route

birdc show protocols should display Established for the session. If you see Active or Connect, the WireGuard tunnel likely isn’t working — check wg show and ping the peer’s link-local address.

Once the session is established, use Burble’s looking glass to confirm your /48 appears in the global DN42 routing table. Propagation delay is roughly 30 seconds.

What BGP Doesn’t Replace

BGP solves external routing — it doesn’t replace your existing network tools:

• Internal DNS (AdGuard Home, Pi-hole, Unbound) remains necessary for resolving your service names.
• Reverse proxies (Traefik, Nginx) handle TLS termination and hostname-based HTTP routing — BGP routes IP packets, not HTTP requests.
• VPNs (WireGuard, Tailscale) remain the way to access your network from outside if you’re not announcing prefixes on the public Internet — which is the case for DN42.

BGP is a layer under your services, not an alternative to them. It determines where packets go, not what they carry.

Verdict

Home BGP isn’t a networking vanity project — it’s the logical next step for a homelab that’s grown past five services. If you self-host your email, your cloud, and your DNS, understanding how your packets route outside your local network is the next frontier.

• You’re new to networking: start with DN42 and BIRD on a €5 VPS. One evening is enough to announce your /48 and see your prefix appear in a looking glass — the satisfaction is immediate.
• You already run a multi-site homelab: test anycasting your DNS resolver between two VPS instances. Redundancy without a floating IP fundamentally changes how you think about high availability.
• You’re aiming for real multihoming: DN42 builds the muscle memory before negotiating with a LIR. BGP doesn’t forgive filter mistakes on the public Internet — make them on a network where the worst consequence is a message on IRC.

BGP has been around since 1989 because it does one thing and does it well. Your homelab deserves to be part of it.

References

• DN42 Wiki — Getting Started
• DN42 Wiki — BIRD 2 Configuration
• DN42 Wiki — FRRouting Configuration
• BIRD 2 User’s Guide v2.16.1
• FRRouting Documentation — BGP
• DN42 Registry
• Burble DN42 Explorer
• RFC 4271 — A Border Gateway Protocol 4 (BGP-4)
• RFC 4193 — Unique Local IPv6 Unicast Addresses