adam/tripoli.cloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
- 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>
This commit is contained in:
Adam Belkacemi 2026-09-17 01:17:15 +02:00
parent db306433d5
commit 7802c59931
7 changed files with 269 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

82
bird-lab/README.md Normal file
View file

@ -0,0 +1,82 @@
# 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).