Zusammenfassung

  • Ein SNMP-Agent konnte mehrere logische Entitäten und einen Baum physischer Komponenten darstellen; dieselbe Indexzahl konnte je nach Namensraum etwas anderes bezeichnen.
  • Containment-, LP- und Alias-Tabellen machten die lokale Referenz nachvollziehbar, bewiesen aber weder Eigentum noch Ort, Vollständigkeit oder Übereinstimmung mehrerer Agenten.

Eine Fünf kann in zwei Inventarzeilen korrekt sein und trotzdem zwei verschiedene Schnittstellen bezeichnen. RFC 2037 baute sein Entity-Modell um genau diese Gefahr.

Das Dokument beschrieb einen Router in mehreren autonomen Systemen, jeweils mit einer OSPF-Backbone-Area 0.0.0.0. Ebenso konnte ein Gehäuse mehrere logische Router, Bridges oder Repeater hinter einem Management-Endpunkt enthalten. Objektkennung und Index waren nur innerhalb ihres Entstehungskontexts eindeutig.

Der Namensraum gehörte zum Schlüssel

Als naming scope definierte RFC 2037 die in einer Operation erreichbare Managementinformation mit einem gemeinsamen eindeutigen Bezeichnerraum. Bei SNMPv1 und SNMPv2c zeigte entLogicalCommunity, über welche Community die jeweilige logische Entität erreichbar war.

Zwei Werte ifIndex.5 durften daher nicht allein wegen ihrer Ziffer verbunden werden. Zur Beobachtung gehörten Agent, Zeitpunkt, Community und logischer Index. Wer nur „Schnittstelle 5“ speicherte, behielt den Wert und verlor seine Adresse.

Auch Verwaltungsbeziehungen ließen sich nicht aus der Tabelle lesen. Die gleiche Community schuf keine administrative Zugehörigkeit. Eine Zeile sagte nicht, ob die Entität lokal lief oder per Proxy vertreten wurde. Die Verwaltung des Namensraums selbst lag außerhalb der MIB.

Ein leerer Steckplatz blieb Teil der Struktur

Mit entPhysicalContainedIn entstand ein Baum aus Gehäuse, Steckplätzen, Modulen und Ports. Die Kette endete am Index null. Container mussten unabhängig davon erscheinen, ob sie leer oder bestückt waren.

Damit unterschied sich ein bekannter leerer Steckplatz von einem Steckplatz, den der Agent gar nicht modellierte. Letzteres konnte unvollständige Unterstützung, eine veraltete Sicht oder bewusst begrenzte Abdeckung bedeuten. Die Tabelle blieb jedoch das Modell eines Agenten, kein beglaubigtes Ergebnis einer physischen Inventur.

Logisch und physisch waren nicht eins zu eins

entLPMappingTable erlaubte viele-zu-viele-Beziehungen. Eine logische Entität konnte mehrere Komponenten nutzen; mehrere logische Entitäten konnten dieselbe Komponente teilen. Daraus folgten weder Alleineigentum noch administrative Kontrolle, Miete oder rechtliche Verantwortung.

Auch die Granularität war eine Aussage. Bei einem Hub, dessen Ports zwischen Repeatern umgeschaltet werden konnten, würde eine einzige Modulzuordnung die tatsächlich steuerbaren Portbeziehungen verdecken. Kürzer war nicht automatisch genauer.

Der Alias band den Fremdindex an Hardware

entAliasMappingTable verband logische Entität, physische Komponente und einen Bezeichner aus einer anderen MIB, etwa ifIndex. Der logische Index wählte den Namensraum, der physische Index die Komponente, der Alias das externe Objekt.

Der logische Index null diente als Platzhalterregel, wenn keine spezifischere Abbildung vorhanden war. Er erklärte keine weltweite Gleichheit. Fehlende Alias-Zeilen bedeuteten ebenfalls nur, dass kein Alias offengelegt wurde.

Zwei Agenten durften verschieden modellieren

Überlappende Entity-MIB-Instanzen mussten weder äquivalent noch konsistent sein. Agenten konnten andere willkürliche Indizes, Herstellerkennungen und Ausschnitte wählen. Ein gleicher Index bewies agentenübergreifend keine Identität; eine abweichende Beschreibung bewies keinen Fehler.

Für die Abstimmung brauchte es zusätzliche Belege wie Serieninformationen, Topologie oder Betriebsunterlagen. Die Verlässlichkeit folgte der externen Verknüpfung, nicht einer Garantie der Entity MIB.

In RFC 2037 waren alle zugänglichen Objekte des Moduls nur lesbar. Eine erfolgreiche Abfrage bestätigte eine Antwort dieses Agenten in diesem Namensraum zu diesem Zeitpunkt. Sie bestätigte weder aktuelle Bereitstellung noch Erreichbarkeit, Vollständigkeit oder Befugnis. RFC 2737 ergänzte später SNMPv3-Kontexte und beschreibbare Verwaltungsobjekte; RFC 4133 und RFC 6933 folgten. Diese späteren Eigenschaften gehören nicht in die Fassung von 1996.

Quellen