HA Sync Error on Commit

[dancoyote]

Hi All,

I have two PA-2020 in Active/Passive HA. Both on same code (v4.1.4) and latest subscriptions.

The pair have been running fine for almost 12 months.

Recently, when I tried to Commit a fairly basic change on the Active node, it fails to Sync with the passive node.

The Passive logs shows an interface config mis-match: one of the Trust zone interfaces is hard set to 1000 / Full.

The corresponding i/f on the Active box is Auto, Auto.

I tried to set the Passive i/f to match the Primary (i.e. Auto, Auto) but, on Commit, I get the message:

'device config>HA>group>1>mode is a duplicate node'

Has anyone come across this before?

Thanks,

Dan

[UhMayYeah]

Check the Group ID on the HA unit which shows the commit error.

Try matching it up with the other unit.

[dancoyote]

Yes, that was the first thing I checked.

Both units show original Group ID (value = 1).

[zarina]

Hello,

Do you have different A/P clusters in the network using the same group id? If so, changing the group id will resolve the duplicate node issue.

Thanks,

Sri Darapuneni

[dancoyote]

Hello Sri,

No, it is a single A/P cluster.

Regards,

Dan

[dancoyote · Accepted solution]

I managed to find (and fix) the cause of this error...

The 'mode is dupliacte node' message appears to be referring to XML config for the affected device.

I saved the config off the box and inspected it using XML-Notepad.

When I traced the XML path to: deviceconfig -> high-availability -> group -> 1
It is clear that there are two entires in the hierarchy with the name 'mode' (see image below).  Hence, 'mode is a duplicate node'

I removed the bottom 'mode' entry using XML Notepad and saved the resulting XML.

I then:

used the 'Import named configuration snapshot' link from the PA GUI (to get the corrected XML onto the PA box);

followed by 'Load named configuration snapshot' - choose the fixed XML snapshot to overwrite the existing Candidate Config;

then, clicked 'Validate candidate configuration' to check that the fixed XML would be viable.

The fixed XML proved a valid candidate config, so I was then able to 'Commit' this and get rid of the error message.

This is the first time I have manipulated XML config files off the Palo-Alto firewalls, so I don't know how the error was introduced initially.

The most important thing is... it is now FIXED!

Thanks,

Dan

P.S. here's what XML Notepad showed...