Active/Active failback

Reply
Highlighted
L1 Bithead

Active/Active failback

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

Tags (1)

Accepted Solutions
Highlighted
L1 Bithead

Re: Active/Active failback

 

 

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


All Replies
Highlighted
L4 Transporter

Re: Active/Active failback

Hi @ChamindaK

 

Cyber Elite

Re: Active/Active failback

@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. ;)

Highlighted
L1 Bithead

Re: Active/Active failback

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.

Highlighted
L1 Bithead

Re: Active/Active failback

 

 

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

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 Live Community as a whole!

The Live Community thanks you for your participation!