cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1529
Views
20
Helpful
6
Replies

ASA failover active-active and HSRP L3 switches

Florin Barhala
Level 6
Level 6

Hi guys,

 

I need your input about this design scenario. I want to break current 3850 stack into 2x 3850 separate units and add HSRP between them.

On each ASA failover pair I will monitor interfaces connected to the HSRP switches. Routing wise I am using static routes (for now).

I can also add track on each HSRP group if required (as we speak, I see no scenario where it would be needed).

 

Please advise about any concern about scenario redundancy.

 

Thanks,

Florin.

6 Replies 6

Collin Clark
VIP Alumni
VIP Alumni

Why are you breaking up the stacks? I can't think of a situation where not stacking them would provide any extra redundancy or quicker failover times. 

 

Are your failover links really directly connected to each firewall? The failover links should be going through the switching fabric on the switches. This will prevent split-brain on failovers.

 

Are your firewalls running Active/Active or Active/Passive?

Florin

 

I agree with Colin that we need a better understanding of your environment. The title of the post seems to suggest that it is active active. But some other things in the post and the drawing seem to suggest active standby. Please provide more information.

 

The drawing shows a single physical connection from each firewall to its connected switch. From my perspective this compromises the redundancy. Assume that the primary firewall is connected to the HSRP active switch (which you would want to be the case, especially with a single physical connection). Then think what will happen if there is a firewall failover event. Now the other firewall is the active one. But it is connected to the standby switch. So for the newly active ASA to get to the HSRP active switch it must go through the standby switch.

 

also think about the scenario where the active ASA is connected to the HSRP active switch. Then think what happens if the HSRP active switch goes down. Now the active ASA is connected to a not active switch. HSRP will make the other switch active in HSRP but how will the primary ASA reach the new HSRP active switch?

 

I strongly suggest that each ASA should have a physical connection to each switch. And I agree with Colin that in this environment it wold be easier if the switches were stacked rather than operating separately.

 

HTH

 

Rick

HTH

Rick

Hello gentlemen,

 

Thanks for your time on this matter. Here are my thoughts and replies below

1. I am breaking the stack due to multiple times a year software updates on those switches. Upgrading a stack gives the chance of an unexpected event and additional worries. Now with HSRP I can always update the standby member, take as much as it's required then simply failover, similar to ASA update and the risk of something going wrong is minimal in regard to the production traffic.

 

2. Failover and stateful links are directly connected between the firewalls. I have read the design guide but we simply picked this option over using additional equipment. I might eventually come back on this but hopefully not now as I am focused into splitting this stack.

 

3. Current setup is Active - Active, but as you know what this really comes to is Active - Passive pairs for different contexts. So currently FW_1 keeps external context active on it, while FW_2 runs the internal context on it, hence my drawing.

 

4. Assume that the primary firewall is connected to the HSRP active switch (which you would want to be the case, especially with a single physical connection). Then think what will happen if there is a firewall failover event. Now the other firewall is the active one. But it is connected to the standby switch. So for the newly active ASA to get to the HSRP active switch it must go through the standby switch. 

As you said traffic should pass through standby switch at Layer 2 until reaches Active HSRP switch for Layer 3 duties. If we rule out the traffic overhead how exactly is the redundancy compromised? Or this is more a performance/optimization concern?

 

5. also think about the scenario where the active ASA is connected to the HSRP active switch. Then think what happens if the HSRP active switch goes down. Now the active ASA is connected to a not active switch. HSRP will make the other switch active in HSRP but how will the primary ASA reach the new HSRP active switch?

My idea here is straightforward: ASA failover interface monitoring. If the HSRP active switch fails then it should trigger a failover also on ASA. Now I am not sure what happens if HSRP preempt is setup? Does ASA can also "preempt" and return to its original state?

Florin

 

Thanks for the update and explaining your reasons from breaking the stack. While I see some advantages in maintaining the stack it is certainly a decision for you to make and if you decide that you prefer to break the stack you can do so.

 

There are no absolutes about how to implement the failover and stateful links. There is some advice in favor of using a connection through a switch but it is far from a requirement. I have implemented several ASA for customers who chose to make the connections direct ASA to ASA and it works. There are risks in that choice, as there are risks in most of the choices we make when we design a network. You make your choice and you accept the risk that goes along with it.

 

Let me add a wrinkle to the scenarios in 4 and 5. Let us assume that the switch interfaces to the ASA remain up and that there is some issue with the link between switches. Now the ASA interfaces do not experience any failure that would cause failover event on the ASA but you could have issues accessing the HSRP active switch from the active ASA.

 

And in reference to your question in 5 about preempt - there is no preempt equivalent on the ASA. When there is a failover event on the ASA the newly active ASA will remain the active one until there is a new failover event on the ASA or until you manually reset the active relationship.

 

HTH

 

Rick

HTH

Rick

Definitely valuable answers. I am left with two questions:
- except those weird scenarios physical link up but no l2 access will both 4 and 5 be ok? Will redundancy work as I am describing it?
- let's say I have fw_1 as active and the monitored interface goes down, then fw_2 becomes active ; what are my options to make fw_1 active again? EEM?

Last but not least I am thinking to add some track objects on switches to prevent weird scenarios, but before tweaking I need your thoughts on the current drawing

Florin

 

I believe that what you are describing can work, acknowledging the potential challenges. And every network implementation has some challenges that you must deal with.

 

Failover on an ASA pair generally works smoothly and frequently there is no external sign that there was a problem. So if you care which ASA is active then you need to implement procedures to periodically check on the state of your ASAs and have procedures to fail back to the preferred active ASA. I have worked with customers implementing ASAs in active/standby operation who feel that the network works ok no matter which ASA is primary. In that case they do not need as careful monitoring of the state of their ASAs. If you care then you need to monitor. The customers I have worked with have used CLI or ASDM commands to fail back to the preferred active ASA. Newer versions of ASA code do support EEM and I assume that you might be able to develop something using EEM to control which ASA is active. As I think about it there are a couple of things that might be tricky to work out in EEM: A) detecting that failover has occurred, B) after failover is detected how to determine when it is appropriate to fail back to the original (how to determine that the problem that caused failover is resolved).

 

HTH

 

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: