From 1d793b03e3c1d2fd3a4348f4d2b3d15a9424695c Mon Sep 17 00:00:00 2001 From: GnomeZworc Date: Sun, 4 Oct 2026 17:57:11 +0200 Subject: [PATCH] =?UTF-8?q?f-50:=20docs:=20route=20reflector=20=E2=80=94?= =?UTF-8?q?=20adressage=20et=20configuration=20FRR=20valid=C3=A9s=20dans?= =?UTF-8?q?=20le=20lab=20#50?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: GnomeZworc --- docs/deploiement/route-reflector.rst | 103 +++++++++++++++++++++++++-- 1 file changed, 97 insertions(+), 6 deletions(-) diff --git a/docs/deploiement/route-reflector.rst b/docs/deploiement/route-reflector.rst index e0095d2..ab57b32 100644 --- a/docs/deploiement/route-reflector.rst +++ b/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 - par l'agent comme les autres ou d'un cas particulier — l'image, elle, est l'image golden de - :doc:`image-qcow2` ; - * son adressage, et comment les hyperviseurs le connaissent ; - * la configuration du démon de routage qu'elle héberge ; + .. code-block:: bash + + nmcli connection modify +ipv4.addresses 169.254.0.3/28 + 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. + +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