Zusammenfassung

  • RFC 1451 ließ eine SNMPv2-Managementstation zugleich als Agent auftreten und Überwachungsdienste für andere Stationen übernehmen.
  • Periodische Stichprobe, Schwellenübergang, Ereignisdefinition und zielbezogene Inform-Benachrichtigung lagen in getrennten Tabellen.
  • Die Benachrichtigungszeile besaß eine eigene Lebensdauer und wurde ohne Erneuerung zerstört; Alarm und Ereignis mussten dadurch nicht verschwinden.

Eine Managementstation wurde zum Dienstleister

RFC 1451 verteilte Überwachung und Steuerung über mehrere Stationen. Der Dienstleister nahm Konfiguration in der Agentenrolle entgegen und fragte die überwachte Information in der Managerrolle ab. Das sollte große Netze und getrennte Verwaltungen skalierbarer machen.

Drei Tabellen hielten die Abhängigkeiten sichtbar. Alarm beschrieb Variable, Kontext, Zeitabstand und Schwellen. Event benannte das ausgelöste Ereignis und führte lokale Historie. Notification verband ein Ereignis mit einem Zielkontext und einer InformRequest-Strategie. Keine dieser Zeilen ersetzte die andere.

Der Wert gehörte zum abgeschlossenen Intervall

Bei einer absoluten Stichprobe wurde der Wert am Periodenende direkt verglichen. Beim Delta zählte die Differenz zwischen zwei Periodenenden. snmpAlarmValue zeigte erst nach Abschluss einer Periode den letzten fertigen Wert. Über den laufenden Abschnitt machte das Objekt keine Aussage.

Die Beobachtung war damit zeitlich gerastert. Eine Spitze zwischen zwei Abfragen konnte unsichtbar bleiben. Für bestimmte Delta-Grenzen empfahl der Text eine präzisere Teilabtastung, verlangte aber keine einheitliche Umsetzung.

Nur ausgewählte ganzzahlige ASN.1-Typen waren zulässig. Passte eine Statistik nicht in die vorzeichenbehaftete 32-Bit-Darstellung, durfte die Implementierung sie auf eigene Weise kürzen. Der angezeigte Wert war ein begrenztes Protokollartefakt, keine vollständige physische Tatsache.

Delegation war kein zusätzlicher Zugriff

Die Alarmtabelle durfte keine MIB-Sicht umgehen. Kontext sowie Quell- und Ziel-Party mussten gemäß dem Verwaltungsmodell aus RFC 1445 Zugriff besitzen. Das Recht, einen Überwachungsdienst zu bestellen, schuf kein Recht auf beliebige Objekte.

Ein expliziter Autorisierungsfehler, ein fehlendes Objekt oder falsche Syntax konnte ein einzelnes Unavailable-Ereignis erzeugen und die Alarmzeile zerstören. Blieb nur die Antwort aus, durfte die Station entweder aufgeben oder lediglich den letzten Wert entfernen und weiter versuchen. Ein fehlender Wert hatte mehrere mögliche Ursachen.

Hysterese machte aus Zahlen Zustandswechsel

Nach einem steigenden Ereignis entstand kein weiteres, bevor der Wert die fallende Schwelle erreicht hatte. Für die Gegenrichtung galt das Spiegelbild. Die Hysterese begrenzte Flattern an der Schwelle.

Ein dauerhaft hoher Wert und ein neuer Anstieg waren deshalb verschiedene Aussagen. Der Ereigniszähler maß erkannte Übergänge im Zustand der Alarmmaschine. Für die erste Stichprobe nach Aktivierung gab es zusätzlich eine eigene Startregel.

Eine Überschreitung konnte ohne Event enden

Alarmzeilen verwiesen für Anstieg, Abfall und Nichterreichbarkeit auf Event-Indizes. Null bedeutete keine Zuordnung; ein Index ohne bestehende Event-Zeile ebenfalls. Die Messung konnte aktiv sein, obwohl ihre semantische Fortsetzung fehlte.

Eine Event-Zeile enthielt Ereignis-OID, lokalen Zähler und lokales sysUpTime der letzten Erzeugung. Diese Werte waren Belege des Erzeugers. Sie sagten nichts über die Zahl der Empfänger aus.

Gewünschte Wiederholung traf auf Ressourcenlimits

Notification ordnete einem Event einen Zielkontext zu. Der Auftraggeber wünschte Intervall und Zahl der Wiederholungen. Die Station durfte ein zu kurzes Intervall auf ihr Minimum anheben und eine zu hohe Zahl auf ihr Maximum senken. Konfiguration und ausgeführte Politik waren nicht identisch.

Die damalige InformRequest-Operation kam aus RFC 1448. RFC 3416 beschreibt Inform später als bestätigten Mechanismus, aber ausdrücklich ohne Zustellgarantie. Bei gültigem Empfang wird der Inhalt der passenden Anwendung vorgelegt und eine Response erzeugt. Das bestätigt weder den Wahrheitsgehalt noch die Behebung des Ereignisses.

Nach einem Tag war die Beziehung standardmäßig weg

snmpEventNotifyLifetime zählte Sekunden herunter. Bei null wurde der Status der Notification-Zeile auf destroy gesetzt. Die Managementstation, die diese Zustellung nutzte, musste den Wert regelmäßig erneuern. Der Standardwert betrug 86.400 Sekunden.

Die Frist gehörte zur Verbindung zwischen Event und einem Ziel. Ihr Ablauf löschte nicht automatisch Alarm und Event. Der Erzeuger konnte weiter messen und zählen, während ein bestimmter Empfänger aus der Kette gefallen war.

Historic ist keine Einsatzstatistik

Der RFC-Editor-Eintrag führt RFC 1451 heute als Historic. Der Text selbst erklärt, Sicherheitsfragen nicht zu behandeln. Daraus folgen weder Produktverbreitung noch Schutzwirkung.

RFC 3413 trennte später Notification Originator, Receiver, Targets, Filter und Proxy Forwarder. Diese Quelle markiert die spätere Architektur; sie wird nicht als direkter Ersatz ausgegeben und nicht in das Jahr 1993 zurückprojiziert.

Quellen