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

[ACX] Understanding ARP behavior on ACX devices

0

0

Article ID: KB34097 KB Last Updated: 09 Apr 2019Version: 1.0
Summary:

This article describes the default Address Resolution Protocol (ARP) learning behavior on ACX Series devices.

 

Symptoms:

As per RFC 826 Ethernet Address Resolution Protocol (ARP) definition, a device can learn Ethernet addresses (MAC address) through an ARP request packet as explained below.

Consider that devices X and Y are on the same Ethernet cable. They have the Ethernet addresses EA(X) and EA(Y), respectively, and DOD Internet addresses IPA(X) and IPA(Y), respectively. Consider that the Ethernet type of Internet is ET(IP).

Device X has just been started, and would sooner or later want to send an Internet packet to Device Y on the same cable. X knows that it wants to send to IPA(Y) and tells the hardware driver (here, an Ethernet driver) IPA(Y). The driver consults the Address Resolution module to convert <ET(IP), IPA(Y)> into a 48-bit Ethernet address, but because X was just started, it does not have this information. It therefore discards the Internet packet and creates an Address Resolution packet with the following instead:

 
(ar$hrd) = ares_hrd$Ethernet
(ar$pro) = ET(IP)
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op)  = ares_op$REQUEST
(ar$sha) = EA(X)
(ar$spa) = IPA(X)
(ar$tha) = don't care
(ar$tpa) = IPA(Y)
 

It then broadcasts this packet to all the other devices on the Ethernet.

Device Y gets this packet and determines that it understands the hardware type (Ethernet), that it speaks the indicated protocol (Internet), and that the packet is meant for it [(ar$tpa)=IPA(Y)]. It enters (probably replacing any existing entry) the information that <ET(IP), IPA(X)> maps to EA(X). It then notices that this is a request, so it swaps fields, putting EA(Y) in the new sender Ethernet address field (ar$sha), sets the opcode to reply, and sends the packet directly (not broadcast) to EA(X). At this point, Y knows how to send to X, but X still doesn't know how to send to Y.

Device X gets the reply packet from Y, forms the map from <ET(IP), IPA(Y)> to EA(Y), notices that the packet is a reply, and throws it away. The next time X's Internet module tries to send a packet to Y on the Ethernet, the translation will succeed, and the packet will (hopefully) arrive. If Y's Internet module then wants to talk to X, this will also succeed since Y remembers the information from X's request for Address Resolution.

The above example describes the behavior of routers in general. However, on ACX Series devices, this behavior is different in that they do not populate the ARP table.

As per the behavior explained above, ARP requests are understood to update the ARP cache on a device. But on ACX devices, the ARP cache is not updated, as indicated in the following example.

Consider the following ACX device that is running Junos OS release 18.1:

lab@R1# run show version
Model: acx2200
Junos: 18.3R1-S3.3 
 

This device has the following interface configuration:

 
lab@R1# show interfaces ge-0/0/2 
unit 0 {
    family inet {
        address 192.168.1.2/24;
    }
}

[edit]
lab@R1# run show interfaces terse ge-0/0/2 
Interface               Admin Link Proto    Local                 Remote
ge-0/0/2                up    up
ge-0/0/2.0              up    up   inet     192.168.1.2/24 
                                   multiservice
 

From the output, it can be seen that the interface is continuously receiving ARP requests for an unknown destination.

 
lab@R1# run monitor traffic interface ge-0/0/2.0 size 9999 no-resolve extensive layer2-headers    
Address resolution is OFF.
Listening on ge-0/0/2.0, capture size 9999 bytes

12:28:06.547446 bpf_flags 0x85,  In 
        Juniper PCAP Flags [Ext, In], PCAP Extension(s) total length 16
          Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
          Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
          Device Interface Index Extension TLV #1, length 2, value: 33536
          Logical Interface Index Extension TLV #4, length 4, value: 320
        -----original packet-----
        f0:4b:3a:2b:02:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.1.10 tell 192.168.1.1
12:28:07.344007 bpf_flags 0x85,  In 
        Juniper PCAP Flags [Ext, In], PCAP Extension(s) total length 16
          Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
          Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
          Device Interface Index Extension TLV #1, length 2, value: 33536
          Logical Interface Index Extension TLV #4, length 4, value: 320
        -----original packet-----
        f0:4b:3a:2b:02:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.1.10 tell 192.168.1.1
^C
3 packets received by filter
0 packets dropped by kernel
 

However, it is also observed that based on the source MAC address, the ARP cache is not updated on the local device.

 
lab@R1# run show arp 
MAC Address       Address         Name                      Interface               Flags
00:00:5e:00:01:13 10.219.37.193   10.219.37.193             fxp0.0                  none
02:00:00:00:00:10 128.0.0.32      feb0                      em0.0                   none
Total entries: 2

 

Solution:

This is expected behavior on ACX Series devices and works as per design. As per this behavior, the ACX devices are to resolve MAC addresses based on the ARP requests that they receive that have the target IP address set to themselves on the ARP header.

Any other target IP address in the same subnet will not enable the device to update its ARP cache as indicated above.

 

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