Vue d’ensemble

Démarrage natif VPP

Comment un nœud met en service son réseau de management entièrement à l'intérieur de VPP — les niveaux amorcé, seedless (DHCP sur chaque carte) et usine, comment ils sont sélectionnés, et comment la découverte trouve un nœud neuf.

Un nœud SiHA n’a aucun réseau côté noyau pour le management : pas de dhclient sur une interface, pas de cloud-init qui écrit /etc/network, pas de SSH. Le superviseur (PID 1) met en service le plan de management à l’intérieur de VPP, avant le démarrage du plan de contrôle — de sorte que la socket même par laquelle vous atteignez le nœud transite par le dataplane.

La forme générale

Au démarrage, PID 1 résout la (les) carte(s) réseau de management, remet chacune à VPP comme port DPDK, et construit un chemin L3 par carte vers un tap noyau sur lequel apid écoute :

Un VRF de management dédié — table 4096. Chaque adresse de management vit dans sa propre table de routage, isolée des interfaces de données et intouchée par le contrôleur d’interfaces du plan de contrôle.
Un tap LCP par carte — mgmt0, mgmt1, … Le Linux Control Plane de VPP miroite chaque interface VPP vers un netdev noyau et remonte (punt) vers lui le trafic destiné à son adresse. Ce sont les seuls netdevs de management que le noyau voie jamais.
apid sur :6443. La porte d’entrée gRPC se lie aux taps ; chaque client atteint le nœud en mTLS via n’importe lequel d’entre eux.

Un nœud peut déclarer plus d’une carte réseau de management — statique, DHCP, ou un mélange. Chacune est mise en service indépendamment dans le VRF 4096 avec son propre tap, et chaque adresse qu’elle produit rejoint les SAN du certificat d’apid, si bien que le nœud répond sur n’importe laquelle d’entre elles. Si une carte échoue à se mettre en service, les autres le font quand même (best-effort).

D’où provient l’adresse est la seule chose qui varie — il y a donc en réalité deux niveaux capables de DHCP, amorcé (le seed nomme les cartes ; statique, DHCP, ou un mélange) et seedless (aucun seed → DHCP sur chaque carte), plus un repli usine pour quand rien ne prend de bail.

Le niveau amorcé — statique, DHCP, ou un mélange

Lorsque le seed de la plateforme nomme une ou plusieurs cartes réseau de management, PID 1 met en service chacune d’entre elles indépendamment : il adopte le port comme PMD DPDK, le lie au VRF 4096, lui donne une adresse, et le tape (mgmt0, mgmt1, …). La manière dont une carte obtient son adresse est un choix par carte — une adresse statique fixe ou un bail DHCP — de sorte qu’un seul nœud peut faire tourner certaines cartes en statique et d’autres en DHCP simultanément. Chaque adresse résultante atterrit dans les SAN du certificat d’apid, si bien que le nœud répond sur n’importe laquelle. Les cartes de données sont laissées tranquilles — le plan de contrôle les adopte plus tard, à partir du premier DataplaneConfig.

adopt PMD — VPP binds the port as a DPDK interfacelcp punt — Linux-CP mirrors the VPP address to the kernel tapone static, one DHCP — each NIC is independent, same VRF

Statique — le seed porte l’adresse (la network-config livrée via le lecteur vsock/9p) ; PID 1 l’assigne directement à l’interface VPP.

DHCP — le seed nomme le lien mais pas l’adresse. Le piège : LCP est en poussée seule, VPP → noyau, donc un bail obtenu par un dhclient noyau sur le tap ne remonterait jamais vers VPP — VPP ne posséderait pas l’adresse ni ne répondrait à l’ARP pour elle. Le client DHCP tourne donc à l’intérieur de VPP, un par carte : il obtient le bail directement sur l’interface VPP, dans le VRF 4096, et LCP le miroite vers le tap.

Le niveau seedless — DHCP sur chaque carte

Parfois il n’y a aucun seed : pas de config_drive, pas de metadata, pas d’user-data vsock — un nœud usine nu, ou un cloud dont le service de metadata ne répond jamais. Plutôt que de choisir une carte et d’espérer, PID 1 synthétise une requête DHCP sur chaque carte PCI et lance exactement le même fan-out qu’un seed DHCP : un client DHCP VPP par port, dans le VRF 4096, chacun tapé.

La règle est simple — une interface est de management si et seulement si elle a une IP. Chaque carte qui décroche un bail devient une interface de management (son adresse dans les SAN du certificat) ; une carte qui n’en obtient aucun dans le délai imparti est laissée au dataplane. Un nœud à deux cartes sur deux segments DHCP se retrouve donc joignable sur les deux — le même état final qu’un seed qui aurait nommé les deux, découvert plutôt que déclaré.

adopt PMD — VPP binds the port as a DPDK interfacelcp punt — Linux-CP mirrors the VPP address to the kernel tapleases — a DHCP client per NIC, inside VPP

Une seule route par défaut. N cartes ayant un bail installeraient sinon chacune une 0.0.0.0/0 dans le VRF de management partagé — de l’ECMP que l’anti-spoofing par port de certains clouds jette silencieusement. Seule la carte à plus faible BDF PCI ayant un bail garde donc sa route par défaut ; toute autre carte de management n’a que sa route connectée. Déterministe, et ça préserve le réflexe « adopter sur la primaire ».

Délai. L’attente DHCP de chaque carte est bornée (30 s) de sorte qu’un relais lent ne classe jamais à tort une vraie carte de management comme donnée. Les cartes sont essayées l’une après l’autre, donc un nœud avec beaucoup de ports sans DHCP met simplement plus de temps à se stabiliser.

Si aucune carte n’obtient de bail une fois tous les ports essayés, le nœud bascule vers le repli usine ci-dessous — la seule posture où toutes les cartes deviennent une seule surface.

Repli — usine / branchez-partout

Un nœud tout neuf sans seed et sans aucun bail sur aucune carte ne devrait pas non plus rester dans le noir. Plutôt que cela, PID 1 ponte chaque carte dans un unique domaine L2 et lui donne un BVI loopback portant une adresse de secours 192.168.1.1/24 dans le VRF 4096. Branchez un câble sur n’importe quel port et vous atteignez .1 — l’opérateur adopte à partir de là.

bridge — every port joined into one L2 domainlcp punt — Linux-CP mirrors the VPP address to the kernel tapbreak-glass gateway

Ce niveau est strictement la posture usine. Un nœud adopté qui, pour une raison quelconque, n’a pas d’adresse de management est traité comme une faute (un état « dégradé »), jamais ponté silencieusement — ponter chaque port sur un nœud en service serait une passerelle pirate.

Comment un niveau est choisi

Le niveau est déduit du seed et de l’état d’adoption du nœud ; l’arbitrage seedless→repli est ensuite tranché à l’exécution, une fois le fan-out DHCP drainé. Priorité la plus élevée d’abord :

Condition	Niveau
le seed nomme un ou plusieurs réseaux de management	amorcé — chaque carte statique (elle a une adresse) ou DHCP
aucun seed, nœud non adopté, au moins une carte prend un bail	seedless — DHCP sur chaque carte ; celles qui décrochent un bail deviennent management
aucun seed, nœud non adopté, aucune carte ne prend de bail	repli (`.1`)
sinon (adopté, mais sans adresse de management)	dégradé — erreur, ne pas ponter

Le niveau choisi s’inscrit en clair dans la console série (tier=seeded / tier=fallback, chaque carte journalisant mode=static ou mode=dhcp) ; un démarrage seedless journalise en plus une ligne mgmt-probe … result=leased|timeout par carte, de sorte que l’on lit directement depuis la console quel câble s’est levé. Chaque IP de management que le niveau produit alimente les SAN du certificat serveur avant que la PKI ne soit forgée — de sorte que le certificat est valide sur toutes les adresses par lesquelles vous atteindrez réellement le nœud.

Cloud ou metal — l’image décide

L’échelle elle-même est sélectionnée par une estampille de plateforme cuite dans l’image : siha.platform=cloud|metal sur la ligne de commande du noyau, à l’intérieur de l’UKI signé — la posture de démarrage fait donc partie de ce que SecureBoot atteste, pas d’une devinette à l’exécution.

cloud (le défaut) déroule l’échelle complète ci-dessus : chercher d’abord un seed de plateforme (partage de configuration, disque de configuration, service de métadonnées), puis DHCP, puis repli. C’est la posture de tout environnement capable de fournir son identité au nœud dès le premier démarrage — plateforme virtualisée, tenant cloud, hyperviseur de labo.
metal saute entièrement la machinerie de seed — sur du matériel nu, il n’y a rien à sonder, le nœud ne perd donc jamais de temps de boot à chercher. Le DHCP sur chaque carte est le chemin nominal (journalisé en clair, jamais comme une anomalie), le repli usine (192.168.1.1 sur chaque port) est le filet de sécurité, et l’enrôlement passe toujours par découverte → adoption : on racke, on câble, on adopte — du zero-touch provisioning pur, sans aucune préparation par nœud.

Pourquoi une estampille au démarrage plutôt qu’une détection à l’exécution ? Parce que les deux postures ne donnent pas le même sens au silence. En cloud, « aucun seed trouvé » est une anomalie qui mérite un avertissement (la plateforme aurait dû en fournir un) ; en metal, c’est la routine. Cuire l’intention dans l’image signée rend le comportement du nœud déterministe et auditable, au lieu d’heuristique.

Les deux estampilles convergent vers le même état final ; metal y arrive simplement sans jamais sonder de seed. Un nœud qui alterne d’estampille au fil des démarrages A/B garde son identité — adoption et PKI survivent — tandis que son état de forme réseau (ensemble de management, MTU de la fabrique) est remis à zéro pour re-détection.

⚠️ Ce qui est supporté aujourd’hui. cloud est la posture validée et supportée : elle est éprouvée de bout en bout sur des déploiements virtualisés et cloud (niveaux seed, DHCP et repli, adoption, application de configuration, mises à niveau). metal est expérimental pour le moment : le chemin de code est complet et testé en continu sur machines virtuelles, mais il n’a pas encore été validé sur des équipements physiques (cartes réseau réelles, IOMMU matériel, SecureBoot appliqué sur un firmware réel). Considérez les images metal comme de la prévisualisation tant que cette validation n’a pas eu lieu — cette note disparaîtra avec elle.

Survivre à un redémarrage du dataplane

Pousser un DataplaneConfig re-génère le startup.conf de VPP et redémarre VPP avec un apply en deux phases à contrôle de santé et repli sur dernier état bon connu. Un redémarrage de VPP efface tout le dataplane — y compris les PMD de management, le VRF 4096 et les taps mgmt. PID 1 relance donc la même mise en service après le redémarrage, restaurant le plan de management sur place ; le nœud reste joignable tout au long d’un config apply au lieu de disparaître jusqu’au prochain redémarrage.

Jour 2 — réduire la surface de management

Au démarrage, un nœud est joignable sur chaque carte réseau de management que le seed a nommée — délibérément : pendant l’adoption, vous ne savez peut-être pas encore quel câble vous brancherez. Une fois adopté et sûr de votre topologie, vous réduisez le management à la (aux) carte(s) que vous voulez réellement avec une ressource ManagementInterfaces — la liste des ports qui restent en management. Chaque carte que vous retirez est rendue à un simple port de données : elle atterrit dans la table 0 sans adresse (un orphelin inoffensif), libre pour vous de la déclarer comme Interface{kind: pmd} et de l’utiliser pour le trafic. Le re-câblage est à chaud — aucun redémarrage de VPP, aucun reboot, aucune session perdue sur le port que vous conservez.

# ManagementInterfaces — singleton (id: default), reconciled live
interfaces:
  - pci: "0000:05:00.0"        # keep management here (or match by `mac:`)

Une carte est nommée par pci (son BDF) ou mac — jamais un nom noyau (instable via udev). Chacune doit être un PMD actuellement lié ; un BDF non lié ou un ensemble qui se résout à zéro carte joignable est rejeté avant tout re-câblage. Le contrôle d’accès sur l’interface survivante est votre ACL / ACLBinding habituel (l’interface de management est publiée comme une Interface COSI, de sorte qu’un binding peut cibler son sw_if_index) — défense en profondeur par-dessus le mTLS et le VRF de management.

Récupération — recréer, ou break-glass. Un changement de l’ensemble de management se réconcilie à chaud, après que la mise à niveau A/B à contrôle de santé a déjà été validée, si bien qu’une erreur ici échappe à la portée du rollback automatique. Il n’y a pas d’auto-retour en place : les nœuds siha sont du bétail, donc le modèle de récupération est de re-provisionner — le nœud revient sur l’ensemble de management large de son seed — plutôt que de dorloter un nœud coincé. Deux garde-fous rendent une erreur peu coûteuse : un ensemble qui se résout à zéro carte joignable (ou un BDF non lié) est rejeté avant tout re-câblage, et si vous vous verrouillez quand même dehors, le chemin de break-glass (console série + IP de repli sur partition inscriptible) le corrige sur place.

Découverte — trouver un nœud neuf

Vous ne pouvez pas encore atteindre un nœud usine par son nom, et son plan de management vit entièrement dans VPP — il n’y a aucune interface noyau à sonder. sihactl discover résout cela avec une sollicitation multicast tous-hôtes :

La sollicitation part vers 224.0.0.1:15353. VPP installe automatiquement une route multicast has-local pour 224.0.0.1 (le tap de management en est membre implicite), de sorte que le paquet emprunte ip4-mfib → ip4-punt → punt-redirect jusqu’à mgmt0, où le répondeur du superviseur répond avec l’identité du nœud — son IP de management, l’empreinte de la CA, et s’il est encore non adopté.

Pourquoi pas un broadcast de sous-réseau ? Le Linux Control Plane de VPP ne remonte (punt) vers le tap que le local-unicast et le multicast — un broadcast dirigé vers le sous-réseau est jeté au niveau du FIB, avant toute livraison locale. Une sollicitation en broadcast n’atteint tout simplement jamais le répondeur sur un nœud natif VPP ; le multicast est le chemin qui y parvient.

Parce que la découverte est en multicast, plusieurs nœuds non adoptés sur le même segment répondent tous — vous voyez chaque nœud en attente d’adoption, ce qui est précisément le but.

Ensuite : adoptez le nœud et appliquez vos premières ressources.