Un rollback que vous n'avez pas à retenir : les confirmed commits sur le réseau

Tout ingénieur réseau connaît la sensation : vous appuyez sur entrée sur une access list ou un changement de routage, et la session SSH cesse de répondre. La question devient alors de savoir si quelqu'un peut atteindre une console avant que les clients ne s'en aperçoivent. La meilleure question est pourquoi le changement a pu vous couper l'accès. La plupart des plateformes réseau sérieuses peuvent annuler un changement d'elles-mêmes si vous cessez de le confirmer. Cet article décrit comment, plateforme par plateforme, et les habitudes qui rendent cela fiable.

Le principe : un changement doit mériter sa permanence

Un changement ne doit devenir permanent qu'après avoir prouvé, depuis une session qui fonctionne, que l'équipement reste joignable et se comporte correctement. Si vous n'arrivez jamais à la confirmation, parce que le changement vous a coupé, l'équipement doit se rétablir lui-même. Cela transforme le pire cas d'un mauvais changement de « rouler jusqu'au datacenter » en « attendre quelques minutes ».

Quatre briques le rendent possible : une copie sauvegardée de la configuration avant le changement, un minuteur qui rétablit à défaut de confirmation, un moyen de comparer l'état avant et après, et la discipline de ne sauvegarder qu'après vérification.

Juniper : commit confirmed

Junos a le modèle le plus propre. Les changements sont préparés dans une candidate configuration et appliqués par un commit. Un confirmed commit fait un rollback tout seul, sauf si vous recommitez :

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

Si la session meurt, le routeur revient à la configuration précédente après cinq minutes. show system commit et rollback <n> vous donnent l'historique et un retour manuel rapide.

Cisco IOS-XR : commit confirmed aussi

IOS-XR suit la même idée :

commit confirmed 300
# verify
commit

Utilisez show configuration commit list pour voir les commits récents et rollback configuration last 1 pour revenir d'un pas délibérément.

Cisco IOS-XE : revert timers

IOS-XE applique les commandes à chaud, donc le filet de sécurité doit être armé d'abord. La fonction archive le fournit :

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

Si vous ne confirmez pas sous cinq minutes, l'équipement revient à la configuration qu'il avait quand vous êtes entré en mode configuration. Pour remplacer une configuration entière depuis un fichier, associez le replace à un retour automatique sur erreur plutôt que de le forcer :

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

Un replace complet avec force saute les questions de sécurité, donc réservez-le à la restauration d'un snapshot que le même équipement a lui-même produit, et préférez une fusion ou une application section par section pour tout le reste.

Cisco NX-OS : checkpoints

NX-OS offre des checkpoints nommés et un rollback atomique :

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

Il n'y a pas de minuteur de confirmation intégré, donc sur Nexus la discipline pèse davantage : vérifiez le hostname avant la première commande, appliquez une commande à la fois, contrôlez le résultat, et gardez le checkpoint ainsi qu'une copie de la configuration hors de l'équipement jusqu'à ce que le changement soit prouvé.

Firewalls et Linux : construisez le minuteur vous-même

Là où une plateforme n'a pas de mécanisme de confirmation, armez-en un en dehors du changement. Sur un hôte Linux, systemd peut programmer l'annulation avant que vous ne touchiez à quoi que ce soit de risqué :

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

Le minuteur se déclenche même si votre session meurt, donc une erreur dans une configuration de firewall ou de SSH se corrige d'elle-même en quatre minutes. Pour les appliances firewall dotées d'une API, la même idée devient une bascule scriptée : prenez un backup de la configuration sur chaque nœud, appliquez le changement, lancez des contrôles de joignabilité, et restaurez le backup automatiquement s'ils échouent.

Snapshots et diffs : quelque chose d'autre a-t-il bougé ?

Un changement peut réussir ce qu'il visait et pourtant déranger autre chose. Avant et après chaque étape d'un déploiement plus large, capturez l'état qui compte (résumé des sessions de routage, état des interfaces, pairs de l'overlay) et comparez-les :

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

Si quelque chose a changé qui n'aurait pas dû, faites le rollback pendant que la cause est encore évidente. Automatisez-le et vous pouvez l'imposer sur chaque équipement d'un déploiement, avec rollback automatique quand le diff n'est pas propre.

Les habitudes qui font fonctionner les outils

• Une moitié d'une paire redondante à la fois. Changez le standby, vérifiez, puis l'actif. Une erreur coûte alors de la redondance pendant quelques minutes, pas du service.
• Vérifiez depuis une nouvelle session. Une session SSH existante peut survivre à un changement qui bloque les nouvelles. Ouvrez-en une fraîche avant de confirmer.
• Sauvegardez en dernier. N'écrivez la running configuration dans la startup qu'après vérification. Jusque-là, un redémarrage est aussi un rollback.

Interrogez votre propre équipe

• Lesquelles de vos plateformes prennent en charge les confirmed commits ou les revert timers, et sont-ils utilisés à chaque fois ?
• Existe-t-il une copie hors équipement de la configuration de chaque équipement, datant d'avant le dernier changement ?
• Les déploiements comparent-ils l'état du routage avant et après chaque étape ?
• Change-t-on jamais quelque chose sur les deux membres d'une paire redondante en même temps ?

Nos changements réseau suivent cette discipline sur chaque plateforme, et si un changement pouvait toucher votre trafic, nous convenons d'abord du moment avec vous. Si vous voulez de l'aide pour bâtir les mêmes filets de sécurité dans votre propre exploitation, parlez-nous.

cta: Parler à un ingénieur

Related

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