STANDBY-3-DUPADDR not sourced by HSRP process

[schm196]

I have a pretty standard HSRP setup and can't get rid of one final problem: One of my 4908G-L3 switches keeps reporting it's own active IP address in an HSRP group as duplicate but it is not sourced by the MAC address associated with the HSRP process (as indicated in Cisco's troubleshooting documents). Rather, the source is one of my 3550-48 switches that is attached to the core through a distribution layer of 3508G switches. I have verified all core layer configurations; no such thing as a duplicate IP address. I also think that I have thoroughly configured and checked all STP settings on all distribution and access layer switches; still no improvement. Any ideas where else I can look or what I might have overlooked?

[thisisshanky]

Can you paste the error message ?

[schm196]

CH-Core#term monit

CH-Core#

1w5d: %STANDBY-3-DUPADDR: Duplicate address 192.168.103.252 on Port-channel2.3, sourced by 0009.b7d9.0b80

CH-Core#term no monit

CH-Core#sh ip arp 0009.b7d9.0b80

Protocol Address Age (min) Hardware Addr Type Interface

Internet 192.168.103.21 226 0009.b7d9.0b80 ARPA Port-channel2.3

CH-Core#

192.168.103.252 is the higher-priority physical IP of an HSRP pair

192.168.103.21 is that 3550-48 switch with SMI

Port-channel 2.3 is the management VLAN interface of the core router to the distribution layer 3508G switches

[thisisshanky]

You can check out this link and see the Case Study 1 and find if you can troubleshoot.

http://www.cisco.com/warp/public/473/62.shtml

[schm196]

I already did. Note that this case is based on the observation that the layer 3 device receives its own HSRP hellos back on the same interface, as indicated by the source MAC address of 0000.0c07.ac19 (well-known HSRP). This is *not* the case in my situation - I receive a duplicate IP address report from a "real" third device (note the different sourced-by MAC address in my error message), which is the 3550-48 switch. How does this make it different? Thanks for your efforts; I appreciate your responses.

[londint]

I'd really like an answer to this, as I have asked this question before, but did not get a precise answer.

Please help

Thanks

[schm196]

Versions as someone requested via e-mail:

Core routers (4908G-L3):

IOS (tm) L3 Switch/Router Software (CAT2948G-IN-M), Version 12.0(18)W5(22b) RELEASE SOFTWARE

Distribution switches (3508G):

IOS (tm) C3500XL Software (C3500XL-C3H2S-M), Version 12.0(5)WC3b, RELEASE SOFTWARE (fc1)

Access switches (3550):

IOS (tm) C3550 Software (C3550-I9Q3L2-M), Version 12.1(8)EA1c, RELEASE SOFTWARE (fc1)

Please note that we have three 4908G-L3 switches at diffrent locations as a Layer 3 core with full equipment and path redundancy, whereas both our distribution and access layers are Layer 2 only (still full equipment and path redundancy at distribution layer). While Cisco normally favors layer 3 functionality at the distribution and access layers these days, this is one of their sugegsted designs for extremely scalable and high-performance backbones as outlined in one of their design documents (can't find it on the new web site right now).

[schm196]

The problem has been resolved with the help of Cisco TAC. They traced it back to a bug in the IOS release initially delivered with my new 3550 switches (SMI). After upgrading all my 3550-series switches in the access layer to IOS (tm) C3550 Software (C3550-I9Q3L2-M), Version 12.1(11)EA1, the problem disappeared.