cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1072
Views
0
Helpful
6
Replies

HSRP duplicate address

Hello,

I have normal HSRP configuration.

On first core switch

!

interface Vlan8

ip address 110.120.180.252 255.255.252.0

ip access-group traffic_11 in

ip helper-address 110.120.130.230

standby 1 ip 110.120.180.254

standby 1 priority 110

standby 1 preempt

end

On second core switch

!

interface Vlan8

ip address 110.120.180.253 255.255.252.0

ip access-group traffic_11 in

ip helper-address 110.120.130.230

standby 1 ip 110.120.180.254

standby 1 priority 90

end

I am getting duplicate address log in both switches, I observed - every time conflicting MAC address is diff.

I know that duplicate add is typical problem of HSRP, but how to solve it permanently?

6 Replies 6

sstudsdahl
Level 4
Level 4

If you do a "show standby brief" do you see both routers as active or one active and one standby? If both are active, do your ACL's allow the HSRP packets to pass?

hello,

Its showing no problem in standby brief.

Core switch 1 - sh standby brief shows-

Interface Vl8

Grp 1

Prio 110

P P

State Active

Active addr local (110.120.180.252)

Standby addr 110.120.180.253

Group addr 110.120.180.254

core switch 2 - sh standby brief shows -

Interface Vl8

Grp 1

Prio 90

P

State Standby

Active addr 110.120.180.252

Standby addr Local (110.120.180.253)

Group addr 110.120.180.254

ACL allows HSRP traffic.

hi,

Are you receiving the error message similar as below ? However, for my case the mac-address reported are from the same source...

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

Feb 3 14:40:15.445 CCT: %STANDBY-3-DUPADDR: Duplicate address 10.99.10.4 on Vla

n40, sourced by 0000.0c07.ac00

Feb 3 14:40:47.826 CCT: %STANDBY-3-DUPADDR: Duplicate address 10.99.10.4 on Vla

n40, sourced by 0000.0c07.ac00

Feb 3 14:41:19.822 CCT: %STANDBY-3-DUPADDR: Duplicate address 10.99.10.4 on Vla

n40, sourced by 0000.0c07.ac00

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

Solved it. Problem is due to config error. I accidentally configured both the active address to be the same ip address on both switch.

Maybe you may want to check your other vlan config besides vlan 8, to see if there is any duplicate in ip address ?

Hope this helps...

You probably have read this info:

"These error messages do not necessarily indicate an HSRP problem. Rather, the error messages indicate a possible Spanning Tree Protocol (STP) loop or router/switch configuration issue. The error messages are just symptoms of another problem.

In addition, these error messages do not prevent HSRP from operating correctly. The duplicate HSRP packet is ignored. These error messages are throttled at 30 second intervals. Network slow performance and packet loss, however, may result from the network instability that is causing the STANDBY-3-DUPADDR error messages of the HSRP address."

from the following link:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#t20

With a pair of Catalyst 3550 switches, we were able to reproduce this error message. The cause was an Etherchannel misconfiguration on one of the switches. You might want to look into this if it applies to your setup.

Hello,

Yes, here also I am using 3550 switch in stacks and I am getting conflicted MAC address apart from HSRP standerd one.

Plz tell me more about Etherchannel config, what problem it may have in it?

In STP issue I have manualy provided the bridge priority on core switches (16384) and access switches are on default bridge priority 32768.

I can't remember the exact process on how we did it but I think it was during the etherchannel mode configuration or the interface port-channel configuration. I also noticed that after you have connected the corresponding ports on both switches (and the link is up), then you configure etherchannel, the error message pops up. So what we did was:

1. Remove all etherchannel configurations on both switches.

2. Shutdown the etherchannel ports on both switches.

3. Re-configured etherchannel.

4. Re-enable the ports.

After doing this we did not see the error message anymore. Of course you should not try this is on a live

network. We did it on our lab. More importantly, we did follow the etherchannel configuration guidelines:

http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12119ea1/3550scg/swethchl.htm#1021856

Hope this helps.