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
