From 80ade71653ee0af8a7bf01711afc969a25e87b61 Mon Sep 17 00:00:00 2001 From: GnomeZworc Date: Mon, 5 Oct 2026 20:55:52 +0200 Subject: [PATCH] =?UTF-8?q?f-50:=20docs:=20routeur=20de=20cluster=20et=20F?= =?UTF-8?q?RR=20des=20hyperviseurs,=20d=C3=A9ploiement=20sans=20r=C3=A9sul?= =?UTF-8?q?tats=20de=20lab=20#50?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: GnomeZworc --- docs/deploiement/image-qcow2.rst | 8 +-- docs/deploiement/premier-hyperviseur.rst | 48 ++++++++++++++---- docs/deploiement/route-reflector.rst | 43 +++------------- docs/deploiement/routeurs.rst | 64 +++++++++++++++++++++--- 4 files changed, 103 insertions(+), 60 deletions(-) diff --git a/docs/deploiement/image-qcow2.rst b/docs/deploiement/image-qcow2.rst index cba2e27..1bf8866 100644 --- a/docs/deploiement/image-qcow2.rst +++ b/docs/deploiement/image-qcow2.rst @@ -323,12 +323,8 @@ Points de vigilance 22.4.2 —, sans barre oblique finale il demande ``http://169.254.169.254:80meta-data`` : la source échoue, la VM démarre en ``DataSourceNone``, sans nom d'hôte ni user-data. À partir de 23.1, un drapeau actif par défaut (``NOCLOUD_SEED_URL_APPEND_FORWARD_SLASH``) ajoute la barre - oblique manquante, ce qui explique qu'une image récente fonctionne sans elle. - - Vérifié le 2026-10-04 dans le lab (#50), sur une VM Debian 12 lancée par l'agent : sans barre - oblique, ``Datasource DataSourceNone`` ; avec, ``DataSourceNoCloudNet - [seed=…http://169.254.169.254…]`` et le nom d'hôte de la VM. Avec la barre oblique, la - configuration fonctionne quelle que soit la version de cloud-init. + oblique manquante, ce qui explique qu'une image récente fonctionne sans elle. Avec la barre + oblique, la configuration fonctionne quelle que soit la version de cloud-init. .. note:: diff --git a/docs/deploiement/premier-hyperviseur.rst b/docs/deploiement/premier-hyperviseur.rst index ae70bc1..dc480fe 100644 --- a/docs/deploiement/premier-hyperviseur.rst +++ b/docs/deploiement/premier-hyperviseur.rst @@ -24,19 +24,47 @@ créées par l'agent. C'est ce qui rend un subnet utilisable au-delà d'un seul l'agent désactive l'apprentissage et ne configure aucun voisin — cf. :doc:`architecture-cluster`. +Configuration de FRR +~~~~~~~~~~~~~~~~~~~~ + +Seul ``bgpd`` est activé dans ``/etc/frr/daemons``. D'un hyperviseur à l'autre ne changent que +``hostname`` et ``router-id``, l'adresse de l'hyperviseur sur son segment. + +.. literalinclude:: ../../test/e2e/topologies/frr/hv1.conf + :language: text + +Ce qu'elle établit : + +* **Une seule session**, en iBGP dans l'AS 64600, vers la loopback du route reflector + (``10.255.255.1``), jointe par la passerelle par défaut — le routeur de cluster l'a apprise du + route reflector (:doc:`routeurs`). Aucune adresse d'un autre hyperviseur n'est écrite : ajouter + un nœud ne touche pas la configuration des autres. +* **EVPN seulement** : l'IPv4 unicast n'est pas activé (``no bgp default ipv4-unicast``). + ``advertise-all-vni`` annonce les VNI de toutes les interfaces VXLAN que FRR voit, et donc + celles que l'agent crée. +* **Pas de BFD** sur cette session, contrairement à la session entre route reflector et routeur. + +Articulation avec l'agent +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Rien à configurer à la création d'un subnet : la VXLAN apparaît, FRR la voit et l'annonce, sans +action ni redémarrage. Il faut en revanche que la VXLAN porte une **adresse VTEP locale** : sans +elle, FRR voit la VNI mais n'annonce rien, et deux hyperviseurs gérés par two ne se joignent pas. +L'agent la pose à partir de la release ``0.2.0rc003`` +(`#51 `_) : l'adresse IPv4 primaire du ``local_iface`` +du subnet. + .. note:: - **À rédiger.** À documenter : + **À rédiger.** Reste à documenter : - * la version de FRR de référence et son mode d'installation, sachant que l'hyperviseur est - sans état : le paquet et la configuration doivent être posés à chaque démarrage, par le - bootstrap ou par un mécanisme équivalent ; - * les démons activés dans ``/etc/frr/daemons`` ; - * la configuration de référence : numéro d'AS, session vers le route reflector, famille - d'adresses utilisée pour annoncer les MAC et les VNI ; - * l'articulation avec les interfaces créées par l'agent : comment FRR découvre une interface - VXLAN qui apparaît à la création d'un subnet, et si une action est nécessaire ensuite ; - * ce qui se passe au démarrage à froid, quand FRR démarre avant ou après l'agent ; + * la version de FRR de référence et son installation sur l'hyperviseur **sans état** : paquet + et configuration doivent être posés à chaque démarrage, par le bootstrap ou un mécanisme + équivalent (`#52 `_) ; + * le démarrage à froid, selon que FRR démarre avant ou après l'agent ; + * les subnets ``vxlan`` créés avant ``0.2.0rc003``, dont la VXLAN n'a pas d'adresse VTEP + locale : les recréer ou poser l'adresse à chaud, à trancher dans + `#51 `_ ; * le cas particulier du **premier** hyperviseur, dont la session ne peut pas s'établir tant que le route reflector n'existe pas. diff --git a/docs/deploiement/route-reflector.rst b/docs/deploiement/route-reflector.rst index a9bcb08..e4143a4 100644 --- a/docs/deploiement/route-reflector.rst +++ b/docs/deploiement/route-reflector.rst @@ -50,15 +50,12 @@ réseau du système, pas la poser à la main. nmcli connection add type dummy ifname lo1 con-name lo1 \ ipv4.method manual ipv4.addresses 10.255.255.1/32 ipv6.method disabled - Le lab, en Debian, pose ces adresses par cloud-init et un script rejoué au démarrage ; ces - commandes restent à valider sur l'image golden. + Ces commandes restent à valider sur l'image golden. Configuration de FRR -------------------- -``bgpd`` et ``bfdd`` activés dans ``/etc/frr/daemons``. La configuration ci-dessous est **celle du -lab** (``test/e2e/topologies/frr/rr1.conf``) : ASN, loopback et plages sont ceux de la production, seul le nom -d'hôte diffère. Le lab qualifie donc exactement ce fichier. +``bgpd`` et ``bfdd`` activés dans ``/etc/frr/daemons``. .. literalinclude:: ../../test/e2e/topologies/frr/rr1.conf :language: text @@ -75,44 +72,16 @@ Ce qu'elle établit : * **EVPN** : seule famille activée vers les hyperviseurs, qui sont ses clients (``route-reflector-client``) : il réfléchit les routes EVPN de chacun vers tous les autres. -Vérifié dans le lab -~~~~~~~~~~~~~~~~~~~ - -Le 2026-10-04, FRR 10.7.1, route reflector en Debian 12 sur le segment des hyperviseurs, avec -l'adresse du lien en secondaire et la loopback sur ``lo1`` : - -.. list-table:: - :header-rows: 1 - :widths: 55 45 - - * - Vérification - - Résultat - * - session avec le routeur, IPv4 unicast - - Established ; le routeur reçoit **un seul** préfixe, la loopback, et l'installe via - ``169.254.0.3`` - * - BFD avec le routeur - - up des deux côtés - * - sessions des deux hyperviseurs vers ``10.255.255.1`` - - Established, voisins dynamiques, iBGP AS 64600, famille L2VPN EVPN négociée - * - routes EVPN échangées, VM ↔ VM entre deux hyperviseurs - - routes de type 3 échangées, ping et MTU 1500 de bout en bout — à partir de la release - ``0.2.0rc003``, qui pose l'adresse VTEP locale des VXLAN - (`#51 `_) - .. warning:: - **Les tunnels ne survivent pas à la perte du route reflector.** Mesuré dans le lab - (2026-10-04, FRR 10.7.1, un seul route reflector, sans ``graceful-restart``) : à l'arrêt de - FRR sur le route reflector, la session EVPN des hyperviseurs tombe aussitôt, FRR retire les - routes apprises et, avec elles, le VTEP distant et l'entrée d'inondation du VXLAN — **plus + **Les tunnels ne survivent pas à la perte du route reflector.** Avec un seul route reflector + et sans ``graceful-restart``, à l'arrêt de FRR sur le route reflector, la session EVPN des + hyperviseurs tombe aussitôt, FRR retire les routes apprises et, avec elles, le VTEP distant et l'entrée d'inondation du VXLAN — **plus aucun paquet ne passe** entre hyperviseurs, à 30 s comme à 90 s. Au redémarrage de FRR sur le route reflector, VTEP distant et trafic reviennent **31 s** plus tard. Le trafic entre VM d'un même hyperviseur n'est pas concerné. La redondance (deux route reflectors) ou ``graceful-restart`` sont les deux leviers ; ni l'un ni l'autre n'est encore qualifié. -Le routeur du lab est un Linux avec FRR, par choix : il joue le rôle générique de routeur de -cluster, l'équipement réel n'ayant besoin que de BGP et d'EVPN (:doc:`routeurs`). - .. note:: **À rédiger.** Reste à documenter : @@ -122,7 +91,7 @@ cluster, l'équipement réel n'ayant besoin que de BGP et d'EVPN (:doc:`routeurs autres ou d'un cas particulier — l'image, elle, est l'image golden de :doc:`image-qcow2` ; * la redondance : une seule VM route reflector, ou deux, et sur quels hyperviseurs ; * la procédure de reconstruction — l'état du cluster pendant l'absence du route reflector est - mesuré ci-dessus : plus de trafic entre hyperviseurs ; + décrit ci-dessus : plus de trafic entre hyperviseurs ; * la procédure d'amorçage : ce qui fonctionne, et dans quel ordre, quand on démarre un cluster entier depuis zéro — le premier hyperviseur n'a pas de session FRR établie tant que cette VM n'existe pas, cf. :doc:`premier-hyperviseur`. diff --git a/docs/deploiement/routeurs.rst b/docs/deploiement/routeurs.rst index 76ec2e7..f8e8dbf 100644 --- a/docs/deploiement/routeurs.rst +++ b/docs/deploiement/routeurs.rst @@ -15,16 +15,66 @@ Routeurs de datacentre Routeurs de bordure terminent le routage vers l'extérieur. +Routeur de cluster +------------------ + +Le routeur de cluster est la passerelle des hyperviseurs et le voisin eBGP du route reflector, dont +il apprend la loopback : c'est par lui que chaque hyperviseur joint ``10.255.255.1`` pour ouvrir sa +session EVPN (:doc:`route-reflector`). + +Adressage +~~~~~~~~~ + +.. list-table:: + :header-rows: 1 + :widths: 30 25 45 + + * - Adresse + - Interface + - Rôle + * - ``192.168.14.1/24`` + - interface du segment des hyperviseurs + - passerelle par défaut des hyperviseurs et du route reflector + * - ``169.254.0.1/28`` + - même interface, **adresse secondaire** + - lien avec le route reflector (``169.254.0.3``) ; ``router-id`` ; le second routeur prend + ``169.254.0.2`` + +Le MTU minimal du segment, imposé par VXLAN, est donné plus bas. + +Configuration de FRR +~~~~~~~~~~~~~~~~~~~~ + +``bgpd`` et ``bfdd`` activés dans ``/etc/frr/daemons``. + +.. literalinclude:: ../../test/e2e/topologies/frr/sw1.conf + :language: text + +Ce qu'elle établit : + +* **Route reflector** : eBGP de l'AS 65100 vers l'AS 65000, avec BFD, en IPv4 unicast. +* **En entrée**, seule la loopback du route reflector est acceptée (``RR-IN``) ; **en sortie**, + rien n'est annoncé (``NO-OUT``). Symétrique de ``RR-LOOPBACK-OUT`` et ``NO-IN`` côté route + reflector : chaque côté filtre, aucun ne dépend du filtre de l'autre. +* **Aucune session avec les hyperviseurs** : le routeur leur sert de passerelle, pas de voisin BGP. + +Le route reflector déclare aussi le second routeur (``169.254.0.2``). La redondance est l'objet de +`#54 `_. + .. note:: - **À rédiger.** Cette page attend les éléments de terrain. Pour chacun des trois niveaux : + Ce qui précède est le contrat du routeur de cluster : adresses, ASN, session, filtres. Sa + traduction dans la configuration d'un constructeur n'a pas sa place ici. - * le matériel ou le logiciel employé, et la version de référence ; - * la configuration de référence : interfaces, adressage, protocole de routage et numéros - d'AS ; - * la redondance : combien d'équipements, quel mécanisme de bascule, quel comportement attendu - pendant une bascule ; - * ce qui est annoncé et ce qui est filtré à chaque niveau ; +.. note:: + + **À rédiger.** Reste à documenter, faute d'éléments de terrain : + + * pour le routeur de cluster : le matériel employé et sa version de référence ; la redondance + — deux routeurs, mécanisme de bascule, comportement attendu pendant une bascule + (`#54 `_) ; + * pour les routeurs de datacentre et de bordure : tout — équipement, configuration de + référence, ce qui est annoncé et filtré à chaque niveau, redondance ; * l'ordre de mise en service, et ce qui doit être opérationnel avant de préparer le premier hyperviseur.