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>
This commit is contained in:
parent
ab12484a70
commit
80ade71653
GPG key ID:
4406BBBF8845D632
4 changed files with 104 additions and 61 deletions
|
|
@ -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::
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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 <https://git.g3e.fr/syonad/two/issues/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 <https://git.g3e.fr/syonad/two/issues/51>`_ ;
|
||||
* le cas particulier du **premier** hyperviseur, dont la session ne peut pas s'établir tant
|
||||
que le route reflector n'existe pas.
|
||||
|
||||
|
|
|
|||
|
|
@ -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 <https://git.g3e.fr/syonad/two/issues/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`.
|
||||
|
|
|
|||
|
|
@ -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 ;
|
||||
* 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 <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.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue