Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

STANDBY-3-DUPADDR not sourced by HSRP process

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?


Re: STANDBY-3-DUPADDR not sourced by HSRP process

Can you paste the error message ?

New Member

Re: STANDBY-3-DUPADDR not sourced by HSRP process

CH-Core#term monit


1w5d: %STANDBY-3-DUPADDR: Duplicate address 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 226 0009.b7d9.0b80 ARPA Port-channel2.3

CH-Core# is the higher-priority physical IP of an HSRP pair 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

Re: STANDBY-3-DUPADDR not sourced by HSRP process

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

New Member

Re: STANDBY-3-DUPADDR not sourced by HSRP process

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.

New Member

Re: STANDBY-3-DUPADDR not sourced by HSRP process

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

Please help


New Member

Re: STANDBY-3-DUPADDR not sourced by HSRP process

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).

New Member

Re: STANDBY-3-DUPADDR not sourced by HSRP process

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.

CreatePlease to create content