Uma atualização de firewall raramente falha por causa do comando de atualização em si — ela falha porque algo não foi copiado, o pacote não foi verificado antes de ser carregado, ou um par em espera ativa foi atualizado na ordem errada. Esta é a lista de backup, os passos de verificação do pacote, a sequência isolar-atualizar-verificar-comutar para um par em espera ativa, o caminho de reversão, e a lista de verificação a executar antes de fechar a mudança.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Quase toda atualização que dá errado remonta a uma destas três lacunas — algo não foi copiado, o pacote não foi verificado antes de ser carregado, ou um par em espera ativa foi atualizado na ordem errada.
A maioria das atualizações de firewall é rotineira, até aquela que não é — e nessa hora já é tarde demais para voltar e fazer backup da configuração que acabou de ser sobrescrita. As diretrizes de manutenção da Huawei para a plataforma HiSecEngine USG6000F, USG6000G e USG12000 tratam o backup como pré-condição de qualquer operação de manutenção séria, não como um pensamento posterior: os dados críticos da rede são citados explicitamente — topologia e inventário de dispositivos, arquivo de configuração, arquivo de License, e arquivos do software do sistema e dos patches — para serem copiados antes de qualquer outra coisa acontecer.
A seguir está essa lista de backup, como verificar um pacote de atualização antes de carregá-lo, a sequência que mantém um par em espera ativa passando tráfego durante toda a atualização, o caminho de reversão caso a nova versão não funcione, e a lista de verificação a executar antes de considerar a mudança concluída.
A documentação de origem nomeia explicitamente esta lista como os dados críticos da rede — faça backup dela antes que qualquer outra coisa aconteça.
| Categoria | O que abrange | Por que importa |
|---|---|---|
| Topologia e inventário de dispositivos | Modelos de dispositivos, versões de software e patches, diagrama de topologia | Sem um instantâneo de o que estava conectado a o quê, uma atualização ruim passa de “reverter um dispositivo” para “reconstruir a rede de memória”. |
| Arquivo de configuração | vrpcfg.cfg / current-configuration | Todo caminho de reversão pressupõe que você ainda tem isso, em uma forma que pode comparar. |
| Arquivo de License | Carregado de forma independente em cada dispositivo | Um par em espera ativa não compartilha uma License — cada dispositivo precisa da sua própria, com o mesmo conjunto de recursos e vencimento. |
| Arquivos do software do sistema e dos patches | Os pacotes .cc atualmente em execução, mais qualquer patch carregado | Tanto a versão para a qual você está migrando quanto a versão da qual está saindo — excluir a antiga antes que a nova seja verificada remove seu caminho de reversão. |
| (Opcional) Logs e versões da base de assinaturas | Versões da base de recursos IPS / AV / URL | Confirma que nada regrediu silenciosamente; não é obrigatório para uma reversão básica. |
A documentação de origem compara Console, FTP, TFTP, SFTP e SCP como métodos de transferência de arquivos: TFTP e FTP simples enviam dados e credenciais de login em texto claro, enquanto SFTP e SCP criptografam e protegem a integridade da transferência. Para retirar um backup de configuração ou License de um dispositivo em produção, prefira SFTP ou SCP em vez de FTP ou TFTP.
Dez passos, nesta ordem — pule a etapa de isolamento e um par em espera ativa pode acabar dividido; pule a etapa de verificação e você estará levando adiante uma suposição não verificada.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Os passos 1 a 5 rodam em um dispositivo de um par em espera ativa, isolado de seu par; os passos 6 a 10 repetem o mesmo padrão isolar-atualizar-verificar no outro dispositivo, depois que o tráfego foi comutado de propósito. Em um firewall único, sem redundância, os passos 3, 6 e 7 simplesmente não se aplicam — mas 1, 2, 4, 5, 9 e 10 continuam se aplicando.
Uma atualização falha geralmente não é um arquivo ruim — é um arquivo não verificado; algumas verificações detectam a maior parte do que apareceria no meio da atualização.
<HUAWEI> dir
Directory of flash:/
Idx Attr Size(Byte) Date Time(LMT) FileName
10 -rw- 25,841,428 Nov 17 2015 09:48:10 basicsoft.cc
12 -rw- 26,101,692 Dec 21 2015 11:44:52 devicesoft.cc
1,927,220 KB total ( 1,130,464 KB free )
<HUAWEI> display version
Huawei YunShan OS
Version 1.23.0.X (XXX)
// software version must match this device's type — not interchangeable across device types
<HUAWEI> check system-software upgrade.cc
Caution! Confirm to check startup file! Continue? [Y/N]:y
Info: Prepare to check system software cfcard:/upgrade.cc, please wait, XX% completed.
// look for: System software signature check passed! / ...check failed!
C:\Users\xxxx> certutil -hashfile "C:\upgrade\upgrade.cc" SHA256
<HUAWEI> check file-digest digest-algorithm sha256 <hash-from-certutil> upgrade.cc
Info: Verification completed. The digest value of cfcard:/upgrade.cc is the same as the input digest value.A ordem importa mais que os comandos — isole completamente um dispositivo, atualize-o sozinho, verifique-o, depois comute o tráfego de propósito.
HRP_M[sysname] hrp switch standby
// forces this active device to yield; peer takes over as active
HRP_S[sysname] hrp switch active
// forces this standby device to take over as active
<sysname> system-view
[sysname] hrp track interface 10GE 1/0/1
// raises this device's HRP fault metric on a Down interface, for a controlled switchover test without touching live business interfacesCompare os arquivos de configuração dos dois dispositivos (uma ferramenta de diff funciona bem aqui). Tudo deveria coincidir exceto: o nome do dispositivo, o Router ID e os segmentos de rota que cada um anuncia, os endereços IP das interfaces, o estado de adesão da interface HRP, o atraso de preempção, e — apenas no modo de compartilhamento de carga — a faixa de portas NAT. Qualquer outra diferença vale a pena investigar antes de confiar no par.
Reverter não é um reflexo de pânico — é a mesma disciplina da atualização, executada ao contrário, dentro de uma janela de mudança.
[HUAWEI] diagnose
[HUAWEI-diagnose] display configuration commit changes
Building configuration
Commit changes of commitId 1000000002 2024-12-23 07:08:24 by root
#
- sysname 11
#
+ sysname HUAWEI
[HUAWEI-diagnose] display configuration changes start-time 2025/06/18,12:01:18Seis verificações, executadas nos dois dispositivos de um par — a diferença entre “a atualização terminou” e “a atualização realmente funcionou”.
Mesma atualização, mesmos comandos — eis o que realmente pega as pessoas.
RISCOEm um par em espera ativa, os dois dispositivos não compartilham uma License; recursos como IPS, AV ou filtragem de URL que dependem dela são licenciados e aplicados de forma independente em cada dispositivo, com conjunto de recursos, quantidade de recursos e vencimento correspondentes.
PRÁTICA MAIS SEGURAAo atualizar ou renovar, verifique display license nos dois dispositivos, não apenas naquele em que você entrou por acaso — uma License que venceu silenciosamente no de espera só se torna visível no momento em que ele assume como ativo.
RISCOUm dispositivo não retoma o papel ativo no instante em que termina de reiniciar. Ele só tenta assumir depois que a configuração da placa principal é restaurada, pelo menos uma CPU está online, e pelo menos uma placa de interface que carrega o batimento voltou — e somente após esperar mais um minuto.
PRÁTICA MAIS SEGURASe um dispositivo recém-atualizado ficar em espera por mais tempo do que o esperado, verifique se as três condições realmente foram atendidas — especificamente a placa de interface de batimento — antes de supor que a atualização falhou.
RISCODesligar as interfaces de negócio para isolar um dispositivo para atualização está correto; lidar mal com a interface de batimento, sua zona de segurança, ou a política que permite a passagem de seus pacotes de batimento deixa os dois dispositivos acreditando que estão ativos assim que o isolado reinicia.
PRÁTICA MAIS SEGURAdisplay hrp state mostrando Local role: Active, Peer role: Unknown nos dois dispositivos é a assinatura de um par dividido — verifique display hrp interface em busca de um estado de batimento down, invalid ou negotiation failed antes de declarar a atualização concluída.
RISCOcheck system-software reportando uma falha na verificação de assinatura é tratado por reflexo como “baixar o arquivo novamente”, o que desperdiça tempo se a falha real for uma transferência parcial ou interrompida em vez de um arquivo de origem genuinamente ruim.
PRÁTICA MAIS SEGURACompare um checksum — SHA256 ou MD5, obtido com certutil -hashfile no PC de origem e check file-digest no dispositivo — antes de concluir que o arquivo de origem em si está ruim e buscar uma cópia nova.
RISCOdelete /unreserved é documentado como irrecuperável — usá-lo no pacote de software anterior assim que o espaço flash fica escasso remove silenciosamente a única coisa da qual uma reversão depende.
PRÁTICA MAIS SEGURALibere espaço primeiro com uma limpeza rotineira de arquivos realmente não utilizados, e mantenha pelo menos um pacote de software anterior conhecido como bom até que a nova versão tenha passado na lista de verificação completa.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Apenas brevemente, durante a própria janela de atualização, eles ficam intencionalmente desalinhados. O requisito mínimo para o par funcionar corretamente é que modelo de produto, versão de software, versão de patch, pacote de recursos e versão da base de assinaturas coincidam todos — então planeje concluir os dois lados na mesma janela de manutenção em vez de deixar a atualização pela metade.
hrp switch é um acionamento deliberado e controlado, não uma falha não planejada. A mesma verificação exigida pela documentação de origem — desligar uma interface de negócio, desconectar um cabo, e um reinício completo — sempre precisa mover o tráfego para o outro dispositivo sem uma interrupção que um usuário notaria; teste esse acionamento antes da mudança real com hrp track interface em uma interface já down em vez de supor que simplesmente funcionará no dia.
Não necessariamente. Uma falha na verificação de assinatura também pode significar que a própria transferência ficou incompleta ou foi interrompida. Compare um hash SHA256 ou MD5 entre o arquivo de origem e o arquivo enviado antes de concluir que a origem está ruim e buscar uma cópia nova.
A documentação de origem não dá um número fixo de dias; a resposta prática é: até que a lista de verificação acima tenha passado nos dois dispositivos e o par tenha passado por pelo menos um teste de comutação planejado na nova versão. Reserve — não faça /unreserved — exclua antes disso.
Não necessariamente — veja a segunda armadilha acima. Verifique se a configuração da placa principal terminou de restaurar, se pelo menos uma CPU está online, e se a placa de interface que carrega o batimento voltou, e aguarde o minuto adicional antes de tratar como uma falha.
Esta nota se baseia no material de casos do manual de manutenção HiSecEngine USG6000F, USG6000G e USG12000 V600 sobre disciplina de backup, verificação de pacotes de atualização e melhores práticas de espera ativa, cruzado com o manual USG6000E/USG9500 da mesma família de plataforma, onde o mecanismo HRP subjacente e o comportamento de licenciamento por dispositivo são compartilhados. A sincronização específica de preempção na reinicialização e as regras de licenciamento descritas são próprias desta plataforma; uma implementação de alta disponibilidade de outro fabricante usará comandos e contadores diferentes, embora a ordem backup-verificação-isolamento-comutação se transponha conceitualmente. Não cobre em profundidade a substituição de placas em nível de chassi durante uma atualização, nem o rateio de License multi-vsys.
Conte-nos o modelo do dispositivo, a versão de software atual e desejada, e se é um par em espera ativa — ajudamos você a revisar o plano antes de tocar no comando de atualização.