Zusammenfassung

  • GetNext suchte den ersten lexikografischen Nachfolger unter den für die Anfrage zugänglichen Variablen und gab vollständige OID und Wert zurück.
  • Indem der Manager jeden Antwortnamen erneut vorlegte, konnte er unbekannte Tabellenindizes entdecken, ohne dass der Agent eine besondere Listenoperation brauchte.
  • SNMPv2 führte endOfMibView je Variablenbindung und GetBulk ein; Zugriffsansicht, Nachrichtengröße und zeitliche Veränderung begrenzten den Rundgang weiterhin.

Der Agent beantwortete eine Frage, die der Manager noch nicht formulieren konnte

MIB-Definitionen benannten Spalten für Zieladresse, nächsten Hop oder Metrik. Die Instanzsuffixe entstanden jedoch aus den Zeilen, die ein bestimmtes Gerät gerade führte. Ein gewöhnliches GetRequest für den bloßen Spaltennamen konnte diese Instanzen nicht aufzählen.

RFC 1067 definierte 1988 GetNextRequest. Der Agent ordnete die Namen aller in der einschlägigen MIB view lesbaren Variablen lexikografisch und wählte den unmittelbaren Nachfolger des angefragten Namens. Seine Antwort enthielt nicht nur den Wert, sondern auch die vollständige OID.

Der Manager setzte diese OID in die nächste Anfrage ein. Die nächste Antwort rückte um eine Position weiter. Aus einer dünnen Nachfolgerregel entstand eine Schleife, deren Gedächtnis, Ziel und Ende außerhalb des Agents lagen.

Tabellen waren aus Namen zusammengesetzt

Die MIB war ein virtueller Informationsspeicher, keine relationale Datenbank. Ein Variablenname verband die OBJECT IDENTIFIER des Objekttyps mit einem Fragment, das die Instanz bezeichnete. RFC 2578 beschrieb später die konzeptionellen Tabellen und INDEX-Klauseln von SMIv2.

Das historische Routingbeispiel startet mit drei Spalten-OIDs. Die Antwort liefert die indizierten Namen von Ziel, Next Hop und Metrik für eine Zeile. Diese Namen werden erneut gesendet, worauf die nächste Zeile folgt. Maßgeblich ist die Zahlenfolge der OID, nicht die alphabetische Reihenfolge menschenlesbarer Bezeichner und nicht die Sortierung einer Oberfläche.

Diese Arbeitsteilung hielt den Agent klein. Detaillierte Zustandsbeobachtung sollte hauptsächlich durch Polling im Managementzentrum erfolgen; wenige Traps lenkten Zeitpunkt und Schwerpunkt. Ein reiches Erkundungswerkzeug konnte aus einer minimalen gemeinsamen Operation entstehen.

Eine gültige Antwort konnte die Tabelle verlassen

Nach der letzten Instanz einer Spalte folgt möglicherweise die erste Instanz der nächsten Spalte. Nach dem letzten Objekt einer Tabelle geht der OID-Namensraum mit einem fremden Objekt weiter.

RFC 3416 zeigt beides: Der Rundgang durch die IP-net-to-media-Tabelle wechselt die Spalte und tritt anschließend aus der Tabelle heraus. Das fremde Objekt ist kein Protokollfehler. Sein Präfix zeigt dem Manager, dass sein gewählter Unterbaum beendet ist.

Darum muss der Manager die Zielgrenze prüfen. Wer nur auf einen Fehler wartet, kann benachbarte MIB-Bereiche einlesen und das Ergebnis fälschlich als zusätzliche Vollständigkeit darstellen.

SNMPv1 behandelte das Ende gröber. Nach RFC 1157 führte bereits ein angefragter Name ohne zugänglichen Nachfolger zu noSuchName und einem Fehlerindex. Das Ende einer Spalte beeinträchtigte damit eine Antwort, in der andere Spalten noch hätten fortschreiten können.

SNMPv2 trennte die Enden mehrerer Wege

RFC 1448 gab einer erschöpften Variablenbindung endOfMibView. Andere Bindungen derselben Antwort konnten weiterhin Namen und Werte tragen. RFC 1905 übernahm die Regel in die weitere Standardisierung; RFC 3416 führt sie fort.

Die Aussage bleibt lokal: Für diese Bindung gibt es in der für diese Operation sichtbaren Ordnung keinen späteren zugänglichen Namen. Sie sagt nicht, dass das Gerät keine weiteren Managementdaten besitzt.

GetBulk bündelte mehrere Schritte. non-repeaters erhalten je einen Nachfolger, während die übrigen Bindungen mit max-repetitions mehrere Positionen anfordern können. Weniger Austausch bedeutet jedoch keine garantierte Komplettantwort. Größenlimits dürfen das Ergebnis verkürzen. RFC 1905 warnt zudem davor, mit großen Wiederholungswerten IP-Fragmentierung und damit geringere Zuverlässigkeit zu provozieren.

Sichtbarkeit war Teil der Semantik

Der Nachfolger wird nur aus den für die Anfrage zugänglichen Variablen gewählt. RFC 3415 baut MIB views innerhalb eines Kontexts aus einbezogenen und ausgeschlossenen Unterbäumen und ordnet Gruppen unterschiedliche Rechte zu.

Zwei berechtigte Manager können daher demselben Gerät dieselbe Start-OID geben und unterschiedliche korrekte Nachfolger erhalten. Ein ausgeblendetes Objekt nimmt an der sichtbaren Ordnung nicht teil. endOfMibView beweist weder das Fehlen privater Module noch das Fehlen anderer Kontexte oder privilegierter Ansichten.

Auch die Zeit bleibt sichtbar. Zwischen mehreren Anfragen kann sich eine Routing- oder Nachbartabelle ändern. GetBulk verkürzt die Dauer, schafft aber keine Snapshot-Isolation. Das in RFC 3416 parallel gelesene sysUpTime hilft beim Einordnen und beim Erkennen eines Neustarts; es macht nacheinander gelesene Zeilen nicht atomar.

Quellen und Reichweite

Die Regeln sind in RFC 1067, RFC 1157, RFC 1448, RFC 1905, RFC 2578, RFC 3415 und RFC 3416 belegt. Sie bestätigen Semantik und Entwicklung, nicht die heutige Verbreitung, Produktkonformität, sichere Übertragung oder die betriebliche Wirkung eines gelesenen Wertes.