Zusammenfassung

  • RFC 1516 erlaubte einen kurzen Aufschub des Repeater-Resets, damit die SNMP-Antwort übertragen werden konnte; sie belegte den Verwaltungsaustausch, nicht den Abschluss der Hardwareaktion.
  • Der disruptive Selbsttest ließ offen, ob eingehende Pakete weitergegeben wurden, während Verwaltungszähler und administrativer Portzustand erhalten blieben.
  • Zustandsaktualisierung und Abschlussmeldung folgten später. Für eine Diensterholung war weiterhin ein unabhängiger Test nötig.

Die Antwort vor dem dunklen Moment

Eine Managementstation schrieb reset(2) in rptrReset. Nach RFC 1516 durfte der Agent den Reset kurz verzögern, etwa lange genug, um die SNMP-Antwort zu übertragen. In jedem Fall musste die Antwort gesendet werden.

Ein empfangenes noError gehörte damit zur offenen Anfrage. Es sagte nicht, dass der Repeater die nachfolgende Aktion bereits beendet hatte. Der positive Kontrollbeleg konnte genau deshalb eintreffen, weil die disruptive Phase noch nicht begonnen hatte.

Zum Reset gehörte ein disruptiver Selbsttest, dessen Art nicht festgelegt war. Er durfte keine Pakete einspeisen und die Managementfunktionen nicht stören; während des Tests empfangene Pakete konnten jedoch weitergeleitet werden oder auch nicht. Eine erreichbare Managementebene war kein Nachweis einer störungsfreien Datenebene.

Der Lesewert führte kein Arbeitsprotokoll

Das Schreiben von reset(2) löste den Übergang in den START-Zustand aus. noReset(1) zu schreiben hatte keine Wirkung, und jede Leseoperation lieferte noReset(1). Das Objekt speicherte weder „angefordert“ noch „läuft“ oder „abgeschlossen“.

Wer nur den späteren MIB-Wert sammelte, verlor die Handlung. Request ID, Ziel, Schreibwert, Antwort und Zeitpunkte mussten außerhalb des Objekts aufbewahrt werden. Derselbe Ruhewert konnte bedeuten, dass nie ein Befehl kam oder dass er längst verbraucht war.

Auch der Name Repeater MIB begrenzte die Aussage. Hub und Konzentrator konnten damals Gehäuse mit Token Ring, FDDI, Bridges, Routern und Terminalservern bezeichnen. Standardisiert wurde der IEEE-802.3-Repeater, nicht jede Funktion des verkauften Systems.

Was der Reset nicht löschen durfte

Die Aktion setzte die Managementzähler der RFC nicht zurück und änderte portAdminStatus nicht. Ein administrativ abgeschalteter Port blieb abgeschaltet. Messhistorie und lokale Richtlinie überquerten den Hardware-Reset.

Diese Kontinuität hatte eine klare Grenze. Ein erhaltener Zähler beweist nicht, welche Pakete den Selbsttest passierten. Ein unveränderter administrativer Zustand belegt die fortbestehende Absicht, nicht die Verfügbarkeit von Link oder Anwendung.

Hardwarezustand, Richtlinie und Beobachtung hatten verschiedene Lebenszyklen. „Reset“ als „alles vergessen“ zu behandeln, hätte gerade die Belege vernichtet, mit denen die Wirkung des Eingriffs geprüft werden konnte.

Der Abschluss besaß eine andere Nachricht

Nach dem Selbsttest aktualisierte der Agent rptrOperStatus und den agentspezifischen rptrHealthText und sendete einen Health Trap. rptrResetEvent wurde dagegen beim Abschluss eines durch Management ausgelösten Resets gesendet. Set-Antwort und Abschlussmeldung bezeugten unterschiedliche Zeitpunkte.

Auch der spätere Kanal war nicht vollständig. Zwischen aufeinanderfolgenden Reset-Events mussten mindestens fünf Sekunden liegen; unterdrückte Meldungen wurden verworfen, nicht nachgereicht. Ein Neustart des Agents verwendete coldStart oder warmStart statt rptrResetEvent. Das Ausbleiben einer Meldung widerlegte nicht jede Aktivität.

Der Health Text war agentspezifisch. Ein nicht disruptiver Test durfte sogar nach einem trivialen Test „okay“ melden. Agentenzustand, Reset-Abschluss und nutzbarer Dienst blieben getrennte Behauptungen.

Die Korrektur blieb im Nachfolger erhalten

RFC 1368 erhielt bereits Zähler und Administrationszustand. Die Änderungsliste von RFC 1516 nennt jedoch ausdrücklich die Klarstellung des kurzen Aufschubs und der Schritte nach Reset und Selbsttest. Die Reihenfolge war eine bewusste Vertragskorrektur.

RFC 2108 ersetzte die MIB durch ein SMIv2-Superset für mehrere Repeater und 100 Mb/s. Alte Skalare wurden deprecated, doch rptrInfoReset bewahrte das Muster: antworten, disruptiv handeln, Managementinformation erhalten und mit rptrInfoResetEvent abschließen.

RFC 1157 definiert die Zuordnung von Anfrage und Antwort über die Request ID und die erfolgreiche Set-Antwort. RFC 1215 liefert die Trap-Konvention. Beide identifizieren Nachrichten, machen aber aus einer frühen Nachricht keinen Zeugen eines späteren Ergebnisses.

Ein prüfbarer Reset-Nachweis

Der Mindestsatz enthält Agent, Objekt, Wert, Request ID, Antwortcode und Sende-/Empfangszeiten. Getrennt folgen Aktionsbeginn und -ende, Zählerkontinuität, portAdminStatus, Health-Änderung, empfangene Abschluss- oder Neustartmeldung sowie ein unabhängiger Verkehrs- oder Diensttest.

Dann bleiben „Set ohne Fehler beantwortet“, „Reset-Abschluss gemeldet“ und „Dienst wieder erreichbar“ drei überprüfbare Sätze. Ist nur der erste belegt, bleiben die anderen offen.

Heng Lus Texte über den Vorrang laufenden Codes, die minimale Anfangsspezifikation und Realitätsschichten erklären diese Zurückhaltung. Der Standard fixiert den gemeinsamen Austausch; die Implementierung bestimmt den Test, der Betreiber die Erlaubnis und das laufende Netz die Folge.

Quellen und Beweisgrenze

Der RFC-Editor-Eintrag, RFC 1516, RFC 1368, RFC 1157, RFC 1215 und RFC 2108 tragen Historie und Semantik. Die drei Texte von Heng Lu liefern die redaktionelle Trennung.

Die Quellen belegen kein Produkt, Deployment, ausgeführten Befehl, reale Dauer, zugestellte Antwort oder Meldung, weitergeleitetes Paket, Störung oder Erholung. Der Einstieg rekonstruiert die Normlogik und berichtet keinen Vorfall.