Redundant Network Config with two ASA's and two switches
I'm hoping some can critique a very basic redundant ASA configuration. Currently, we have rackspace at our provider. The provider provides us two uplinks to their cores. I have one ASA5520 and one 3560 switch, so both uplinks (fiber) are on the same switch. I would like to introduce another ASA and another 3560 (or 3750). I envision that one provider uplink will go into one switch, and the other uplink will go to our new switch. I can simply run spanning tree and will not need a routing protocol. We do not have an internet router. The outside interface of our ASA is placed into the same VLAN as the provider uplinks, and we "go out" from there. Our provider routes us a netblock to our ASA outside interface IP. I then NAT to our internal servers which are also plugged into the same switch, and VLAN appropriately. You can see we have all our eggs in one basket with the switch and ASA.
I can only introduce two more devices into our rack, so one more switch and one more ASA is all I have to work with. Please see the attached pic to see if I've thought this out.
1. I am confused if the two switches need to be connected together via an etherchannel and HSRP or anything like that. The ASA is the default gateway for all the devices on the network, so the switches really aren't routing.
2. Our current ASA is running some older 7.2 code. I obviously want to get it up to the 8.X series. This may have to be a phased implementation, since this is a production site and my downtimes can't be long. Is it difficult to bring a single, standalone ASA into an Active/Standby configuration with an entirely new ASA? I know they have to be the same hardware config, code rev, etc.
I've done one of these before, but it was from scratch and I had the luxury of time.
The goal here (obviously) is to keep our servers available in the event we lose one ASA or one switch. Please look at the pic and offer any suggestions. Thanks very much.
Re: Redundant Network Config with two ASA's and two switches
1) The servers are dual honed to both switches. Are the NICs on the servers in active/standby configuration ?
If they are you will have a problem if you don't connect the 2 switches with a L2 etherchannel trunk. An example -
ASA1 is connected to SW1. SW1 is also the active switch for the servers ie. the NIC in use on each server is connected to SW1. The port that ASA1 connects to for one of the server vlans fails. So ASA2 becomes the active firewall. But the server ports are still okay on SW1. So a server sends a packet to it's default gateway ie. one of the ASA interfaces and the packet is sent to SW1. But SW1 has no path to get to ASA2 because there is no connection between SW1 and SW2, where SW2 is the switch connected to ASA2.
So you need a connection between the switches but only a L2 trunk or L2 etherchannel trunk. HSRP is not needed because as you say the ASAs are the default-gateways for servers.
If the servers are active/active on their NICs then you don't need a connection.
2) Not difficult no. You need to add failover commands to the active unit. This will not affect the active unit as it won't be able to find the standby unit and so will stay active.
Then add just the relevant failover commands to your new unit and connect them up and the failover unit should then sync with the active unit.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...