05-19-2022 09:14 AM - edited 05-19-2022 09:19 AM
so our organization recently upgraded our firewalls from PANOS 9.1 to 10.1. ever since the upgrade, we've had an issue with HA pairs not synchronizing their configs automatically. this does not seem to happen every time a commit is pushed from PAN but it happens regularly enough that we have to manually sync at least one pair weekly. is this something the rest of the community is noticing as well? is this something that can be corrected with a simple config change somewhere? I'd like to avoid opening a ticket if possible because our recent experiences with PA support have been less than stellar.
update:
just checked and yes, config sync is enabled in the HA general menu in the device tab.
05-31-2022 10:05 AM
that's not really an option in our case. these are live production firewalls and that would take the HA peer offline for several hours, possibly even days as there are a lot of tunnels, routing instances, and IP instances that would need to be completely rebuilt.
the issue is apparently caused by Panorama pushes using the "merge with candidate config" option. if one FW finishes its commit first, it will attempt to do a synchronizing push to the HA peer while it is still working on the PAN push commit, which then fails out. even though both FWs have the same policy and object bases, they still show out of sync because of the failed sync commit.
05-19-2022 06:48 PM
Recommendation is to save and export the running config from the Primary FW and import and load the config on the backup FW.
Then change the mgmt IP, the HA configuration, and the host name, so that you will have a 100% identical config (minus the mgmt IP, HA and hostname), and try that. I have used this technique and it seems to resolve issues.
05-31-2022 10:05 AM
that's not really an option in our case. these are live production firewalls and that would take the HA peer offline for several hours, possibly even days as there are a lot of tunnels, routing instances, and IP instances that would need to be completely rebuilt.
the issue is apparently caused by Panorama pushes using the "merge with candidate config" option. if one FW finishes its commit first, it will attempt to do a synchronizing push to the HA peer while it is still working on the PAN push commit, which then fails out. even though both FWs have the same policy and object bases, they still show out of sync because of the failed sync commit.
09-01-2022 05:55 AM
Did you ever get a resolution on this?
09-01-2022 08:36 AM
Hello,
I would make sure you are running a recommended version. I recall reading about an HA sync bug in some of the release notes.
Not sure if youre hitting it or not.
Regards,
11-08-2023 11:13 AM
I would like to better understand the comments/replies back and offer my own comments to the original poster:
1) that's not really an option in our case. these are live production firewalls and that would take the HA peer offline for several hours, possibly even days as there are a lot of tunnels, routing instances, and IP instances that would need to be completely rebuilt.
SCantwell response... a running config, saved from primary to backup firewall would be 100% identical. I would be confused to say that there are configurations that need to be rebuilt.. because that is why you have a running config from a working primary FW.
2) the issue is apparently caused by Panorama pushes using the "merge with candidate config" option. if one FW finishes its commit first, it will attempt to do a synchronizing push to the HA peer while it is still working on the PAN push commit, which then fails out. even though both FWs have the same policy and object bases, they still show out of sync because of the failed sync commit.
SCantwell: I am confused in the reply, because 99% of your configuration should be programmed via Templates and Device Groups on the Panorama. There should not be any local configurations that need to sync between two firewalls. In my experience, the only (1%) that I would program locally would be the HA configuration for firewalls, because if you associate 2 serial numbers to the same template of information (like peerIP) then BOTH firewalls have that same PeerIP.
I just think it is important to note that if you are programming partially in Panorama and partially in local mode on FWs, that perhaps companies would slowly transition to Panorama only managed configurations.
Thank you for your comments and clarifications.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
