tripoli.cloud/bird-lab

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).