HSRP using 2 routers connecting to 2 switches

[ngthen]

I have two L2 switches that are redundant using spanning tree and I have two ISPs.  I would like to put in 2 switches (we'll call them ISW1 and ISW2) capable of running HSRP as well as IP SLA to achieve the following.

ISW1 and ISW2 are running HSRP with a virtual IP which would be the gateway for all my devices on my redundant switches.

ISP A will hook into ISW1 (primary ISP should be used at all costs)

ISB B will hook into ISW2

IP SLA is running which points to ISP A, and if that goes down switches to ISP B

Is it possible to do this type of setup?  If so, how would I go about configuring my Routers/Switches with HSRP and routing thenconnect them back to my redundant switches.  Basically each switch would have a path to each HSRP device.  My internet is delivered via Ethernet from TW Telecom so an actual router isn't really necessary.  If anyone could provide a few examples I would greatly appreciate it.

[Jon Marshall]

ngthen@moonark.com
I have two L2 switches that are redundant using spanning tree and I have two ISPs.  I would like to put in 2 switches (we'll call them ISW1 and ISW2) capable of running HSRP as well as IP SLA to achieve the following.
ISW1 and ISW2 are running HSRP with a virtual IP which would be the gateway for all my devices on my redundant switches.
ISP A will hook into ISW1 (primary ISP should be used at all costs)
ISB B will hook into ISW2
IP SLA is running which points to ISP A, and if that goes down switches to ISP B
Is it possible to do this type of setup?  If so, how would I go about configuring my Routers/Switches with HSRP and routing thenconnect them back to my redundant switches.  Basically each switch would have a path to each HSRP device.  My internet is delivered via Ethernet from TW Telecom so an actual router isn't really necessary.  If anyone could provide a few examples I would greatly appreciate it.

It is possible but just a quick question before going into details. Do you need to NAT your internal IP addresses because be aware that only the Catalyst 6500 can do NAT ie. the 3560/3750 switches can't.

Did you have any thoughts on which L3  switches you were going to use ?

Jon

[ngthen]

The switches we are going to use are Catalyst 3550s for the routing/hsrp.  The internal switches are HP 3550yl but I don't plan on routing anything here.  It isn't in the budget to purchase anything newer at this time.  With that said, my ISPs are only 10mb/s each so the 3550s should work just fine.  I don't have any plans for NAT internally on these switches as that is done on my firewalls.

[Jon Marshall]

ngthen@moonark.com
The switches we are going to use are Catalyst 3550s for the routing/hsrp.  The internal switches are HP 3550yl but I don't plan on routing anything here.  It isn't in the budget to purchase anything newer at this time.  With that said, my ISPs are only 10mb/s each so the 3550s should work just fine.  I don't have any plans for NAT internally on these switches as that is done on my firewalls.

So where are the firewalls in relation to the switches and what type firewalls are they ?

Jon

[ngthen]

The firewalls would plug into each 3550 and they are SonicWALL Pro 4100s...I know mismatched equipment   The 3550s do not have to link redundantly to each firewall  ISW1 would be firewall 1 and ISW2 would be firewall 2

[Jon Marshall]

Okay, so just to clarify you would have 2 L2 switches connecting into 2 L3 3550 switches which then connect to the firewalls ? It sounded like you were terminating the ISP links directly into the L3 3550 switches.

Sorry for all the questions but it's important to understand the topology. Also 3550s are more limited in features than 3560/3750 so it may be more difficult.

What feature set are you going to run on the 3550 switches and which IOS version are you running ?

Jon

[ngthen]

I have the latest IOS for the 3550s and they are the EMI switches (c3550-ipservicesk9-mz.122-44.SE6.bin).  So yes just to clearify

ISP1 plugs into SonicWALL 1

ISP2 plugs into SonicWALL 2

3550-1 plugs into SonicWALL 1

3550-2 plugs into SonicWALL 2

L2-1 plugs into 3550-1 & 3550-2

L2-2 plugs into 3005-1 & 3550-2

[Jon Marshall]

ngthen@moonark.com
I have the latest IOS for the 3550s and they are the EMI switches (c3550-ipservicesk9-mz.122-44.SE6.bin).  So yes just to clearify
ISP1 plugs into SonicWALL 1
ISP2 plugs into SonicWALL 2
3550-1 plugs into SonicWALL 1
3550-2 plugs into SonicWALL 2
L2-1 plugs into 3550-1 & 3550-2
L2-2 plugs into 3005-1 & 3550-2

Not that familiar with Sonicwalls, but if you want to use the L3 3550s to choose which sonicwall to go to then for the 3550s to check the ISP you are going to need to allow ICMP requests from the 3550 switches through your Sonicwalls and ICMP replies back to the 3550 switches. Are you okay with this ?

Do the Sonicwalls not have this sort of functionality ?

Jon

[ngthen]

Yup...we actually allow this now for other types of checks

[Jon Marshall]

Well, according to Feature Navigator the 3550 with your release does support route tracking with IP SLA which would be the way to go. You can basically setup your 3550 switches to ping the ISP next-hop (through the sonicwalls), and if the ping works use the sonicwall connected to ISP1, if the ping fails switch the default-route on the 3550 switches to sonicwall connected to ISP2.

Still not entirely sure though as a bit of searching suggests quite a few issues with the 3550 and tracking and some posts suggesting it is not supported. I do have a couple of 3550 switches but would need to upgrade to test so it could be a while if you want me to test it, unless someone else knows for sure whether it works.

Jon

[ngthen]

Is the HSRP portion pretty easy to configure based on the switch setup that I am using?

[Jon Marshall]

ngthen@moonark.com
Is the HSRP portion pretty easy to configure based on the switch setup that I am using? 

Yes the HSRP bit is straightforward without any tracking. Lets say you want to route 3 vlans on the 3550 switches -

vlan 10 = 192.168.5.0/24

vlan 11 = 192.168.6.0/24

vlan 12 = 192.168.7.0/24

Connect your L3 3550 switches together with a L2 trunk link or L2 etherchannel trunk allowing the 3 vlans across

Allocate 3 addresses from each subnet above for the physical and HSRP VIP addresses ie.

SW1

int vlan 10

ip address 192.168.5.2 255.255.255.0

standby 10 ip 192.168.5.1

standby 10 authentication

standby 10 priority 110

standby 10 preempt

SW2

int vlan 10

ip address 192.168.5.3 255.255.255.0

standby 10 ip 192.168.5.1

standby 10 priority 100

standby 10 authentication

and you do this for each vlan ie. vlan 10/11 & 12.

Your clients in vlan 10 would get allocated an IP out of the 192.168.5.x subnet and they would be configured with a default-gateway of 192.168.5.1

Jon

[ngthen]

Ok I see how that is working, now here is the next scenaro which we may use instead (hence I am still in the planning phase)

I have the possibilty of using my procurve 3500yls for all internal routing with VRRP.  Unfortunately they do not support tracking like the Cisco 3550.  Could I do all of the routing there and then use my 3550s to act just as multiport routers still connecting back to the SonicWALLs like before?  If I were to go with this option, would I need to have a common VLAN between the HPs and 3550s which would be what HSRP uses?  So in theory....

The 2 HPs would show a virtual IP address (from VRRP) to the 3550s and the 3550s would show a virtual IP to the HPs from HSRP.  I am going about this completely wrong?  The reason we are thinking the 3500yl for internal routing is that they are gigabit L3s.  However we still have the need for tracking with regards to internet switches.