Excessive %ARP-3-DUP_VADDR_SRC_IP: arp [4769] log-entries

[Ulrich Hansen]

Hi,

I'm looking into a problem, which involves excessive logentries containing the message below:

%ARP-3-DUP_VADDR_SRC_IP:  arp [4769]  Source address of packet received from 0000.0c07.ac00 on Vlan814(port-channel4095) is duplicate of local virtual ip, 10.10.215.1

The attached drawing shows the topology between the distribution-switches and the OTV-AED's.

The logentry repeats itself every 10 seconds, and is only seen on the Root-Bridge. The other distributionswitch is unaffected by this. The behaviour itself doesn't seem to pose any stress on the N7K, as generel forwarding and day-to-day operation is not affected in any way. However, periodic spikes in CPU are recorded, with NetStack and STP being the top-talkers. The overall stp-topology is stable, when taking a detailed look in the various vlans. TC-notifications are rarely seen and usually only when we would expect to see them.

I've gone through releasenotes for v5.2 and tried to find something with the BugToolKit, but so far no luck. I've found various posting on the net, with others having similar issues, only theese very mostly related specifictly to Hsrp. So far, I've been unable to find any incident related to OTV.

I'm only seeing this behaviour for vlans extended across OTV. All OTV-AED's have the required filtering in place, prohibiting the learning and/or advertising of fhrp information, both at L2 and L3. The filtering works, since we've successfully managed to isolate Hsrp at the two sites. There's nothing to suggest occasional split-brain scenarios, Hsrp is stable and working as expected. Futhermore, we're not seeing this issue on any other vlans not extended across OTV. Nor are we seeing theese logentries recorded on any other Port-channels than thoose connecting the OTV-edge devices to their parentswitches.

The configured vlan-filter on the OTV devices are as listed below:

mac access-list OTV-BLOCK-L2

  10 remark * HSRPv1 and HSRPv2 *

  11 permit any 0000.0c07.ac00 ffff.ffff.ff00

  12 permit any 0000.0c9f.f000 ffff.ffff.f000

  20 remark * VRRP *

  21 permit any 0000.5e00.0100 ffff.ffff.ff00

  30 remark * GLBP *

  31 permit any 0007.b400.0000 ffff.ff00.0000

ip access-list OTV-BLOCK-L3

  10 remark * HSRPv1 and HSRPv2 *

  11 permit udp any 224.0.0.2/32 eq 1985

  12 permit udp any 224.0.0.102/32 eq 1985

  20 remark * VRRP *

  21 permit 112 any 224.0.0.18/32

  30 remark * GLBP *

  31 permit udp any 224.0.0.102/32 eq 3222

mac access-list OTV-FORWD-L2

  10 remark * Everything else *

  11 permit any any

ip access-list OTV-FORWD-L3

  10 remark * Everything else *

  11 permit ip any any

  12 permit icmp any any

vlan access-map OTV-BLOCK 10

        match mac address OTV-BLOCK-L2

        action drop

        statistics per-entry

vlan access-map OTV-BLOCK 20

        match ip address OTV-BLOCK-L3

        action drop

        statistics per-entry

vlan access-map OTV-BLOCK 90

        match mac address OTV-FORWD-L2

        action forward

        statistics per-entry

vlan access-map OTV-BLOCK 91

        match ip address OTV-FORWD-L3

        action forward

        statistics per-entry

vlan filter OTV-BLOCK vlan-list 814-817,2020

Interestingly, the OTV aed does have the hsrp-mac in its CAM-table, though I would expect the above filter to drop that.

So far, the only valid conclusions I have come to is either a STP-issue or somehow, the above filter is not programmed correctly into the hardware and thus not processed correctly.

Any thoughts will do.

Thanks

/Ulrich

[bonestorm]

Hi Ulrich,

I had the same issue in my environment.  I have two 7ks at each of two sites, so four in total.  These 7ks are split into two VDCs - one for the M1 card, and the second for the F2 card.  The data centre SVIs live on the F2 VDC.  OTV is running on the M1 VDC.

After changing the vPC peer-link from one port channel to another on the F2 card I got the duplicate address error. Since I am not yet in production I was able to try a number of different things to make the error go away. 

What I eventually found was that shutting the overlay interfaces at one of the sites, then un-shutting them fixed the issue.  Not such a good fix whilst in production!

I don't have anything to advise on why this happens, but regardless, this is one possible fix.

Mark

[Ulrich Hansen]

Hi Mark,

I'll give it a try and see what happens.

Thanks for replying.

/Ulrich

[Ulrich Hansen]

Well,

As it seems, an ARP-filter did the trick. Applied the following filter on the OTV-Edge devices, which seem to have solved the problem:

arp access-list HSRP_VMAC_ARP

  10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00

  20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000

ip arp inspection filter HSRP_VMAC_ARP vlan [vlan-list]

/Ulrich

[bonestorm · Accepted solution]

Hi Ulrich,

An update from my end.  I found a command that can be added to the SVI to suppress this error.  It is :

     no ip arp gratuitous hsrp duplicate

See this link:

https://supportforums.cisco.com/thread/2136520

I have tried it in our environment and it works fine.  Might be easier than configuring arp filters.

Mark