IP-4-DUPADDR: Duplicate address Error on MSFC??

[sharma.advait]

I am getting below error on MSFC since last few days

IP-4-DUPADDR: Duplicate address10.2.221.35 on Vlan23, sourced by 0000.0c07.ac0b

Ip Address 10.2.221.35 is HSRP Gate way IP address of Vlan23.

When I check its arp entry I get below result.

sh ip arp | include 0000.0c07.ac0b

Internet  10.2.210.35           187   0000.0c07.ac0b  ARPA   Vlan11

Now again 10.2.210.35 is Vlan11 HSRP IP address which is use as Gateway for Vlan 11.

The mac address of both the gateways are same.

Please kindly help me to resolve the issue.

[Calin C.]

Can you please post the output of the following commands:

show standby vlan 11

show standby vlan 23

Thanks!

[sharma.advait]

sh standby vlan 23

Vlan23 - Group 18

  Local state is Active, priority 110

  Hellotime 3 holdtime 10

  Next hello sent in 00:00:00.036

  Virtual IP address is 10.2.221.35 configured

  Active router is local

  Standby router is 10.2.221.33 expired

  Standby virtual mac address is 0000.0c07.ac12

  11 state changes, last state change 00:00:08

sh standby vlan 11

Vlan11 - Group 11

  Local state is Listen, priority 110

  Hellotime 3 holdtime 10

  Virtual IP address is 10.2.210.35 configured

  Active router is 10.2.210.32 expires in 00:00:09, priority 120

  Standby router is 10.2.210.34 expires in 00:00:07

  3 state changes, last state change 23:02:50

[Calin C.]

I don't know your topology but on Vlan23 you have flaps ongoing:

11 state changes, last state change 00:00:08

I believe at some point both parts that form the HSRP for VLAN23 lose the connection one to each other, and each of them thinks that it is the active one. If you have multiple trunks between this 2 devices, or a topology in which you can run into loops (like a square topology) than you encounter this error.

Human speaking, if both routers think that they are the Active part on HSRP, and in between you have a trunk (or a loop) transporting VLAN 23, then is normal that one router will say, hey there is another router on this segment who's using 10.2.221.35 (even if this address is virtual).

My advice is to check why HSRP on vlan 23 is flapping. Check logs, check if there are flappings on the physical interface that is transporting this vlan23.

Check with sh standby vlan 23 which router is active. If both of them are active...there is your problem. See if you can ping on the vlan23 from one router to the other one.

Let me know how this works for you!

[Giuseppe Larosa]

Hello Advait,

as Calin has noted you probably are facing stability issues in vlan 23.

In this case the message is more an indication of underlying problems at OSI layer2 rather then a problem.

This kind of messages appear at the beginning of a broadcast storm caused by a spanning-tree loop

Hope to help

Giuseppe

[sharma.advait]

This is making some sense now.

I have got 2 MSFC, I have shutdown vlan 23 on MSFC on which I was receiving Duplicate address error. After that there is no vlan flap logs on both MSFC. Before that I was receiving Vlan Flapping Errors on all vlans.

if I enabled vlan 23 on MSFC again I will start receiving same error. Please let me know how can I solve this problem.

There is no physical port flapping errors.

[sharma.advait]

when I am checking sh standby brief

The vlan 23 state is showing active on both MSFC.

[Giuseppe Larosa]

Hello Advait,

two MSFCs

are the two MSFCs in the same C6500 chassis and you are running in dual routing mode DRM or single routing mode?

if the two MSFCs are in different chassis you need to check the path between them for vlan 23: if both claim to be active it means that HSRP hello messages sent to 224.0.0.2 are not received by the other MSFC and viceversa and this means that vlan23 is partititioned in some place.

to be noted that if both MSFCs are in the same chassis the use of HSRP may be not appropriate, this depends on the routing engine redundancy mode.

In DRM both MSFCs are active and each needs to have its own IP addresses on the different Vlans, different IP addresses for loopbacks and so on.

External world knows there are two routing engines.

DRM is not recommended and the recent way to use two MSFCs in same chassis is Single Router Mode: in this case there is a standby MSFC that is isolated from outside world, outside world never knows there two MSFCs in the box only one speaks.

Hope to help

Giuseppe

[sharma.advait]

Both MSFC are in different Core on Different Location.

Please check the attached file.

[Calin C.]

You have there HA configured? If yes, what method for the HA?

[Giuseppe Larosa · Accepted solution]

Hello Advait,

you probably have  two MSFC in chassis1 and  two MSFC in chassis2= 4 MSFC

first node:

Vl23        11  120  P Active   local           10.2.221.34     10.2.221.35

second node:

Vl23        18  105    Active   local           10.2.221.33     10.2.221.35

you are using two different HSRP groups 11 and 18 with the same virtual address 10.2.221.35 this is not correct!

Or you have the same HSRP group on all MSFCs or you associate a different vrtual address to group 18

Clearly first option making a single group including up to 4 MSFCs is the more useful choice.

the 4 MSFCs can have 4 different HSRP priorities for the same group

From your SVI configuration my guess is that you are using DRM the older method to handle MSFC redundancy

POY_MSFC2#sh running-config interface vlan 23

Building configuration...

Current configuration : 362 bytes

!

interface Vlan23

description ***** PSF Segment 1 VLAN *****

ip address 10.2.221.32 255.255.255.0 alt ip address 10.2.221.34 255.255.255.0

ip helper-address 10.2.161.2

ip helper-address 10.2.161.17

no ip redirects

standby 11 priority 120 preempt alt standby 11 priority 115

standby 11 ip 10.2.221.35 alt standby 11 ip 10.2.221.35

hold-queue 125 in

so all 4 MSFCs are alive and connected to outside world

I would suggest to use the same standby group everywhere, only one device will be active, one MSFC will be standby and the other two will be in HSRP listen state.

with SRM you would have only two MSFCs on line and no need to use the alternate command

Hope to help

Giuseppe

[sharma.advait]

After changing standby group I am not getting error on MSFC.