Inicio / Notas técnicas / Mantenimiento de actualización del firewall

Actualización del firewall sin tiempo de inactividad: disciplina de respaldo, actualización y reversión

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

Por qué los incidentes de actualización son en realidad incidentes de respaldo

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.

Qué respaldar antes de tocar el comando de actualización

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íaQué abarcaPor qué importa
Topología e inventario de equiposModelos de equipos, versiones de software y parches, diagrama de topologíaSin 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ónvrpcfg.cfg / current-configurationToda ruta de reversión asume que usted todavía tiene esto, en una forma que puede comparar.
Archivo de LicenseCargado de forma independiente en cada equipoUn 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 parchesLos paquetes .cc actualmente en ejecución, más cualquier parche cargadoTanto 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 firmasVersiones de la base de funciones IPS / AV / URLConfirma que nada retrocedió silenciosamente; no es obligatorio para una reversión básica.
Transferencia de archivos: use un método cifrado para todo lo que extraiga del equipo

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.

La secuencia de actualización de principio a fin

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.

1. Back UpConfig, License,software & patch files 2. Verify PackageSpace, version match,signature & checksum 3. IsolateStandby device: shutbusiness + heartbeat if 4. Upgrade & RebootLoad new software onthe isolated device 5. Verify Versiondisplay version beforetouching anything else 6. Switch Overhrp switch active /hrp switch standby 7. Isolate Old ActiveSame isolation asstep 3, other device 8. Upgrade & RebootSame load-and-rebootas step 4 9. Verify Bothversion, patch, License,hrp state on each device 10. Restore & ConfirmInterfaces up, hrpinterface running

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í.

Verifique el paquete antes de cargarlo

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.

  1. Si va a extraer el archivo por FTP/SFTP, confirme primero que el equipo puede siquiera alcanzar el servidor de archivos: haga Ping entre la PC y el equipo, e inicie sesión manualmente una vez en el servicio FTP o SFTP para confirmar que el usuario y la contraseña son realmente correctos en ese servidor.
  2. Verifique el espacio de almacenamiento libre del equipo con dir antes de suponer que una transferencia fallida fue un problema de red — un dispositivo flash lleno hace fallar una carga tan confiablemente como un enlace defectuoso.
  3. Verifique display version para confirmar que el paquete de software realmente coincide con el tipo de hardware de este equipo; un paquete creado para el tipo de equipo equivocado no cargará sin importar cuántas veces reintente la transferencia.
  4. Compare el tamaño del archivo cargado con el tamaño del mismo archivo en el servidor de origen — una discrepancia significa que la transferencia en sí estuvo incompleta.
  5. Ejecute check system-software sobre el archivo cargado. Un fallo en la verificación de firma no significa automáticamente que el archivo esté dañado — verifique con una suma de comprobación antes de concluir eso y volver a la fuente.
  6. Obtenga el valor SHA256 o MD5 del archivo en la PC de origen con certutil -hashfile, luego compárelo con el valor propio del equipo con check file-digest digest-algorithm sha256 (o md5) — si coinciden, la corrupción ocurrió antes de que el archivo llegara siquiera al equipo.
<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.

Cómo actualizar un par en espera activa sin perder tráfico

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.

  1. Antes de empezar, confirme que ambos equipos del par todavía califican para ser un par: modelo de producto, versión de software, versión de parche, paquete de funciones y versión de la base de firmas idénticos; tarjetas de interfaz idénticas en ranuras idénticas; interfaces de negocio y de latido idénticas; y — dado que un par en espera activa no comparte una License — cada equipo ya con su propia License vigente, con conjunto de funciones y vencimiento coincidentes.
  2. Elija qué equipo actualizar primero (comúnmente el de respaldo) y aíslelo por completo: apague sus interfaces de negocio y su interfaz de latido para que no intente renegociar su rol con su par a mitad de la transferencia.
  3. Cargue el nuevo software en el equipo aislado y reinícielo, luego confirme que realmente arrancó en la versión objetivo con display version antes de tocar cualquier otra cosa.
  4. Reactive sus interfaces solo después de confirmar la versión. Espere que se reincorpore como respaldo, no activo: un equipo reiniciado solo intenta tomar el rol activo 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.
  5. Provoque la conmutación a propósito en lugar de esperar una falla no planificada para mover el tráfico — hrp switch standby en el equipo que todavía ejecuta la versión antigua, o hrp switch active en el equipo que acaba de actualizar.
  6. Repita el ciclo aislar, actualizar, verificar en el equipo que originalmente era activo y ahora es de respaldo.
  7. Ejecute las tres pruebas de disparo antes de cerrar el cambio: apagar una interfaz de negocio, desconectar físicamente un cable, y un reinicio completo con corte de energía. Cada una debe mover el tráfico al otro equipo sin una interrupción que un usuario notaría.
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
Qué debería — y no debería — diferir entre los dos equipos

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.

Si algo sale mal: la ruta de reversión

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.

  1. reboot y startup system-software aparecen ambos en la lista de operaciones peligrosas por una razón — vea Comandos peligrosos de routers y switches. Revertir significa apuntar deliberadamente startup system-software de vuelta al archivo de software anterior, todavía presente en el equipo, y reiniciar dentro de una ventana aprobada — no como un reflejo en cuanto algo se ve mal.
  2. Si la falla parece un problema de configuración en lugar de un problema de versión de software, verifique exactamente qué cambió antes de restaurar cualquier cosa: display configuration commit changes en vista diagnose muestra los commits más recientes, y display configuration changes start-time / end-time aísla una ventana específica.
  3. No elimine el paquete de software anterior con delete /unreserved hasta que la nueva versión haya pasado la lista de comprobación de verificación siguiente — esa eliminación está documentada como irrecuperable en la misma referencia de operaciones peligrosas.
  4. En un par en espera activa, revierta un equipo a la vez usando la misma secuencia aislar, degradar, verificar, reincorporar que la propia actualización; no revierta ambas mitades a la vez.
[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

Lista de comprobación de verificación antes de cerrar el cambio

Seis comprobaciones, ejecutadas en ambos equipos de un par — la diferencia entre «la actualización terminó» y «la actualización realmente funcionó».

  1. display version — confirma que la versión de software y parche realmente coincide con el plan en ambos equipos.
  2. display patch-information — confirma que el parche esperado está cargado, no solo la imagen base.
  3. display license — confirma que la License está presente y activa, no en estado Demo o vencida en ninguno de los equipos.
  4. display hrp state — confirma que un equipo muestra Local role: Active, Peer role: Standby. Peer role: Unknown en ambos lados es una división de doble activo, no un par saludable.
  5. display hrp interface — confirma que la interfaz de latido muestra running, no down, invalid o negotiation failed.
  6. Interfaces de negocio físicamente Up con contadores de tráfico moviéndose en ambos equipos, y current-configuration comparada con el respaldo previo al cambio en busca de algo no intencional.

Cinco trampas del terreno

Misma actualización, mismos comandos — esto es lo que realmente atrapa a la gente.

1. La License no se comparte entre los dos equipos de un par en espera activa

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.

2. Un equipo recién reiniciado no retoma el rol activo de inmediato

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ó.

3. Aislar un equipo de forma incorrecta deja al par en doble activo

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.

4. Un fallo en la verificación de firma no siempre significa que el archivo esté dañado

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.

5. Eliminar el paquete de software antiguo elimina su ruta de reversión

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.

Diseños de soluciones relacionadas

Cinco preguntas que surgen constantemente

Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.

¿Ambos firewalls de un par en espera activa deben ejecutar siempre exactamente la misma versión?

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.

¿Qué pasa realmente con las sesiones activas durante el paso de conmutación?

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.

El paquete de actualización falló la verificación de firma — ¿el archivo está definitivamente dañado?

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.

¿Cuánto tiempo debo conservar el archivo de software antiguo después de una actualización exitosa?

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.

Mi equipo de respaldo recién reiniciado todavía muestra respaldo cuando esperaba que tomara el control — ¿falló la actualización?

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.

Límites honestos de esta nota

Límites honestos de esta nota

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.

¿Está planeando una actualización de firewall y quiere una segunda opinión sobre el plan?

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.

WhatsApp con un ingeniero →

Lectura relacionada

Solo usamos cookies para analítica anónima — sin publicidad ni rastreo entre sitios.Política de privacidad