Summary

  • RFC 3430 nutzte TCP-Flusskontrolle für umfangreiche SNMP-Austausche; ein zuverlässiger Bytestrom bewies jedoch nicht, dass die Operation verarbeitet wurde.
  • Die Operationsart blieb entscheidend: snmpV2-trap blieb unbestätigt, während inform-request eine SNMP-Antwort mit einer festgelegten Bedeutung auf der Empfängerseite erhielt.

Bei einem „zuverlässigen“ Transport ist der gedankliche Sprung verführerisch. Die Verbindung bleibt offen, TCP bestätigt Bytes, und am Ende wird sie ordentlich geschlossen. Bedeutet das, dass die Management-Anwendung das Ereignis erhalten hat? Abschnitt 2.4 von RFC 3430 stellt genau den Unterschied zwischen zuverlässigem Transport und bestätigten Operationen heraus.

Der im Dezember 2002 als Experimental veröffentlichte RFC definierte ein optionales Transport-Mapping für Simple Network Management Protocol über TCP. Er ersetzte weder das SNMP-Nachrichtenmodell noch machte er aus jeder Benachrichtigung eine bestätigte Operation. Hauptzweck war ein effizienterer Massentransfer. SNMP-Engines, die dieses optionale Mapping implementierten, mussten weiterhin das SNMP-over-UDP-Mapping aus RFC 3417 unterstützen. Der Ursprung einer Anfrage-Antwort-Transaktion wählte den Transport für die gesamte Transaktion; ein Wechsel währenddessen war unzulässig.

TCP brachte Flusskontrolle und Segmentierung mit, wodurch sich bei großen Management-Datenmengen viele kleine UDP-Anfrage-Antwort-Runden vermeiden ließen. Verbindungen verursachten aber zusätzliche Kosten: Aufbau, Abbau und der vom Betriebssystem gehaltene offene Zustand. Ein ausgelasteter Responder konnte neue TCP-Verbindungen ablehnen. RFC 3430 empfahl außerdem, SNMP-Wiederholungstimer später als TCP-Timer auszulösen, damit die Anwendung nicht abläuft, während TCP noch eine Wiederherstellung versucht.

Der Wechsel vom Datagramm zum Bytestrom veränderte die Rahmung. UDP lieferte pro Datagramm eine Nachrichtengrenze. TCP lieferte eine Bytefolge, deren Leseabschnitte nicht mit den Grenzen der SNMP-Nachrichten übereinstimmen mussten. Deshalb verlangte RFC 3430, dass der Empfänger das Längenfeld der BER-Kodierung zur Trennung der Nachrichten verwendet. Der Sender durfte Bytes verschiedener Nachrichten nicht verschachteln. Eine persistente Vollduplex-Verbindung konnte jedoch mehrere Anfrage-Antwort-Paare zugleich tragen; Antworten mussten nicht in der Reihenfolge der eingegangenen Anfragen eintreffen.

Die Nachrichtengrenze blieb explizit, auch wenn die Antwortreihenfolge wechselte.

Rahmung beweist noch keine Aktion der Anwendung. Im von RFC 3430 beschriebenen Rahmen schützt TCP den geordneten Bytestrom zwischen den Endpunkten. Es beweist nicht, dass der entfernte SNMP-Prozess die Nachricht analysiert oder verarbeitet hat. Selbst ein ordentlicher TCP-Abschluss beweist nicht, dass die empfangende TCP-Engine alle Bytes an einen Anwendungsprozess übergeben hat. Und TCP garantiert nicht, dass jede abgesendete Nachricht schließlich das entfernte System erreicht.

Die SNMP-Operation selbst liefert eine andere Bestätigung. RFC 3430 stellt den unbestätigten snmpV2-trap dem bestätigten inform-request gegenüber. Wird der Trap über TCP transportiert, entsteht dadurch keine SNMP-Bestätigung. Die SNMP-Antwort auf ein Inform zeigt laut RFC, dass die Benachrichtigung Transport und Sicherheitsmodell passiert hat und zur Zustellung an die Notification-Receiver-Anwendung eingereiht wurde. Eine Antwort auf set-request zeigt, dass der Command Responder den Schreibvorgang verarbeitet hat. Das sind aussagekräftige Protokollbestätigungen, aber kein Beweis, dass ein Mensch die Warnung sah, ein Geschäftsprozess reagierte oder sich der angestrebte reale Zustand änderte.

Auch der Verbindungsaufbau trennt Absicht von Empfangsbeleg. Scheitert die TCP-Verbindung, wird die Transaktion laut RFC abgebrochen und der Anwendung als Timeout gemeldet. Der Anhang erörtert UDP-Fallback und weitere Alternativen, aber kein anderes Transportverfahren beseitigt die Ungewissheit: Ein Notification Originator, der zuverlässige Zustellung benötigt, muss bei fehlgeschlagenem Verbindungsaufbau ein lokales Protokoll der Benachrichtigungen führen. Wiederholungen oder Fallback heben diese Pflicht nicht auf, wenn auch sie scheitern. Das Protokoll hält offene Arbeit fest, beweist aber keinen Empfang am Ziel.

Sicherheit bleibt eine eigene Ebene. Das TCP-Mapping verändert die SNMPv3-Sicherheitsmechanismen nicht. RFC 3430 empfiehlt das User-based Security Model und das View-based Access Control Model und weist zugleich auf neue Denial-of-Service-Möglichkeiten wie SYN Flooding hin. Authentifizierung, Autorisierung, Bytezustellung, Warteschlangeneintrag und betriebliche Wirkung sind verschiedene Belege.

Der historische Beitrag von RFC 3430 ist präziser als „SNMP über TCP ist zuverlässig“: Der RFC bot einen Bytestrom für große Management-Austausche, definierte Nachrichtengrenzen darin und erklärte, dass Transportzuverlässigkeit ein schlechter Ersatz für eine bestätigte Operation ist. Ein Trap bleibt ein Trap. Ein Inform bleibt eine Operation mit Antwort. Der Strom kann beides transportieren, entscheidet aber nicht, was der Empfänger getan hat.

Dieser Artikel beschreibt den Protokollvertrag und behauptet weder heutigen Einsatz noch Produktunterstützung, gemessene Leistung oder einen konkreten Ausfall. Die Beweiskette unterscheidet Verbindung, BER-Rahmung, Bytezustellung, Empfang oder Verarbeitung durch die SNMP-Engine, Einreihung in die Empfängeranwendung und spätere Handlung. RFC 3430 definiert Antworten nur für einen Teil dieser Schritte.

Quellen: RFC 3430; RFC 3417; RFC 3411; RFC 3413; RFC 3414; RFC 3415; RFC 3419; RFC 9293. Status: RFC Editor.