Résumé
- La RFC 9721 corrige une limite du modèle EVPN-IRB : un numéro porté par une route MAC+IP ne suffit pas à dater séparément les deux identités lorsqu’une IP change de MAC, qu’un MAC change d’IP ou que plusieurs PE apprennent le même hôte à des instants différents.
- La solution conserve le champ unique, mais organise autour de lui un parent MAC, des enfants MAC+IP, une synchronisation multi-homing, une règle de maximum, des sondes ARP/NDP et une récupération des doublons. Le plus grand nombre ordonne une route ; il n’atteste ni l’hôte, ni le lieu physique, ni la convergence du service.
La migration est terminée selon l’orchestrateur. La machine virtuelle répond à sa nouvelle adresse physique et garde la même adresse IP. Pourtant, un PE annonce encore l’ancienne association avec un numéro élevé, tandis que le nouveau couple repart à zéro. Pour le réseau, la réalité récente ressemble à l’histoire la plus ancienne.
Le problème n’est pas un compteur défectueux. C’est l’objet que l’on demande au compteur de représenter. Une route EVPN de type 2 peut transporter ensemble un MAC et une IP ; le premier alimente le pont, la seconde une table ARP/ND ou un IP-VRF. Le paquet BGP rassemble ces données, mais il ne fusionne pas leurs identités.
La RFC 7432 avait défini la mobilité MAC : un numéro plus élevé permet de préférer le nouveau segment Ethernet. La RFC 9135 décrit ensuite l’intégration routage-pontage et la mobilité des hôtes. Tant que MAC et IP se déplacent ensemble, le raccourci fonctionne. Les environnements virtualisés cassent précisément cette condition.
Le couple n’est pas une identité indivisible
Une VM peut redémarrer avec la même IP et un autre MAC. Un équipement peut conserver son MAC après reprovisionnement et recevoir une nouvelle IP. Plusieurs clients derrière un pare-feu peuvent partager un MAC. La relation devient un-à-plusieurs ou plusieurs-à-un ; elle n’est plus l’étiquette stable que supposait l’ancien ordre.
Si chaque nouveau couple {MAC, IP} reçoit son propre compteur, une association réellement récente peut naître avec zéro face à une ancienne association numérotée 18. À l’inverse, augmenter arbitrairement le nouveau couple peut modifier l’histoire du MAC et de ses autres IP sans mécanisme commun.
La RFC 9721 choisit de ne pas ajouter deux numéros dans la route. Elle fait du MAC local le parent de version. Les routes MAC+IP liées héritent de ce numéro. Lorsqu’une IP était auparavant associée à un autre MAC distant, le nouveau parent doit dépasser aussi le numéro de cet autre MAC. Ce choix réduit la modification du format, mais transfère de la complexité dans l’état local.
Un observateur du trafic BGP ne voit pas cet état. Il reçoit une valeur, pas le graphe qui l’a produite. Il ignore quelles routes distantes ont été comparées, quels enfants ont été mis à jour, quelle valeur Peer-Sync-Local a été retenue et si une entrée ARP ancienne subsiste.
La preuve utile commence donc avant l’annonce. Elle relie l’événement d’apprentissage à l’interface et à l’ESI, conserve la valeur du parent avant et après calcul, énumère les enfants, puis enregistre les annonces et retraits. Une valeur bien formée n’est pas encore une valeur justifiée.
Deux pairs actifs peuvent vivre dans deux époques
Le cas le plus révélateur se trouve dans le multi-homing all-active. Deux PE représentent le même segment. Les trames et réponses ARP/NDP se répartissent entre leurs liens ; l’apprentissage local est asynchrone.
Après un déplacement, le premier PE peut apprendre l’hôte lorsque l’ancienne route distante a déjà disparu : il attribue zéro. Le second l’apprend avant ce retrait : il attribue N+1. Les deux appliquent honnêtement leur contexte. À distance, ils donnent pourtant au même ESI deux versions incompatibles. L’ECMP peut ne pas être construit ; une future route distante sera rejetée par l’un et acceptée par l’autre.
La RFC 9721 impose de synchroniser les séquences MAC et MAC+IP locales ou Peer-Sync-Local entre les PE concernés. Une valeur reçue du pair peut élever le parent local ; tous ses enfants doivent alors suivre. L’objet à vérifier n’est pas une session de synchronisation « verte », mais une époque commune détenue par tous les locuteurs autorisés de l’ESI.
Il faut donc conserver l’appartenance au groupe, l’objet synchronisé, la valeur reçue, l’ancienne valeur locale, l’arbitrage et l’accusé d’application sur chaque PE. L’identité de l’ESI ne prouve pas que ces bases sont identiques.
Le maximum rétablit l’ordre sans découvrir la cause
Une implémentation distante peut annoncer des séquences différentes dans la route MAC seule et dans ses routes MAC+IP. La RFC 9721 demande au récepteur de dériver la version MAC distante à partir du maximum, puis de recalculer lors d’un retrait. En l’absence de route MAC seule, le maximum des routes combinées joue ce rôle.
Cette règle est robuste pour l’interopérabilité. Elle empêche une petite valeur tardive d’effacer une histoire plus élevée déjà connue. Mais elle ne transforme pas le maximum en horodatage. Une hausse peut venir d’un déplacement réel, d’une correction entre pairs, d’une course, d’une entrée obsolète qui rebondit, ou de paquets hostiles côté accès.
Le registre d’errata de la RFC 9721 contient l’erratum technique 9001, rejeté. Il décrit un déploiement mixte dans lequel un PE limité à la RFC 7432 ne sait pas nécessairement dépasser, pour une nouvelle association MAC, l’ancienne séquence attachée à la même IP. L’Area Director a reconnu la limite du nouveau comportement sur un équipement ancien, mais a refusé d’en déduire une incompatibilité rétroactive : l’ancien protocole n’avait jamais promis cette extension et l’encodage demeure utilisable.
La conclusion opérationnelle doit rester exacte. L’erratum ne corrige pas la norme. Il rappelle que les scénarios étendus exigent le comportement RFC 9721 sur les PE qui doivent les résoudre. L’inventaire de versions est une preuve de mobilité, pas un détail d’actif.
La sonde répond à une autre question
Une route distante gagnante déclenche la vérification puis la suppression des états locaux liés. ARP, défini par la RFC 826, et Neighbor Discovery, défini par la RFC 4861, fournissent les mécanismes de voisinage. Une réponse prouve qu’un équipement répond localement pour l’adresse. Elle ne prouve pas qu’il s’agit de la VM voulue, que l’orchestrateur l’autorise ou que le chemin distant fonctionne.
L’absence de réponse reste elle aussi ambiguë : départ réel, silence, filtrage, perte ou état local mal choisi. Il faut enregistrer la cible, l’interface, le délai, la réponse, l’entrée supprimée, le retrait émis et le remplacement effectivement programmé.
La course liée aux MAC partagés rend cette discipline indispensable. Deux IP peuvent changer de MAC en sens opposés alors que les anciennes entrées persistent. Les nouvelles associations rebondissent et les séquences montent jusqu’à ce que les anciennes observations soient éliminées. L’arithmétique ne termine pas la course ; la suppression vérifiée de l’état périmé la termine.
Un doublon est un verdict protecteur, pas une attribution
La RFC 9161 encadre la détection des IP dupliquées dans Proxy ARP/ND. La RFC 9721 sépare trois portées : MAC dupliqué, même IP derrière des MAC différents, et IP seule dans un overlay routé. La RFC 9136 apporte le contexte de Route Type 5 pour ce dernier cas.
Un nombre de mouvements dans une fenêtre donnée peut geler une adresse. C’est une mesure de sûreté face à l’ambiguïté, non une preuve d’attaque. Une migration en boucle, une désynchronisation ou une configuration contradictoire produit des signaux voisins.
La récupération commence côté hôte : il faut supprimer l’affectation fautive. L’âge peut ensuite purger l’état ; une commande d’unfreeze ou de clear peut accélérer le retour. Mais l’unfreeze émet une séquence supérieure. Si le mauvais hôte existe encore, le conflit revient avec un nombre plus grand. Si un seul pair est corrigé, la prochaine synchronisation peut restaurer l’époque contestée.
La clôture d’incident relie donc quatre preuves : correction sur l’hôte, action précisément bornée sur le PE, convergence de tous les pairs et trafic applicatif bidirectionnel. Le numéro ne remplace aucune d’elles.
Le registre qui rend le nombre gouvernable
Un opérateur doit conserver l’intention de l’orchestrateur ; l’événement local ayant appris MAC et IP ; le parent et ses enfants ; les messages de pair ; les annonces et retraits distants ; la capacité de chaque version logicielle ; le calcul du maximum ; les changements RIB/FIB, pont, ARP/NDP et IP-VRF ; les sondes ; les seuils de doublon ; l’autorisation de geler ou libérer ; enfin le résultat du service.
Ces éléments ont des propriétaires différents. La plateforme contrôle l’identité voulue. Le PE observe l’attachement. Le groupe multi-homing partage une époque. BGP distribue une affirmation. Le FIB l’exécute. L’application révèle si le travail s’achève.
La doctrine de spécification minimale de Lu Heng permet de garder un champ commun sans lui attribuer un pouvoir universel. La discipline des couches de réalité empêche l’annonce, la route choisie et le service de se prêter mutuellement leur autorité. La primauté du running code donne plus de poids aux tables synchronisées, aux sondes et aux paquets qu’à un compteur propre.
La RFC 9721 ne rend pas le numéro omniscient. Elle construit autour de sa limite une procédure vérifiable. Si l’exploitation ne conserve pas cette procédure, elle finira par choisir le plus grand nombre parce qu’il est facile à voir — et par agir sur l’histoire qu’elle comprend le moins.
Sources
- Texte intégral de la RFC 9721
- Notice de publication de la RFC 9721
- Dossier IETF de la RFC 9721
- Historique documentaire de la RFC 9721
- Errata de la RFC 9721
- RFC 7432 : BGP MPLS-Based Ethernet VPN
- RFC 9135 : Integrated Routing and Bridging in EVPN
- RFC 9161 : Proxy ARP/ND dans EVPN
- RFC 9136 : IP Prefix Advertisement in EVPN
- RFC 826 : Address Resolution Protocol
- RFC 4861 : IPv6 Neighbor Discovery
- Lu Heng : Running-Code Primacy
- Lu Heng : Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Lu Heng : On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
