f-50: docs: route reflector — adressage et configuration FRR validés dans le lab #50

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

docs/deploiement/route-reflector.rst

@@ -8,15 +8,106 @@ reflector, qui redistribue.
 Il tourne lui-même en machine virtuelle, ce qui crée une dépendance circulaire à traiter
 explicitement : la VM qui porte le plan de contrôle du cluster est hébergée par le cluster.
 
+Adressage
+---------
+
+Le route reflector est **sur le même segment L2 que les hyperviseurs**, avec trois adresses :
+
+.. list-table::
+   :header-rows: 1
+   :widths: 30 25 45
+
+   * - Adresse
+     - Interface
+     - Rôle
+   * - une adresse de ``192.168.14.0/24``
+     - interface principale
+     - celle de n'importe quelle machine du segment ; les réponses aux hyperviseurs en partent
+   * - ``169.254.0.3/28``
+     - interface principale, **adresse secondaire**
+     - le lien avec les routeurs de cluster (``169.254.0.1`` et ``.2``), sur le même L2
+   * - ``10.255.255.1/32``
+     - ``lo1``, interface ``dummy``
+     - ``router-id``, ``cluster-id`` et source des sessions EVPN ; seule route annoncée aux routeurs
+
+Les hyperviseurs ne connaissent que la loopback : ils ouvrent leur session vers ``10.255.255.1``
+par leur passerelle (``192.168.14.1``), les routeurs l'ayant apprise du route reflector en eBGP.
+Aucune adresse d'hyperviseur n'est déclarée côté route reflector : il accepte toute session venant
+du segment (``bgp listen range``).
+
+L'adresse du lien est une **adresse secondaire** de l'interface principale, pas une interface à
+part : même L2, même MAC sur le fil, une interface de moins qu'avec un ``ipvlan``. Elle doit
+survivre aux renouvellements DHCP de l'adresse principale : la déclarer dans la configuration
+réseau du système, pas la poser à la main.
+
 .. note::
 
-   **À rédiger.** À documenter :
+   **Non vérifié sur l'image de production.** Avec NetworkManager, la forme attendue est :
 
-   * la création de la VM : ressources, subnet et mode utilisés, et s'il s'agit d'une VM créée
+   .. code-block:: bash
-     par l'agent comme les autres ou d'un cas particulier — l'image, elle, est l'image golden de
+
-     :doc:`image-qcow2` ;
+      nmcli connection modify <connexion> +ipv4.addresses 169.254.0.3/28
-   * son adressage, et comment les hyperviseurs le connaissent ;
+      nmcli connection add type dummy ifname lo1 con-name lo1 \
-   * la configuration du démon de routage qu'elle héberge ;
+          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.
+
+Configuration de FRR
+--------------------
+
+``bgpd`` et ``bfdd`` activés dans ``/etc/frr/daemons``. La configuration ci-dessous est **celle du
+lab** (``conf/lab/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:: ../../conf/lab/frr/rr1.conf
+   :language: text
+
+Ce qu'elle établit :
+
+* **Routeurs de cluster** (groupe ``CLUSTER``) : eBGP vers l'AS 65100, avec BFD, en IPv4
+  unicast. Le route reflector n'annonce que sa loopback (``RR-LOOPBACK-OUT``) et **n'accepte
+  rien** (``NO-IN``) : il ne reçoit aucune route des routeurs.
+* **Hyperviseurs** (groupe ``fabric``) : voisins dynamiques, toute session venant de
+  ``192.168.14.0/24`` étant acceptée, jusqu'à 200. ``local-as 64600 no-prepend replace-as`` fait
+  que, du point de vue des hyperviseurs, la session est en iBGP dans l'AS 64600 — celui de leur
+  configuration — alors que le route reflector est en AS 65000 face aux routeurs.
+* **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
+     - aucune : rien à annoncer tant que two n'a pas créé de VXLAN — voir
+       :doc:`premier-hyperviseur`
+
+Le routeur du lab n'est qu'une configuration minimale écrite pour l'essai, pas celle des routeurs
+de cluster (:doc:`routeurs`).
+
+.. note::
+
+   **À rédiger.** Reste à documenter :
+
+   * la création de la VM : ressources, subnet et mode utilisés (``bridge``, pour pouvoir la
+     lancer sur n'importe quel hyperviseur), et s'il s'agit d'une VM créée par l'agent comme les
+     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, et l'état du cluster pendant que le route reflector est
      absent — les tunnels déjà établis continuent-ils de fonctionner, et pendant combien de