Active/Active failback

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Active/Active failback

L1 Bithead

Hi,

We are looking at deploying an A/A L3 cluster with dynamic routing (has to be A/A to satisfy requirements of the existing setup). We've pinned all the routing preferences and floating IP priorities to 'unit A'. We are new A/A so any help with the below would be much welcome:

 

1)

The issue we are facing (will be facing) is when failing back, there is a delay between 'unit A' coming out of tentative-hold and then routing convergence. Ie. after tentative-hold floating IPs failback, but routing takes 10 or so seconds to converge meaning a slight outage.

 

Has anyone else experienced a similar scenario? Is there a work around?

 

2)

Also with Ha3 Ae interace, if we go direct cabling between peers, would an outage of 'unit B' cause 'unit A' to go to a non-forwarding state?

Do we need a switch in-between to avoid the above scenario. 

 

thanks very much,

CK

1 accepted solution

Accepted Solutions

 

 

1)

The issue we are facing (will be facing) is when failing back, there is a delay between 'unit A' coming out of tentative-hold and then routing convergence. Ie. after tentative-hold floating IPs failback, but routing takes 10 or so seconds to converge meaning a slight outage.

 

-- This can be mitigated using smaller BGP retry connect timers and BFD. There is still a 1-2second drop but this acceptable than 10 seconds.

 

2)

Also with Ha3 Ae interace, if we go direct cabling between peers, would an outage of 'unit B' cause 'unit A' to go to a non-forwarding state?

Do we need a switch in-between to avoid the above scenario. 

 

No - heartbeat will stay up.

 

Also from labbing found the following:

- A/A fails over session owner ship to the active firewall, which means there is no HA3 traffic to the former active=primary. Thus HA3 link does not need to support the full expected throughput of the firewall transit traffic.

 

The downside is there is L7 or IPS for the failed over sessions even when it failsback.

 

 

View solution in original post

4 REPLIES 4

Hi @ChamindaK

 

Cyber Elite
Cyber Elite

@ChamindaK,

So to verify you have asymmetrical routing in your enviroment at this point in time correct? If not A/A really shouldn't be used; depending on who your last vendor was there could be instances where I would use A/A on a Cisco deployment that I would never dream of using A/A in a Palo Alto deployment. I would verify that before  you actually implement this. 😉

thanks!

I'm in the process of labbing this, so will post once I find out exactly how this behaves.

Unfortunately stuck with A/A, as the firewalls are deployed as such in vwire. We are going to implement a L3 vsys on the existing firewall deployment.

 

 

1)

The issue we are facing (will be facing) is when failing back, there is a delay between 'unit A' coming out of tentative-hold and then routing convergence. Ie. after tentative-hold floating IPs failback, but routing takes 10 or so seconds to converge meaning a slight outage.

 

-- This can be mitigated using smaller BGP retry connect timers and BFD. There is still a 1-2second drop but this acceptable than 10 seconds.

 

2)

Also with Ha3 Ae interace, if we go direct cabling between peers, would an outage of 'unit B' cause 'unit A' to go to a non-forwarding state?

Do we need a switch in-between to avoid the above scenario. 

 

No - heartbeat will stay up.

 

Also from labbing found the following:

- A/A fails over session owner ship to the active firewall, which means there is no HA3 traffic to the former active=primary. Thus HA3 link does not need to support the full expected throughput of the firewall transit traffic.

 

The downside is there is L7 or IPS for the failed over sessions even when it failsback.

 

 

  • 1 accepted solution
  • 2724 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!