Un rollback che non dovete ricordare: commit confirmed in rete

Ogni ingegnere di rete conosce la sensazione: premete invio su una access list o su una modifica di routing, e la sessione SSH smette di rispondere. Ora la domanda è se qualcuno riesce a raggiungere una console prima che i clienti se ne accorgano. La domanda migliore è perché quella modifica abbia potuto lasciarvi fuori. La maggior parte delle piattaforme di rete serie sa annullare una modifica da sola, se smettete di confermarla. Questo articolo spiega come, piattaforma per piattaforma, e le abitudini che lo rendono affidabile.

Il principio: una modifica deve guadagnarsi la permanenza

Una modifica dovrebbe diventare permanente solo dopo che avete dimostrato, da una sessione funzionante, che il dispositivo è ancora raggiungibile e si comporta come previsto. Se non arrivate mai a confermare, perché la modifica vi ha tagliato fuori, il dispositivo deve tornare indietro da solo. Questo trasforma il caso peggiore di una modifica sbagliata da «guidare fino al datacenter» a «aspettare qualche minuto».

Quattro elementi lo rendono possibile: una copia salvata della configurazione prima della modifica, un timer che ripristina se non arriva la conferma, un modo per confrontare lo stato prima e dopo, e la disciplina di salvare solo dopo aver verificato.

Juniper: commit confirmed

Junos ha il modello più pulito. Le modifiche vengono preparate in una candidate configuration e applicate con un commit. Un confirmed commit fa rollback da solo, a meno che non facciate di nuovo commit:

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

Se la sessione muore, il router torna alla configurazione precedente dopo cinque minuti. show system commit e rollback <n> vi danno lo storico e un rientro manuale rapido.

Cisco IOS-XR: anche qui commit confirmed

IOS-XR segue la stessa idea:

commit confirmed 300
# verify
commit

Usate show configuration commit list per vedere i commit recenti e rollback configuration last 1 per tornare indietro di un passo in modo deliberato.

Cisco IOS-XE: revert timer

IOS-XE applica i comandi dal vivo, quindi la rete di sicurezza va armata prima. La funzione archive la fornisce:

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

Se non confermate entro cinque minuti, il dispositivo torna alla configurazione che aveva quando siete entrati in configuration mode. Per sostituire un'intera configurazione da file, abbinate il replace al ripristino automatico in caso di errore invece di forzarlo:

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

Un replace completo con force salta le domande di sicurezza: riservatelo al ripristino di uno snapshot prodotto dallo stesso dispositivo, e preferite il merge o l'applicazione sezione per sezione per tutto il resto.

Cisco NX-OS: checkpoint

NX-OS offre checkpoint con nome e rollback atomico:

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

Non c'è un timer di conferma integrato, quindi sui Nexus la disciplina pesa di più: verificate l'hostname prima del primo comando, applicate un comando alla volta, controllate il risultato, e conservate il checkpoint insieme a una copia della configurazione fuori dal dispositivo finché la modifica non è dimostrata.

Firewall e Linux: costruitevi il timer da soli

Dove una piattaforma non ha un meccanismo di conferma, armatene uno fuori dalla modifica. Su un host Linux, systemd può programmare l'annullamento prima che tocchiate qualcosa di rischioso:

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

Il timer scatta anche se la vostra sessione muore, quindi un errore nella configurazione del firewall o di SSH si corregge da solo in quattro minuti. Per le appliance firewall con API, la stessa idea diventa un cutover scriptato: backup della configurazione su ogni nodo, applicazione della modifica, controlli di raggiungibilità, e ripristino automatico del backup se falliscono.

Snapshot e diff: si è mosso qualcos'altro?

Una modifica può riuscire in ciò che voleva e disturbare comunque qualcos'altro. Prima e dopo ogni passo di un rollout più ampio, catturate lo stato che conta (riepilogo delle sessioni di routing, stato delle interfacce, peer dell'overlay) e fatene il diff:

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

Se è cambiato qualcosa che non doveva cambiare, fate rollback finché la causa è ancora evidente. Automatizzatelo e potrete imporlo su ogni dispositivo di un rollout, con rollback automatico quando il diff non è pulito.

Le abitudini che fanno funzionare gli strumenti

• Una metà di una coppia ridondata alla volta. Modificate lo standby, verificate, poi l'attivo. Un errore costa allora ridondanza per qualche minuto, non servizio.
• Verificate da una sessione nuova. Una sessione SSH esistente può sopravvivere a una modifica che blocca quelle nuove. Apritene una fresca prima di confermare.
• Salvate per ultimo. Scrivete la running configuration nella startup solo dopo la verifica. Fino ad allora, anche un reload è un rollback.

Chiedete al vostro team

• Quali delle vostre piattaforme supportano confirmed commit o revert timer, e vengono usati ogni volta?
• Esiste una copia fuori dispositivo della configurazione di ogni apparato, da prima dell'ultima modifica?
• I rollout confrontano lo stato di routing prima e dopo ogni passo?
• Capita mai che qualcosa venga cambiato su entrambi i membri di una coppia ridondata insieme?

Le nostre modifiche di rete seguono questa disciplina su ogni piattaforma, e se una modifica potrebbe toccare il vostro traffico, concordiamo prima con voi la tempistica. Se volete aiuto per costruire le stesse reti di sicurezza nella vostra operatività, parlateci.

cta: Parla con un ingegnere

Related

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