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.
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?
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.
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).
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.
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 ???
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.
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?
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...