03-22-2004 03:15 PM - edited 03-02-2019 02:28 PM
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?
03-22-2004 03:21 PM
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?
03-22-2004 04:15 PM
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.
03-22-2004 04:39 PM
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...
03-22-2004 04:54 PM
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.
03-22-2004 05:11 PM
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.
03-22-2004 05:34 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide