For whatever reason, I had a Palo Alto Networks cluster that was not able to sync. A manual sync was not working, nor did a reboot of both devices (sequentially) help. Finally, the PAN support told me to “Export device state” on the active unit, import it on the passive one, do some changes, and commit. Indeed, this fixed it. A little more details:
I was running a PA-820 cluster with PAN-OS 8.1.13. Screenshot from the dashboard:
Some system logs:
I wanted to do some OS upgrades but wanted to fix this error before, of course.
This finally made it:
- Export of the “device state” from the active device. Device -> Setup -> Operations -> “Export device state”.
- Now on the passive device: “Import device state”. DO NOT COMMIT YET!
- Change the following settings on the passive device:
- hostname & login banner (if specific)
- management IP settings
- HA settings
- Commit on the passive device.
Worked for me. Though I do not know why this happened at all…
Photo by Gabriel Gusmao on Unsplash.
7 thoughts on “Palo Alto Networks Cluster “not synchronized””
Usually it helps to manually sync the other way around (passive to active device).
Never had to used the workaround that you were provided by PAN support :O
Uh really? Haven’t tried it that way, to be honest… (Since we saw this issue for some weeks, a sync from the passive to the active device would have deleted some running configs on the active one …)
If it was not synced for a longer time, that is indeed no good option.
But if the active unit fails in the meantime and the passive one gets active with old config it could be even worse ;-)
I’d be very careful with that and would absolutely not recommend that approach.
Careful with that Axe, Eugene! When you import a device state, the appliance immediately becomes a clone of the device you import – commit is not required, it happens instantly. So you will have two identical devices, with the same management IP’s, the same HA priority, same HA IP addresses and so forth. It may not be an issue, if you the device is in your vicinity and you can disconnect the cables, but otherwise expect to have two firewalls battling each other. Once it nearly cost me a 315 km drive across the country.
What did a comparison of the two configurations show in terms of differences? Sometimes an export of the XML on each device and a compare in your preferred text editor (e.g. Notepad++) will show the culprit.
On the rare occasions when a forced sync doesn’t do the trick (remember to try from CLI as well), in my experience the culprit has always been certificates. A reboot of the passive device may also have helped, once or twice. I don’t remember any times where we didn’t manage to solve it without drastic measures :-)
device state import requires commit to be effective…its not immediate!
Honestly, I didn’t check it recently. It used to be so, but it may well have been changed. Anyway, it doesn’t change the fact, that using a device state import to recover from a “Not synchronized” error state, isn’t a good idea.