Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

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

0

0

Article ID: KB35921 KB Last Updated: 12 Jun 2020Version: 2.0
Summary:

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:

  1. 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.
  2. The hidden knob does not auto-populate on pressing the Tab key or the Space bar. You must type the command completely.
  3. Consult JTAC in case you are unsure about how this feature could affect ARP learning based on your network and requirements.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search