Résumé

  • La RFC 9625 crée un Supplementary Broadcast Domain afin que l’intérêt appris dans un BD ordinaire atteigne aussi les PE du même Tenant Domain qui ne sont pas reliés à ce BD.
  • Un PE fusionne les états IGMP/MLD de plusieurs BDs en routes SBD-SMET ; l’absence de snooping ou de prise en charge RFC 9251 peut même signifier « intéressé par tous les flux ».
  • La preuve exploitable sépare le rapport client, la politique locale, la correspondance BD/SBD, la fusion, l’import de route, l’élection des passerelles, l’éligibilité OIF, l’émission, les doublons et la réception.

L’alerte de capacité est apparue loin du port d’origine

Le premier symptôme n’était pas un paquet perdu. C’était une croissance d’état sur plusieurs PE qui n’avaient aucun AC vers le broadcast domain du récepteur. La recherche a fini par retrouver un rapport IGMP entré par un seul port. Entre ce port et les tables distantes, OISM avait fait exactement ce qu’on lui demandait : élargir la visibilité de l’intérêt au Tenant Domain.

Cette amplification est nécessaire au routage optimisé. Un ingress PE relié au sous-réseau source doit savoir qu’un autre sous-réseau contient un récepteur, même s’il ne partage aucun BD ordinaire avec l’egress PE. Enfermer le rapport dans son BD rendrait cette décision impossible ou obligerait à hairpinner le trafic.

Mais la portée technique n’est pas la portée de l’autorisation. Le client a exprimé un intérêt local. Il n’a pas, par ce seul message, approuvé une dépense de mémoire, de contrôle et de forwarding sur tous les PE du tenant. La politique d’admission doit produire ce second reçu avant que l’amplification commence.

La norme décrit elle-même le rayon d’impact

Les considérations de sécurité de la RFC 9625 sont inhabituelles par leur franchise. Une personne ayant accès à un seul BD peut provoquer l’annonce de routes SMET importées par tous les PE du Tenant Domain. L’impact potentiel sur les ressources ne se limite donc plus aux PE attachés à ce BD, contrairement à une diffusion strictement locale.

La réponse proposée n’est pas de renoncer à SBD-SMET. L’implémentation doit permettre de filtrer ou de contrôler les rapports IGMP/MLD reçus des hôtes. En exploitation, cela veut dire identifier le port, le client, le groupe, la source, le mode Include/Exclude, le débit de rapports et le budget d’état avant de créer une annonce partagée.

Il faut aussi vérifier la fin du phénomène. Refuser un nouveau Join n’efface pas l’état déjà installé. Le reçu de récupération relie l’expiration ou le Leave local, le recalcul de la fusion, le retrait BGP et la disparition de l’état sur chaque PE importateur.

Le SBD relie les BDs sans devenir un LAN client

Chaque PE OISM d’un Tenant Domain reçoit le même SBD. Son SBD-RT est importé à travers le domaine, mais le SBD n’a pas d’attachment circuits. Aucun hôte ne s’y connecte directement. Il fournit un contexte commun pour représenter une source ou un récepteur dont le BD réel n’existe pas localement.

Cette propriété explique sa puissance et son risque de simplification. Pour un PE éloigné, le SBD peut devenir le « BD source apparent ». Le paquet reste routable, mais l’appareil ne voit plus immédiatement le BD ordinaire où l’événement est né. Si la télémétrie ne conserve que le SBD, la provenance locale disparaît.

Le dossier d’audit doit donc conserver le couple : BD réel et SBD de projection. Ajoutons l’EVI, l’Ethernet segment, le Tenant Domain et l’époque de configuration. « Associé au SBD » n’est pas une réponse suffisante lorsque deux PE ont pu dériver des frontières différentes.

La fusion comprime plusieurs causes en un seul signal

Un PE calcule ses routes SBD-SMET en fusionnant l’état IGMP/MLD de tous les BDs du Tenant Domain auxquels il est attaché. Un intérêt (*,G) dans un BD peut couvrir le besoin (S,G) d’un autre. Une route plus large attire alors tous les flux nécessaires avec moins d’annonces.

La compression est correcte au regard du forwarding, mais elle perd naturellement du détail causal. La route agrégée n’indique pas forcément quel BD a demandé le groupe en premier, combien de récepteurs subsistent, ni quel Leave supprimera la dernière justification. Le wildcard peut rester valide alors que la majorité de ses causes ont disparu.

Conservons un journal de dérivation : membres contributifs, époques, règles de fusion, clé annoncée et condition de retrait. Ainsi, l’agrégat reste une optimisation réversible plutôt qu’une nouvelle vérité sans provenance.

L’intérêt universel peut n’être qu’un défaut de compatibilité

Lorsque le snooping IGMP/MLD ne fonctionne pas sur un AC, la RFC considère cet AC intéressé par tous les flux. Lorsqu’un PE distant ne signale pas la prise en charge des procédures RFC 9251, il est lui aussi supposé intéressé par tous les flux. Ces défauts évitent de casser le service avec des équipements moins expressifs.

Ils ne mesurent aucune demande réelle. Deux éléments identiques dans une OIF list peuvent donc avoir des origines opposées : l’un vient d’un Join explicite, l’autre de l’impossibilité de prouver l’absence d’intérêt. Les agréger sous un même compteur « receivers » fausse la capacité et masque l’endroit où une modernisation réduirait le trafic.

Chaque entrée doit porter son motif : rapport observé, configuration statique, défaut sans snooping ou compatibilité legacy. La durée de vie et le niveau de confiance peuvent ensuite suivre cette provenance.

Route Targets et Tag IDs donnent une classification bornée

La RFC définit comment IMET, SMET, S-PMSI et Leaf s’attachent à un BD ordinaire ou au SBD. Les Route Targets et, selon le modèle de service, le Tag ID du NLRI servent à cette classification. Plusieurs SBD-RTs, deux BD-RTs ordinaires incompatibles ou un mélange inter-tenant constituent des erreurs ; le PE applique treat-as-withdraw selon la RFC 7606.

Ce contrôle sémantique est essentiel parce que les routeurs BGP intermédiaires ne détectent généralement pas l’erreur EVPN. Le PE de réception peut attester que l’annonce respectait sa propre table de correspondance au moment de l’import.

Il ne peut pas, par cette seule validation, attester que l’affectation RT était autorisée, que l’origine avait le droit d’élargir le groupe ou que tous les PE partageaient la même configuration. Archivez l’annonce brute, le voisin, l’origine, les RTs, le Tag ID, la table locale et la décision. Une route acceptée prouve une classification, pas une volonté du tenant.

Une élection désigne l’actif sans créer son autorité

L’interfonctionnement avec des PE non-OISM repose sur des IP Multicast Gateways. Les candidats annoncent leur capacité, la présence de leur route IMET pour le BD réduit l’ensemble, puis une élection de DF choisit l’IPMG-DF. Des mécanismes voisins choisissent MEG ou PEG pour les domaines externes.

Le résultat déterministe évite plusieurs passerelles actives pour la même fonction. La RFC avertit pourtant qu’un attaquant contrôlant une passerelle peut influencer l’élection et modifier le forwarding. « A gagné l’élection » et « était autorisé à devenir maître » ne sont donc pas synonymes.

Le reçu doit réunir les candidats, drapeaux de capacité, routes de présence, algorithme, préférences, gagnant, habilitation de gestion et époque. L’alerte utile compare le gagnant à la liste autorisée, même lorsque l’algorithme a produit un résultat unique et cohérent.

L’OIF list ne dit pas encore ce qui est sorti

Au niveau 2, le PE choisit l’état (S,G) ou se rabat sur (*,G), puis applique l’OIF list en fonction du mode d’arrivée et du BD source apparent. La liste peut comprendre des ACs, des tunnels distants et une interface IRB. Elle évolue avec les rapports et les routes, et la procédure ne réalise pas de contrôle RPF au niveau 2.

L’appartenance à la liste ne suffit pas. Pour un segment multihomé, le label ESI exige que le PE soit DF et que la trame ne retourne pas vers son segment d’origine. Avec local bias, l’identité de l’ingress PE décide si le segment a déjà reçu une copie. Le trafic interne ne doit pas redescendre par l’IRB du SBD, sinon une seconde distribution devient possible.

Pour une trame donnée, il faut enregistrer l’état sélectionné, le BD apparent, la version de la liste, les données ESI ou local-bias, chaque suppression et chaque émission. Un snapshot OIF ne différencie pas une suppression légitime d’un refus de service involontaire.

La limite anycast montre que même l’adresse n’est pas une identité

La RFC impose une restriction nette : s’il existe des récepteurs (*,G) dans le Tenant Domain, il ne doit pas y avoir de sources anycast pour G à l’intérieur du domaine. OISM distribuerait les deux flux (S,G) et pourrait remettre des doublons. La même adresse source ne prouve pas que deux émissions représentent un seul événement.

Ce point doit devenir un prérequis testable, pas une note de conception. Inventorier les sources, contrôler la combinaison avec les états wildcard et observer les doublons au récepteur donnent trois reçus distincts. Un plan de contrôle propre n’atteste pas que la topologie interdite était absente au moment du paquet.

La chaîne de preuve repart du port et se termine au récepteur

Le premier reçu contient le rapport client, l’identité d’accès, l’AC, le BD ordinaire, l’EVI, le segment, le tenant, la politique et l’heure. Viennent ensuite la transition d’adhésion, la fusion multi-BD et la route SBD-SMET avec ses contributeurs et sa condition de retrait.

Puis la chaîne conserve RTs, Tag ID, origine, import, état installé, rôles de passerelle et élection. Pour la donnée, elle joint la trame à son BD apparent, à son état multicast, à l’OIF list effective, aux décisions d’éligibilité, aux tunnels et aux transmissions AC. La réception, le nombre de copies et la consommation applicative restent des faits ultérieurs.

La RFC 9625 fournit la mécanique de portée. Cette chaîne décide si la portée était voulue, encore justifiée, correctement exécutée et entièrement retirée.

Sources