Una actualización de firewall rara vez falla por el comando de actualización en sí — falla porque algo no se respaldó, el paquete no se verificó antes de cargarlo, o un par en espera activa se actualizó en el orden equivocado. Esta es la lista de respaldo, los pasos de verificación del paquete, la secuencia aislar-actualizar-verificar-conmutar para un par en espera activa, la ruta de reversión, y la lista de comprobación a ejecutar antes de cerrar el cambio.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Casi todas las actualizaciones que fallan se remontan a una de estas tres brechas — algo no se respaldó, el paquete no se verificó antes de cargarlo, o un par en espera activa se actualizó en el orden equivocado.
La mayoría de las actualizaciones de firewall son rutinarias, hasta la que no lo es — y para entonces ya es tarde para volver atrás y respaldar la configuración que se acaba de sobrescribir. Las directrices de mantenimiento de Huawei para la plataforma HiSecEngine USG6000F, USG6000G y USG12000 tratan el respaldo como una condición previa para cualquier operación de mantenimiento seria, no como una idea de último momento: los datos críticos de la red se nombran explícitamente — topología e inventario de equipos, archivo de configuración, archivo de License, y archivos del software del sistema y de parches — para respaldarlos antes de que ocurra cualquier otra cosa.
A continuación, esa lista de respaldo, cómo verificar un paquete de actualización antes de cargarlo, la secuencia que mantiene a un par en espera activa cursando tráfico durante toda la actualización, la ruta de reversión si la nueva versión no funciona, y la lista de comprobación a ejecutar antes de considerar completo el cambio.
La documentación fuente designa explícitamente esta lista como los datos críticos de la red — respáldela antes de que ocurra cualquier otra cosa.
| Categoría | Qué abarca | Por qué importa |
|---|---|---|
| Topología e inventario de equipos | Modelos de equipos, versiones de software y parches, diagrama de topología | Sin una instantánea de qué estaba conectado a qué, una mala actualización pasa de «revertir un equipo» a «reconstruir la red de memoria». |
| Archivo de configuración | vrpcfg.cfg / current-configuration | Toda ruta de reversión asume que usted todavía tiene esto, en una forma que puede comparar. |
| Archivo de License | Cargado de forma independiente en cada equipo | Un par en espera activa no comparte una License — cada equipo necesita la suya propia, con el mismo conjunto de funciones y vencimiento. |
| Archivos del software del sistema y de parches | Los paquetes .cc actualmente en ejecución, más cualquier parche cargado | Tanto la versión a la que se está moviendo como la versión desde la que se mueve — eliminar la antigua antes de verificar la nueva elimina su ruta de reversión. |
| (Opcional) Registros y versiones de la base de firmas | Versiones de la base de funciones IPS / AV / URL | Confirma que nada retrocedió silenciosamente; no es obligatorio para una reversión básica. |
La documentación fuente compara Console, FTP, TFTP, SFTP y SCP como métodos de transferencia de archivos: TFTP y el FTP simple envían datos y credenciales de inicio de sesión en texto claro, mientras que SFTP y SCP cifran y protegen la integridad de la transferencia. Para extraer un respaldo de configuración o License de un equipo en producción, prefiera SFTP o SCP antes que FTP o TFTP.
Diez pasos, en este orden — omita el paso de aislamiento y un par en espera activa puede terminar dividido; omita el paso de verificación y estará llevando adelante un supuesto sin verificar.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Los pasos 1 a 5 se ejecutan en un equipo de un par en espera activa, aislado de su par; los pasos 6 a 10 repiten el mismo patrón aislar-actualizar-verificar en el otro equipo, después de que el tráfico se ha conmutado deliberadamente. En un firewall único, sin redundancia, los pasos 3, 6 y 7 simplemente no aplican — pero 1, 2, 4, 5, 9 y 10 sí.
Una actualización fallida a menudo no es un archivo defectuoso — es uno sin verificar; un puñado de comprobaciones detecta la mayoría de lo que de otro modo surgiría a mitad de la actualización.
<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.
El orden importa más que los comandos — aísle completamente un equipo, actualícelo solo, verifíquelo, y luego conmute el tráfico deliberadamente.
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 interfaces
Compare los archivos de configuración de ambos equipos (una herramienta de comparación funciona bien aquí). Todo debería coincidir excepto: el nombre del equipo, el Router ID y los segmentos de ruta que cada uno anuncia, las direcciones IP de las interfaces, el estado de adhesión de la interfaz HRP, el retraso de preferencia, y — solo en modo de reparto de carga — el rango de puertos NAT. Cualquier otra diferencia vale la pena investigarla antes de confiar en el par.
Revertir no es un reflejo de pánico — es la misma disciplina que la actualización, ejecutada al revés, dentro de una ventana de cambio.
[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:18
Seis comprobaciones, ejecutadas en ambos equipos de un par — la diferencia entre «la actualización terminó» y «la actualización realmente funcionó».
Misma actualización, mismos comandos — esto es lo que realmente atrapa a la gente.
RIESGOEn un par en espera activa, los dos equipos no comparten una License; funciones como IPS, AV o filtrado de URL que dependen de ella se licencian y aplican de forma independiente en cada equipo, con conjunto de funciones, cantidad de recursos y vencimiento coincidentes.
PRÁCTICA MÁS SEGURAAl actualizar o renovar, verifique display license en ambos equipos, no solo en el que le tocó iniciar sesión — una License que venció silenciosamente en el de respaldo solo se hace visible en el momento en que asume el rol activo.
RIESGOUn equipo no retoma el rol activo en el instante en que termina de reiniciarse. Solo intenta tomar el control una vez que la configuración de su tarjeta principal está restaurada, al menos una CPU está en línea, y al menos una tarjeta de interfaz que lleva el latido ha vuelto — y solo después de esperar un minuto adicional.
PRÁCTICA MÁS SEGURASi un equipo recién actualizado permanece en respaldo más tiempo del esperado, verifique si realmente se cumplen las tres condiciones — específicamente la tarjeta de interfaz de latido — antes de suponer que la actualización falló.
RIESGOApagar las interfaces de negocio para aislar un equipo con fines de actualización es correcto; manejar mal la interfaz de latido, su zona de seguridad, o la política que permite el paso de sus paquetes de latido deja a ambos equipos creyendo que son activos una vez que el aislado se reinicia.
PRÁCTICA MÁS SEGURAdisplay hrp state mostrando Local role: Active, Peer role: Unknown en ambos equipos es la firma de un par dividido — verifique display hrp interface en busca de un estado de latido down, invalid o negotiation failed antes de declarar terminada la actualización.
RIESGOcheck system-software reportando un fallo en la verificación de firma se trata por reflejo como «volver a descargar el archivo», lo que desperdicia tiempo si la falla real es una transferencia parcial o interrumpida en lugar de un archivo fuente genuinamente dañado.
PRÁCTICA MÁS SEGURACompare una suma de comprobación — SHA256 o MD5, obtenida con certutil -hashfile en la PC de origen y check file-digest en el equipo — antes de concluir que el archivo fuente en sí está dañado y volver por una copia nueva.
RIESGOdelete /unreserved está documentado como irrecuperable — usarlo en el paquete de software anterior en cuanto el espacio flash escasea elimina silenciosamente lo único de lo que depende una reversión.
PRÁCTICA MÁS SEGURALibere espacio primero con una limpieza rutinaria de archivos realmente sin uso, y conserve al menos un paquete de software anterior conocido como bueno hasta que la nueva versión haya pasado la lista de comprobación completa.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
Solo brevemente, durante la propia ventana de actualización, están intencionalmente desalineados. El requisito mínimo para que el par funcione correctamente es que el modelo de producto, la versión de software, la versión de parche, el paquete de funciones y la versión de la base de firmas coincidan todos — así que planee completar ambos lados en la misma ventana de mantenimiento en lugar de dejar la actualización a medias.
hrp switch es un disparador deliberado y controlado en lugar de una falla no planificada. La misma verificación que exige la documentación fuente — apagar una interfaz de negocio, desconectar un cable, y un reinicio completo — debe siempre mover el tráfico al otro equipo sin una interrupción que un usuario notaría; pruebe ese disparador antes del cambio real con hrp track interface en una interfaz ya caída en lugar de suponer que simplemente funcionará el día del cambio.
No necesariamente. Un fallo en la verificación de firma también puede significar que la transferencia en sí estuvo incompleta o interrumpida. Compare un hash SHA256 o MD5 entre el archivo fuente y el archivo cargado antes de concluir que la fuente está dañada y volver por una copia nueva.
La documentación fuente no da un número fijo de días; la respuesta práctica es: hasta que la lista de comprobación de verificación anterior haya pasado en ambos equipos y el par haya pasado por al menos una prueba de conmutación planificada en la nueva versión. Conserve — no haga /unreserved — elimínelo antes de eso.
No necesariamente — vea la segunda trampa arriba. Verifique si la configuración de la tarjeta principal terminó de restaurarse, si al menos una CPU está en línea, y si la tarjeta de interfaz que lleva el latido ha vuelto, y espere el minuto adicional antes de tratarlo como una falla.
Esta nota se basa en el material de casos del manual de mantenimiento HiSecEngine USG6000F, USG6000G y USG12000 V600 sobre disciplina de respaldo, verificación de paquetes de actualización y mejores prácticas de espera activa, contrastado con el manual USG6000E/USG9500 de la misma familia de plataforma, donde el mecanismo HRP subyacente y el comportamiento de licencia por equipo son compartidos. La sincronización específica de preferencia al reiniciar y las reglas de licencia descritas son propias de esta plataforma; una implementación de alta disponibilidad de otro fabricante usará comandos y contadores diferentes, aunque el orden respaldo-verificación-aislamiento-conmutación se traslada conceptualmente. No cubre en profundidad el reemplazo de tarjetas a nivel de chasis durante una actualización, ni el reparto de License multi-vsys.
Cuéntenos el modelo del equipo, la versión de software actual y objetivo, y si es un par en espera activa — le ayudaremos a revisar el plan antes de tocar el comando de actualización.