This article explains the behavior of ACX devices with respect to ARP resolution when transit traffic passes through a loopback interface.
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.
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.
2019-04-26: Added work-around to the solution.