f-50: docs: routeur de cluster et FRR des hyperviseurs, déploiement sans résultats de lab #50

Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr>

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.
+   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.
-   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.
 
 .. note::
 

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 <https://git.g3e.fr/syonad/two/issues/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
+   * la version de FRR de référence et son installation sur l'hyperviseur **sans état** : paquet
-     sans état : le paquet et la configuration doivent être posés à chaque démarrage, par le
+     et configuration doivent être posés à chaque démarrage, par le bootstrap ou un mécanisme
-     bootstrap ou par un mécanisme équivalent ;
+     équivalent (`#52 <https://git.g3e.fr/syonad/two/issues/52>`_) ;
-   * les démons activés dans ``/etc/frr/daemons`` ;
+   * le démarrage à froid, selon que FRR démarre avant ou après l'agent ;
-   * la configuration de référence : numéro d'AS, session vers le route reflector, famille
+   * les subnets ``vxlan`` créés avant ``0.2.0rc003``, dont la VXLAN n'a pas d'adresse VTEP
-     d'adresses utilisée pour annoncer les MAC et les VNI ;
+     locale : les recréer ou poser l'adresse à chaud, à trancher dans
-   * l'articulation avec les interfaces créées par l'agent : comment FRR découvre une interface
+     `#51 <https://git.g3e.fr/syonad/two/issues/51>`_ ;
-     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 ;
    * le cas particulier du **premier** hyperviseur, dont la session ne peut pas s'établir tant
      que le route reflector n'existe pas.
 

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
+   Ces commandes restent à valider sur l'image golden.
-   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
+``bgpd`` et ``bfdd`` activés dans ``/etc/frr/daemons``.
-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.
 
 .. 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 <https://git.g3e.fr/syonad/two/issues/51>`_)
-
 .. warning::
 
-   **Les tunnels ne survivent pas à la perte du route reflector.** Mesuré dans le lab
+   **Les tunnels ne survivent pas à la perte du route reflector.** Avec un seul route reflector
-   (2026-10-04, FRR 10.7.1, un seul route reflector, sans ``graceful-restart``) : à l'arrêt de
+   et sans ``graceful-restart``, à l'arrêt de FRR sur le route reflector, la session EVPN des
-   FRR sur le route reflector, la session EVPN des hyperviseurs tombe aussitôt, FRR retire les
+   hyperviseurs tombe aussitôt, FRR retire les routes apprises et, avec elles, le VTEP distant et l'entrée d'inondation du VXLAN — **plus
-   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`.

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 <https://git.g3e.fr/syonad/two/issues/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 ;
+.. note::
-   * la configuration de référence : interfaces, adressage, protocole de routage et numéros
+
-     d'AS ;
+   **À rédiger.** Reste à documenter, faute d'éléments de terrain :
-   * la redondance : combien d'équipements, quel mécanisme de bascule, quel comportement attendu
+
-     pendant une bascule ;
+   * pour le routeur de cluster : le matériel employé et sa version de référence ; la redondance
-   * ce qui est annoncé et ce qui est filtré à chaque niveau ;
+     — deux routeurs, mécanisme de bascule, comportement attendu pendant une bascule
+     (`#54 <https://git.g3e.fr/syonad/two/issues/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.