Rollback, an das Sie nicht denken müssen: bestätigte Commits im Netzwerk

Jeder Netzwerkingenieur kennt das Gefühl: Sie drücken Enter bei einer Access List oder einer Routing-Änderung, und die SSH-Sitzung antwortet nicht mehr. Jetzt lautet die Frage, ob jemand eine Konsole erreicht, bevor Kunden etwas merken. Die bessere Frage ist, warum die Änderung Sie überhaupt aussperren konnte. Die meisten ernsthaften Netzwerkplattformen können eine Änderung von selbst rückgängig machen, wenn Sie aufhören, sie zu bestätigen. Dieser Artikel zeigt wie, Plattform für Plattform, und die Gewohnheiten, die das verlässlich machen.

Das Prinzip: Eine Änderung muss sich ihre Dauerhaftigkeit verdienen

Eine Änderung sollte erst dauerhaft werden, nachdem Sie aus einer funktionierenden Sitzung heraus bewiesen haben, dass das Gerät weiterhin erreichbar ist und sich richtig verhält. Wenn Sie nie zur Bestätigung kommen, weil die Änderung Sie abgeschnitten hat, sollte das Gerät sich selbst zurücksetzen. Das verwandelt den schlimmsten Fall einer schlechten Änderung von «zum Rechenzentrum fahren» in «ein paar Minuten warten».

Vier Bausteine lassen das funktionieren: eine gespeicherte Kopie der Konfiguration vor der Änderung, ein Timer, der zurücksetzt, solange nicht bestätigt wird, ein Weg, den Zustand vorher und nachher zu vergleichen, und die Disziplin, erst nach der Verifizierung zu speichern.

Juniper: commit confirmed

Junos hat das sauberste Modell. Änderungen werden in einer Candidate Configuration vorbereitet und mit einem Commit angewendet. Ein bestätigter Commit rollt von selbst zurück, solange Sie nicht erneut committen:

commit confirmed 5
# verify reachability, routing, the thing you changed
commit

Stirbt die Sitzung, kehrt der Router nach fünf Minuten zur vorherigen Konfiguration zurück. show system commit und rollback <n> geben Ihnen Historie und eine schnelle manuelle Rückkehr.

Cisco IOS-XR: ebenfalls commit confirmed

IOS-XR folgt derselben Idee:

commit confirmed 300
# verify
commit

Verwenden Sie show configuration commit list, um die letzten Commits zu sehen, und rollback configuration last 1, um bewusst einen Schritt zurückzugehen.

Cisco IOS-XE: Revert-Timer

IOS-XE wendet Befehle live an, also muss das Sicherheitsnetz zuerst scharf geschaltet werden. Die Archive-Funktion liefert es:

archive
 path bootflash:archive
 maximum 14
!
configure terminal revert timer 5
! make the change
configure confirm

Wenn Sie nicht innerhalb von fünf Minuten bestätigen, kehrt das Gerät zu der Konfiguration zurück, die es beim Betreten des Konfigurationsmodus hatte. Zum Ersetzen einer ganzen Konfiguration aus einer Datei kombinieren Sie das Replace mit automatischem Zurücksetzen bei Fehlern, statt es zu erzwingen:

configure replace bootflash:known-good.cfg revert trigger error timer 5

Ein vollständiges Replace mit force überspringt die Sicherheitsabfragen, heben Sie es sich also für die Wiederherstellung eines Snapshots auf, den dasselbe Gerät selbst erzeugt hat, und bevorzugen Sie für alles andere ein Merge oder die Anwendung Abschnitt für Abschnitt.

Cisco NX-OS: Checkpoints

NX-OS bietet benannte Checkpoints und atomares Rollback:

checkpoint before-change-001
! make the change
show diff rollback-patch checkpoint before-change-001 running-config
rollback running-config checkpoint before-change-001 atomic

Es gibt keinen eingebauten Bestätigungs-Timer, auf Nexus wiegt die Disziplin also schwerer: Verifizieren Sie den Hostnamen vor dem ersten Befehl, wenden Sie einen Befehl nach dem anderen an, prüfen Sie das Ergebnis, und behalten Sie den Checkpoint plus eine Kopie der Konfiguration außerhalb des Geräts, bis sich die Änderung bewährt hat.

Firewalls und Linux: Bauen Sie den Timer selbst

Wo eine Plattform keinen Bestätigungsmechanismus hat, schalten Sie einen außerhalb der Änderung scharf. Auf einem Linux-Host kann systemd die Rücknahme planen, bevor Sie irgendetwas Riskantes anfassen:

systemd-run --on-active=240 --unit=net-safety /usr/local/sbin/restore-previous-network.sh
# make the change, then verify with a brand new SSH session
systemctl stop net-safety.timer

Der Timer löst aus, selbst wenn Ihre Sitzung stirbt, ein Fehler in einer Firewall- oder SSH-Konfiguration behebt sich also in vier Minuten von selbst. Für Firewall-Appliances mit API wird dieselbe Idee zu einem skriptgesteuerten Cutover: ein Konfigurations-Backup auf jedem Knoten ziehen, die Änderung anwenden, Erreichbarkeitsprüfungen laufen lassen, und das Backup automatisch wiederherstellen, wenn sie fehlschlagen.

Snapshots und Diffs: Hat sich sonst noch etwas bewegt?

Eine Änderung kann erreichen, was sie sollte, und trotzdem etwas anderes stören. Vor und nach jedem Schritt eines größeren Rollouts halten Sie den Zustand fest, der zählt (Zusammenfassungen der Routing-Sessions, Interface-Status, Overlay-Peers), und vergleichen ihn:

show bgp all summary > before.txt
# change
show bgp all summary > after.txt
diff before.txt after.txt

Wenn sich etwas geändert hat, das sich nicht hätte ändern sollen, rollen Sie zurück, solange die Ursache noch offensichtlich ist. Automatisieren Sie das, und Sie können es auf jedem Gerät eines Rollouts erzwingen, mit automatischem Rollback, wenn der Diff nicht sauber ist.

Gewohnheiten, die die Werkzeuge wirksam machen

• Eine Hälfte eines redundanten Paars auf einmal. Ändern Sie das Standby, verifizieren Sie, dann das Aktive. Ein Fehler kostet dann für ein paar Minuten Redundanz, nicht den Dienst.
• Verifizieren Sie aus einer neuen Sitzung. Eine bestehende SSH-Sitzung kann eine Änderung überleben, die neue blockiert. Öffnen Sie eine frische, bevor Sie bestätigen.
• Speichern Sie zuletzt. Schreiben Sie die Running Configuration erst nach der Verifizierung in die Startup Configuration. Bis dahin ist auch ein Reload ein Rollback.

Fragen Sie Ihr eigenes Team

• Welche Ihrer Plattformen unterstützen bestätigte Commits oder Revert-Timer, und werden sie jedes Mal verwendet?
• Gibt es von jeder Gerätekonfiguration eine Kopie außerhalb des Geräts, aus der Zeit vor der letzten Änderung?
• Vergleichen Rollouts den Routing-Zustand vor und nach jedem Schritt?
• Wird je etwas an beiden Mitgliedern eines redundanten Paars gleichzeitig geändert?

Unsere Netzwerkänderungen folgen dieser Disziplin auf jeder Plattform, und wenn eine Änderung Ihren Verkehr berühren könnte, stimmen wir den Zeitpunkt zuerst mit Ihnen ab. Wenn Sie Hilfe dabei möchten, dieselben Sicherheitsnetze in Ihren eigenen Betrieb einzubauen, sprechen Sie mit uns.

cta: Mit einem Ingenieur sprechen

Related

• /what-we-do/network/change-discipline/
• /what-we-do/network/datacenter-fabric/
• /what-we-do/network/perimeter-firewalls/