EN
en direct

Votre homelab peut parler BGP avec le reste du monde — annoncez vos propres préfixes IP

DN42 compte plus de 1 800 numéros d’AS et 12 000 préfixes annoncés en avril 2026. BIRD 2.16 et FRRouting 10.2 rendent le peering BGP accessible depuis un simple conteneur Docker, et un /48 IPv6 s’annonce en moins de 30 lignes de configuration.

Votre homelab peut parler BGP avec le reste du monde — illustration ETTAYEB

BGP fête ses 37 ans en 2026 sans avoir pris une ride. Le protocole qui achemine chaque paquet entre les 75 000 systèmes autonomes de l’Internet public est resté fondamentalement le même depuis RFC 4271 (janvier 2006), et sa longévité tient à un principe simple : chaque réseau annonce les préfixes IP qu’il sait router, et le meilleur chemin gagne. Ce qui a changé, c’est que vous n’avez plus besoin d’être un FAI pour y jouer.

DN42, un internet parallèle lancé en 2011 et maintenu par une communauté de passionnés, a dépassé les 1 800 ASN actifs et les 12 000 préfixes annoncés début 2026. BIRD 2.16, le démon de routage utilisé par DE-CIX, LINX et les plus gros points d’échange mondiaux, tourne sur un Raspberry Pi avec 50 Mo de RAM. Votre homelab peut annoncer un /48 IPv6 sur DN42 en une soirée, et le chemin vers un anycast de vos propres services DNS ou un multihoming entre deux VPS est plus court que vous ne le pensez.

Pourquoi BGP mérite une place dans votre homelab

Le routage domestique s’arrête généralement à une route par défaut — tout ce qui n’est pas le réseau local part vers la box de l’opérateur. BGP casse ce modèle en trois concepts qui changent la façon de penser un réseau :

  • Votre réseau devient une entité autonome. Un ASN (Autonomous System Number) identifie votre réseau comme un pair à part entière, pas comme un simple consommateur de connectivité. C’est la différence entre être locataire et propriétaire de son adressage.
  • Vous maîtrisez votre plan d’adressage. Un /48 IPv6 vous donne 65 536 sous-réseaux /64, chacun capable d’accueillir 18 milliards de milliards d’adresses. Vous n’empruntez plus les préfixes de votre FAI — vous possédez les vôtres.
  • Le routage devient dynamique. Si un lien tombe, BGP retire automatiquement la route et bascule sur le chemin alternatif, sans intervention, sans script de failover maison.

Ces concepts ne sont pas théoriques. Des projets comme DN42, ChaosVPN ou NeoNetwork les rendent accessibles sans acheter un ASN réel ni un bloc d’adresses chez un RIR (RIPE, ARIN, APNIC). Le coût d’entrée est un VPS à 5 €/mois ou une machine qui tourne 24/7 chez vous.

DN42 — l’internet miniature qui vous donne un vrai ASN

DN42 n’est pas un simulateur. C’est un réseau opérationnel avec ses propres ASN (plage 4242420000–4242423999), ses propres préfixes IPv4 (172.20.0.0/14) et IPv6 (fd00::/8, en ULA), son propre whois, son RPKI, ses serveurs DNS racine et ses points d’échange (IX). La ressemblance avec l’Internet public est voulue : DN42 est conçu pour reproduire les mécanismes du « vrai » BGP sans les conséquences d’une annonce mal configurée.

Le processus d’entrée est une formalité maîtrisable en 30 minutes :

  1. Forkez le registre git.dn42.dev/dn42/registry et créez vos objets : un mntner pour l’authentification, un person pour les contacts, un aut-num pour votre ASN, et un inet6num pour votre /48.
  2. Choisissez un ASN libre dans la plage 4242420000-4242423999 — l’explorateur explorer.burble.com liste les numéros disponibles.
  3. Signez votre commit avec une clé PGP ou SSH, ouvrez une pull request, et un mainteneur valide vos objets en 24 à 48 heures.

Une fois le registre accepté, vous êtes un système autonome à part entière sur DN42. Il ne reste plus qu’à établir des sessions BGP.

Trouver des pairs sur DN42

Le peering sur DN42 se fait via des tunnels WireGuard (le standard de facto depuis 2022) ou GRE. Le registre automatique dn42.peering.managedo.de vous met en relation avec des pairs ouverts, et bird-lg ou le looking glass public de Burble vous permettent de vérifier que vos préfixes sont bien visibles. Commencez par deux ou trois pairs — un seul pair rend votre réseau dépendant de sa disponibilité.

BIRD 2 ou FRRouting — choisir son démon BGP

Deux implémentations dominent le paysage open source, et le choix dépend de votre philosophie opérationnelle.

BIRD — le routeur des IX mondiaux, en 50 Mo de RAM

BIRD (Bird Internet Routing Daemon), développé au CZ.NIC, est le démon de routage derrière les plus gros points d’échange de la planète. La version 2.16.1 (mars 2026) supporte BGP, OSPF, RIP, RPKI, BFD et MPLS. Sa configuration est un DSL déclaratif qui ressemble à du code :

plaintext
# /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;
        };
    };
}

La force de BIRD tient à sa consommation mémoire50 Mo en régime de croisière avec quelques centaines de routes — et à son filtrage programmable. Les filter sont un mini-langage avec variables, structures de contrôle et fonctions, ce qui permet d’écrire des politiques de routage complexes sans fichier externe. L’interface interactive birdc donne un accès direct à l’état des sessions, à la table de routage et au détail de chaque préfixe.

Piège : la documentation de BIRD est dense et sa courbe d’apprentissage raide. Les erreurs de syntaxe dans un filter sont signalées avec un numéro de ligne, mais le message d’erreur est souvent lapidaire.

FRRouting — le couteau suisse des routeurs logiciels

FRRouting (fork de Quagga en 2017, lui-même fork de GNU Zebra en 1996) adopte une approche différente : chaque protocole tourne dans un démon séparé (bgpd, ospfd, zebra pour le RIB), et la configuration utilise une syntaxe proche de Cisco IOS. La version 10.2 (février 2026) a consolidé la configuration intégrée dans /etc/frr/frr.conf via le démon mgmtd.

plaintext
! /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

L’avantage de FRRouting est l’écosystème : si vous administrez des routeurs MikroTik, VyOS, Cisco ou Juniper dans votre vie professionnelle, la syntaxe vous sera familière. Le CLI interactif vtysh unifie l’accès à tous les démons et conserve l’historique des commandes comme un shell.

Le revers : huit démons à orchestrer (zebra, bgpd, ospfd, staticd, mgmtd, etc.), une empreinte mémoire plus élevée (~150 Mo), et une configuration « intégrée » qui peut surprendre les habitués des fichiers par démon.

Verdict : BIRD pour un environnement léger, un seul fichier de configuration et un filtrage expressif. FRRouting pour un parc hétérogène où la familiarité avec le CLI industriel prime.

Anycast et multihoming — les deux super-pouvoirs du BGP domestique

Une fois vos sessions BGP actives et vos préfixes visibles, deux cas d’usage émergent naturellement.

Anycast : un service, plusieurs localisations, une seule IP

L’anycast consiste à annoncer le même préfixe depuis plusieurs emplacements géographiques. Le réseau BGP achemine chaque paquet vers l’instance la plus proche (au sens du plus court AS-PATH), et si un site tombe, le préfixe est retiré automatiquement de la table globale — le trafic bascule sur le site restant sans changement de configuration DNS.

Sur DN42, l’anycast est le cas d’usage le plus immédiat :

  • DNS récursif : annoncez fd00:1921:abcd::53/128 depuis deux VPS et votre résolveur devient redondant sans IP flottante ni keepalived.
  • NTP : un serveur de temps anycasté offre une source fiable même si un nœud est indisponible.

La configuration BIRD pour un service anycasté tient en un préfixe /128 dans le filtre d’export :

plaintext
# Dans le filter export de la session BGP
if net = fd00:1921:abcd::53/128 then accept;

Le même préfixe annoncé depuis deux serveurs distincts — BGP fait le reste.

Multihoming : connecter son homelab à deux fournisseurs

Le multihoming est la raison d’être du BGP dans le monde réel : connecter un réseau à deux FAI (ou deux VPS) et basculer automatiquement si l’un tombe. Dans un homelab, le scénario typique est un serveur chez Hetzner et un autre chez OVH, chacun annonçant votre /48. Si Hetzner subit une panne — ce qui arrive — le préfixe est retiré de leurs sessions BGP et le trafic converge vers OVH en moins de 90 secondes.

Le multihoming domestique complet (deux box opérateurs, un vrai ASN RIPE et un /48 PI) coûte environ 80 €/an de frais RIPE et 50 €/mois de LIR sponsor. DN42 permet de tester la mécanique à zéro euro avant de franchir le pas.

Annoncer son /48 IPv6 sur DN42 — la recette complète

Voici une configuration BIRD fonctionnelle pour annoncer un /48 IPv6 sur DN42, de bout en bout. Elle suppose un tunnel WireGuard déjà établi avec votre pair.

Prérequis : BIRD 2.x installé (apt install bird2 sur Debian/Ubuntu), un tunnel WireGuard fonctionnel avec une adresse IPv6 link-local, un ASN et un /48 validés dans le registre DN42.

Fichier /etc/bird/bird.conf :

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

router id 10.0.0.1;   # une IPv4 locale unique — ne change rien au routage v6

protocol device {
    scan time 10;
}

# Injection du /48 dans la table de routage locale
protocol static my_prefix {
    ipv6;
    route fd00:1921:abcd::/48 unreachable;
}

# Export vers la table kernel pour que le serveur lui-même route le préfixe
protocol kernel kernel_v6 {
    ipv6 {
        import none;
        export all;
    };
}

# Session BGP avec le pair DN42
protocol bgp dn42_peer1 {
    local as 4242421234;
    neighbor fd00:abcd::1%wg0 as 4242425678;
    ipv6 {
        import filter {
            # N’accepter que les préfixes DN42
            if net ~ [fd00::/8+] then accept;
            reject;
        };
        export filter {
            # N’exporter que notre /48
            if net = fd00:1921:abcd::/48 then accept;
            reject;
        };
    };
}

Vérification :

bash
# État de la session BGP
birdc show protocols

# Routes reçues et annoncées
birdc show route protocol dn42_peer1

# Table complète
birdc show route

Le birdc show protocols doit afficher Established pour la session. Si vous voyez Active ou Connect, le tunnel WireGuard n’est probablement pas fonctionnel — vérifiez wg show et le ping sur l’adresse link-local du pair.

Une fois la session établie, utilisez le looking glass de Burble pour confirmer que votre /48 apparaît dans la table de routage DN42 globale. Le délai de propagation est de l’ordre de 30 secondes.

Ce que BGP ne remplace pas

BGP résout le routage externe — il ne remplace pas vos outils réseau existants :

  • Le DNS interne (AdGuard Home, Pi-hole, Unbound) reste nécessaire pour résoudre les noms de vos services.
  • Le reverse proxy (Traefik, Nginx) gère le TLS et le routage HTTP par nom d’hôte — BGP route des paquets IP, pas des requêtes HTTP.
  • Le VPN (WireGuard, Tailscale) reste le moyen d’accéder à votre réseau depuis l’extérieur si vous n’annoncez pas vos préfixes sur l’Internet public — ce qui est le cas pour DN42.

BGP est une couche sous vos services, pas une alternative à ceux-ci. Il détermine par où passent les paquets, pas ce qu’ils contiennent.

Verdict

Le BGP domestique n’est pas un caprice de réseau — c’est la suite logique d’un homelab qui dépasse les cinq services. Si vous auto-hébergez votre mail, votre cloud et votre DNS, comprendre comment vos paquets sont routés à l’extérieur de votre réseau local est la prochaine frontière.

  • Vous débutez le réseau : commencez par DN42 avec BIRD sur un VPS à 5 €. Une soirée suffit pour annoncer votre /48 et voir votre préfixe dans un looking glass — la satisfaction est immédiate.
  • Vous avez déjà un homelab multi-sites : testez l’anycast de votre résolveur DNS entre deux VPS. La redondance sans IP flottante change la conception de la haute disponibilité.
  • Vous visez le multihoming réel : DN42 vous donne le muscle memory avant de négocier avec un LIR. Le BGP ne pardonne pas les erreurs de filtrage sur l’Internet public — autant les faire sur un réseau où la pire conséquence est un message sur IRC.

BGP existe depuis 1989 parce qu’il fait une chose et qu’il la fait bien. Votre homelab mérite d’en faire partie.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Vos APIs sont la porte d’entrée de votre business — un API Gateway les protège, les mesure et les accélère

Vos APIs ne sont plus des tuyaux internes — ce sont vos produits. Un API Gateway centralise le rate limiting, l’authentification, le caching et les analytics que chaque microservice devrait sinon réinventer dans son code. Kong, Traefik et Tyk incarnent trois architectures distinctes : voici comment choisir celle qui ne vous ralentira pas.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer