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 resolution for transit traffic if re-filter is configured on ACX

0

0

Article ID: KB34096 KB Last Updated: 27 Apr 2019Version: 2.0
Summary:

This article explains the behavior of ACX devices with respect to ARP resolution when transit traffic passes through a loopback interface.

 

Symptoms:

On ACX devices, a transit packet can be subject to a loopback filter if the ARP cache is not updated with next-hop information.

Consider the following topology:

R1(ge-1/3/8)----(ge-0/0/2)R2(ge-0/0/0)----(ge-3/0/0)R3

R1

lab@R1> show interfaces terse ge-1/3/8  

Interface               Admin Link Proto    Local                 Remote
ge-1/3/8                up    up
ge-1/3/8.0              up    up   inet     10.0.0.5/30     
                                   multiservice

R2

lab@R2> show interfaces ge-0/0/2 terse  

Interface               Admin Link Proto        Local             Remote
ge-0/0/2                up    up
ge-0/0/2.0              up    up   inet         10.0.0.6/30     
                                   multiservice
lab@R2> show interfaces terse ge-0/0/0  

Interface               Admin Link Proto        Local             Remote
ge-0/0/0                up    up
ge-0/0/0.0              up    up   inet         30.0.0.1/24     
                                   multiservice

R3

lab@R3> show interfaces terse ge-3/0/0  

Interface               Admin Link Proto        Local             Remote
ge-3/0/0                up    up
ge-3/0/0.0              up    up   inet         30.0.0.2/24     
                                   multiservice

Note that an ARP entry is not found on R2 for 30.0.0.2 as seen below:

lab@R2> show arp 

MAC Address       Address         Name                  Interface    Flags
aa:aa:aa:aa:aa:aa 10.0.0.5        R1     ge-0/0/2.0                  none
bb:bb:bb:bb:bb:bb 10.219.37.193   10.219.37.193         fxp0.0       none
cc:cc:cc:cc:cc:cc 128.0.0.32      feb0                  em0.0        none
Total entries: 3
 

When R2 has traffic to be sent to a destination for which R3 is the next-hop, R2 performs ARP resolution.

However, when there is transit traffic that is destined to exit the ge-0/0/0 interface on R2, R2 generates an ARP request for 30.0.0.2. Now let us assume that R1 is pinging 30.0.0.2 and although this is considered transit traffic to R2, the frames are sent to the Routing Engine until ARP resolution is successful.

A loopback filter that is used to block this traffic to the Routing Engine captures the packet, as shown below:

lab@R2> show configuration interfaces lo0 

unit 0 {
    family inet {
        filter {
            input protect-re;
        }
        address 5.5.5.5/32;
    }
}
lab@R2> show configuration firewall family inet filter protect-re | except ## 

interface-specific;
term 1 {
    from {
        protocol tcp;
        port telnet;
    }
    then accept;
}
term 2 {
    from {
        protocol tcp;
        port ssh;
    }
    then accept;
}
term 3 {
    then {
        count discard;
        log;
        discard;
    }
}

lab@R2> show firewall 

Filter: __default_bpdu_filter__                                
Filter: protect-re-lo0.0-i                                     
Counters:
Name                                     Bytes              Packets
discard-lo0.0-i                          204                2


lab@R2> show firewall log   

Log :
Time      Filter    Action Interface     Protocol    Src Addr    Dest Addr
22:33:50  pfe       D      ge-0/0/2.0    ICMP        10.0.0.5    30.0.0.2
22:33:54  pfe       D      ge-0/0/2.0    ICMP        10.0.0.5    30.0.0.2
22:33:46  pfe       D      ge-0/0/2.0    ICMP        10.0.0.5    30.0.0.2
 

Consequently, as shown above, the packet is dropped and ARP resolution fails.

Solution:

This is the default behavior on ACX Series devices due to the PFE architecture.

This limitation applies only if ARP resolution is required for transit traffic destined to the same subnets that are configured on the ACX interfaces. It will not impact implementations where there is protocol or other traffic that is being sent to destinations that are not configured on the ACX interfaces. 

A workaround is to allow the traffic in the firewall filter to permit ARP resolution. 

 

Modification History:
2019-04-26:  Added work-around to the solution.
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