Nexus 5000 peer has incomplete arp entries despite vpc domain ip arp synchronisation

[p.devalck]

ip arp difference between both nexus routers (Nexus 56128) despite arp synchronisation in the vpc domain.

One marks the arp entry as incomplete whereas the other nexus arp table contains the correct mac address.

Any suggestions where this can come from (and how to remedy it) ?

Thank you

Paul De Valck

----------------------------

arp table extract from router DR1

10.116.254.136 00:00:45 506b.8d61.df18 Vlan993
10.116.254.137 00:00:01 INCOMPLETE Vlan993
10.116.254.140 00:04:36 506b.8d15.a06e Vlan993

arp table extract from router DR2

10.116.254.136 00:14:32 506b.8d61.df18 Vlan993
10.116.254.137 00:18:38 506b.8d67.e1fa Vlan993
10.116.254.140 00:14:32 506b.8d15.a06e Vlan993

------- configuration in both routers DR1 and DR2 -------

feature telnet
feature vrrp
cfs ipv4 mcast-address 239.255.1.1
cfs ipv4 distribute
cfs eth distribute
feature ospf
feature interface-vlan
feature lacp
feature vpc
feature lldp
feature vtp
feature fex

ip access-list routerbeheer
1 remark keep-alive tussen beide datacenter routers
2 permit ip 10.192.255.0/29 any
10 remark toegelaten vanaf beheersubnets
20 permit ip 10.32.1.0/24 any
30 permit ip 10.192.1.0/24 any

vrf context management
ip route 0.0.0.0/0 10.192.255.6
vpc domain 1
role priority 1024
system-priority 1024
peer-keepalive destination 10.192.255.2 source 10.192.255.1
delay restore 150
ip arp synchronize 

interface port-channel999
description Peer link DR1-DR2
switchport mode trunk
spanning-tree port type network
speed 40000
vpc peer-link

interface Ethernet1/52
description ANT-DR1-DR2 peering
switchport mode trunk
channel-group 999
no shutdown

interface Ethernet2/26
description ANT-DR1-DR2 peering
switchport mode trunk
channel-group 999
no shutdown

interface mgmt0
ip access-group routerbeheer in
vrf member management
ip address 10.192.255.1/29 (router DR1)
ip address 10.192.255.2/29 (router DR2)

[p.devalck]

Additional information :
In the ip arp list, there are no flags such as * (Adjacencies learnt on non-active FHRP router) or + (Adjacencies synced via CFSoE)
Would this indicate that some additional feature is needed for either CFSoE or learning on non-active FHRP router ?

Paul De Valck

[p.devalck · Accepted solution]

Possible cause identified.
First Hop Redundancy Protocol VRRP was defined on both routers where on one of them the real and virtual IP-address was the same.
Maybe on this router the source MAC-address of the arp request was the virtual MAC-address.
Equipment with primary connection on the other router react, but the other router considers the (return) virtual MAC-address as to be processed locally, and therefore does not pass on the arp reply to the router where real and virtual IP-address are the same.
My solution would be to make sure that the virtual IP-address of a FHRP is not used as an interface IP-address.

So far it appears that the problems have disappeared.