Rollback que não precisa de lembrar, confirmed commits na rede

Todos os engenheiros de rede conhecem a sensação: carrega-se em enter numa access list ou numa alteração de routing, e a sessão SSH deixa de responder. Agora a pergunta é se alguém consegue chegar a uma consola antes de os clientes repararem. A pergunta melhor é porque é que a alteração conseguiu sequer deixá-lo sem acesso. A maioria das plataformas de rede sérias consegue desfazer uma alteração sozinha se deixar de a confirmar. Este artigo percorre como, plataforma a plataforma, e os hábitos que o tornam fiável.

O princípio: uma alteração tem de merecer a sua permanência

Uma alteração só deve tornar-se permanente depois de ter provado, a partir de uma sessão que funciona, que o dispositivo continua acessível e a comportar-se bem. Se nunca chegar a confirmar, porque a alteração o deixou sem acesso, o dispositivo deve repor-se sozinho. Isso transforma o pior caso de uma má alteração de «conduzir até ao datacenter» em «esperar uns minutos».

Quatro blocos de construção fazem isto funcionar: uma cópia guardada da configuração anterior à alteração, um temporizador que reverte a menos que haja confirmação, uma forma de comparar o estado antes e depois, e a disciplina de guardar só depois de verificar.

Juniper: commit confirmed

O Junos tem o modelo mais limpo. As alterações são preparadas numa candidate configuration e aplicadas com um commit; um confirmed commit faz rollback sozinho a menos que volte a fazer commit:

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

Se a sessão morrer, o router volta à configuração anterior passados cinco minutos. show system commit e rollback <n> dão-lhe histórico e um regresso manual rápido.

Cisco IOS-XR: também commit confirmed

O IOS-XR segue a mesma ideia:

commit confirmed 300
# verify
commit

Use show configuration commit list para ver os commits recentes e rollback configuration last 1 para recuar um passo de forma deliberada.

Cisco IOS-XE: revert timers

O IOS-XE aplica os comandos em tempo real, pelo que a rede de segurança tem de ser armada primeiro. A funcionalidade archive fornece-a:

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

Se não confirmar dentro de cinco minutos, o dispositivo volta à configuração que tinha quando entrou em configuration mode. Para substituir uma configuração inteira a partir de um ficheiro, combine o replace com reversão automática em caso de erro em vez de o forçar:

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

Um replace completo com force salta as perguntas de segurança, por isso reserve-o para repor um snapshot que o próprio dispositivo produziu, e prefira o merge ou a aplicação secção a secção para tudo o resto.

Cisco NX-OS: checkpoints

O NX-OS oferece checkpoints com nome e 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

Não há um temporizador de confirmação integrado, pelo que nos Nexus a disciplina pesa mais: verifique o hostname antes do primeiro comando, aplique um comando de cada vez, confira o resultado, e guarde o checkpoint mais uma cópia da configuração fora do equipamento até a alteração estar provada.

Firewalls e Linux: construa o temporizador por si

Onde uma plataforma não tem mecanismo de confirmação, arme um fora da alteração. Num host Linux, o systemd pode agendar a anulação antes de tocar em algo arriscado:

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

O temporizador dispara mesmo que a sua sessão morra, pelo que um erro numa configuração de firewall ou de SSH corrige-se sozinho em quatro minutos. Para firewall appliances com API, a mesma ideia transforma-se num cutover por script: faça um backup da configuração em cada nó, aplique a alteração, corra verificações de acessibilidade, e reponha o backup automaticamente se falharem.

Snapshots e diffs: mexeu-se mais alguma coisa?

Uma alteração pode conseguir o que pretendia e ainda assim perturbar outra coisa. Antes e depois de cada passo de uma implementação maior, capture o estado que importa (resumos das sessões de routing, estado das interfaces, peers do overlay) e faça o diff:

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

Se mudou alguma coisa que não devia, faça rollback enquanto a causa ainda é óbvia. Automatize-o e pode impô-lo em todos os dispositivos de uma implementação, com rollback automático quando o diff não está limpo.

Hábitos que fazem as ferramentas funcionar

• Uma metade de um par redundante de cada vez. Altere o standby, verifique, depois o ativo. Um erro custa então redundância durante uns minutos, não serviço.
• Verifique a partir de uma sessão nova. Uma sessão SSH existente pode sobreviver a uma alteração que bloqueia as novas. Abra uma nova antes de confirmar.
• Guarde em último. Escreva a running configuration na startup só depois da verificação. Até lá, um reinício também é um rollback.

Pergunte à sua própria equipa

• Quais das suas plataformas suportam confirmed commits ou revert timers, e são usados todas as vezes?
• Existe uma cópia fora do equipamento da configuração de cada dispositivo, anterior à última alteração?
• As implementações comparam o estado do routing antes e depois de cada passo?
• Alguma vez se altera alguma coisa nos dois membros de um par redundante ao mesmo tempo?

As nossas alterações de rede seguem esta disciplina em todas as plataformas, e se uma alteração puder tocar no seu tráfego, acordamos primeiro o momento consigo. Se quer ajuda para construir as mesmas redes de segurança na sua própria operação, fale connosco.

cta: Fale com um engenheiro

Related

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