Adam Belkacemi 7802c59931 Phase 6 (bonus) : bird-lab, BGP+BFD entre namespaces (rtnetlink/Bird)

- Topologie en étoile : racine (AS 65000) en transit entre bird-a
  (AS 65010) et bird-b (AS 65011), namespaces créés par tripoli-netctl
  (Phase 4). Chaque feuille origine une route factice, jamais
  installée dans la table de routage réelle (export none partout) -
  labo pédagogique, ne pilote aucun trafic de production.
- Vérifié en conditions réelles : sessions BGP Established dans les
  deux sens, route de bird-b vue par bird-a avec next-hop = racine
  (transit confirmé, pas un peering direct), sessions BFD Up
  (200ms/200ms), coupure de lien détectée en < 5ms.
- Découverte : les namespaces n'ont aucun pare-feu propre, mais ufw
  côté racine bloquait le retour des paquets BFD (chaque bout envoie
  indépendamment, conntrack ne le reconnaît pas comme un flux BGP/TCP
  existant) - même schéma que Caddy -> tripoli-edge en Phase 2. Règle
  ufw ajoutée par run.sh, retirée par teardown.sh : rien de permanent.
- Pas de service systemd : labo lancé, vérifié, puis proprement démonté
  (processus Bird, namespaces et règle ufw temporaire tous supprimés).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-09-17 01:17:15 +02:00

4 KiB

Raw Blame History

bird-lab (Phase 6, bonus)

Labo pédagogique un-seul-poste : BGP + BFD entre les network namespaces créés par tripoli-netctl (Phase 4). Ne pilote aucun trafic de production - tripoli-edge et tripoli-api continuent de tourner nativement sur l'hôte, dans le namespace racine, complètement en dehors de ce labo. Rien de ce qui est appris ici n'est installé dans la table de routage réelle du noyau (export none; dans chaque config Bird).

Topologie

Une étoile, pas un maillage complet : le namespace racine (AS 65000) sert de transit entre deux namespaces "feuilles" qui ne se parlent jamais directement.

   namespace bird-a (AS 65010)          namespace bird-b (AS 65011)
   origine 10.99.10.0/24                origine 10.99.11.0/24
        10.200.10.2                          10.200.11.2
             |                                    |
             | veth (tripoli-netctl)              | veth (tripoli-netctl)
             |                                    |
        10.200.10.1                          10.200.11.1
        +---------------------------------------------+
        |         namespace racine (AS 65000)          |
        |    BGP+BFD vers bird-a      BGP+BFD vers bird-b |
        +---------------------------------------------+

Chaque namespace "feuille" origine une route factice (10.99.1x.0/24 blackhole, juste pour avoir quelque chose de concret à observer traverser le labo) ; le namespace racine la réapprend par BGP et la réexporte vers l'autre feuille - démontrant un vrai comportement de transit eBGP, pas un simple peering point à point.

Ce qui a été vérifié

Sessions BGP établies dans les deux sens (Established) après démarrage des trois instances Bird.
Propagation de route à travers le transit : bird-a voit 10.99.11.0/24 appris via AS65011i avec next-hop 10.200.10.1 (l'adresse du namespace racine, pas celle de bird-b - la route a bien transité par le hub) ; symétriquement pour bird-b.
Sessions BFD Up, intervalle 200ms.
Détection de panne : ip link set tv-birdah down fait passer la session BGP correspondante en Idle en moins de 5ms - avant même que le timer BFD (600ms-1s) n'ait eu besoin de se déclencher, Bird réagit à l'événement netlink d'interface directement. Le vrai apport de BFD se voit sur une panne "silencieuse" (lien physique up, mais plus de paquets) - non isolé précisément dans cette passe, faute de temps ; la mécanique (sessions BFD Up, intervalles sous la seconde) est en place et vérifiée, la détection de ce cas précis reste à chronométrer séparément.

Découverte : ufw bloque le retour BFD

Les namespaces bird-a/bird-b n'ont aucune règle de pare-feu (leur netfilter est vierge - seul le namespace racine a ufw). Pourtant, leurs paquets BFD sortants se faisaient bloquer en arrivant côté racine : contrairement à BGP (TCP, donc suivi par conntrack - le retour d'une connexion initiée est autorisé automatiquement), chaque bout de BFD envoie indépendamment depuis son propre port éphémère vers le port 3784 de l'autre. Du point de vue de conntrack côté racine, le paquet BFD émis par bird-a n'est le retour d'aucun flux connu : ufw le traite comme une connexion entrante neuve et le rejette par défaut. Il a fallu une règle explicite (ufw allow from 10.200.0.0/16 to any port 3784 proto udp), ajoutée par run.sh et retirée par teardown.sh - exactement le même schéma que la règle ajoutée en Phase 2 pour laisser Caddy joindre tripoli-edge.

Utilisation

sudo ./run.sh        # crée les namespaces, démarre Bird, affiche l'état
sudo ./teardown.sh    # arrête tout, détruit les namespaces, retire la règle ufw temporaire

Volontairement pas de service systemd permanent : faire tourner ce labo en continu sur un serveur de production partagé n'apporterait rien de plus pédagogiquement, juste de la RAM utilisée pour rien. Vérifié dans cette session, puis proprement démonté (namespaces, processus Bird et règle ufw temporaire tous supprimés).

4 KiB Raw Blame History