HSRP and SSO on VSS

[Thompso7540_2]

we have two 6509e's running VSS and SSO, single sup's in each 6k - we are running hrsp but w/ onl one switch as active, meaning there is just one vss cluster that's active, so there is no standby peer

had to initiate sso event in order to re-seat the active sup - we notice when we initiated redundancy force-switchover we had a blip to some connectivity behind the VSS - although the standby sup came up right away during the SSO event

we are wondering if HSRP could have taken time to go through listen->speak>active states even though the SSO worked properly - has anyone seen SSO perform normally but still have a blip related to HSRP? What are the rules w/ HSRP on VSS during SSO?

[Reza Sharifi]

Bryan,

One of the benefits of VSS is that you do not  need to run HSRP/VRRP, etc... any more.  The 2 6500 devices are logically one and when one is down the other one takes over without any packet loss at all, so HSRP/VRRP does not server any purpose when you are running VSS.

HTH

Reza

[Nathan Spitzer]

If you think about it of course there is no HSRP peer as there is only one LOGICAL router in a VSS cluster. If there is only one router how can there be a peer? When you create a VSS cluster you are creating a single logical routing entity out of two separate physical boxes. You gain all the redunadancy of the physical boxes but logically they are combined so are managed, accessed, and viewed from a layer2 and layer 3 perspectives as a single unit.

According to the 6500 configuration guide NSF should have kept traffic flowing but during an SSO event EIGRP and OSPF peering relationships DO flap so that may have been the blip you saw.

You may also want to read the following documents:

VSS enabled Campus design guide: http://www.cisco.com/en/US/partner/docs/solutions/Enterprise/Campus/VSS30dg/VSS-dg_ch1.html

Nathan Spitzer

Sr. Network Communication Analyst

Lockheed Martin

[Thompso7540_2]

ok - so i guess there is no answer to my question - we intiated an SSO event, but we had graceful restart enabled in bgp.

i don't think NSF really has anythign to do w/ HSRP

[Nathan Spitzer]

As I understood it your question was about HSRP, and it would not have gone throught the negotiation process since the routing entity (the VSS) cluster never reset. However I am confused because you said you initiated an SSO event but in your initial post state that you only have a single supervisor per switch. I am in the process of setting up my first of three clusters so I havent tested it but if it works as I understand it one of your chassis would have gone offline until the old active supervisor booted up. That means that spanning tree could have also caused a topology change resulting in a blip, depending on whether you are runnign PVST+, RPVST+, or MST.

Graceful restart is not applicable AFAIK to an SSO event. When you initiate an SSO event all the routing processes will have to re-establish neighbor relationships. EIGRP, OSPF, and BGP peering do NOT maintain state between redundant supervisors.However NSF, if properly implemented, allows traffic to still flow on the theory that if flow x used interface Gi1/1 10ms ago, there is a 99% chance that it will use gi1/1 the next packet. If NSF is not properly implemented then when SSO kicks in your BGP peering will go down and take some relatively long (being BGP) amount of time to re-peer and you will have a noticable blip.

In a VSS scenerio (or any other scenerio) HSRP will only delay things by some time while HSRP flips over.

Nathan Spitzer

Sr. Network Communications Analyst

Lockheed Martin