Zusammenfassung

  • Für jede MAU definierte RFC 1515 einen aktuellen Jabber-Zustand, einen Zähler der Eintritte in diesen Zustand und eine Trap zur Benachrichtigung.
  • Zwischen aufeinanderfolgenden Traps mussten mindestens fünf Sekunden liegen. Der Alarmstrom war damit absichtlich begrenzt und kein vollständiger Ereigniszähler.
  • Ein späteres noJabber löschte frühere Übergänge nicht; ein Zähleranstieg bewies umgekehrt keinen fortdauernden Zustand.

Die Pause galt der Meldung

Eine gedachte MAU tritt in den Jabber-Zustand ein, wird normal und tritt vier Sekunden später erneut ein. Der Zähler kann beide Übergänge erfassen. Eine spätere Abfrage kann bereits noJabber ergeben. Doch der Agent darf nicht zwei Jabber-Traps mit weniger als fünf Sekunden Abstand erzeugen.

Ein Alarm, zwei gezählte Eintritte und ein normaler Gegenwartswert können gleichzeitig stimmen. Sie beantworten: Wo ist sofortige Aufmerksamkeit nötig? Was sieht der Agent jetzt? Wie viele Übergänge liegen in der gültigen Zählperiode? Das Protokoll zwang diese Antworten nicht in ein einziges Ampelfeld.

Eine Beobachtung brauchte Koordinaten

Die im September 1993 veröffentlichte RFC 1515 definierte Managed Objects für IEEE-802.3-Medium-Attachment-Units. Eine MAU verband das Medium mit einem Repeater-Port oder einer Ethernet-ähnlichen Schnittstelle. Für beide Fälle gab es eigene Pflichtgruppen.

Repeater-MAUs wurden durch Gruppen-, Port- und MAU-Index bestimmt; Interface-MAUs verwendeten den ifIndex von MIB-II. Wer diese Koordinaten entfernte, verwandelte den Zustand eines bestimmten Anschlusses in eine unprüfbare Aussage über das ganze Netz.

Administrativer Zustand, Medienverfügbarkeit und Jabber blieben getrennt. Je nach Typ konnte Medienverfügbarkeit etwa Linkverlust, schwaches Licht, fehlenden Loopback, Gegenstellenfehler oder ungültiges Signal bedeuten. Solche Beobachtungen durften korreliert, aber nicht als automatische Kausalbeweise benutzt werden.

Der Zustand kannte nur das Jetzt

rpMauJabberState und ifMauJabberState hatten die Werte other, unknown, noJabber und jabbering. Während der Initialisierung war unknown eine zulässige Aussage über fehlendes Wissen. noJabber war normal; jabbering beschrieb den gegenwärtigen Zustand.

Das Objekt nannte weder defekte Komponente noch Dauer oder Verkehrsverlust. Es bestätigte weder Alarmzustellung noch erfolgreiche Reparatur. Bei einer AUI-Ansicht musste der Agent other liefern, der Eintrittszähler blieb null. Null konnte daher Nichtanwendbarkeit ausdrücken statt umfassende Fehlerfreiheit.

Der Zähler maß Übergänge

rpMauJabberingStateEnters und ifMauJabberingStateEnters zählten Eintritte in jabbering. Eine lange Episode konnte eins beitragen, mehrere kurze Episoden mehrere. Sekunden, Frames, Bytes, Nutzer und Meldungen lagen außerhalb seiner Semantik.

Zudem gehörte der Zähler zu einer Epoche. RFC 3636 wies auf Diskontinuitäten bei Reinitialisierung des Managementsystems hin und verband Interface-Zähler mit ifCounterDiscontinuityTime. Ein gespeicherter Endwert ohne Epoche konnte einen Neustart fälschlich als Verbesserung darstellen.

Steigt der Zähler und zeigt der aktuelle Zustand später normal, lautet die belastbare Aussage: In dieser Epoche gab es Übergänge; diese Abfrage sieht derzeit kein Jabber. Dauer und Behebung bleiben offen.

Die Trap durfte Details verlieren

RFC 1515 definierte eigene Jabber-Traps für Repeater- und Interface-MAUs. Beim Eintritt sollte eine Trap mit dem Zustandsobjekt gesendet werden. Aufeinanderfolgende Traps mussten jedoch mindestens fünf Sekunden auseinanderliegen.

Diese Drossel schützte den Managementpfad vor Meldungsstößen. Zugleich begrenzte sie seine Beweiskraft: Empfangene Traps konnten nicht als vollständige Liste der Zustandswechsel gelten. Schweigen innerhalb des Fensters widerlegte keinen zusätzlichen, gezählten Übergang.

RFC 1157 definierte die SNMPv1-Trap-PDU getrennt von Anfrage und Antwort. Sie führte Agentenadresse, Kennungen, Zeit seit der letzten Initialisierung und Variable Bindings. RFC 1215 stellte die TRAP-TYPE-Konvention bereit. Interpretierbarkeit war damit gegeben, Vollständigkeit oder Endzustellung nicht.

Das Muster blieb über Geschwindigkeitsstufen erhalten

RFC 2239 ersetzte RFC 1515 durch eine Obermenge für 100 Mb/s, Auto-Negotiation und Anschlussverwaltung. RFC 2668 erweiterte erneut. RFC 3636 nahm 10 Gb/s auf und erklärte RFC 2668 und RFC 1515 für überholt.

Zustand, Eintrittszähler und Fünf-Sekunden-Abstand blieben bestehen. Später wurde genauer festgelegt, dass mehrere schnellere MAU-Typen in diesen Zählern null liefern. Neue Technik erweiterte den Vertrag, ohne ein altes Objekt zum universellen Gesundheitsurteil zu machen.

Ein prüfbarer Datensatz bewahrt MAU-Identität und -Typ, Zustand, Zähler, Epoche, Trap-Zeitstempel, Empfangszeit und Abfrageintervall. Dann ist „Zähler plus zwei, eine Trap protokolliert“ möglich. „Port zweimal ausgefallen“ bleibt ohne Ursachen- und Wirkungsbeleg Spekulation.

Lu Hengs Texte über Running-Code Primacy, Minimum Initial Specification und Realitätsebenen liefern die redaktionelle Disziplin: Gemeinsame Semantik bleibt schmal und lokal überprüfbar. Eine Meldung kann Handeln auslösen, aber keine Tatsachen beherrschen, die ihr Kanal absichtlich nicht bewahrt.

Quellen und Beweisgrenze

Technische Grundlage sind der RFC-Editor-Eintrag zu RFC 1515, RFC 1515, RFC 1157, RFC 1215, RFC 2239, RFC 2668 und RFC 3636. Sie belegen Semantik und Entwicklung, nicht heutige Produktkonformität, Verbreitung, Zustellraten, konkrete Ausfälle, Paketverlust, Hardwareschaden oder Reparatur.