The following instructions for upgrading an HA pair are recommended because:
It verifies HA functionality before starting the upgrade.
It ensures the upgrade is successfully applied to the first device before starting the upgrade on the second.
At any point in the procedure, if any issue arises, the upgrade can be seamlessly reverted without any expected downtime (unless you are having any dynamic routing protocols line OSPF/BGP).
When finished, the final active/passive device state will be the same as it was before the upgrade with the fewest number of failovers possible (2).
Take backup of the configuration as well as Tech Support from both HA Peers. Give proper names to each file.
Device > Setup > Operations > Save Named Configuration Snapshot
Device > Setup > Operations > Export Named configuration Snapshot
Device > Setup > Operations > Export Device State (If device managed from panorama)
Device > Support > Generate Tech Support File, and then download it. (Might be required if any issues)
(Optional but recommended) Disable preemption on High Availability settings to avoid the possibility of unwanted failovers. Disabling preempt configuration change must be committed on both peers. Likewise, once completed, re-enabling must be commited on both peers.
To disable preempt, go to Device > High Availability > Election Settings and uncheck Preemptive. Then, perform a commit.
If upgrade is between major versions (4.1 -> 5.0 OR 5.0-> 6.0), it is advisable to disable TCP-Reject-Non-SYN, so that sessions can failover even when they are not in sync.
# set deviceconfig setting session tcp-reject-non-syn no
(Optional but recommended) Arrange for Out-of-Band access (Console access) to the firewall if possible. This is again to help recover from any unexpected situation where we are unable to login to the firewall
First suspend the active unit from the CLI. Run the command:
> request high-availability state suspend
or From the GUI, go to Device > High Availability > Operations > Suspend local device. Note: This will cause an HA failover. It is recommended to do this first to verify the HA functionality is working before initiating the upgrade.
Verify network stability on the new active device with the previously active device suspended.
When the upgraded device is rebooted, the CLI prompt should show passive (or non-operational, if on a different major release ie 5.0 to 7.0) and the PAN-OS version should reflect the new version.
On the current passive device, verify auto commit completes successfully (FIN OK) by running the command before proceeding to the next step:
> show jobs all
Note:If the current passive device is in a non-functional state, run the following command to make it functional again:
> request high-availability state functional
Suspend the second device (current active device). When the second device is suspended, the first device, already upgraded, takes over as active. Note: If you have dynamic routing protocols like OSPF/BGP, suspending the current active device may cause a short traffic outage depending upon your network. This is due to the adjacency with existing neighbors going down and coming back up with the new active device. In order to eliminate this downtime, please enable Graceful Restart on the firewall and the neigboring devices. Please note that the Graceful Restart feature is only supported on PAN-OS version 6.0 or later.
Upgrade the second device, then reboot it.
When the second unit reboots, it will come up as the passive unit. Validate the auto commit completes on this device by running the following command (on this device (as done in step 5) to complete the upgrade):
> show jobs all
Note: For upgrading an Active-Active HA pair, following the same steps for upgrading the Active-Passive pair. All the steps and terms used for Active and Passive devices can be correlated to Active-Primary and Active-Secondary, respectively. Please be aware that this whole upgrade process might take upwards to 30 minutes.
How to Downgrade
If an issue occurs on the new version and a downgrade is necessary:
To revert to the previous PAN-OS screen, run the following CLI command:
> debug swm revert
This causes the firewall to boot from the partition in use prior to the upgrade. Nothing will be uninstalled and no configuration change will be made.
However please be aware while running this command - After rebooting from a SWM revert, the configuration active at the time before upgrade will be loaded with the activation of the previous partion. Any configuration changes made after upgrade will not be accounted for and will need to be manually recovered by loading the latest configuration version and committing the changes.