ASA Failover using a switch
TesseracT
Member Posts: 167
I've noticed it's best practice to not connect 2 ASA's directly together when configuring failover, it's best to use a switch.
This is the way I have it setup in a production environment at the moment, using a 2960 switch as the intermediary device.
I'm not totally happy though as now this switch has become the single point of failure
If one ASA goes down the other comes straight up (setup as active/passive by the way) but if this 2960 goes down we're completely screwed. How do you guy setup failover between ASAs and avoid this seemingly stupid problem. Am I doing it the right way?
This is the way I have it setup in a production environment at the moment, using a 2960 switch as the intermediary device.
I'm not totally happy though as now this switch has become the single point of failure
If one ASA goes down the other comes straight up (setup as active/passive by the way) but if this 2960 goes down we're completely screwed. How do you guy setup failover between ASAs and avoid this seemingly stupid problem. Am I doing it the right way?
Comments
-
cisco_trooper Member Posts: 1,441 ■■■■□□□□□□I wouldn't use a switch platform that has only one power supply. If the failover link itself goes down the active device will remain active while the passive device tries to become active. Any device that then ARPs for the active IP address of any ASA interface then has the potential of receiving a response from each ASA. If all your ARP timers at their defaults the best case scenario is that you will start having network issues in under 4 hours. Now, we all know you will have devices that made their last ARP request 3h and 55m prior to this happening...;) What does your network look like on the outside interface of the ASAs? I'm thinking you have some potential for seeing issues in your session state tables if you have this happen.
-
TesseracT Member Posts: 167Yeah I see what you mean. There's unfortunately only 1 power supply in the failover switch. Even if there was two I still have a single point of failure though...? Is this just an unavoidable part of the design?
How does the network outside the ASAs impact things? I have a direct 10mb ethernet connection to the switch, then from the switch a link to the outside interface of both ASAs. those 3 ports on the switch are in a separate vlan -
cisco_trooper Member Posts: 1,441 ■■■■□□□□□□I was just curious if you were doing anything with multiple ISPs or not. I would definitely put the ASAs on a switch with multiple sources of power. While you still have a single point of failure in the 2960, you are more likely to lose power to that 2960 than you are to see the 2960 just go bad.
-
gsnider Member Posts: 7 ■□□□□□□□□□I've been working on ASAs and PIX firewalls for 4 years for large enterprises and I've always directly connected the failover interfaces together and configured failover and state replication on the same interface. Where do you see that it's best practice to use a switch? I've never had any issues fwiw.
-
networker050184 Mod Posts: 11,962 ModI've been working on ASAs and PIX firewalls for 4 years for large enterprises and I've always directly connected the failover interfaces together and configured failover and state replication on the same interface. Where do you see that it's best practice to use a switch? I've never had any issues fwiw.
Thats what I was thinking also. I'm no expert on firewalls, but why would you want a switch in the middle rather than a direct connection? Seems more trouble than its worth.An expert is a man who has made all the mistakes which can be made. -
Bl8ckr0uter Inactive Imported Users Posts: 5,031 ■■■■■■■■□□I've been working on ASAs and PIX firewalls for 4 years for large enterprises and I've always directly connected the failover interfaces together and configured failover and state replication on the same interface. Where do you see that it's best practice to use a switch? I've never had any issues fwiw.
That's exactly what I was thinking. I think the Cisco ASA handbook suggest that you directly connect them to prevent indirect failures to cause your ASAs to failover. -
gsnider Member Posts: 7 ■□□□□□□□□□I found a suggestion on the config guide to use a switch instead of using a crossover. The ASA interfaces automatically detect MDI and MDI-X so there's no need for a crossover. I'm guessing that they just want you to spend more money on an extra switch. If the firewalls are located in the same building I'd go ahead and use a direct connection.
-
TesseracT Member Posts: 167I was actually told to use the switch by TAC... In case an interface goes down and both ASA's decide that they want to become active. A switch will make sure that if one ASA interface goes down the interface on the other ASA will remain up.
This is just what I was told though - I haven't tested directly connecting the interfaces.
So how do you guys set it up directly anyway? Say you have 1 outside connection and 1 inside connection - how do you plug them into both ASAs? I'm not getting the topology... -
Trifidw Member Posts: 281So how do you guys set it up directly anyway? Say you have 1 outside connection and 1 inside connection - how do you plug them into both ASAs? I'm not getting the topology...
Connect the ASA directly to each other. But for the topology:
Router
....|
switch
.|.....|
ASA-ASA-DMZswitch
|.........|
switch..switch
(Obviously DMZ switch has a connection to both ASAs) -
Bl8ckr0uter Inactive Imported Users Posts: 5,031 ■■■■■■■■□□I have one outside, one inside, one connection for state and one connection for flow control. The later to are directly connected into each other.
Edit: Similar to what is above -
cisco_trooper Member Posts: 1,441 ■■■■□□□□□□Same here. My only difference is I'm not using a 2960. I've got everything VLAN'd out on Cat 6500s.
-
gsnider Member Posts: 7 ■□□□□□□□□□Just make sure you connect the outside interface of both ASAs to a switch before connecting to the outside layer 3 hop, then the same with the inside interface. You can also use layer 2 vlan for just the purpose of connecting the ASAs to their next hop.
-
Trifidw Member Posts: 281I still don't see what purpose the switch between the 2 ASA's provides? I know that it is not required as we have 2 pairs of ASAs directly connected to each other. And before this we had 2 PIX firewalls directly connected to each other.
If you were to use a switch between them, I'd be looking at a 4948, but it seems like such a waste and still adds a point of failure. -
gsnider Member Posts: 7 ■□□□□□□□□□I still don't see what purpose the switch between the 2 ASA's provides? I know that it is not required as we have 2 pairs of ASAs directly connected to each other. And before this we had 2 PIX firewalls directly connected to each other.
If you were to use a switch between them, I'd be looking at a 4948, but it seems like such a waste and still adds a point of failure.
It adds another point of failure, another hardware purchase and another smartnet contract
Now that I think of it, maybe they put the switch on there to show you that it is possible to use a switch since the failover and replication uses standard ethernet and IP for communication. I know of places that geographically separate the two sides of their dual stack so that if they lose power in 1 building, the other asa can take over as active. -
TesseracT Member Posts: 167Thanks for all the replies guys.
So for all the guys connecting the ASA's directly together, you just use 1 interface for the failover (and 1 for flowcontrol if needed)? I have a separate network hanging off every interface, I can't see how connecting them directly would work in this instance. 4 interfaces with 4 different networks (inside, outside, DMZ + another network) with the management int used for failover. There is only 1 incoming connection to the ASA from each of these networks as well. It seems like a switch is the only option in this case.
Good discussion here! -
Kelkin Member Posts: 261 ■■■□□□□□□□I was actually told to use the switch by TAC... .
I take what TAC says with a grain of salt.. Ive seen really horrible tac engineers and some really good engineers.. I normally grill them pretty good when im working with them not to be mean but to just learn and understand more.. the good engineers will always produce docs to back them up with.. -
TesseracT Member Posts: 167I take what TAC says with a grain of salt.. Ive seen really horrible tac engineers and some really good engineers.. I normally grill them pretty good when im working with them not to be mean but to just learn and understand more.. the good engineers will always produce docs to back them up with..
I absolutely agree. I did see using a switch referenced in a few online tutorials though. Here for example:
Alfred Tong » Cisco ASA Failover Tips and misc.
To tell you the truth I haven't been able to see this config referenced in Cisco's own documentation.
1 thing I don't like about the failover is that you need an extra IP address in each subnet for the standby IP. What if you're using a /30 subnet... In the pix old days both Pix's could use the same IP for failover, and I think you may be able to still do this with the ASA's as well. I don't have any to try on hand at the moment though and I read somewhere that doing failover the old way is not supported if something goes wrong -
instant000 Member Posts: 1,745I absolutely agree. I did see using a switch referenced in a few online tutorials though. Here for example:
Alfred Tong » Cisco ASA Failover Tips and misc.
To tell you the truth I haven't been able to see this config referenced in Cisco's own documentation.
1 thing I don't like about the failover is that you need an extra IP address in each subnet for the standby IP. What if you're using a /30 subnet... In the pix old days both Pix's could use the same IP for failover, and I think you may be able to still do this with the ASA's as well. I don't have any to try on hand at the moment though and I read somewhere that doing failover the old way is not supported if something goes wrong
The standby IP is for "your" benefit, for in case you needed to manage the device via IP, you could still connect to it, and reference one device separately from the other one., and you could even set up your monitoring, so that you monitored the standby IP's, for example. Imagine a maintenance scenario, and you need to tftp a new image or something. If you have standby IP, you can reference the standby device. If you don't have standby IP, you can't reference the standby device during maintenance via IP. (of course, you have to only get burned once to know to do all maintenance with an active console connection, I'd hate to be the one uploading an image via that same console interface.)
We have tons of devices deployed that don't have standby IP's configured on the interfaces, and it works just fine.
Standby IP only works if both devices are online at the same time, then the non-active one is the standby.
Also, I don't recommend active-active, as according to the documentation, you need to reserve horsepower on either box to make up for what's running through the other one (in the case of failure) which basically means to just run active/standby then, to keep it simpler.Currently Working: CCIE R&S
LinkedIn: http://www.linkedin.com/in/lewislampkin (Please connect: Just say you're from TechExams.Net!) -
nicklauscombs Member Posts: 885so i've found some insight to using a switch between ASA's in that there can be a situation IF using redundant interfaces where the ASAs choose a different link in the redundant pair as being active and the switch would still move the traffic correctly as it references the cam table. however if you're not using redundant interfaces a switch just seems like a waste.WIP: IPS exam
-
Forsaken_GA Member Posts: 4,024nicklauscombs wrote: »so i've found some insight to using a switch between ASA's in that there can be a situation IF using redundant interfaces where the ASAs choose a different link in the redundant pair as being active and the switch would still move the traffic correctly as it references the cam table. however if you're not using redundant interfaces a switch just seems like a waste.
I wouldn't use a switch without a very good reason. If the switch goes down or gets rebooted for maint, and folks either don't remember or don't know that some of those ports are for ASA failover, or if a port goes bad, you're taking unnecessary failovers. If the ASA's are connected together directly, and there's a failover, then you know it's either the cable or the ASA that's the problem. -
nicklauscombs Member Posts: 885Forsaken_GA wrote: »I wouldn't use a switch without a very good reason. If the switch goes down or gets rebooted for maint, and folks either don't remember or don't know that some of those ports are for ASA failover, or if a port goes bad, you're taking unnecessary failovers. If the ASA's are connected together directly, and there's a failover, then you know it's either the cable or the ASA that's the problem.
definitely not disagreeing with you there. that was however the one scenario i found where there was actually some rhyme and reason for suggesting using the switch between. like i said if you're not using redundant interfaces for failover on the ASAs there is absolutely no reason to ever consider the switch between and even if you are i'd still probably forgo using it.WIP: IPS exam -
jason_lunde Member Posts: 567I havent read every part of this, so forgive me if its already been said. But I know for certain, that a switch is recommended so that if the failover link dies, you know which ASA it is limited to (If the issue is on the ASA side). If they are directly connected, you really have no way to tell which ASA the switchport died on. That is why TAC recommends an intermediary device inbetween.
-
jovan88 Member Posts: 393jason_lunde wrote: »I havent read every part of this, so forgive me if its already been said. But I know for certain, that a switch is recommended so that if the failover link dies, you know which ASA it is limited to (If the issue is on the ASA side). If they are directly connected, you really have no way to tell which ASA the switchport died on. That is why TAC recommends an intermediary device inbetween.
but if the switch goes down you get the same problem anyway right?