[EX/QFX] Unwanted ARP cache update by unicast ARP packets

Description

This article describes the ARP updates causing confusion and updating the ARP caches when unicast ARP packets arrive at a switch interface. By the end of this article, the user will be able to prevent such unwanted updates in the ARP cache by enabling a hidden knob.

Symptoms

Unwanted ARP cache changes when unicast ARP entries hit the switch interfaces

Solution

When unicast ARP entries hit the switch on an interface, there will be a change in MAC address entry in ARP table to the particular IP/interface. This behavior creates unnecessary confusion as even the entries that are not destined to the switch are registered by the CPU. This problem can be prevented by avoidng the dynamic learning of ARP and limiting the switch to statically learned entries.

Example:

user@host# run ping 147.46.3.1 count 3 <-- Test IP on interface ge-0/0/44
PING 147.46.3.1 (147.46.3.1): 56 data bytes 64 bytes from 147.46.3.1: icmp_seq=0 ttl=64 time=2.932 ms 64 bytes from 147.46.3.1: icmp_seq=1 ttl=64 time=1.994 ms 64 bytes from 147.46.3.1: icmp_seq=2 ttl=64 time=1.892 ms

--- 147.46.3.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss

Noting down the original MAC for testing purpose,

user@host# run show arp expiration-time MAC Address Address Name Interface Flags TTE 00:00:5e:00:01:15 10.219.42.193 10.219.42.193 em0.0 none 713 fe:00:00:00:00:80 128.0.0.16 fpc0 bme0.0 permanent ec:13:db:20:b9:01 147.46.3.1 147.46.3.1 irb.10 [ge-0/0/44.0] none 1004 <-- ARP resolved as expected (Original MAC for 147.46.3.1)
f4:a7:39:f8:a2:03 192.168.1.1 hypervisor em2.32768 none 32 Total entries: 4

When unicast ARP entries hit the switch on the interface ge-0/0/44, the below behavior is seen:

user@host# run show arp expiration-time

MAC Address       Address         Name                      Interface               Flags    TTE 00:00:5e:00:01:15 10.219.42.193   10.219.42.193             em0.0                   none 862 fe:00:00:00:00:80 128.0.0.16      fpc0                      bme0.0                  permanent
98:83:89:2f:af:a8 147.46.3.1      147.46.3.1                irb.10 [ge-0/0/44.0]    none 988     <-- ARP MAC changes immediately
f4:a7:39:f8:a2:03 192.168.1.1     hypervisor                em2.32768               none 234 Total entries: 4

user@host# run show arp expiration-time MAC Address Address Name Interface Flags TTE 00:00:5e:00:01:15 10.219.42.193 10.219.42.193 em0.0 none 860 fe:00:00:00:00:80 128.0.0.16 fpc0 bme0.0 permanent 98:83:89:2f:af:a8 147.46.3.1 147.46.3.1 irb.10 [ge-0/0/44.0] none 1170 <-- Remains the same
f4:a7:39:f8:a2:03 192.168.1.1 hypervisor em2.32768 none 232 Total entries: 4

To prevent this, clear the affected ARP entry time and again:

user@host> clear arp hostname x.x.x.x x.x.x.x deleted

This is not advised since this manual task becomes very confusing and cumbersome.
To prevent unwanted updates on a specific ARP entry, use the static configuration of the ARP instead of the dynamic learning of it. To configure a static ARP entry:

[edit interfaces interface-name unit logical-unit-number family inet address address]
user@device# set arp ip-address (mac | multicast-mac) mac-address

Unicast ARP packets that are not destined to the switch routed interfaces are copied to CPU in addition to forwarding in HW. This will update the ARP cache on the routing engine. To prevent such a situation, a hidden knob " set switch-options no-arp-trap " is available. This option will direct the switches not to copy unicast ARP packets that are not destined to the switches' interfaces MACs into CPU, which will stop unwanted ARP cache update by unicast ARP packets.

user@host# set switch-options no-arp-trap

Verifying the above command:

user@host# run show arp expiration-time | refresh 10 MAC Address       Address         Name                      Interface               Flags    TTE 00:00:5e:00:01:15 10.219.42.193   10.219.42.193             em0.0                   none 708 fe:00:00:00:00:80 128.0.0.16      fpc0                      bme0.0                  permanent ec:13:db:20:b9:01 147.46.3.1      147.46.3.1                irb.10 [ge-0/0/44.0]    none 998 <-- No ARP MAC changes even when unicast ARP is hitting the interface
f4:a7:39:f8:a2:03 192.168.1.1     hypervisor                em2.32768               none 27 Total entries: 4
---(refreshed at 2018-03-06 16:19:01 KST)--- MAC Address       Address         Name                      Interface               Flags    TTE 00:00:5e:00:01:15 10.219.42.193   10.219.42.193             em0.0                   none 698 fe:00:00:00:00:80 128.0.0.16      fpc0                      bme0.0                  permanent ec:13:db:20:b9:01 147.46.3.1      147.46.3.1                irb.10 [ge-0/0/44.0]    none 1026 <-- No ARP MAC changes f4:a7:39:f8:a2:03 192.168.1.1     hypervisor                em2.32768               none 16 Total entries: 4 ---(refreshed at 2018-03-06 16:19:11 KST)--- MAC Address       Address         Name                      Interface               Flags    TTE 00:00:5e:00:01:15 10.219.42.193   10.219.42.193             em0.0                   none 687 fe:00:00:00:00:80 128.0.0.16      fpc0                      bme0.0                  permanent ec:13:db:20:b9:01 147.46.3.1      147.46.3.1                irb.10 [ge-0/0/44.0]    none 1016 <-- No ARP MAC changes f4:a7:39:f8:a2:03 192.168.1.1     hypervisor                em2.32768               none   6 Total entries: 4

Notes:

The feature is available on all devices starting in release18.3 and higher. There are very few versions before 18.3 where this command works.
The hidden knob does not auto-populate on pressing the Tab key or the Space bar. You must type the command completely.
Consult JTAC in case you are unsure about how this feature could affect ARP learning based on your network and requirements.