Résumé

  • Un seul agent SNMP pouvait représenter plusieurs entités logiques et une arborescence de composants physiques ; le même indice changeait de sens avec la portée.
  • Les tables de confinement et de correspondance permettaient de reconstruire une identité locale, sans prouver propriété, proximité, exhaustivité ni accord entre agents.

Une base d’inventaire peut contenir deux fois le chiffre 5 sans contenir deux fois la même interface. C’est la difficulté que RFC 2037 plaçait au centre de l’Entity MIB.

Un routeur pouvait participer à plusieurs systèmes autonomes, chacun avec une zone dorsale OSPF 0.0.0.0. Un châssis pouvait héberger plusieurs routeurs, ponts ou répéteurs logiques, tous observés par un seul agent. L’identifiant d’objet et l’indice restaient corrects, mais ils n’étaient uniques que dans l’espace où l’agent les avait émis.

La portée faisait partie de l’adresse

Le texte nommait « portée de nommage » l’ensemble d’informations accessible en une opération et partageant un espace d’identifiants unique. Sous SNMPv1 et SNMPv2c, entLogicalCommunity indiquait la communauté donnant accès à la portée de chaque entité logique.

Deux valeurs ifIndex.5 issues de deux entités logiques ne décrivaient donc pas nécessairement la même interface. Une preuve exploitable devait conserver le point de collecte, l’heure, la communauté et l’indice logique. Retrancher ces éléments transformait une coordonnée exacte en nombre ambigu.

La table logique ne permettait pas davantage de conclure à une autorité commune. Deux entités utilisant la même communauté n’avaient aucune relation administrative implicite. La ligne ne disait pas non plus si l’entité fonctionnait dans le châssis ou si l’agent la joignait par procuration. Enfin, l’Entity MIB ne gérait pas elle-même les portées qu’elle désignait.

Un emplacement vide restait un composant du modèle

entPhysicalContainedIn construisait une arborescence : un châssis contenait des emplacements, ceux-ci des modules, puis des ports. La remontée aboutissait à l’indice zéro. RFC 2037 exigeait qu’un conteneur apparaisse, qu’il soit rempli ou vide.

Cette règle distinguait l’emplacement vacant de l’emplacement absent du modèle. Le premier était une absence observée dans une structure connue. Le second pouvait signaler un support incomplet, une vue périmée ou un sous-ensemble choisi par l’agent. La table ne constituait pourtant ni un inventaire physique certifié ni la preuve d’une inspection récente.

La carte logique-physique était plusieurs-à-plusieurs

entLPMappingTable liait les entités logiques aux pièces qui les supportaient. Une entité logique pouvait s’appuyer sur plusieurs composants ; plusieurs entités pouvaient partager le même composant. La relation ne disait donc ni propriété exclusive, ni administration, ni responsabilité contractuelle.

La granularité comptait. Dans l’exemple d’un concentrateur dont les ports pouvaient changer de répéteur, remplacer plusieurs correspondances de ports par une seule correspondance de module effaçait la surface de contrôle réelle. Le module paraissait stable alors que l’affectation restait modifiable port par port.

L’alias reliait l’indice externe à la matière

entAliasMappingTable associait une entité logique, une entité physique et un identifiant venu d’une autre MIB, tel qu’un ifIndex. L’indice logique sélectionnait la portée ; l’indice physique sélectionnait le composant ; l’alias indiquait l’objet externe.

La valeur logique zéro pouvait servir de correspondance générique lorsqu’aucune ligne plus précise n’existait. Ce joker restait une règle par défaut dans la vue d’un agent, pas une identité universelle. De même, l’absence de ligne d’alias signifiait qu’aucun alias n’était exposé, pas qu’aucune relation opérationnelle n’existait.

Deux agents n’avaient pas à raconter la même histoire

RFC 2037 autorisait des agents distincts à représenter des ensembles qui se chevauchaient. Leurs indices arbitraires, leurs identifiants de fabricant et leurs sous-ensembles pouvaient différer. Les instances n’avaient pas à être équivalentes ni cohérentes.

Le rapprochement exigeait donc une preuve extérieure : numéro de série, topologie, registre d’exploitation ou autre jointure validée. Un indice identique n’établissait pas l’identité ; une description différente ne prouvait pas l’erreur.

Dans la version de 1996, tous les objets accessibles définis par le module étaient en lecture seule. Cela prouvait seulement la fonction d’observation du modèle, pas son omniscience. Une lecture réussie n’attestait ni déploiement actuel, ni accessibilité, ni exhaustivité, ni autorité. RFC 2737 ajouta plus tard le contexte SNMPv3 et des objets administratifs modifiables ; RFC 4133 puis RFC 6933 poursuivirent la révision. Ces ajouts ultérieurs ne sont pas des propriétés de RFC 2037.

Sources