Résumé

  • RFC 1286, publié en décembre 1991 sur le parcours de normalisation, ajoutait au MIB SNMP des objets de gestion pour les ponts inspirés d’IEEE 802.1d. Le texte cherchait volontairement un ensemble réduit, utile et non redondant, sans instrumenter lourdement les sections critiques.
  • Un port de pont est associé à une interface du groupe interfaces, mais plusieurs ports peuvent partager cette interface et le numéro de port n’a aucune relation obligatoire avec ifIndex. Les compteurs ne couvrent que le sous-ensemble de trafic ponté. Une entrée de transfert indique où une adresse source a été observée, ou le fait qu’une information de transfert existe sans port appris ; elle n’établit ni identité, ni topologie complète, ni livraison.

Le MIB ne prétendait pas être le réseau entier

RFC 1286 définit des objets pour la gestion de ponts transparents ou à routage par la source, y compris lorsque les sous-réseaux raccordés ne sont pas des segments LAN. Pourtant son ambition n’était pas d’encoder tout ce qu’un opérateur pourrait vouloir savoir. Les auteurs disent partir d’un petit ensemble d’objets essentiels, exiger une utilité pour la gestion de panne ou de configuration, tenir compte de l’usage courant, limiter le nombre total et exclure les objets redondants, dérivables ou inutiles.

Cette discipline donne le bon statut à une variable de MIB. Elle est une surface de gestion définie, pas une photographie exhaustive du boîtier, du câblage ou de l’organisation qui l’exploite. L’absence d’un champ n’efface pas la réalité qu’il ne couvre pas. La présence d’un champ ne donne pas au lecteur le droit de l’étendre à ce que le texte n’a pas mesuré.

Le lien entre port et interface était une correspondance, pas une identité

Le groupe interfaces de MIB-II décrit des interfaces attachées à un « subnetwork », terme que RFC 1286 distingue explicitement d’un sous-réseau IP. Le pont possède, lui, des ports. Chaque port est associé à une interface et dot1dBasePortIfIndex expose l’instance ifIndex de l’interface correspondante.

La relation s’arrête là. Le RFC prévoit qu’une même interface puisse être associée à plusieurs ports, notamment lorsque plusieurs circuits virtuels X.25 sont représentés un à un par des ports tout en restant sur une interface. Chaque port a son numéro unique, mais ce numéro n’a aucun lien obligatoire avec le numéro d’interface. Dans le cas simple ils peuvent être égaux ; l’égalité n’est pas une règle de sens.

Ainsi, lire port 4 et interface 4 ne prouve ni que le port soit une prise physique, ni que l’interface n’ait qu’un rôle, ni qu’aucun autre port ne la partage. Le MIB relie deux plans de description parce que le gestionnaire doit les mettre en relation. Il ne les fusionne pas.

Les compteurs de pont ne totalisaient pas tout le trafic de l’interface

Le texte envisage l’entité qui fait autre chose que du pontage sur ses interfaces. Il donne le cas d’une entité qui route les datagrammes IP et ne ponte que d’autres protocoles. Seule cette dernière partie du trafic appartient au domaine fonctionnel du pont.

La conséquence est nette : le Bridge MIB, et en particulier ses compteurs, ne s’applique qu’aux données envoyées ou reçues pour un protocole ponté. Il ne représente pas nécessairement toutes les données qui ont traversé l’interface. Un compteur de port de pont peut donc appuyer une affirmation étroite sur la fonction de pontage. Il ne devient pas, sans autre mesure, le volume complet de la ligne, le débit d’une application ou la preuve qu’aucun autre protocole n’a circulé.

Cette limite n’est pas une faiblesse accidentelle. Elle conserve le dénominateur de la mesure. Une vue de gestion peut être exacte dans son domaine tout en étant insuffisante pour un énoncé plus large.

La table de transfert enregistrait une observation de pontage

Pour le pont transparent, dot1dTpFdbAddress est une adresse MAC unicast pour laquelle le pont possède une information de transfert ou de filtrage. dot1dTpFdbPort vaut soit zéro, soit le numéro du port où une trame dont cette adresse était source a été vue. Zéro n’est pas l’absence de toute information : le pont peut avoir une information de transfert ou de filtrage, par exemple statique, sans avoir appris de numéro de port.

Le statut différencie other, invalid, learned, self et mgmt. Une entrée invalide peut avoir été apprise puis vieillie sans être encore retirée de la table. Une entrée apprise signifie que le port enregistré a été appris et est utilisé. Une entrée self concerne l’une des adresses du pont. Une entrée de gestion correspond à une adresse statique.

Ces distinctions décrivent l’état de la décision de transfert telle que le pont la tient. Elles ne disent pas qui possède l’adresse, où se trouve une personne, si l’adresse est encore raccordée, si une trame est arrivée à sa destination ou si une action a été autorisée. Une entrée vieillie mais visible est précisément le rappel qu’une trace de gestion n’est pas automatiquement une observation présente.

Une référence de pont unique ne devenait pas un titre de propriété

dot1dBaseBridgeAddress est l’adresse MAC utilisée lorsque le pont doit être désigné de manière unique. Le RFC recommande, sans l’imposer, de choisir la plus petite adresse MAC parmi les ports du pont. Avec la priorité de spanning tree, elle forme le BridgeIdentifier employé par le protocole.

La valeur est donc précieuse pour coordonner le protocole. Elle ne prouve pas qu’un équipement précis existe encore, qu’une personne le possède, qu’une requête de gestion est authentifiée, que la topologie a convergé ou qu’un transfert a réussi. Une référence unique permet de distinguer un objet dans un mécanisme ; elle ne devient pas le monde autour de cet objet.

Sources et limites des preuves

Cet article utilise RFC 1286 — Definitions of Managed Objects for Bridges. La source soutient le domaine du Bridge MIB, le lien port/interface, le périmètre des compteurs, la référence unique du pont et les états de la table de transfert. Elle ne prouve aucun pont, port, interface, hôte, propriétaire, trafic complet, topologie, autorisation, livraison ou déploiement actuel.