Quick query, we are in the process of implementing a HA cluster that will be BGP peering with several upstream routers, both route import and export, and in trying to reduce the interruption due to a failover we are looking to implement the Graceful Restart option.
My question is...... will this have any effect?
I was not sure how, in the case of a failover, the newly activated secondary node would know to send packets marked with the Graceful restart flag.
I have noted a couple of posts on the forums that say it is recommended to enable this feature but just wanted to confirm it would have the same effect in HA as it does with a single node.
Solved! Go to Solution.
PA firewalls in HA ,sync their forwarding tables . The packet forwarding decisions made by the active device (before failure) will be the same as those made by the passive device once it takes over. A failover does not result in any loss of service due to routing. The routing table (and BGP protocol state) must be built up on the passive device when it becomes active. Graceful restart is recommended.
Thanks for the reply.
We've always had a short but noticeable 2min+ outage when we failover to the passive firewall because most of our connections are using BGP.
We have graceful restart (enabled by default) on our peers as well as the HA cluster.
So when you say
"The routing table (and BGP protocol state) must be built up on the passive device when it becomes active"
Are you confirming that this is expected behaviour? for the routing table to be built up after a failover? Meaning - a short 2 minute outage is expected during failover?
For our organization, we expect the PA to give us sub second failover - including continuous forwarding with Dynamic routing protocols.
If so, this is not really acceptable for us. Is there a way not to have an intrusive failover?
I'm not a BGP expert, but everything I can find points to two (2) things that need to be in place for Graceful Restart to be effective:
Graceful Restart is negotiated during BGP Peer handshake, so if this was done after initial BGP Peering it will not take effect until the next full peering is done. Two minutes looks to be default timing for BGP restart so this might point to BGP Peers to configured the same.
If you believe all of this is in place with your configurations than a call with our TAC is in order to see if something is not working as expected between the BGP Peers.
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 Live Community as a whole!
The Live Community thanks you for your participation!