Résumé

  • RFC 9786 remplace une série d’élections par étiquette Ethernet par un verdict commun au port de l’ES ; ce verdict ne teste pas tous les services transportés.
  • Port Mode exige l’unanimité sur l’algorithme et le bitmap de capacités. Une seule PE dissidente ou ancienne peut entraîner le retour de tout l’ES à l’algorithme par défaut.
  • L’état LACP, les caches ARP/ND, les tables MAC et VRF, les annonces P/B, le FIB, les paquets et l’acceptation client sont des preuves séparées.

Un seul verdict pour un portefeuille de services

RFC 9786 définit Port-Active comme un mode actif/secours à l’échelle de l’interface. Là où l’élection DF classique de RFC 7432 distingue l’ES et l’Ethernet Tag, Port Mode retire le tag du calcul. Une PE garde son interface d’accès active ; les autres placent la leur en secours. Les services L2, VPWS, L3 et IRB qui empruntent cette attache suivent ensemble le port élu.

La simplification a une valeur opérationnelle réelle. Le CE conserve un LAG unique, les PE présentent les mêmes paramètres LACP — identifiant système, priorité de port et clé — et l’opérateur obtient un chemin d’interface déterministe, notamment pour des traitements QoS qui se combinent mal avec une distribution de flux. Le mécanisme ne dépend ni de l’underlay ni d’ICCP ou LDP.

Mais son unité de commande devient aussi son unité de risque. Une mauvaise interprétation ne touche plus seulement un EVI : elle peut concerner tout ce que porte l’interface. Le RFC demande au DF de maintenir le port actif et en transfert, et recommande aux non-DF de bloquer les deux sens sur tous les VLAN. Un non-DF peut mettre le lien down ou le conserver en LACP Out of Sync. L’étiquette « DF » indique le vainqueur de la procédure ; elle ne mesure pas que ces comportements ont effectivement eu lieu.

Le bit P ne promet que la même procédure

Le registre IANA BGP Extended Communities attribue le bit 5 à Port Mode Designated Forwarder Election. Avec P=1, Modulo et HRW calculent au niveau de l’ES. Les préférences de RFC 9785 peuvent aussi classer les ports, et le bit Don’t Preempt peut conserver le titulaire après le retour d’une PE mieux classée.

Cette annonce exprime une intention commune, pas un état d’exécution. RFC 8584 impose que toutes les routes ES de type 4 reçues portent le même algorithme et le même bitmap. Une communauté absente, dupliquée ou différente suffit pour revenir à l’algorithme 0 sans capacités. RFC 9786 souligne donc que Port Mode fonctionne par unanimité.

Ce détail agrandit une faute locale. Modifier une seule PE peut pousser l’ensemble de l’ES vers la procédure RFC 7432/RFC 8584 par défaut. Le texte cite alors une répartition inéquitable, une interruption, une perte ou une duplication possibles. Un tableau de bord qui n’affiche que « P=1 » sur la PE locale masque la vraie question : toutes les annonces observées au même instant étaient-elles identiques ?

Même en cas d’accord parfait, le résultat DF ne prouve pas que l’optique est stable, que le CE reconnaît le bon partenaire LACP, que les adjacences sont installées ou que la politique locale a programmé les bonnes tables. Le contrôle a choisi un responsable ; il n’a pas produit son certificat de capacité.

Le secours doit encore acquérir son état

Un port de secours peut être maintenu down. Quand il devient actif, le lien et le réseau ont besoin de se stabiliser. RFC 9786 recommande donc une synchronisation préalable : caches ARP et Neighbor Discovery pour IRB/L3, éventuellement tables VRF associées, et tables MAC pour L2. Ce sont des dépendances de la bascule, pas des sous-produits de l’élection.

Le warm standby par LACP Out of Sync réduit une partie du délai. Le membre reste négocié sans être considéré comme pleinement transférant. Pourtant OOS ne renseigne ni la fraîcheur des voisins, ni le FIB, ni les MAC, ni le choix des chemins distants. Inversement, une copie de table réussie ne prouve pas que le CE collecte et distribue sur ce membre. Chaque reçu couvre un périmètre précis.

Le même principe vaut pour les bits Primary et Backup. RFC 8214 définit la communauté L2-Attr ; RFC 9786 recommande de porter seulement P ou B dans les routes Ethernet A-D per-ES afin d’accélérer la convergence distante. Le rôle per-ES parent doit primer sur le rôle per-EVI. Cette annonce prouve le rôle communiqué, jamais le passage réel d’un paquet.

Les anciennes implémentations RFC 7432 ou RFC 8214 ignorent L2-Attr per-ES et conservent leur résolution par défaut, tout en voyant Single-Active via la communauté ESI Label. Dans un ES mixte, deux équipements peuvent donc décider à partir d’ensembles d’information différents. L’inventaire de capacités fait partie de la preuve, il ne peut pas être supposé.

Une panne de service peut laisser le DF intact

Port Mode neutralise AC-DF : A doit être annoncé à zéro avec P, et A=1 reçu est ignoré. La panne d’une sous-interface et le retrait Ethernet A-D per-EVI qui en découle ne modifient donc pas l’élection du port. C’est volontaire. C’est aussi la démonstration la plus nette qu’un DF inchangé n’atteste pas la santé de chaque service.

Il faut conserver deux vues reliées. La vue port rassemble ESI, membres, algorithme, bitmap complet, timers, DF/BDF, LACP et P/B per-ES. La vue service suit VLAN, EVI, VPWS ou VRF, MAC, ARP/ND, FIB, adjacences, compteurs, accessibilité distante et sondes client. L’une attribue la commande de l’ensemble ; l’autre vérifie le contenu.

RFC 9722 peut aligner les fenêtres d’activation pour réduire un risque transitoire de double DF, sans mesurer la livraison applicative. RFC 9784 traite de vES, de coloration de port et du périmètre EVC/ENNI ; RFC 9785 traite du classement et du non-préemptif. RFC 9786 réutilise certains outils mais pose une autre question : quelle preuve accompagne une décision qui agrège tous les services d’un port ?

La fiche RFC Editor, le Datatracker IETF et la recherche d’errata établissent le dossier normatif. Aucun erratum correspondant n’était affiché lors de la capture du 11 septembre 2026. Aucun de ces éléments ne prouve une implémentation, un déploiement ou une performance.