Commit confirmed e rollback no Junos: mudar sem perder acesso

Toda mudança em roteador remoto tem um risco que não aparece no laboratório: o comando que corta o próprio acesso. Um filtro na loopback sem a regra de SSH, uma rota de gerência apontando para o lugar errado, uma política que derruba a sessão BGP por onde você chega. No Junos, a resposta para isso é o commit confirmed: a mudança entra na hora, mas com prazo. Se você não confirmar, o roteador volta sozinho para a versão anterior.

Este guia mostra como usar o commit confirmed numa janela de manutenção, como conferir o histórico de commits, como comparar versões e como voltar para uma configuração anterior com rollback. No fim, comparo com o que existe no Huawei VRP8 e no Cisco IOS XE. Os exemplos foram montados num roteador de laboratório chamado r1, com endereços de documentação. Se você ainda não domina candidate, set e show | compare, comece pelos comandos Junos básicos.

Resposta rápida: commit confirmed em quatro passos

1. Faça a mudança na candidate e confira com show | compare.
2. Valide com commit check. Nada muda no roteador nesse passo.
3. Aplique com commit confirmed 5. A mudança entra em produção e um relógio de 5 minutos começa a contar. Sem número, o prazo padrão é de 10 minutos; o máximo é 65.535.
4. Teste o acesso e o serviço de outra sessão. Se tudo estiver bem, rode commit (ou commit check) dentro do prazo para confirmar. Se você perdeu o acesso, espere: o Junos desfaz a mudança e avisa todos os usuários conectados.

Por que o Junos consegue desfazer uma mudança

Para o commit confirmed, o que importa é um detalhe do modelo de candidate e configuração ativa do Junos (o básico está nos comandos Junos básicos): cada commit guarda a versão que estava valendo antes. Pela documentação da Juniper, a atual e as três versões mais recentes ficam em /config, e as mais antigas, até a 49, em /var/db/config.

Quando o prazo de um commit confirmed vence, o roteador usa essa versão guardada para voltar sozinho. O rollback manual, que aparece mais adiante, usa a mesma pilha, só que por decisão sua.

Candidate compartilhada e configure private

Em janela com mais de uma pessoa no equipamento, entre com configure private, para o seu commit não levar mudanças pela metade de outro técnico. A diferença entre a candidate compartilhada e a privada está explicada nos comandos Junos básicos. A documentação da Juniper confirma que o commit confirmed também funciona no modo privado.

Cenário de laboratório: um filtro na lo0

O exemplo clássico de mudança que derruba o próprio acesso é o filtro de entrada na interface lo0, que protege o plano de controle do roteador. Ele vale para todo tráfego destinado ao equipamento: SSH, BGP, ICMP, SNMP, NTP. Esqueceu um termo e o roteador passa a descartar aquele protocolo.

user@r1# edit firewall family inet filter PROTEGE-RE
[edit firewall family inet filter PROTEGE-RE]
user@r1# set term SSH from source-address 203.0.113.0/24
user@r1# set term SSH from protocol tcp
user@r1# set term SSH from destination-port ssh
user@r1# set term SSH then accept
user@r1# set term BGP from protocol tcp
user@r1# set term BGP from port bgp
user@r1# set term BGP then accept
user@r1# set term ICMP from protocol icmp
user@r1# set term ICMP then accept
user@r1# set term RESTO then discard
user@r1# top
[edit]
user@r1# set interfaces lo0 unit 0 family inet filter input PROTEGE-RE

Linha a linha, o porquê de cada parte:

• edit firewall family inet filter PROTEGE-RE entra na hierarquia do filtro para os set seguintes ficarem curtos.
• O termo SSH aceita TCP na porta 22 apenas da rede de gerência 203.0.113.0/24. É ele que mantém a sua sessão viva.
• O termo BGP aceita TCP 179 em qualquer sentido (from port bgp casa origem ou destino). Sem ele, as sessões BGP caem quando o hold time vence.
• O termo ICMP deixa o ping funcionar, o que ajuda no diagnóstico.
• O termo RESTO descarta todo o resto. A ordem importa: o Junos avalia os termos de cima para baixo e para no primeiro que casa.
• set interfaces lo0 unit 0 family inet filter input aplica o filtro. Até aqui é só candidate.

Commit confirmed passo a passo

1. Compare e valide antes de aplicar

user@r1# show | compare
user@r1# commit check
configuration check succeeds

O show | compare mostra só o que muda em relação à ativa, com + e -. Leia com calma: é a última chance de ver um termo fora de ordem. O commit check roda a mesma validação do commit (sintaxe, referências, coerência) sem ativar nada. Se ele reclamar, corrija antes de pensar em prazo.

2. Aplique com prazo

user@r1# commit confirmed 5
commit complete

O Junos aplica a candidate e avisa com a mensagem commit confirmed will be automatically rolled back in 5 minutes unless confirmed. A partir daí, a mudança está valendo para o tráfego. O número é o prazo em minutos, de 1 a 65.535. Sem número, vale o padrão de 10 minutos.

3. Teste por outro caminho

user@r1> show bgp summary
user@r1> ping 192.0.2.2 count 5
user@r1> show firewall filter PROTEGE-RE

Não teste só pela sessão que já está aberta. Ela prova que o caminho que você usa agora funciona, não que um login novo passa pelo filtro, nem que o acesso de contingência ou o sistema de monitoramento continuam chegando. Abra uma sessão nova a partir da rede de gerência, confira o show bgp summary (as sessões continuam Established?), faça um ping para o vizinho e veja os contadores do filtro.

4. Confirme dentro do prazo

user@r1# commit
commit complete

Um commit simples, ou um commit check, dentro do prazo torna a mudança permanente. Se o prazo vencer sem confirmação, o Junos volta à configuração anterior ao commit confirmed e manda uma mensagem de broadcast para todos os usuários logados. Quem perdeu o acesso só precisa esperar o prazo acabar e entrar de novo.

Quanto tempo escolher

O prazo precisa cobrir o teste, não a mudança inteira. Para um filtro ou uma rota, 5 minutos costumam bastar. Para uma política de BGP que depende de o vizinho reanunciar rotas, dê mais folga, algo entre 10 e 15 minutos. Isso vale, por exemplo, para mudanças de policy-statement de BGP no Juniper, em que o efeito aparece só depois que as rotas são reavaliadas. Prazo longo demais tem o custo oposto: se algo quebrou, a rede fica quebrada até o relógio zerar.

Comentário e histórico de commits

Daqui a três meses ninguém lembra por que o filtro mudou. O commit comment grava um texto de até 512 caracteres junto com o commit, e o show system commit lista o histórico com data, usuário, origem e comentário.

user@r1# commit comment "CHG-0142 filtro lo0"
commit complete
user@r1> show system commit

Uma saída resumida de exemplo:

0   2026-10-20 07:42:10 by user via cli
    CHG-0142 filtro lo0
1   2026-10-20 07:38:55 by user via cli commit confirmed, rollback in 5mins
2   2026-10-19 22:10:03 by user via cli

A linha 1 mostra o commit confirmed com o prazo que estava valendo, e a linha 0 é a confirmação, feita com commit comment e o número da mudança. Usar o número do chamado ou da GMUD no comentário facilita cruzar o histórico do roteador com o registro da operação. Desde o Junos 24.2R1 dá para exigir comentário em todo commit pela hierarquia [edit system commit].

Outra opção útil em janela de madrugada é o commit at, que agenda a ativação para um horário (formato hh:mm ou data e hora completas). A validação acontece na hora em que você digita; a ativação, no horário marcado.

Rollback: voltando para uma versão anterior

O commit confirmed cuida do caso em que a mudança quebra na hora. Quando o problema aparece depois da confirmação (um cliente reclama uma hora mais tarde, por exemplo), o caminho é o rollback manual. Primeiro, descubra o que mudou entre as versões.

user@r1> show system rollback 1 compare 0
user@r1> show system rollback 3 compare 1
user@r1> configure
user@r1# show | compare rollback 1

O show system rollback 1 compare 0 mostra a diferença entre a versão anterior e a ativa sem entrar em modo de configuração. O segundo exemplo compara duas versões antigas entre si. Dentro do modo de configuração, o show | compare rollback 1 faz a mesma conta usando a candidate como referência.

user@r1# rollback 1
load complete
user@r1# show | compare
user@r1# commit comment "volta filtro lo0"
commit complete

Lembre que rollback 1 apenas prepara a volta: a versão 1 vai para a candidate, a CLI responde load complete e o tráfego continua passando pela configuração ativa. Revise com show | compare e só então faça o commit. Se a volta também mexe em filtro ou rota de gerência, use commit confirmed nela também.

Rescue configuration: o ponto de retorno conhecido

A pilha de rollback anda a cada commit. Depois de 49 commits, a versão boa de seis meses atrás some. A rescue configuration resolve isso: é uma cópia que você grava de propósito, num ponto em que sabe que o roteador está bom, e que fica numa área protegida do sistema de arquivos.

user@r1> request system configuration rescue save
user@r1> configure
user@r1# rollback rescue
load complete
user@r1# commit
commit complete

Grave a rescue depois de cada janela que terminou bem. Se um dia precisar dela, o rollback rescue carrega a cópia na candidate e o commit aplica. Se a rescue não existir ou estiver incompleta, o Junos recusa o rollback e mantém a configuração atual.

Equivalentes no Huawei VRP8 e no Cisco IOS XE

A ideia de aplicar com prazo existe em outros fabricantes, com nomes e unidades diferentes. Vale conhecer para não errar a conta na hora da janela.

Huawei VRP8: commit trial

Nos equipamentos com VRP8 em modo de duas etapas (NE8000, NE40E, CloudEngine), a configuração também passa por uma candidate. O prompt mostra [*PE1] quando há mudança pendente e [~PE1] quando tudo foi aplicado. Quem já usa a lista de comandos para roteadores e switches Huawei vai reconhecer o fluxo.

<PE1> system-view
[~PE1] interface GigabitEthernet0/1/0
[~PE1-GigabitEthernet0/1/0] description uplink-lab
[*PE1-GigabitEthernet0/1/0] quit
[*PE1] display configuration candidate changes
[*PE1] commit trial 300
[~PE1] display configuration trial status
[~PE1] display configuration commit list verbose

O commit trial 300 aplica em modo de teste por 300 segundos. Repare na unidade: no VRP o tempo é em segundos (60 a 65.535, padrão 600), enquanto no Junos é em minutos. Antes de o prazo acabar, você confirma com commit ou desfaz com abort trial. O display configuration trial status mostra se há teste em andamento, e o display configuration commit list verbose lista os pontos de retorno com usuário e horário. A sintaxe exata varia entre linhas de produto, então confira na Command Reference da sua versão.

Cisco IOS XE: configure replace com prazo

No IOS XE, a configuração entra na hora em que você digita, então não existe candidate. O recurso mais próximo é o configure replace com tempo de confirmação, que troca a running por um arquivo completo. Se você vem dos comandos básicos do Cisco IOS, o arquivamento é o primeiro passo.

Router# configure terminal
Router(config)# archive
Router(config-archive)# path flash:cfg-lab
Router(config-archive)# maximum 10
Router(config-archive)# end
Router# archive config
Router# show archive
Router# configure replace flash:cfg-nova list time 10
Router# configure confirm

O bloco archive define onde guardar as cópias e quantas manter. O archive config grava a running atual, que será o ponto de volta. O configure replace flash:cfg-nova list time 10 substitui a running pelo arquivo preparado, lista os comandos aplicados e dá 10 minutos para o configure confirm. Sem confirmação, a running volta ao estado anterior. O configure revert now antecipa essa volta.

Roteiro para a janela de manutenção

1. Antes de começar, grave a rescue com request system configuration rescue save se a configuração atual estiver boa.
2. Entre com configure private se houver mais alguém no equipamento.
3. Faça a mudança, leia o show | compare inteiro e rode commit check.
4. Aplique com commit confirmed e um prazo que cubra o teste.
5. Abra uma sessão nova pela gerência e teste o serviço afetado (BGP, rota, filtro).
6. Confirme com commit comment "número da mudança", que encerra o prazo e já registra o motivo, ou deixe o prazo vencer se algo quebrou.
7. Depois da janela, confira o show system commit e grave a rescue de novo.

Erros comuns com commit confirmed e rollback

• Esquecer de confirmar. A mudança estava certa, o técnico saiu para tomar café e o roteador desfez tudo. Ponha um alarme no celular com o mesmo prazo do commit confirmed.
• Testar pela sessão antiga. A sessão aberta pode sobreviver a um filtro errado. Teste sempre com uma conexão nova.
• Achar que rollback aplica. rollback 1 só carrega na candidate. Sem commit, nada muda.
• Confundir minutos com segundos. commit confirmed 300 no Junos são cinco horas. commit trial 5 no VRP nem é aceito, porque o mínimo é 60 segundos.
• Commitar a candidate compartilhada com mudanças de outra pessoa. Leia o show | compare inteiro ou use configure private.
• Confiar só na pilha de 49 versões. Em roteador com muitos commits automáticos, a versão boa sai da pilha rápido. Mantenha a rescue atualizada.

Perguntas frequentes

O que acontece se eu não confirmar o commit confirmed?

Quando o prazo vence, o Junos volta para a configuração que estava ativa antes do commit confirmed e envia uma mensagem de broadcast para todos os usuários conectados. Você só precisa esperar e acessar o roteador de novo.

Qual é o prazo padrão do commit confirmed?

Dez minutos. Você pode informar de 1 a 65.535 minutos logo depois da palavra confirmed, como em commit confirmed 5.

Como confirmar um commit confirmed?

Rode commit ou commit check antes de o prazo acabar. Qualquer um dos dois encerra a contagem e mantém a mudança.

O rollback 1 muda a configuração do roteador na hora?

Não. Ele carrega a versão anterior na candidate. Confira com show | compare e aplique com commit.

Qual a diferença entre rollback e rescue configuration?

O rollback usa a pilha automática de até 49 versões, que anda a cada commit. A rescue é uma cópia que você grava de propósito com request system configuration rescue save e que não sai da pilha. Para voltar a ela, use rollback rescue e commit.

Existe commit confirmed no Huawei e no Cisco?

No Huawei VRP8 em modo de duas etapas existe o commit trial, com tempo em segundos. No Cisco IOS XE, o mais próximo é o configure replace com a opção time, confirmado por configure confirm.

Conclusão

O commit confirmed é o hábito que mais evita viagem até o POP. Ele não substitui o show | compare nem o commit check, mas cobre o erro que passou pelos dois. Some a isso o comentário em cada commit, a comparação entre versões e uma rescue gravada depois de cada janela boa, e mudar um roteador remoto deixa de ser aposta.

Se você trabalha com mais de um fabricante, lembre da unidade de tempo de cada um e do jeito de confirmar. O próximo passo natural é aplicar o mesmo cuidado às mudanças de política de BGP, onde um erro pode afetar todo o tráfego do provedor.