HSRP Group Number causing connectivity issue

[astanislaus]

I haven't got all the details as yet, but a customer is saying that if he uses a certaing HSRP group number (say for argument number 16) he has intermittent IP connectivity - i.e. Intermittent Ping Packet drops. If he just changes the group number to any any other number - 64 for example there is no problem at all. No IP packet drops at all.

Question:

==========

Is it possible that Group Number of 16 which translates to a MAC Address of 00-00-0c-07-ac-10 may have an "Evil Twin" MAC address in their network, but if he uses another group number it will translate to another MAC address and hence has no problem?

Troubleshooting tip:

=====================

I told him to not configure the problem group number 16 and look at the CAM table of his two CAT 6500 and see if there is a MAC address of 00-00-0c-07-ac-10. If there is then we know we have an "Evil Twin" - Inglebert.

[astanislaus]

I got a bit more information now. It is not a particluar group number that is causing packet drop problem as I explained in my previous entry. So teh fault description has changed:

Fault description now is:

=========================

If the same HSRP group number is configured on different VLANs customer has intermittent packet drop problems. About 50% of the packets will get through and 50% won't when a PC in one VLANs pings another PC in a different VLAN.

For example if we use the same HSRP group number 1 on VLAN 4 and VLAN 5 then we have packet drop problem.

See attached diagram and explanation in those diagrams.

Now, reading a few articles about using same group number in different VLANs (i.e. different bridge groups) I found the following information:

In the Cat6500 IOS documentation there is the following about standby using the bia (burned in address).

http://www.cisco.com/en/US/products/hw/switches/ps708/products_command_reference_chapter09186a00801eaed9.html#wp1066949

There is also a note "identically numbered HSRP groups use the same virtual MAC address, which might cause errors if you configure bridge groups".

=============================================

I don't think using standby bia will help based on the following statements. (taken from http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a0080093f93.shtml)

Note: Using the standby use-bia command has the following disadvantages:

* When a router becomes Active the virtual IP address is moved to a different MAC address. The newly Active router sends a gratuitous Address Resolution Protocol (ARP) response, but not all host implementations handle the gratuitous ARP correctly.

* Proxy ARP breaks when standby use-bia is configured. A standby router can not cover for the lost proxy ARP database of the failed router.

* Due to internal limitations, the standby use-bia command is not supported on the Multilayer Switch Feature Card 2 (MSFC2). For more information, refer to the Configuration Guidelines and Restrictions section of Configuring IP Unicast Layer 3 Switching on Supervisor Engine 2.

============================================

HSRP V2 would fix lots of the problems as it supports 4096 standby groups.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d2d21.html but it is not supported as yet on the Cat6500.

[glen.grant]

Have never heard of anything like that . We have like 80 vlans all using the same hsrp group number #1 without a problem and it is very stable. Possible you have a dup address on one side or the other ???

[astanislaus]

Got a bit more information from customer as follows:

============================================

The trunk link between the two CAT 6500 is not a straight piece of wire as was first explained to me. That link goes through via another couple of switches that do dot1Q in dot1Q tunnelling. It is then when the HSRP group numbers on VLAN 4 and VLAN 5 have to be unique and not duplicated. If it is a straight piece of wire for the trunk link between the two CAT 6500 there is no problem. Customer only told me this after I said to him that I cannot simulate the problem in my lab with a straight piece of wire for the trunk link.

[astanislaus]

Customer has agreed to change the HSRP group number when using QinQ Tunneling just as a workaround. He is not willing to accept this as a fix. We are Service Partners for Cisco and customer is saying raise a TAC case. I cannot see this as a problem wanting a TAC case and I think changing the group number should be taken as a fix. Any thoughts or other suggestions?

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm#xtocid122333

says to use a different group number.

[cjnwodo]

Hi,

As best practice, I always use a different HSRP group id. I use the VLAN id as the HSRP id and I also use the VLAN id and some extra characters as the HSRP password. This way there is no layer 2 'funnies'. The HSRP group mac addresses for each HSRP group is unique and the password also ensures that if someone else mistakingly used the same HSRP group id as myself, my routers will reject their HSRP messages because the passwords will not match.