Lab : redondance du plan de contrôle — deux route reflectors, deux switchs #54

New issue

Open

opened 2026-10-04 19:43:36 +00:00 by nicolas.boufideline · 0 comments

nicolas.boufideline commented

2026-10-04 19:43:36 +00:00

Owner

Suite de #50 (4ᵉ étape de son découpage, sortie du ticket pour le clore) : rendre le plan de
contrôle du lab redondant, puis mesurer.

Pourquoi

Scénario s6-rr-loss de #50 (2026-10-04) : avec un seul route reflector et sans
graceful-restart, sa perte coupe tout le trafic entre hyperviseurs (0 paquet à 30 s comme à
90 s), qui revient 31 s après son retour. La redondance est nécessaire avant la production.

Second route reflector — sans code

Tout est déjà dans l'outillage, le travail est dans conf/lab/ :

evpn-2hv.yml : nœud rr2 sur underlay (adresse fixée, 169.254.0.4/28 en secondaire,
loopback) ;
frr/rr2.conf : celle de rr1 avec son router-id et sa loopback ;
frr/hv*.conf : second voisin fabric vers la loopback de rr2 ;
frr/sw1.conf : voisin 169.254.0.4, loopback de rr2 acceptée ;
s6-rr-loss : arrêter rr1, vérifier que le trafic continue par rr2 ; puis l'inverse.

À trancher : loopback de rr2 (proposé 10.255.255.2) ; cluster-id commun aux deux route
reflectors ou propre à chacun.

Second switch — évolution du modèle

La topologie n'admet qu'un switch par segment ; deux routeurs sur le même L2 demandent un lien
entre switchs, ou un segment porté par deux switchs (topology, render). Le switch du lab reste un
Linux avec FRR : il joue le rôle générique de routeur de cluster, l'équipement réel (MikroTik
aujourd'hui, au choix de qui déploie demain) n'a besoin que de BGP et d'EVPN.

Critère

s6 rejoué : perte d'un route reflector, puis d'un switch, sans interruption mesurable du trafic
entre hyperviseurs ; documenté dans route-reflector.rst et lab.rst.

Suite de #50 (4ᵉ étape de son découpage, sortie du ticket pour le clore) : rendre le plan de contrôle du lab redondant, puis mesurer. ## Pourquoi Scénario `s6-rr-loss` de #50 (2026-10-04) : avec un seul route reflector et sans `graceful-restart`, sa perte **coupe tout le trafic entre hyperviseurs** (0 paquet à 30 s comme à 90 s), qui revient 31 s après son retour. La redondance est nécessaire avant la production. ## Second route reflector — sans code Tout est déjà dans l'outillage, le travail est dans `conf/lab/` : - `evpn-2hv.yml` : nœud `rr2` sur `underlay` (adresse fixée, `169.254.0.4/28` en secondaire, loopback) ; - `frr/rr2.conf` : celle de rr1 avec son `router-id` et sa loopback ; - `frr/hv*.conf` : second voisin `fabric` vers la loopback de rr2 ; - `frr/sw1.conf` : voisin `169.254.0.4`, loopback de rr2 acceptée ; - `s6-rr-loss` : arrêter rr1, vérifier que le trafic **continue** par rr2 ; puis l'inverse. À trancher : loopback de rr2 (proposé `10.255.255.2`) ; `cluster-id` commun aux deux route reflectors ou propre à chacun. ## Second switch — évolution du modèle La topologie n'admet qu'un switch par segment ; deux routeurs sur le même L2 demandent un lien entre switchs, ou un segment porté par deux switchs (`topology`, `render`). Le switch du lab reste un Linux avec FRR : il joue le rôle générique de routeur de cluster, l'équipement réel (MikroTik aujourd'hui, au choix de qui déploie demain) n'a besoin que de BGP et d'EVPN. ## Critère `s6` rejoué : perte d'un route reflector, puis d'un switch, sans interruption mesurable du trafic entre hyperviseurs ; documenté dans `route-reflector.rst` et `lab.rst`.

nicolas.boufideline added this to the 0.2.0 milestone

2026-10-04 19:43:36 +00:00

nicolas.boufideline added the

new feature

label

2026-10-04 19:43:36 +00:00

nicolas.boufideline referenced this issue

2026-10-04 19:54:35 +00:00

Lab virtuel multi-nœud : hyperviseurs en KVM imbriqué, route reflectors et switchs L3 en VM #50