06-09-2017 03:02 PM
Hi folks,
Configuring my first HA tomorrow around 1:30pm cst.
I am enabling HA on a production 3020 as active, then adding a secondary 3020 as passive (same OS, updates, etc. according to HA documentation).
Expecting a network interuption because of the MAC Address change, so we have a maintenance window of 1 hour.
We are small company, the PA 3020 in production now is our only router, connected to one HP Procurve 2910al switch, with several servers behind it.
I have PA support on standby for guidance if necessary.
If the network interuption is delayed, I will restart the data plane so that G-ARPs will be issue hopefully help ARP table updates.
I have our ISP on standby ready to clear our public IPs to MAC ARP entries, if necessary.
I have also backed up the Production snapshot in case need to restore.
Hoping it goes well and sync to secondary using crossover cables for HA1, HA2, HA1 backup, and HA2 backup.
If anyone has any tips or comments about our DNAT rules or clearing servers ARP cache, or other, let me know. 🙂
06-09-2017 04:56 PM - edited 06-09-2017 04:58 PM
Something to consider...
I usually use management interface for HA1 backup because management interface is on control plane.
If you set HA1 backup on network interface then it is on data plane.
I have heard claims that in case HA1 backup is on dataplane it sends heart beats but does not syncronize config. Have not tested myself. Might or might not be true. Maybe someone will confirm.
HA2 backup is not too important. Worst can happen if HA2 sync is not working is that in case of failover sessions will drop and they have to be re-established.
06-09-2017 04:56 PM - edited 06-09-2017 04:58 PM
Something to consider...
I usually use management interface for HA1 backup because management interface is on control plane.
If you set HA1 backup on network interface then it is on data plane.
I have heard claims that in case HA1 backup is on dataplane it sends heart beats but does not syncronize config. Have not tested myself. Might or might not be true. Maybe someone will confirm.
HA2 backup is not too important. Worst can happen if HA2 sync is not working is that in case of failover sessions will drop and they have to be re-established.
06-09-2017 05:01 PM
Hi @OMatlock
Here are a few tips from the field that may be of assistance to you.
Control Link (HA1) Monitor Hold Time
To monitor the health of the Primary HA1 interface, an additional “Monitor Hold Time” timer is used to detect a failed Primary HA1 condition. If three heartbeats or hello messages are missed between the HA devices, the HA1 Monitor Hold Time will be consulted to determine the amount of time the HA device should wait before declaring a failed Primary HA 1 connection. The default is 3000 ms.
Once a failed Primary HA1 condition has occurred, the units will log the appropriate information into the system logs and failover to the Backup HA1 or Management interface—depending on how the HA1 backup is configured.
Recommendation: If you have a Backup HA1 interface configured, lowering this value will allow a faster failover to the backup HA1 links. Leaving the value at the default of 3000 ms is recommended for most HA implementations. The range for the HA1 Monitor Hold Time is 1000 to 60000 ms. I personally cut this time in half and put 1500 ms instead.
Passive Link State Auto Configuration (A/P)
An important fact to consider when designing an Active/Passive HA architecture is the traffic forwarding links on the passive device defaults to a “Shutdown” state. In the shutdown state, upstream and downstream devices connected to the passive device will not see a valid path until the passive firewall becomes active.
The Passive Link State Auto Configuration feature allows you to bring up the passive device’s traffic forwarding links to reduce the failover time. It does this by bringing the interfaces on the firewall to a “link up” state, but blocks inbound and outbound traffic to the interfaces until the passive unit becomes active. This helps to reduce failover times by eliminating the need to go through port learning and negotiation phases right after a failover to the passive device and can reduce failover times by approximately one to two seconds.
The Passive Link State Auto Configuration setting is enabled under Device > High Availability > Election Settings. The Passive Link State defaults to “Shutdown” and should be set to “Auto” to facilitate faster failover times and to force the link status of the neighboring devices to be in the “link up” state. When the Passive Link State is set to “Auto”, the HA device in the “passive” state will not forward traffic or respond to ARP requests. I like this option, because we are able to avoid the gratuitous ARP delay with up and downstream devices.
If you set the passive link state to "Shutdown", you will notice that the standby appliance will have all its ports in in shutdown state; hence, delaying the failover due to the ARP responses.
For more details, refer to the following link: https://live.paloaltonetworks.com/twzvq79624/attachments/twzvq79624/documentation_tkb/543/2/HA_Failo...
As for your DNAT rules, the only advise I always give to my clients is to ensure that they do not have Proxy-ARP configured in the upstream switch or router. If they do, I always advise to either change it accordingly a few minutes prior to the cutover start time and then clear the MAC address table, or in some cases completely remove it if at all possible. In some cases because the upstream switch or router is not managed by the client, they will need to open a case with their ISP, which may delay your cutover window, so, having this figured out beforehand is always best practice.
Another advise as well, is to open a proactive case with Palo Alto eTAC support, informing basic details of the activity that you will be performing. This helps to speed up support if you call out of the blue because you are having issues or questions, so you don't have to explain things from the very beginning. That was an advise from one of the Palo Alto SEs in my region, and I have been very successful in doing so. Of course in 90% of the time you never even ended up calling them, but better safe than sorry.
I hope it helps.
Willian
06-11-2017 06:53 AM - edited 06-11-2017 06:55 AM
Thank you guys for the feedback.
I completed the configuration yesterday successfully! Very happy about that. 🙂
I did have to call our ISP to have them clear the ARP cache entry for our IPs/MAC. They have a 4 hour ARP refresh time!! After manually clearing, we were back up. With the call, took just a couple of minutes. Restarting the data plane did not restore connectivity, had to call ISP.
I did miss the comment about using Management interface as HA1 backup. I did use 1/11. I've read about using it that way, but I guess I was nervous about messing the the management interface. But sounds like I should do some testing with it now that more comfortable. Can probably change it, I'm assuming.
I used the defaults for timer settings. I will be using your feedback in the coming weeks to test failover on the weekends to make adjustments.
Thanks again!!!
06-11-2017 03:04 PM
Thanks for update!
06-11-2017 03:49 PM
GARP probably would help to clear MAC address:
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!
