cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3260
Views
0
Helpful
25
Replies

VSS -vs- HSRP with 4510R+E SUP8-E

iatsenbf417
Level 1
Level 1

Greetings,

We recently purchased two identical WS-C4510R+E switches (to replace our single), each with dual WS-X45-SUP8-E Supervisors. This is NOT a tired network design. All PCs, Phones, Servers, Storage, etc. will be plugged directly into these switches, essentially making them Access, Distribution and Core, all in one.

I'm planning to configure inter-vlan routing on the switches,and move away from our current router-on-a-stick config on our checkpoint firewall and was initially planning to set up HSRP between the switches, using our eight 10Gb Ethernet cables.

But, I just found out our switches will support VSS, which I guess could replace the HSRP config altogether and now I'm left wondering which way to go.

If I have two SUPs in each switch, does that mean I would have a Quad-SUP setup? From what I'm reading, it almost seems like there may be limitations setting up VSS on two 4510s this way.

Given the details above, can someone please tell me which is better to use in my scenario?

Thanks very much, in advance.

Equipment: Two 4510R+E's with Redundant SUP 8-E's, connecting to a single (for now) Checkpoint firewall.

IOS: 03.06.03.E

ROM: 15.1(1r)SG4

IOS-XE 

License Level: ipbase

25 Replies 25

shillings
Level 4
Level 4

VSS Quad-Supervisor Stateful Switchover (VS4O) with sub-second recovery is not available on the 4500 Series.

So I think you need 3.8 IOS-XE to support in-chassis standby supervisor in RPR mode:

3.8 IOS-XE Release Notes

However, I've got no idea how well it works and whether or not it's actually worth the additional complexity and risk of something breaking. Sometimes it's best to keep things simple and there's nothing wrong with HSRP. If you were only connecting single homed endpoints then you'd achieve very little benefit by enabling VSS. However, if it's possible to dual-home your servers across the two switches and you very much want to load balance the server traffic then VSS might be worthwhile.

Honestly, with dual sups, if you lost both or both PS, you likely lost the chassis; so, VSS and or HSRP did you no good.  You are more likely to have a board connecting your users if it drives PoE than both SUPs or PS anyway.  If you are worried about uptime, lowering your density of users to blades / diversifying users across blades would be more effective that another chassis for your small user population.  Just my two cents on saving a poop ton of cents

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

As Shilling has already noted, you should only really consider VSS if you intend to dual home.  Not sure about VSS on 4500s, but on 6x00s you want to dual home everything.  This to avoid using the VSL path except in the case of some failure.

As an alternative to VSS or HSRP, do you really need to extend VLANs across the two 4500s?  If not, run each as an independent L3 device.  (For redundancy, you note you have dual sups, and for hosts, you could dual home to different line cards.  The only extra redundancy that VSS offers is for the chassis, which don't fail that often.)

Not sure about VSS on 4500s, but on 6x00s you want to dual home everything.  This to avoid using the VSL path except in the case of some failure.

Good point. I should have mentioned that. It's not best practice to single-home to a VSS pair and since your terminating endpoints then I think you're best advised to keep to independent chassis.

Thank you for the responses. I've uploaded a diagram to show how my users will connect.

Referencing my diagram, if Host 3 needs to get to the internet, they packets would go to Switch-2, then over the Ether-channel to Switch-1, then to the Checkpoint firewall, and up to the ISP.

If the users are connecting directly to both of the switches, and there's only a single connection to the Checkpoint from Switch-1, wouldn't it make sense to have a routing protocol such as HSRP running, with users connecting to a virtual IP? Or...set up VSS?

VSS would give you very little here if the end devices are connecting directly to the 4500s.

If you did use VSS then as Joe notes a lot of traffic would have to go via the VSL which is not really what you want.

However if the devices really do connect directly to the 4500s then HSRP gives you nothing either because if the switch fails then the devices connected to that switch lose connectivity regardless of the fact you have moved the VIP to the other switch.

You can run it if you want so that all traffic goes via one switch but it is not really giving you redundancy.

You are really relying purely on your supervisors for any redundancy but that does not protect against a chassis failure or specific modules within the chassis that clients connect to.

This is generally why clients connect to access switches so they have alternate paths to the distribution switches.

Jon

Thanks, Jon.

Unfortunately, the diagram is correct. There are no access switches and the users are connecting directly to one 4500, or the other, which will perform inter-vlan routing, with a single connection to the ISP through a Checkpoint firewall. I asked for access switches, and I was told it was unnecessary for our environment, and to work with this. We are currently running a single 4500 for the past 10 years, which has never failed, so management is not that concerned about one of the 4500's going down...especially with dual supervisors in each switch.

With approximately 100 users, half the users will connect to Switch-1 and the other half will connect to Switch-2. Wouldn't it make sense to at least run HSRP on the 4500's so regardless of the switch they're connected to, the users will always have the same default gateway configured via DHCP (10.1.1.1, for example), which would be the virtual IP for that subnet, while the actual IP for Switch-1 would be 10.1.1.2 and Switch-2 would be 10.1.1.3?

Thanks.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Yes, I can understand why you would want dual connected hosts to avoid transiting switch 2, but when you work with L2 technologies, it gets a bit involved.

If using VSS, normally dual homed hosts run Etherchannel, and from the host's perspective, Etherchannel won't know what switch the firewall is connected to, so traffic has a 50/50 chance of taking an extra hop.  (BTW, this is one reason VSS likes to have everything dual connected.)

If using HSRP, you dual connected host would likely create a bridge between the two switches, and if it does, STP will break the loop, usually one of the links to the host, so unless you "tune" STP, your link to switch 1 might be blocked, and if not, any traffic that needs to go to switch 2 now needs to transit switch 1.

If you hosts supported routed connections to both switch 1 and 2, then they could be configured to prefer the shortest path to specific destination networks.

Of course, an important question, with 10g links between the two 4500s, really how much of an issue is jumping through an "extra" 4500 hop?

Understand/appreciate the purpose of these technologies, so you can distinguish between what might be done and what should be done.

HSRP is great when working with L2 switch(es) and separate routers.  You have L3 switches.

VSS is great when working with L2 hosts, that have Etherchannel, and need the best possible redundancy (again, provides chassis redundancy, although also adds a new point of failure, the OS that controls the VSS pair).

If you network is mostly like your drawing, running each 4500 as standalone L3 will work fine and if you really need to extend some VLANs across both 4500s, that can be done concurrently via L2 using HSRP/GLBP.

Thanks, Joseph.

Yes, it is exactly like my drawing.

Each 4500 has two 48-port POE modules, giving us a total of 96 ports per switch. So, the user PCs will be daisy-chained through their phones and plugged into a single POE port on one 4500 switch, or the other. Therefore, we need to divide the connections, roughly in half, between the two switches. So, if they're connected to switch-2 and need to get to the internet, wouldn't the traffic have to run over the 10Gb links to switch-1, since switch-1 is the one connected to the firewall? The same thing would apply to a server that is connected to the other switch.

My main concern is that the firewall is only connected to Sw1. If that switch fails then all users will lose Internet access. I think you should help better protect users connected to Sw2. 

You could implement a stacked pair of L3 switches to form a small network services block. The firewall would require two uplinks to the stack, one to each member. The two uplinks would form a single LACP bundle at layer-2 and a single routed P2P link at layer-3. Therefore, the firewall still has a single 'inside' L3 interface for ease of configuration and management.

You'd then need to form a triangulated routed network between the 3 nodes, i.e. 2 x 4500E and 1 x switch stack. This would also negate the need for Sw2 traffic to traverse across to Sw1 in order to reach the Internet. 

Just an idea. And there might be better ways of achieving the same goal.

I'm having a bit of a hard time picturing that. Is there any way you could provide a reference?

Thanks.

Easier to knock up on visio than try to find something similar.

iatsenbf417
Level 1
Level 1

I managed to successfully set up VSS on the 4510R+E switches last night so I could see it in action and in a quad-sup config, the standby supervisors for each switch are now in rommon, with one active sup on switch-1, and a standby sup on switch-2. I guess I'm wondering what this means to me, if one of the supervisors goes down.

I just want to know which way to go before putting all the time into the rest of the switches' configuration, especially if I have to tear down the VSS connection.

Here are a couple of verification outputs for VSS:

CORE-1#show switch virtual

Executing the command on VSS member switch role = VSS Active, id = 1


Switch mode : Virtual Switch
Virtual switch domain number : 1
Local switch number : 1
Local switch operational role: Virtual Switch Active
Peer switch number : 2
Peer switch operational role : Virtual Switch Standby

Executing the command on VSS member switch role = VSS Standby, id = 2


Switch mode : Virtual Switch
Virtual switch domain number : 1
Local switch number : 2
Local switch operational role: Virtual Switch Standby
Peer switch number : 1
Peer switch operational role : Virtual Switch Active

CORE-1#show switch virtual redundancy

Executing the command on VSS member switch role = VSS Active, id = 1


My Switch Id = 1
Peer Switch Id = 2
Last switchover reason = none
Configured Redundancy Mode = Stateful Switchover
Operating Redundancy Mode = Stateful Switchover

Switch 1 Slot 5 Processor Information :
-----------------------------------------------
Current Software state = ACTIVE
Image Version = Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500es8-UNIVERSALK9-M), Version 15.2(2)E3, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Wed 26-Aug-15 20:41 by prod_rel_team
BOOT =
Configuration register = 0x2101
Fabric State = ACTIVE
Control Plane State = ACTIVE

Switch 2 Slot 5 Processor Information :
-----------------------------------------------
Current Software state = STANDBY HOT (switchover target)
Image Version = Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500es8-UNIVERSALK9-M), Version 15.2(2)E3, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Wed 26-Aug-15 20:41 by
BOOT =
Configuration register = 0x2101
Fabric State = ACTIVE
Control Plane State = STANDBY


Executing the command on VSS member switch role = VSS Standby, id = 2

show virtual switch redundancy is not supported on the standby

QUAD SUPERVISOR STATUS:

Access-Server#connect CORE1-MOD5
CORE-1#

Access-Server#connect CORE1-MOD6
rommon 1 >

Access-Server#connect CORE2-MOD5
CORE-1-standby>

Access-Server#connect CORE2-MOD6
rommon 0 >

We will not be getting any other switches. I am just working with the two 4510R+E's and a single connection from Switch-1 to the Checkpoint firewall.

But...I was just informed that we are planning to get two new Checkpoint firewalls to replace the existing one. And...the existing firewall has an additional LAN port.

Does this change things at all for this discussion, regarding VSS and HSRP?

I would prefer to set everything up now, prior to putting these switches in production and having them ready for when the new firewalls come.

Thanks so much for all the responses.

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: