Rollback que no tiene que recordar: commits confirmados en la red

Todo ingeniero de redes conoce la sensación: pulsa intro en una access list o en un cambio de routing, y la sesión SSH deja de responder. Ahora la pregunta es si alguien llegará a una consola antes de que lo noten los clientes. La mejor pregunta es por qué el cambio pudo dejarle fuera siquiera. La mayoría de las plataformas de red serias pueden deshacer un cambio por sí solas si usted deja de confirmarlo. Este artículo recorre cómo, plataforma a plataforma, y los hábitos que lo hacen fiable.

El principio: un cambio tiene que ganarse su permanencia

Un cambio debería volverse permanente solo después de que usted haya demostrado, desde una sesión que funciona, que el dispositivo sigue siendo accesible y se comporta bien. Si nunca llega a confirmar, porque el cambio le dejó fuera, el dispositivo debería volver atrás por sí mismo. Eso convierte el peor caso de un mal cambio de «conducir hasta el datacenter» en «esperar unos minutos».

Cuatro piezas lo hacen funcionar: una copia guardada de la configuración anterior al cambio, un temporizador que revierte si no hay confirmación, una forma de comparar el estado antes y después, y la disciplina de guardar solo después de verificar.

Juniper: commit confirmed

Junos tiene el modelo más limpio. Los cambios se preparan en una candidate configuration y se aplican con un commit. Un confirmed commit hace rollback por sí solo a menos que usted vuelva a hacer commit:

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

Si la sesión muere, el router vuelve a la configuración anterior pasados cinco minutos. show system commit y rollback <n> le dan el historial y una vuelta atrás manual rápida.

Cisco IOS-XR: también commit confirmed

IOS-XR sigue la misma idea:

commit confirmed 300
# verify
commit

Use show configuration commit list para ver los commits recientes y rollback configuration last 1 para dar un paso atrás de forma deliberada.

Cisco IOS-XE: revert timers

IOS-XE aplica los comandos en vivo, así que la red de seguridad tiene que armarse primero. La función archive la proporciona:

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

Si no confirma en cinco minutos, el dispositivo vuelve a la configuración que tenía cuando usted entró en el modo de configuración. Para sustituir una configuración completa desde un fichero, combine el replace con la reversión automática ante error en lugar de forzarlo:

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

Un replace completo con force se salta las preguntas de seguridad, así que resérvelo para restaurar un snapshot que el propio dispositivo haya generado, y prefiera el merge o la aplicación sección a sección para todo lo demás.

Cisco NX-OS: checkpoints

NX-OS ofrece checkpoints con nombre y rollback atómico:

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

No hay un temporizador de confirmación integrado, así que en Nexus la disciplina pesa más: verifique el hostname antes del primer comando, aplique un comando cada vez, compruebe el resultado, y conserve el checkpoint junto con una copia de la configuración fuera del dispositivo hasta que el cambio esté probado.

Firewalls y Linux: construya usted el temporizador

Donde una plataforma no tiene mecanismo de confirmación, arme uno fuera del cambio. En un host Linux, systemd puede programar la reversión antes de que toque nada arriesgado:

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

El temporizador se dispara aunque su sesión muera, así que un error en una configuración de firewall o de SSH se corrige solo en cuatro minutos. En firewalls con API, la misma idea se convierte en un cutover con script: haga backup de la configuración en cada nodo, aplique el cambio, ejecute comprobaciones de accesibilidad, y restaure el backup automáticamente si fallan.

Snapshots y diffs: ¿se movió algo más?

Un cambio puede conseguir lo que pretendía y aun así alterar otra cosa. Antes y después de cada paso de un despliegue mayor, capture el estado que importa (resúmenes de sesiones de routing, estado de las interfaces, peers del overlay) y compárelos:

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

Si cambió algo que no debía, haga rollback mientras la causa todavía es evidente. Automatícelo y podrá exigirlo en cada dispositivo de un despliegue, con rollback automático cuando el diff no esté limpio.

Hábitos que hacen que las herramientas funcionen

• Una mitad de un par redundante cada vez. Cambie el standby, verifique, después el activo. Un error entonces cuesta redundancia durante unos minutos, no servicio.
• Verifique desde una sesión nueva. Una sesión SSH existente puede sobrevivir a un cambio que bloquea las nuevas. Abra una fresca antes de confirmar.
• Guarde al final. Escriba la running configuration en la startup solo después de verificar. Hasta entonces, un reinicio también es un rollback.

Pregunte a su propio equipo

• ¿Cuáles de sus plataformas admiten confirmed commits o revert timers, y se usan cada vez?
• ¿Existe una copia de la configuración de cada dispositivo fuera del dispositivo, anterior al último cambio?
• ¿Comparan los despliegues el estado del routing antes y después de cada paso?
• ¿Se cambia alguna vez algo en los dos miembros de un par redundante a la vez?

Nuestros cambios de red siguen esta disciplina en todas las plataformas, y si un cambio pudiera tocar su tráfico, acordamos antes con usted el momento. Si quiere ayuda para construir las mismas redes de seguridad en su propia operación, hable con nosotros.

cta: Hable con un ingeniero

Related

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