HSRP and multiple VLANS, sometimes strange behaviour

[p.devalck]

Hello,

in the network in which we are currently involved, there are a multitude of VLANs, most of them also involved in HSRP.

On the routers it seems te me that in a same HSRP group there are different VLANs.

On inspection, the priority of a given HSRP group is not the same for the different VLANs associated with the HSRP group. This means that for some VLANs in an HSRP group router A should be the active router, whereas for other VLANs in the same HSRP group router B should be the active router.

Can anybody confirm or deny that this can cause strange behaviour w.r.t. connectivity and possibly with application throughput ?

Thank you,

[smcquerry]

It sounds like you are describing a typical HSRP load balancing design. For example take the following configuration.

Router A

Interface VLAN 10

ip address 10.1.10.2 255.255.255.0

standby 1 ip 10.1.10.1

standby 1 priority 150

standby 1 preempt

Interface vlan 20

ip address 10.1.20.2 255.255.255.0

standby 1 ip 10.1.20.1

standby 1 priortiy 50

Interface vlan 30

ip address 10.1.30.2 255.255.255.0

standby 1 ip 10.1.30.1

standby 1 priority 150

standby 1 preempt

Router B

Interface VLAN 10

ip address 10.1.10.3 255.255.255.0

standby 1 ip 10.1.10.1

standby 1 priority 50

Interface vlan 20

ip address 10.1.20.3 255.255.255.0

standby 1 ip 10.1.20.1

standby 1 priortiy 150

standby 1 preempt

Interface vlan 30

ip address 10.1.30.3 255.255.255.0

standby 1 ip 10.1.30.1

standby 1 priority 50

This configuration would make Router A active for VLAN's 10 and 30 while Router B is active for VLAN 20.

First lets start with the fact that even though the group number is the same, these are not the same HSRP groups. The group number is significant only to a given broadcast domain (i.e. VLAN) in determining the HSRP MAC address. As long as you do not bridge between the interfaces, this is not an issue. Incidentally on a SUP2 for a 6500 you would want to keep the HSRP group numbers the same due to a hardware limitation of the device.

http://www.cisco.com/en/US/products/hw/switches/ps700/products_qanda_item09186a008011c6bb.shtml

Now you can determine if the proper router is active by using the show standby brief command on each device and you can verify this with a trace from a client device. The address returned should be that of the interface (e.g. 10.1.10.2 or 10.1.10.3) and by looking at this you can determine which device is actually active.

Now for the question. The HSRP design in itself should NOT cause strange behavior, but that's not to say it's not a contributing factor.

For example lets say there is something wrong with router B in particular maybe there is a HW or SW problem affecting performance. Then what you would see is when router B is active the problem occurs, but when router A is active the problem goes away. Here HSRP would contribute to the problem, but not cause the problem.

[p.devalck]

Thank you,

The network consists indeed of 2 core C6500 switches (hybrid mode) with MSFC-SUP2-PFC2.

I thought the HSRP identity limitation (to 16 IDs), forcing us to divide the (100 or so) VLANs over these IDs, might have caused the strange problems (spurious loss of ping requests/replies and possibly real traffic too). The loss of packets however is not predictable.

On top of HSRP, the 2 core C6500 switches also participate in all the spanning tree instances, which are a mix of MST and PVST areas, the latter consisting of catalyst types not supporting MST.

The problems encountered may have to do with asymmetric switching/routing, as the routing between the VLANs in one direction might be on C6500 switch A whereas the return data are router in C6500 switch B, due to the different HSRP active routers.

Your clarification directs me to suspect the combination of spanning tree and HSRP.

Thank you.