Zusammenfassung

  • RFC 1215 ordnete mit TRAP-TYPE Registrierungsautorität, Variablenfolge, Textbedeutung und Ganzzahl den Feldern eines SNMPv1 Trap-PDU zu. Die Makroerweiterung geschah bei der Implementierung, nicht beim Ereignis.
  • Ein Trap gab wieder, was die sendende Anwendung oder Protokollinstanz erkannte. Er belegte weder physischen Fehler noch Ursache, Kundenauswirkung oder authentisierte Identität.
  • SNMPv1 nutzte einen unzuverlässigen Datagrammdienst; Ziele waren implementierungsabhängig. Definition, Erkennung, Erzeugung, Übertragung, Empfang, Bestätigung und Maßnahme erzeugten verschiedene Belege.

Die Schablone existierte vor dem Störfall

RFC 1215 zieht die Grenze mit einem Satz: Die Erweiterung des TRAP-TYPE-Makros findet konzeptionell während der Implementierung statt, nicht zur Laufzeit.

Ein Entwickler konnte also myLinkDown beschreiben, Objekte auswählen und eine Managementoberfläche vorbereiten, obwohl nie eine Leitung ausgefallen war. Die Definition war eine leere Schablone für mögliche Instanzen.

Weil die Schablone Ereignissprache verwendet, wirkt sie leicht wie ein Befund. Der Beschreibungstext spricht von erkannter Störung. Die Ganzzahl sieht wie ein Ereigniscode aus. Die Variablenliste ähnelt einer Beweissammlung. Doch keine dieser Angaben enthält bereits eine Messung.

Der RFC-Editor-Eintrag datiert das Informational-Dokument auf März 1991. Der IETF-Datatracker führt dieselbe Identität. Der Text nennt den Einsatz von Traps umstritten, rät nachdrücklich davon ab und will bestehende Traps knapp definierbar machen, nicht neue hervorbringen.

Diese Zurückhaltung beweist nicht, dass Traps ungenutzt waren. Sie begrenzt den Anspruch: eine Informationskonvention, kein Internetstandard und keine allgemeine Empfehlung.

Enterprise bezeichnete ein Register, keinen Absender

ENTERPRISE war obligatorisch. Die Klausel nannte das Managementunternehmen, unter dessen Registrierungsautorität der Trap definiert war, und lieferte den Wert für das enterprise-Feld.

Damit ließ sich die Definition einordnen. Der Wert war aber weder Signatur noch Benutzerkonto. Er bewies nicht, welche Person oder welcher Prozess das Datagramm gesendet hatte, wem ein Gerät aktuell gehörte oder wer Änderungen autorisieren durfte.

Für die Darstellung allgemeiner SNMP-Traps setzte die Konvention sysObjectID in das Feld. Auch das war eine Typinformation über ein konfiguriertes Objekt, keine Identitätsprüfung. Registrierendes Unternehmen, heutiger Produkteigentümer, Integrator, lokaler Administrator und sendender Prozess konnten auseinanderfallen.

RFC 1215 sagt zu Sicherheitsfragen nur, dass sie nicht behandelt werden. Daraus folgen keine Herkunftsauthentisierung, Integrität, Vertraulichkeit oder Wiederholungssicherheit.

Geordnete Variablen waren kein vollständiger Sachverhalt

VARIABLES legte die Reihenfolge der MIB-Objekte fest, die jede Instanz dieses Trap-Typs enthalten sollte. Der Agent durfte danach zusätzliche Variablen anhängen.

Die Definition lieferte somit einen erwarteten Kern. Sie enthielt keine künftigen Werte und garantierte keine operative Vollständigkeit. Zusätzliche Objekte konnten eigene Auslegungsregeln benötigen.

Ein ifIndex verweist auf eine Schnittstelle in der Agentenkonfiguration. Er beweist allein weder Kabelbruch noch Leitungsausfall, Ursache oder Dienstbeeinträchtigung.

DESCRIPTION beschrieb die Bedeutung. REFERENCE konnte auf einen Trap, ein Ereignis oder einen Alarm in einem anderen Modul zeigen. Der erste war Spezifikationstext, der zweite eine Beziehung zwischen Definitionen. Beide waren keine unabhängigen Beobachter.

Der Ganzzahlwert ging bei unternehmensspezifischen Traps in specific-trap, während generic-trap auf enterpriseSpecific(6) gesetzt wurde. In der besonderen snmp-Konvention ging er in generic-trap, und specific-trap wurde null. Die Zahl gehörte zu einem Namensraum. Sie bedeutete nicht Schwere, Vertrauen, Anzahl, Zeitpunkt oder Reihenfolge.

linkDown blieb eine Quellenaussage

Das Beispiel myLinkDown bedeutet, dass die sendende SNMP-Anwendung eine Störung an einer in der Agentenkonfiguration dargestellten Kommunikationsverbindung erkennt.

Subjekt ist die Anwendung. Sie kann Treiberzustand, Schwelle, Zähler oder lokale Zustandsänderung ausgewertet haben. Der Trap prüft nicht unabhängig die physische Strecke, benennt keine Ursache und misst keine Kundenauswirkung.

RFC 1157 formuliert den allgemeinen linkDown ebenso: Die sendende Protokollinstanz erkennt eine Störung. Die erste Variablenbindung nennt die betroffene ifIndex-Instanz. Der Index lokalisiert einen Datensatz, nicht die gesamte Fehlerkette.

Auch der Zeitstempel ist eng begrenzt. Er zählt die Zeit seit der letzten Neuinitialisierung der Netzinstanz bis zur Trap-Erzeugung. Physischer Beginn, Anwendungserkennung, PDU-Erzeugung, Versand und Empfang sind eigene Zeitpunkte.

Eine Anwendung musste die Erzeugung erst verlangen

Nach RFC 1157 erzeugte die Protokollinstanz das Trap-PDU nur auf Anforderung der SNMP-Anwendung. Wie Ziele gewählt wurden, blieb der Implementierung überlassen.

Zwischen Typ und Paket lagen folglich Erkennungslogik, Generierungsanforderung, Unterdrückung und Zielkonfiguration. Ein definierter Trap konnte nie gesendet werden, an einen alten Manager gehen oder von einem Empfänger ohne passende Unternehmenssemantik gelesen werden.

Das Beispiel authenticationFailure macht den fehlenden Trap mehrdeutig. Eine Implementierung musste ihn erzeugen können und seine Emission zugleich durch einen eigenen Mechanismus unterdrücken können. Schweigen bedeutete nicht „keine Authentisierungsfehler“. Es konnte Nichterkennung, Unterdrückung, Fehlkonfiguration, Verlust oder fehlende Verarbeitung bedeuten.

UDP 162 war eine Adresse, keine Empfangsbestätigung

SNMPv1 verlangte nur einen unzuverlässigen Datagrammdienst. Jede Nachricht lag in einem Datagramm; Trap-Nachrichten sollten an UDP-Port 162 zur weiteren Verarbeitung empfangen werden.

Der Port belegte keinen Listener, keine Firewall-Freigabe, keinen Puffer, keine erfolgreiche Dekodierung, Speicherung oder Aufmerksamkeit. Ein Sendeeintrag war kein Empfangseintrag.

Nach tatsächlichem Empfang übergab die Protokollinstanz den Inhalt an ihre SNMP-Anwendung. Das war eine belegbare Empfangsstufe, aber noch kein Ticket, Urteil, Eingriff oder Wiederherstellung.

Spätere Texte benannten die Grenze genauer. RFC 2578 ordnet RFC 1215 SMIv1 zu und definiert mit NOTIFICATION-TYPE Syntax und Semantik einer SMIv2-Benachrichtigung. Ein neuer Makrotyp blieb eine Definition.

RFC 3416 beschreibt SNMPv2-Trap als Benachrichtigung ohne Bestätigung. InformRequest ist bestätigt, garantiert aber dennoch keine Zustellung. Beim Empfang präsentiert die Gegenseite den Inhalt und sendet ein Response-PDU.

Die Antwort belegt einen weiter fortgeschrittenen Protokollaustausch. Sie bestätigt weder unabhängig den behaupteten Zustand noch menschliche Zustimmung oder erfolgreiche Reparatur.

Lesbarkeit ersetzte keine Beweiskette

Modulautor, Registrierungsstelle, Agentenanwendung, Protokollinstanz, Konfiguration, Netzwerk, Empfänger und Operator kontrollierten je einen Ausschnitt. RFC 1215 gab ihnen eine gemeinsame Sprache, keine gemeinsame Allmacht.

Mit Polling, Zählern, Routingzustand und Dienstmessung konnte ein Trap Teil eines belastbaren Befunds werden. Ohne diese Kette blieb er eine begrenzte Aussage aus der Quelle.

Quellen