tripoli.cloud/bird-lab/README.md

# 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

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