Résumé

  • La RFC 5240 expose, dans une même MIB, l’état local de l’élection BSR et des lignes de configuration inscriptibles. Lire révèle une topologie ; écrire peut modifier les candidats et les priorités.
  • Un drapeau « élu », un délai d’expiration ou une notification ne décrit qu’un routeur et une zone à un instant donné. Aucun de ces éléments ne démontre à lui seul la convergence du domaine ni la livraison du trafic.

Le poste d’observation possède une poignée

La MIB BSR de PIM est souvent présentée comme un inventaire : quatre tables, des adresses, des priorités et des temporisateurs. Deux tables décrivent la candidature locale d’un RP ou d’un BSR. Deux autres montrent l’ensemble RP détenu par le BSR élu et le BSR que le routeur croit élu.

Mais l’inventaire n’est pas neutre. Plusieurs colonnes sont read-create. Un responsable autorisé peut créer une candidature, changer une adresse, une priorité ou la longueur de masque utilisée par le hachage. Le même canal SNMP qui répond à une requête de lecture peut donc accepter une mutation de l’entrée électorale.

Il faut conserver deux récits. Le premier est descriptif : quel agent a renvoyé quelle valeur, pour quelle zone, à quelle heure ? Le second est causal : quelle identité a demandé quelle modification, quelle configuration a été acceptée, quelle élection a suivi et quel effet le réseau a-t-il effectivement observé ? Une réponse positive à SET ne remplit que la première étape du second récit.

Une candidature n’est pas un mandat partagé

Dans la table Candidate-BSR, l’adresse, la priorité et la longueur de masque sont des intentions locales. Le booléen indiquant si ce routeur est élu est en lecture seule. Le temporisateur d’amorçage vaut zéro quand le routeur n’est pas élu. Zéro peut donc être un état normal, non la preuve d’un mécanisme bloqué.

La table du BSR élu contient l’adresse, la priorité, la longueur de masque et le temps minimal avant expiration. Elle montre la croyance actuelle de cet agent. Deux routeurs peuvent momentanément présenter des croyances différentes pendant une transition ou après une perte de messages. Dire « l’élection a convergé » exige des observations indépendantes ou des paquets d’amorçage sur le chemin de distribution.

Même cet accord ne prouve pas le service. Il faut encore relier le BSR à la diffusion des associations groupe–RP, à leur installation et aux jointures puis au trafic multicast. L’autorité déclarée et l’effet observable sont des faits distincts.

Le nombre le plus élevé n’a pas toujours le même sens

La priorité du Candidate-BSR favorise la valeur numérique la plus haute. Pour un Candidate-RP, la valeur la plus basse représente au contraire la meilleure priorité. Une automatisation qui applique une règle uniforme aux deux colonnes peut déplacer l’autorité dans la direction opposée à celle prévue.

La RFC 5240 décrit explicitement le risque : un Candidate-BSR à haute priorité peut prendre la fonction élue ; un Candidate-RP à priorité numérique plus faible peut être choisi pour un préfixe de groupe. Ces opérations peuvent perturber le service. Le contrôle d’accès ne doit donc pas s’arrêter à « lecture » ou « écriture » : il doit distinguer création, suppression, adresse, priorité, temporisation et paramètres de hachage.

La lecture mérite également une protection. Elle révèle les candidats, l’élu et une partie de la topologie multicast. Un secret de transport sans politique d’autorisation précise ne résout pas le problème d’agence : il protège la session, pas le droit d’agir.

La table RP est un atelier, pas le réseau

Le BSR élu maintient des associations groupe–RP reçues par les annonces des candidats ou créées localement. Une politique locale décide d’en inclure certaines ou toutes dans les messages Bootstrap. Une ligne présente dans la table peut donc ne jamais être diffusée.

Et la diffusion n’est encore qu’un passage. Le récepteur doit obtenir le message, accepter l’association, l’utiliser pour la plage concernée et traduire cette décision en état PIM puis en trafic. Pour chaque étape, la preuve change : version de table, politique, paquet émis, paquet reçu, association installée, jointure et données.

Un tableau de bord qui affiche simplement « RP actif » efface ces frontières. Il transforme une possibilité en résultat et attribue au BSR une certitude sur des routeurs qu’il n’observe pas.

Les notifications ne forment pas un consensus

Le groupe de diagnostic facultatif signale qu’un candidat gagne ou qu’un élu perd. Une notification date une transition locale ; elle n’est ni obligatoire ni garantie à la livraison. Son absence peut signifier stabilité, fonction non implémentée, filtrage, défaut d’abonnement ou perte du message.

Sa présence ne vaut pas quorum. Elle indique qu’un agent a produit un événement avec quelques objets associés. La vérifier par un sondage séparé, un autre routeur et un paquet observé évite de donner à un seul émetteur le pouvoir de raconter sa propre réussite.

Enfin, les index font partie de la preuve. Type d’adresse, préfixe normalisé, longueur et index de zone déterminent l’identité de la ligne. Des bits non nuls au-delà de la longueur du préfixe désignent une autre entrée. En supprimant ces clés lors de l’ingestion, on conserve une valeur exacte mais on détruit son attribution.

La RFC 5240 ne relate aucun incident réel et ne qualifie aucun produit. Elle définit des objets et leurs conséquences de sécurité. La discipline du code en fonctionnement défendue par Lu Heng impose alors une règle simple : une interface n’est pas une source d’autorité parce qu’elle est lisible. Il faut savoir qui a observé, qui a modifié et quel effet indépendant a suivi.

Sources