Zusammenfassung

  • RFC 1224 begrenzte alle Alarme eines Agenten gemeinsam über maxAlertsPerTime, windowTime und alertsEnabled.
  • Nach Überschreiten der Grenze sendete der Agent einmal alertsDisabled und verstummte; gerade diese Meldung konnte verloren gehen.
  • Ein nummeriertes Journal hielt alertId und alertData, doch Abruf oder Löschung bewiesen keine Behebung.

Zu viel und zu wenig Meldung waren dasselbe Vertrauensproblem

RFC 1224 erschien im Mai 1991. Der RFC Editor führt ihn als Experimental, der IETF Datatracker bewahrt die Alert-Man-Herkunft. Der Text regelte nicht, welche Zustände einen Alarm auslösen sollten. Er regelte den anschließenden Informationsfluss.

Eine ausgefallene Maschine konnte ihren Ausfall womöglich nicht melden. Eine flatternde Leitung konnte dagegen so viele Meldungen erzeugen, dass Managementstation und Netzweg überlasteten. Die Architektur musste daher Überflutung verhindern und verlorene Information erkennbar oder rekonstruierbar machen.

RFC 1157 setzte SNMP auf einen unzuverlässigen Datagrammdienst und überließ die Trap-PDU-Ziele der Implementierung. RFC 1215 standardisierte eine Trap-Definition, warnte aber nachdrücklich vor neuen Traps. Formale Korrektheit war kein Zustellnachweis.

Der Pin schaltete den Agenten stumm

Die gleitende Schwelle kombinierte maxAlertsPerTime und windowTime. Gezählt wurde die Summe aller Alarmtypen eines Agenten.

Beim Start war alertsEnabled wahr. Jeder erzeugte Alarm prüfte den Zustand. Bei falsch wurde nichts gesendet; bei wahr erfolgte die Sendung und der Zeitpunkt ging in die Berechnung ein. Passte die festgelegte Anzahl in das Zeitfenster, sendete der Agent einmal alertsDisabled und setzte den Zustand auf falsch.

Damit schützte er CPU, Bandbreite und Manager. Doch die abschließende Nachricht konnte ebenfalls ausfallen. Der Manager sollte deshalb den Zustand regelmäßig abfragen, ihn gegebenenfalls wieder aktivieren und mögliche Trap-Verluste während der Stille vermerken. Schweigen wurde ein erklärungsbedürftiger Betriebszustand.

Das Journal war endlich

Der zweite Weg legte für jeden lokalen Alarm eine Zeile mit steigendem alertId und OPAQUE alertData an. Der Manager konnte die nächste oder eine benannte Zeile abrufen und sie optional per SET oder DELETE entfernen. RFC 1189 liefert den damaligen CMOT/CMIP-Kontext für diese Paralleloperationen.

Nach einer Trennung konnten alte Bedingungen noch abrufbar sein. Die Tabelle hatte jedoch eine Grenze: Ein neuer Eintrag ersetzte bei voller Kapazität den ältesten. Älteste zuerst auszuliefern verringerte das Risiko, beseitigte es aber nicht.

Eine ID bewies lokale Aufbewahrung, nicht asynchrone Sendung, Netzzustellung, rechtzeitigen Abruf oder menschliche Reaktion. Eine Löschung dokumentierte Tabellenpflege, nicht Störungsbehebung. Mehrere Manager konnten zudem verschiedene Schwellen, Zustände und Ansichten besitzen. RFC 1224 behandelte Sicherheit ausdrücklich nicht; eine SET- oder DELETE-Spur authentifizierte daher keinen Akteur.

Quellen