Rollback που δεν χρειάζεται να θυμάστε: confirmed commits στο δίκτυο

Κάθε μηχανικός δικτύων ξέρει το συναίσθημα: πατάτε enter σε μια access list ή σε μια αλλαγή routing, και η συνεδρία SSH σταματά να απαντά. Τώρα το ερώτημα είναι αν θα προλάβει κάποιος μια κονσόλα πριν το προσέξουν οι πελάτες. Το καλύτερο ερώτημα είναι γιατί η αλλαγή μπόρεσε καν να σας αποκλείσει. Οι περισσότερες σοβαρές πλατφόρμες δικτύου μπορούν να αναιρέσουν μια αλλαγή μόνες τους, αν σταματήσετε να την επιβεβαιώνετε. Αυτό το άρθρο περιγράφει πώς, πλατφόρμα προς πλατφόρμα, και τις συνήθειες που το κάνουν αξιόπιστο.

Η αρχή: μια αλλαγή πρέπει να κερδίσει τη μονιμότητά της

Μια αλλαγή πρέπει να γίνεται μόνιμη μόνο αφού αποδείξετε, από μια συνεδρία που δουλεύει, ότι η συσκευή παραμένει προσβάσιμη και συμπεριφέρεται σωστά. Αν δεν φτάσετε ποτέ στην επιβεβαίωση, επειδή η αλλαγή σας απέκοψε, η συσκευή πρέπει να επανέλθει μόνη της. Αυτό μετατρέπει τη χειρότερη περίπτωση μιας κακής αλλαγής από «οδήγησε μέχρι το datacenter» σε «περίμενε λίγα λεπτά».

Τέσσερα δομικά στοιχεία το κάνουν να δουλεύει: ένα αποθηκευμένο αντίγραφο της διαμόρφωσης πριν από την αλλαγή, ένας χρονοδιακόπτης που επαναφέρει αν δεν υπάρξει επιβεβαίωση, ένας τρόπος να συγκρίνετε την κατάσταση πριν και μετά, και η πειθαρχία να αποθηκεύετε μόνο αφού επαληθεύσετε.

Juniper: commit confirmed

Το Junos έχει το πιο καθαρό μοντέλο. Οι αλλαγές ετοιμάζονται σε μια candidate configuration και εφαρμόζονται με ένα commit. Ένα confirmed commit κάνει rollback μόνο του, εκτός αν κάνετε commit ξανά:

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

Αν η συνεδρία πεθάνει, ο router επιστρέφει στην προηγούμενη διαμόρφωση μετά από πέντε λεπτά. Τα show system commit και rollback <n> σας δίνουν ιστορικό και γρήγορη χειροκίνητη επιστροφή.

Cisco IOS-XR: επίσης commit confirmed

Το IOS-XR ακολουθεί την ίδια ιδέα:

commit confirmed 300
# verify
commit

Χρησιμοποιήστε show configuration commit list για να δείτε τα πρόσφατα commits και rollback configuration last 1 για να κάνετε ένα βήμα πίσω συνειδητά.

Cisco IOS-XE: revert timers

Το IOS-XE εφαρμόζει τις εντολές ζωντανά, οπότε το δίχτυ ασφαλείας πρέπει να οπλιστεί πρώτα. Η λειτουργία archive το παρέχει:

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

Αν δεν επιβεβαιώσετε μέσα σε πέντε λεπτά, η συσκευή επιστρέφει στη διαμόρφωση που είχε όταν μπήκατε σε configuration mode. Για αντικατάσταση ολόκληρης διαμόρφωσης από αρχείο, συνδυάστε το replace με αυτόματη επαναφορά σε σφάλμα αντί να το επιβάλετε:

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

Ένα πλήρες replace με force παρακάμπτει τις ερωτήσεις ασφαλείας, οπότε κρατήστε το για επαναφορά ενός snapshot που παρήγαγε η ίδια συσκευή, και προτιμήστε merge ή εφαρμογή τμήμα προς τμήμα για οτιδήποτε άλλο.

Cisco NX-OS: checkpoints

Το NX-OS προσφέρει επώνυμα checkpoints και ατομικό 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

Δεν υπάρχει ενσωματωμένος χρονοδιακόπτης επιβεβαίωσης, οπότε στα Nexus η πειθαρχία μετράει περισσότερο: επαληθεύστε το hostname πριν από την πρώτη εντολή, εφαρμόστε μία εντολή τη φορά, ελέγξτε το αποτέλεσμα, και κρατήστε το checkpoint μαζί με ένα αντίγραφο της διαμόρφωσης εκτός συσκευής μέχρι η αλλαγή να αποδειχθεί.

Firewalls και Linux: φτιάξτε τον χρονοδιακόπτη μόνοι σας

Όπου μια πλατφόρμα δεν έχει μηχανισμό επιβεβαίωσης, οπλίστε έναν έξω από την αλλαγή. Σε έναν Linux host, το systemd μπορεί να προγραμματίσει την αναίρεση πριν αγγίξετε οτιδήποτε επικίνδυνο:

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

Ο χρονοδιακόπτης πυροδοτείται ακόμη κι αν η συνεδρία σας πεθάνει, οπότε ένα λάθος σε διαμόρφωση firewall ή SSH διορθώνεται μόνο του σε τέσσερα λεπτά. Για firewall appliances με API, η ίδια ιδέα γίνεται ένα scripted cutover: πάρτε backup της διαμόρφωσης σε κάθε κόμβο, εφαρμόστε την αλλαγή, τρέξτε ελέγχους προσβασιμότητας, και επαναφέρετε το backup αυτόματα αν αποτύχουν.

Snapshots και diffs: κουνήθηκε κάτι άλλο;

Μια αλλαγή μπορεί να πετύχει αυτό που ήθελε και παρ' όλα αυτά να ενοχλήσει κάτι άλλο. Πριν και μετά από κάθε βήμα μιας μεγαλύτερης εγκατάστασης, καταγράψτε την κατάσταση που μετράει (σύνοψη routing sessions, κατάσταση interfaces, overlay peers) και κάντε diff:

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

Αν άλλαξε κάτι που δεν έπρεπε, κάντε rollback όσο η αιτία είναι ακόμη προφανής. Αυτοματοποιήστε το και μπορείτε να το επιβάλετε σε κάθε συσκευή μιας εγκατάστασης, με αυτόματο rollback όταν το diff δεν είναι καθαρό.

Συνήθειες που κάνουν τα εργαλεία να δουλεύουν

• Το ένα μισό ενός πλεονάζοντος ζεύγους τη φορά. Αλλάξτε το standby, επαληθεύστε, μετά το active. Ένα λάθος τότε κοστίζει πλεονασμό για λίγα λεπτά, όχι υπηρεσία.
• Επαληθεύστε από νέα συνεδρία. Μια υπάρχουσα συνεδρία SSH μπορεί να επιβιώσει μιας αλλαγής που μπλοκάρει τις νέες. Ανοίξτε μια φρέσκια πριν επιβεβαιώσετε.
• Αποθηκεύστε τελευταίο. Γράψτε τη running configuration στη startup μόνο μετά την επαλήθευση. Μέχρι τότε, μια επανεκκίνηση είναι κι αυτή rollback.

Ρωτήστε τη δική σας ομάδα

• Ποιες από τις πλατφόρμες σας υποστηρίζουν confirmed commits ή revert timers, και χρησιμοποιούνται κάθε φορά;
• Υπάρχει αντίγραφο της διαμόρφωσης κάθε συσκευής εκτός συσκευής, από πριν την τελευταία αλλαγή;
• Συγκρίνουν οι εγκαταστάσεις την κατάσταση routing πριν και μετά από κάθε βήμα;
• Αλλάζει ποτέ κάτι και στα δύο μέλη ενός πλεονάζοντος ζεύγους ταυτόχρονα;

Οι αλλαγές δικτύου μας ακολουθούν αυτή την πειθαρχία σε κάθε πλατφόρμα, και αν μια αλλαγή θα μπορούσε να αγγίξει την κίνησή σας, συμφωνούμε πρώτα μαζί σας τον χρόνο. Αν θέλετε βοήθεια να χτίσετε τα ίδια δίχτυα ασφαλείας στη δική σας λειτουργία, μιλήστε μας.

cta: Μιλήστε με έναν μηχανικό

Related

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