Zusammenfassung

  • RFC 5190 räumt ein, dass eine logische MIDCOM-Transaktion mehrere SNMP-Operationen benötigen kann. Während mehrerer GETs darf sich der Middlebox-Zustand ändern; Ergebnis und zwischenzeitliche Notifications müssen abgeglichen oder neu gelesen werden.
  • Auch die Konfigurationsantwort ist zusammengesetzt. Ein SET-Reply bestätigt eine enge Schreiboperation, eine Notification meldet den Zustandswechsel, und weitere GETs liefern positive Parameter oder den Fehler.

Die Inventur war nicht falsch gelesen worden. Jeder einzelne GET-Reply war korrekt. Falsch war die Behauptung, alle zurückgegebenen Zeilen beschrieben denselben Zeitpunkt.

RFC 5190 bildet MIDCOM-Semantik auf SNMP ab. Für Monitoring können mehrere GETs nötig sein. Neue Regeln dürfen während der Folge entstehen, bereits gelesene Regeln verschwinden. Die verbleibende Atomizität reicht für die Anforderungen nur dann, wenn der Client Änderungen berücksichtigt.

Darum braucht ein Snapshot ein Intervall. Start, Ende, Reihenfolge und Ereignisse während der Erfassung gehören zur Aussage. Ohne sie ist eine präzise Zahl nur eine Montage verschiedener Versionen.

Ein SET-Reply schließt nur den SET

Auch Konfiguration wird verteilt. Ein Client erzeugt eine Zeile, schreibt Parameter und setzt schließlich den administrativen Trigger. Der letzte erfolgreiche SET erlaubt dem Middlebox, mit Prüfung und Verarbeitung zu beginnen.

checkingRequest und processingRequest sind eigene Zustände. Erst danach folgen reserved, enabled, rejection oder termination. Wer den letzten SET-Reply als abgeschlossene Policy-Operation speichert, überspringt genau den Prozess, dessen Ergebnis beobachtet werden soll.

Der Datensatz muss daher SNMP-Schreibreceipt und logisches Resultat trennen. Für jeden SET: Principal, VACM-Entscheidung, Varbinds, Row-Koordinaten, Reply oder Timeout. Für die logische Operation: Trigger-Version und OperStatus-Verlauf.

Diese Grenze ist nicht die allgemeine RowStatus-Lebenszyklusfrage. Sie betrifft die Autorität mehrerer Nachrichten, die gemeinsam eine größere Operation darstellen.

Die Notification ist schmal

midcomSolicitedRuleEvent trägt OperStatus und Lifetime. Bei positivem Lifetime liest der Client die positiven Antwortparameter aus der Tabelle. Bei null liest er Status und Fehler.

Die Notification beweist also einen gemeldeten Übergang. Sie muss nicht Adresse, Port oder Fehlertext enthalten. Ein Archiv, das nur den Trap bewahrt, hält einen Index ohne vollständige Erklärung.

Nachträgliche GET-Werte dürfen ergänzt werden, aber mit eigener Herkunft und Zeit. Sie rückwirkend als ursprünglichen Notification-Inhalt darzustellen, verdeckt mögliche Änderungen zwischen Ereignis und Lesen.

Wenn die Notification ausbleibt, ist das ebenfalls kein Fehlschlagbeweis. Der Client soll nach Timeout Status pollen. RFC 5190 nennt Polling teurer, aber zuverlässiger, weil Zustand erneut gelesen werden kann.

Drei Verluste, drei verschiedene Diagnosen

SET request, SET reply und Notification können jeweils verloren gehen. Ein verlorener Request bewirkt keine Schrift. Ein verlorener Reply kann eine bereits wirksame Schrift verbergen. Ein verlorener Trap kann eine abgeschlossene Verarbeitung verbergen.

Das Frontend sieht in allen Fällen Stille. Die Wiederherstellung ist verschieden. Vor SET-Wiederholung kann ein GET den ersten Schreibversuch prüfen. Nach Notification-Timeout kann OperStatus gelesen werden. Für vollständige Antwort folgen weitere GETs.

snmpSetSerialNo, begrenzte Retransmission Timer oder ausgeschaltete Wiederholung reduzieren Idempotenzrisiko. Sie beweisen keine Paketzustellung und keine Anwendungswirkung.

Ein Audit muss den ursprünglichen Timeout erhalten. „Retry erfolgreich“ löscht die Abzweigung, ob der erste Versuch nie ankam oder nur seine Antwort verlor.

Die Ergebniszeile kann vorzeitig verschwinden

Die Rule-Tabelle enthält Aufbau, Prüfung, Fehler, aktive und terminierte Zustände. midcomRuleStorageTime zählt nach Fehler oder Terminierung ab.

Trotzdem garantiert RFC 5190 nicht, dass die Zeile bis zum angezeigten Ende bleibt. Eine Implementierung darf eine terminierte Zeile früher entfernen. Danach fehlen Fehler und Rückgabefelder.

Eine nicht gefundene Zeile ist deshalb kein Beweis, dass keine Operation stattfand. Sie kann bereits beendet und gelöscht, unter anderem Index gespeichert oder für den Principal unlesbar sein.

Der Operator braucht eine dauerhafte Kopie beim ersten Terminalzustand: Owner, Gruppe, Index, Request, Status, Fehler, gewährte Werte und Beobachtungszeiten. Device retention ist kein Auditarchiv.

Gleichberechtigte Writer schwächen die Zusammensetzung

Wenn mehrere SETs eine Anfrage aufbauen, kann ein zweiter berechtigter Client Werte ändern. Jede Nachricht kann korrekt authentisiert sein; die endgültige Kombination muss dennoch keiner einzelnen Absicht entsprechen.

RFC 5190 empfiehlt Zeitplanung, getrennte Group Indices oder nicht überlappende Rule-Index-Bereiche. Diese Regeln müssen überprüfbar sein. Die Annahme, Clients seien gewöhnlich koordiniert, ersetzt keine Schreibprovenienz.

Für jeden Feldwechsel werden Writer, Vorwert, Nachwert und Row-Version benötigt. Gemeinsamer Owner zeigt Namensraum und Rechte, nicht einen gemeinsamen Autor.

Beim Failover entscheidet diese Spur, ob der zweite Controller fortsetzte oder einen teilweise aufgebauten Request überschrieb.

Bestandsbeweis als Versionenfolge

Eine Monitoring-Abfrage sollte Collection Epoch, erste und letzte Antwort, zwischenzeitliche Notifications und Merge-Regel tragen. Trifft ein Ereignis ein, kann der Client es integrieren oder von vorn beginnen.

Das ist keine Schwäche, die ein Dashboard verbergen sollte. Es ist die präzise Grenze dessen, was ein veränderliches System beobachten lässt.

Ein Bericht kann sagen: „Diese Regeln wurden innerhalb des Fensters gesehen; diese Änderungen kreuzten die Erfassung.“ Er darf nicht behaupten, die kombinierte Liste habe in einem nicht beobachteten Augenblick existiert.

Erst mit dieser Versionierung werden Kapazitäts- und Incident-Entscheidungen überprüfbar.

Operatives Evidence Object

Zuerst logische Operation, Ziel, Rule/Group/Interface, verantwortlicher Principal und erwartete Parameter fixieren. Jeden SET mit Zugriff, Varbinds, Serial, Reply oder Timeout anhängen.

Trigger und OperStatus-Übergänge getrennt speichern. Completion-Quelle — Notification oder Poll — nennen. Tatsächliche Notification-Felder von ergänzenden GETs unterscheiden.

Storage-Zeit, externe Kopie, frühe Löschung und konkurrierende Writer festhalten. Monitoring-Ergebnisse als Zeitfenster mit Ereignissen behandeln.

Zuletzt lokale NAT/Firewall-Ressource, Packet Capture, Remote Receipt und Application Outcome verbinden. Eine vollständige Managementantwort bleibt ein lokaler Kontrollbeleg, nicht automatisch ein End-to-End-Ergebnis.

Quellen

  1. RFC 5190 HTML
  2. RFC 5190 Text
  3. RFC 5190 Datensatz
  4. Datatracker RFC 5190
  5. RFC 5190 Historie
  6. RFC 5190 Referenzen
  7. RFC 5190 Errata
  8. RFC 5189
  9. RFC 5189 Datensatz
  10. RFC 3416
  11. RFC 3418
  12. RFC 3414
  13. RFC 3415
  14. RFC 2578
  15. RFC 2579
  16. RFC 2580
  17. RFC 3304
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy