Zusammenfassung

  • Nimmt der Server <commit><confirmed/> an, wird Candidate bereits zu Running. Der Timer verschiebt nicht die Ausführung, sondern hält die Pflicht offen, bei ausbleibender Bestätigung zum vorherigen Zustand zurückzukehren.
  • Beim normalen Verfahren löst der Abbruch der initiierenden Session die Wiederherstellung aus. Mit persist überlebt das Verfahren die Session; eine andere Session kann mit passender persist-id bestätigen, verlängern oder abbrechen.
  • Ein <ok>, eine erfolgreiche YANG-Validierung oder ein complete-Ereignis beweist weder Startup-Persistenz noch Operational-Anwendung, Pakettransport oder atomare Änderung über mehrere Geräte.

Der Server antwortete erfolgreich und begann trotzdem mit dem Rückweg

Eine Netzingenieurin ändert den Managementzugang eines entfernten Geräts. Sie bereitet die Konfiguration in Candidate vor, validiert sie und sendet einen Confirmed Commit. Der Server antwortet mit <ok>. Running enthält nun die neuen Werte. Kurz darauf bricht die SSH-Verbindung ab, und der neue Managementpfad ist nicht erreichbar.

Die Ingenieurin kann keinen Gegenbefehl senden. Der Server braucht ihn beim normalen Confirmed Commit auch nicht. Endet die Session vor der Bestätigung, muss er die Konfiguration wiederherstellen, die vor Beginn des Verfahrens galt. Läuft der Timer ab, gilt dieselbe Pflicht. Startet das Gerät vorher neu, ebenfalls.

Diese Abfolge enthält keinen Widerspruch. Die Änderung war ausgeführt; ihre Finalität war befristet. Das <ok> sagte wahrheitsgemäß, dass der Server den RPC angenommen hatte. Es sagte nicht, dass der neue Zustand bleiben würde, nach einem späteren Neustart geladen würde oder den beabsichtigten Dienst erbrachte.

Confirmed Commit schützt damit gegen einen eng umrissenen Fehler: Eine Fernänderung kann genau den Pfad zerstören, über den ein Mensch sie zurücknehmen müsste. Der Server behält einen unabhängigen Rücksetzungsauftrag. Er besitzt dadurch aber kein Wissen über betriebliche Freigaben, parallele Änderungen, Hardwarezustand oder das Netz als Ganzes.

Der Übergang nach Running ist keine Warteschlange

RFC 6241 definiert die NETCONF-Datastores und Operationen. Mit :candidate kann ein Client eine vollständige Konfiguration zusammenstellen, ohne Running sofort zu verändern. <commit> setzt Running auf den Inhalt von Candidate. Die von Candidate abhängige Fähigkeit :confirmed-commit:1.1 legt nach diesem Übergang eine Bedingung für die Finalität fest.

Fehlt confirm-timeout, beträgt die Voreinstellung 600 Sekunden. Ein späterer bestätigender Commit beendet die Rücksetzungspflicht. Ein weiterer Confirmed Commit kann das laufende Verfahren verlängern und eine neue zulässige Frist setzen. <cancel-commit> beendet es durch Wiederherstellung. Der Ablauf der Frist führt ebenfalls dorthin.

Für die Betriebsakte sind das verschiedene Ereignisse:

  • Candidate war unter einem bestimmten Modell gültig;
  • der Server nahm den Confirmed Commit an;
  • Running wechselte auf den Candidate-Inhalt;
  • das Verfahren wurde verlängert, bestätigt, abgebrochen oder lief aus;
  • Running endete auf einem bestimmten Fingerprint;
  • Startup und die tatsächlich angewandte Konfiguration folgten diesem Ergebnis oder wichen ab.

RFC 6470 unterstützt diese Trennung mit den Benachrichtigungsereignissen start, extend, complete, cancel und timeout. Sie sind wertvolle Chronologie, aber keine Finalitätsinstanz. Ein Collector kann ein Ereignis verpassen; complete kann eintreten, während Hardware noch arbeitet. Erst die Korrelation von RPC, Benutzer, Session, Candidate, Ausgangszustand, Frist, Benachrichtigung und Endzustand schafft Beweiswert.

Der Timer ist eine lokale Risikopolitik

Sechshundert Sekunden sind ein Protokollstandard, keine universelle Sicherheitsdauer. Eine kleine Filteränderung wird möglicherweise in Sekunden sichtbar. Eine umfangreiche Policy-Neuberechnung oder Hardwareprogrammierung kann deutlich länger brauchen. Eine kurze Frist begrenzt einen schädlichen Zwischenzustand, kann aber vor dem Auftreten langsamer Fehler enden. Eine lange Frist erlaubt tiefere Beobachtung und verlängert zugleich Schaden und Konkurrenzfenster.

Deshalb muss vor der Zeitwahl feststehen, welche Beobachtung eine Bestätigung rechtfertigt. Reicht eine neue Managementsession? Müssen Nachbarschaften, Routingtabellen, FIB, bidirektionale Pakete und ein unabhängiger Servicetest stimmen? Wer darf verlängern? Wie oft? Wann wird fehlender Beweis zum Grund für Abbruch statt für eine weitere Verlängerung?

Bei mehreren Geräten gibt es zudem keinen gemeinsamen Startpunkt. Der Orchestrator sendet nacheinander, Netzlatenz variiert, jeder Server beginnt seine eigene Frist. Ein einziger Countdown in der Benutzeroberfläche kann eine gemeinsame Finalität vortäuschen. Erforderlich sind serverseitiger Start, Ablauf und verbleibendes Beobachtungsbudget pro Gerät.

Wer die Frist festlegt und verlängert, besitzt einen Teil der Änderungsgewalt. Diese Rolle gehört ebenso in die Autorisierungsmatrix wie die Berechtigung zum Commit selbst.

Persistenz löst die Entscheidung von der Session

Beim normalen Confirmed Commit ist die initiierende NETCONF-Session Teil der Sicherheitsbedingung. Bricht sie vor Abschluss ab, wird zurückgesetzt. Für eine Managementpfadänderung ist das oft genau das gewünschte Verhalten.

In verteilten Automatisierungen kann dieselbe Bindung hinderlich sein. Ein Job startet, ein anderer prüft, ein Incident-Team übernimmt über einen neuen Pfad. Liefert der Initiator einen undurchsichtigen Wert in persist, bleibt das Verfahren nach Ende der ursprünglichen Session bestehen. Eine andere Session kann den passenden Wert als persist-id bei der vorgesehenen Bestätigung, Verlängerung oder Stornierung vorlegen.

Der Wert trägt Kontinuität, nicht Identität. Der Server beweist keinen zweiten Menschen, keine unabhängige Prüfung und kein Mandat. Derselbe Orchestrator kann Token erzeugen, Änderung starten und sich über eine zweite Session selbst bestätigen. Zwei Sessions sind nicht automatisch Funktionstrennung.

Soll ein Vier-Augen-Prinzip gelten, müssen Identitäten, Credentials, NACM-Rechte, Aufgabenbesitz und Beweisspeicher getrennt sein. Auch das rohe Token gehört nicht in breite Logs. Sonst wird aus Auditmaterial eine wiederverwendbare Entscheidungsfähigkeit. Ein geschützter Fingerprint kann Ereignisse verbinden; der nutzbare Wert braucht eine kontrollierte Verwahrung.

Sessionauthentisierung, Tokenübereinstimmung und Änderungsautorisierung sind drei unabhängige Aussagen.

Wiederherstellung ist breiter als die gedachte Gegenänderung

Rollback wird gern als inverse Fassung genau jener Zeilen verstanden, die ein Job geschrieben hat. Confirmed Commit stellt einen vorherigen Konfigurationszustand wieder her. RFC 6241 warnt, dass Änderungen, die nach dem provisorischen Commit vorgenommen wurden, dadurch verändert oder entfernt werden können.

Änderung A geht mit fünf Minuten Frist nach Running. Zwei Minuten später schreibt ein anderes System Änderung B in einen vermeintlich unabhängigen Bereich. A verliert die Session. Der Server kennt die organisatorische Unabhängigkeit von B nicht; er besitzt eine Ausgangsbasis vor A. Ohne nachgewiesene engere Merge-Semantik kann B mit verschwinden.

Locks begrenzen dieses Risiko. Ein globales NETCONF-Lock schließt andere Sessions vom betroffenen Datastore aus. RFC 5717 erlaubt Partial Locks, zeigt aber gerade hier die Grenze: Während eines ausstehenden Confirmed Commit muss der Server ein neues Partial Lock auf Running ablehnen, weil er den Datastore möglicherweise umfassender wiederherstellen muss.

Ein Lock bestätigt keine inhaltliche Richtigkeit. Es beweist Ausschluss in seinem tatsächlichen Bereich und nur für Schreibwege, die es respektieren. Der Nachweis umfasst daher Scope, Eigentümer, Erwerb, Freigabegrund, konkurrierende Schreibversuche und Fingerprints vor und nach der Wiederherstellung. Ohne diese Angaben ist „Rollback-fähig“ lediglich eine Produktbezeichnung.

Eine RESTCONF-Änderung kann das NETCONF-Fenster schließen

Protokollgrenzen müssen keine Zustandsgrenzen sein. RFC 8040 beschreibt RESTCONF über konzeptionellen Datastores eines ko-lokierten NETCONF-Servers. Nutzt dieser Candidate, wird eine erfolgreiche RESTCONF-Änderung automatisch committed.

Ist ein nicht persistenter NETCONF Confirmed Commit offen, wirkt dieser neue Commit als Bestätigung. Ein RESTCONF-Client kann damit das Rücksetzungsfenster eines NETCONF-Vorgangs beenden, ohne einen Befehl namens „confirm“ zu senden. Wer nur die NETCONF-Auditspur beobachtet, kann den finalisierenden Akteur übersehen.

Beim persistenten Verfahren ist das Ergebnis anders. RESTCONF hat kein Feld für persist-id. Verlangt der offene Vorgang dieses Token, muss die Änderung mit HTTP 409 in-use scheitern. Ein NETCONF-Lock kann denselben Status auslösen. Die 409-Ereignisse sollten deshalb einem bekannten Commit- oder Lock-Inhaber zugeordnet werden, statt als allgemeine API-Fehler zu verschwinden.

Auch Startup hängt vom Schreibweg ab. Unterstützt der ko-lokierte Server Startup, aktualisiert ein erfolgreicher RESTCONF-Edit ihn nach RFC 8040 automatisch. Aus einem NETCONF-Commit nach Running darf diese Aussage nicht abgeleitet werden. Die API-Provenienz ist Teil der Persistenzbehauptung.

SSH-Identität, NACM-Berechtigung und YANG-Gültigkeit

RFC 6242 bildet NETCONF auf SSH ab. Der geschützte Kanal und die authentisierte Gegenstelle sind grundlegend. Sie entscheiden nicht, ob der Nutzer <commit> aufrufen oder einen bestimmten Datenknoten ändern darf.

Das NACM aus RFC 8341 trennt Zugriff auf Protokolloperationen, Datenknoten und Benachrichtigungen. Eine authentisierte Session kann beim RPC abgewiesen werden. Ein erlaubter RPC kann einen verbotenen Knoten berühren. Recovery-Sessions können implementierungsspezifische Ausnahmen besitzen. Jede Stufe braucht ein eigenes Ergebnis im Audit.

Danach folgt die Modellgültigkeit. RFC 7950 definiert YANG 1.1 mit Typen, Strukturen, Referenzen und Constraints. Eine Adresse kann dem Typ entsprechen und zum falschen Standort gehören. Eine formal konsistente Policy kann einen Dienst abschneiden. Validierung zeigt Modellkonformität, nicht richtige Absicht.

RFC 8525 macht Module, Features, Deviations, Datastore-Schemas und eine serverspezifische content-id sichtbar. Der Validierungsnachweis muss auf genau diesen Bibliothekszustand verweisen. Ändert er sich zwischen Vorbereitung und Commit, kann derselbe Candidate unter einem anderen Vertrag laufen.

Running ist nicht Operational

Die NMDA aus RFC 8342 trennt Running, Intended und Operational. Running enthält die vollständige aktuelle Konfiguration. Das System kann sie durch Template-Expansion, Entfernen inaktiver Knoten oder systemgesteuerte Werte in Intended überführen. Operational zeigt Konfiguration und Zustand, die tatsächlich verwendet werden.

Konfiguration für eine fehlende Ressource kann in Running und Intended verbleiben, ohne in Operational als angewandt zu erscheinen. Physische Grenzen, interne Abhängigkeiten und asynchrone Prozesse können Anwendung verzögern oder verändern. Der Confirmed Commit kann complete sein, während das Gerät weiterhin teilweise abweicht.

Die Probe muss dem Änderungsgegenstand folgen. Eine Interface-Änderung verlangt effektiven Zustand und Pakete. Routingpolicy verlangt Nachbarschaften, Kandidaten, Auswahl, Installation und Forwarding. Ein Managementpfad verlangt Prüfung des neuen Wegs und einen unabhängigen Rückweg. Ein Konfigurationsvergleich ist Datastore-Evidenz, keine Netz-Evidenz.

Freigabeticket, SSH-Identität, NACM-Entscheidung, YANG-Gültigkeit, finales Running, erzeugtes Intended, angewandtes Operational und funktionierender Dienst sind verschiedene Realitätsschichten. Jede kann wahr sein, während die nächste falsch bleibt.

Mehr Server erzeugen keine verteilte Atomizität

RFC 6244 ordnet NETCONF und YANG in eine umfassendere Managementarchitektur ein. Ein Controller kann Confirmed Commits als Baustein einer Netzänderung nutzen. Jeder Server speichert jedoch seine eigene Basis, startet seinen eigenen Timer und folgt eigenen Fähigkeiten, Locks, Neustarts und Hardwarepfaden.

RPCs beginnen zeitversetzt. Ein Gerät kann neu starten, ein anderes ein Lock verweigern, ein drittes Running akzeptieren und die Ressource nicht anwenden. Antworten neun Geräte mit <ok> und eines mit Fehler, existiert ein Teilzustand. Bestätigt der Controller neun, macht er ihn final. Storniert er neun, muss er danach Operational und Paketpfade prüfen.

Die verteilte Ebene ist Aufgabe des Orchestrators: gemeinsame Transaktionsidentität, Basis pro Gerät, Reihenfolge, Abbruchbedingungen, Canaries, Kompensation und Abgleich. Gestufte Einführung kann ehrlicher sein als eine unerfüllbare Alles-oder-nichts-Zusage. Mehrere grüne RPCs sind jedenfalls kein gemeinsamer Commit-Punkt.

Die schmale Behauptung ist die belastbare

Die IANA-Registrierung koordiniert URNs für Candidate, Confirmed Commit, Startup, Validate und weitere Fähigkeiten. Diese gemeinsame Sprache soll klein und interoperabel bleiben. Rollen, Fristen, Sperrpolitik, Beobachtung und Mehrgeräteentscheidungen bleiben lokal.

Ein belastbarer Bericht sagt: Dieser Nutzer und diese Session überführten unter dieser Autorisierungs- und Schemafassung diesen Candidate aus dieser Basis nach Running; diese Frist und diese Session- oder Tokenregel beherrschten die Finalität; dieses Ereignis beendete das Verfahren; Running und Startup hatten danach diese Zustände; Intended, Operational, Pakete und Dienste zeigten diese Ergebnisse; sämtliche Geräte wurden abgeglichen.

Praktische Autorität liegt bei den Akteuren, die RPCs senden, Token verwahren, Fristen verlängern, bestätigen, Startup schreiben und Beobachtung als ausreichend erklären können. Namen in einem Genehmigungsdiagramm erzeugen diese Fähigkeit nicht. Erst wenn ausführbare Kontrolle und dokumentierte Rolle übereinstimmen, entsteht Governance.

Confirmed Commit ist gerade deshalb stark, weil es nicht mehr verspricht. Es gibt dem Server einen klaren Übergang zwischen provisorischer Ausführung und Wiederherstellung. Die Verantwortung für alle späteren Behauptungen bleibt sichtbar beim Betreiber.

Quellen