A firewall upgrade rarely fails because of the upgrade command itself — it fails because something wasn't backed up, the package wasn't verified before it was loaded, or a hot-standby pair got upgraded in the wrong order. This is the backup checklist, the package verification steps, the isolate-upgrade-verify-switchover sequence for a hot-standby pair, the rollback path, and the checklist to run before you close the change.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Almost every upgrade that goes wrong traces back to one of three gaps — something wasn't backed up, the package wasn't verified before it was loaded, or a hot-standby pair got upgraded in the wrong order.
Most firewall upgrades are routine, right up until the one that isn't — and by then it is too late to go back and back up the configuration you just overwrote. Huawei's own maintenance guidance for the HiSecEngine USG6000F, USG6000G and USG12000 platform treats backup as a precondition of any serious maintenance operation, not an afterthought: the network's critical data is named explicitly — topology and device inventory, the configuration file, the License file, and the system software and patch files — to be backed up before anything else happens.
What follows is that backup checklist, how to verify an upgrade package before you load it, the sequence that keeps a hot-standby pair passing traffic through the whole upgrade, the rollback path if the new version does not work out, and the checklist to run before you consider the change complete.
The source documentation names this list explicitly as the network's critical data — back it up before anything else happens.
| Category | What It Covers | Why It Matters |
|---|---|---|
| Topology & device inventory | Device models, software and patch versions, topology diagram | Without a snapshot of what used to be connected to what, a bad upgrade turns from “roll back one device” into “reconstruct the network from memory.” |
| Configuration file | vrpcfg.cfg / current-configuration | Every rollback path assumes you still have this, in a form you can diff against. |
| License file | Loaded independently per device | A hot-standby pair does not share a License — each device needs its own, matching feature set and expiry. |
| System software & patch files | The .cc packages currently running, plus any loaded patch | Both the version you're moving to and the version you're moving from — deleting the old one before the new one is verified removes your rollback path. |
| (Optional) Logs & signature-database versions | IPS / AV / URL feature-database versions | Confirms nothing silently regressed; not required for a bare rollback. |
The source documentation compares Console, FTP, TFTP, SFTP and SCP as file-transfer methods: TFTP and plain FTP send data and login credentials in clear text, while SFTP and SCP encrypt and integrity-protect the transfer. For pulling a configuration or License backup off a live device, prefer SFTP or SCP over FTP or TFTP.
Ten steps, in this order — skip the isolation step and a hot-standby pair can end up split; skip the verification step and you carry an unverified assumption forward.
Diagram labels are kept in English for engineering clarity.
Steps 1 through 5 run on one device of a hot-standby pair, in isolation from its peer; steps 6 through 10 repeat the same isolate-upgrade-verify pattern on the other device, after traffic has been switched across on purpose. On a single, non-redundant firewall, steps 3, 6 and 7 simply don't apply — but 1, 2, 4, 5, 9 and 10 still do.
A failed upgrade is often not a bad file — it's an unverified one; a handful of checks catch most of what would otherwise surface mid-upgrade.
<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.The order matters more than the commands — isolate one device completely, upgrade it alone, verify it, then switch traffic across on purpose.
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 the two devices' configuration files (a diff tool works well here). Everything should match except: device name, Router ID and the route segments each advertises, interface IP addresses, HRP interface joined state, preemption delay, and — in load-sharing mode only — NAT port range. Anything else that differs is worth investigating before you trust the pair.
Rolling back is not a panic reflex — it's the same discipline as the upgrade, run in reverse, inside a change window.
[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:18Six checks, run on both devices of a pair — the difference between “the upgrade finished” and “the upgrade actually worked.”
Same upgrade, same commands — here's what actually catches people out.
RISKOn a hot-standby pair the two devices do not share a License; features like IPS, AV or URL filtering that depend on one are licensed and applied independently on each device, matching in feature set, resource count and expiry.
SAFER PRACTICEWhen you upgrade or renew, check display license on both devices, not just the one you happened to log in to — a License that expired quietly on the standby only becomes visible the moment it takes over as active.
RISKA device doesn't retake the active role the instant it finishes rebooting. It only attempts to preempt once its main-board configuration is restored, at least one CPU is online, and at least one heartbeat-carrying interface board has come back — and only after a further one-minute wait.
SAFER PRACTICEIf a just-upgraded device is sitting in standby longer than expected, check whether all three conditions are actually met — and check the heartbeat interface board specifically — before assuming the upgrade failed.
RISKShutting down business interfaces to isolate a device for upgrade is correct; mishandling the heartbeat interface, its security zone, or the policy that lets its heartbeat packets through leaves both devices believing they're active once the isolated one reboots.
SAFER PRACTICEdisplay hrp state showing Local role: Active, Peer role: Unknown on both devices is the signature of a split pair — check display hrp interface for a down, invalid or negotiation failed heartbeat state before declaring the upgrade finished.
RISKcheck system-software reporting a failed signature check gets treated as “re-download the file” by reflex, which wastes time if the actual fault is a partial or interrupted transfer rather than a genuinely bad source file.
SAFER PRACTICECompare a checksum — SHA256 or MD5, taken with certutil -hashfile on the source PC and check file-digest on the device — before you conclude the source file itself is bad and go back for a fresh copy.
RISKdelete /unreserved is documented as unrecoverable — using it on the previous software package the moment flash space runs low quietly removes the one thing a rollback depends on.
SAFER PRACTICEFree space with routine cleanup of genuinely unused files first, and keep at least one known-good previous software package until the new version has passed the full verification checklist.
Pulled straight from the field — the ones worth having an answer ready for.
Only briefly, during the upgrade window itself, are they intentionally mismatched. The minimum requirement for the pair to function correctly is that product model, software version, patch version, feature package and signature-library version all match — so plan to complete both sides in the same maintenance window rather than leaving the upgrade half-done.
hrp switch is a deliberate, controlled trigger rather than an unplanned failure. The same verification the source documentation calls for — shutting down a business interface, unplugging a cable, and a full reboot — all have to move traffic to the other device without an interruption a user would notice; test that trigger before the real change with hrp track interface on an already-down interface rather than assuming it will simply work on the day.
Not necessarily. A signature-check failure can also mean the transfer itself was incomplete or interrupted. Compare a SHA256 or MD5 hash between the source file and the uploaded file before concluding the source is bad and going back for a fresh copy.
There's no fixed number of days in the source documentation; the practical answer is: until the verification checklist above has passed on both devices and the pair has been through at least one planned switchover test on the new version. Reserve — don't /unreserved — delete it before then.
Not necessarily — see the second gotcha above. Check whether the main-board configuration has finished restoring, whether at least one CPU is online, and whether the heartbeat-carrying interface board has come back, and allow the additional one-minute wait before treating it as a fault.
This note is built from the HiSecEngine USG6000F, USG6000G and USG12000 V600 maintenance-manual case material on backup discipline, upgrade-package verification and hot-standby best practice, cross-checked against the same platform family's USG6000E/USG9500 manual where the underlying HRP and per-device licensing behavior is shared. The specific reboot-preemption timing and licensing rules described are this platform's own; a different vendor's HA implementation will use different commands and counters even though the backup, verify, isolate and switchover order carries over conceptually. It doesn't cover chassis-level board replacement during an upgrade, or multi-vsys License apportionment, in depth.
Tell us the device model, current and target software version, and whether it's a hot-standby pair — we'll help you check the plan before you touch the upgrade command.