7802c59931
- 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>
82 lines
4 KiB
Markdown
82 lines
4 KiB
Markdown
# 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).
|