ARP entry is missing on the CRB spine despite the presence of type 2 MAC and MAC+IP route
Topology:SPINES: Spine12 Spine13 MX240 (AgentSmith FPC) | \ / | | \ / | | X | | / \ | | / \ | LEAVES: Leaf1 Leaf2 QFX5120 \ / \ / servers Some of the ARP entries are missing on one spine, and some are missing on both spines (most ARP entries corresponding to the MAC+IPs from the same ESI are present on both spines). Below is an example for 192.168.100.100 for which ARP entry is only present on Spine13, but is missing on Spine12: The corresponding Type 2 MAC+IP routes from both leaves are there on both spines:
Spine12-re0> show route table evxlan-vs-tinet-ole-servernet.evpn.0 | match aa:bb:cc:dd:11:ee
2:192.168.92.154:1::1034::aa:bb:cc:dd:11:ee/304 MAC/IP
2:192.168.92.155:1::1034::aa:bb:cc:dd:11:ee/304 MAC/IP
2:192.168.92.154:1::1034::aa:bb:cc:dd:11:ee::192.168.100.100/304 MAC/IP
2:192.168.92.155:1::1034::aa:bb:cc:dd:11:ee::192.168.100.100/304 MAC/IP
Spine13-re0> show route table evxlan-vs-tinet-ole-servernet.evpn.0 | match aa:bb:cc:dd:11:ee
The entries in the mac-table look the same on both Spine12 and Spine13:
Spine12-re0> show bridge mac-table instance evxlan-vs-tinet-ole-servernet aa:bb:cc:dd:11:ee extensive
MAC address: aa:bb:cc:dd:11:ee
Routing instance: evxlan-vs-tinet-ole-servernet
Bridging domain: bd34, VLAN : 34
Learning interface: esi.3680
MAC MAC Logical NH MAC active
address flags interface Index property source
01:01:00:00:00:00:02:00:08:00
ELP-NH: 0
Base learning interface: esi.3680
Layer 2 flags: in_hash,in_ifd,in_ifl,in_vlan,in_rtt,kernel,in_ifbd,ctrl_dyn,esi_mac,rcvd_from_remote
Epoch: 0 Sequence number: 0
Learning mask: 0x4000000000000000030000000000000000000000
Spine13-re0> show bridge mac-table instance evxlan-vs-tinet-ole-servernet aa:bb:cc:dd:11:ee extensive
Learning interface: esi.2709
Base learning interface: esi.2709
But the below output is not empty only on Spine13:
Spine12-re0> show bridge mac-ip-table instance evxlan-vs-tinet-ole-servernet aa:bb:cc:dd:11:ee extensive
// EMPTY
Spine13-re0> show bridge mac-ip-table instance evxlan-vs-tinet-ole-servernet aa:bb:cc:dd:11:ee extensive
IP address: 192.168.100.100
Bridging domain: bd34
Logical interface: esi.2709
IP MAC Flags Logical Active
address address Interface source
MAC-IP local mask: 0x0000000000000000
MAC-IP remote mask: 0x0000000000000003
MAC-IP remote-proxy mask: 0x0000000000000000
MAC-IP RPD flags: 0x08000081
MAC-IP flags: remote,kernel,dest_route
The ARP entry is only present on Spine13:
Spine13-re0> show arp interface irb.1034
MAC Address Address Name Interface Flags
..
aa:bb:cc:dd:11:ee 192.168.100.100 192.168.100.100 irb.1034 [.local..7] permanent remote
EVPN-VXLAN CRB solution - needs proxy-macip-advertisiment configuration at IRB level.
In an EVPN-VXLAN centrally-routed bridging (CRB) overlay, spine devices typically function as L3 VXLAN gateways, and leaf devices typically function as L2 gateways. In this overlay network, the L2 VXLAN gateways can advertise only the EVPN Type 2 MAC routes for the attached hosts. Because the L2 gateways are unable to resolve the MAC-IP bindings for the hosts, each of the L3 gateways rely on the Address Resolution Protocol (ARP) and the Neighbour Discovery Protocol (NDP) to discover and install the bindings.
With the proxy-macip-advertisement setting, the L3 gateway device manages learning and aging for the ARP and NDP entries. By default, the L3 gateway does not refresh the ARP and NDP entries. As a result, the MAC-IP bindings on the spine devices expire after a timeout interval. Upon receiving the next IPv4 or IPv6 packet after the MAC-IP entry expires, the spine devices try to resolve the MAC-IP binding again using ARP (for IPv4 packets) or NDP (for IPv6 packets). The spine device might drop traffic until it records the new MAC-IP binding.
proxy-macip-advertisement
Please refer to the documents below, which explain the proxy-macip-advertisement knob detail:
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/proxy-macip-advertisement-edit-interfaces.html