Description

This article describes a scenario wherein a user was unable to ping a LAN interface IP address from another spoke.

Symptoms

Topology

192.168.1.0/24---(.254)CPE(Site -100) ----- Internet -----(Site-101)CPE(.254)--- 192.168.2.0/24

User was trying to ping from Site-100 to Site-200 but the ping failed.

A flow trace on Site-100 for receiving traffic shows the following:

Feb 13 15:29:54 15:29:54.008539:CID-0:RT:flow_first_routing: vr_id 32, call flow_route_lookup(): src_ip 192.168.1.254, x_dst_ip 192.168.2.254, in ifp ge-0/0/4.31, out ifp N/A sp 11320, dp 0, ip_proto 1, tos c0
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:Doing DESTINATION addr route-lookup
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:flow_ipv4_rt_lkup success 192.168.2.254, iifl 0x76, oifl 0x76 <<< destination interface is incorrect , it being a loopback should point to junos-host zone
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:flow_first_routing: setting out_vrf_id in lpak to 0, grp 0
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: routed (x_dst_ip 192.168.2.254) from LAN (ge-0/0/4.31 in 0) to ge-0/0/4.31, Next-hop: 10.209.147.4
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:Policy lkup: vsys 0 zone(7:LAN) -> zone(7:LAN) scope:0
src vrf (0) dsv vrf (0) scope:0
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: 192.168.1.254/2048 -> 192.168.2.254/59447 proto 1
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:Policy lkup: vsys 0 zone(5:global) -> zone(5:global) scope:0
src vrf (0) dsv vrf (0) scope:59447
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: 192.168.1.254/2048 -> 192.168.2.254/59447 proto 1
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:flow_first_policy_search: policy search from zone LAN-> zone LAN (0x0,0x2c380000,0x0), result: 0x45b5a20, pending: 0?
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:flow_first_policy_search: dynapp_none_policy: TRUE, uc_none_policy: TRUE, is_final: 0x0, is_explicit: 0x0, policy_meta_data: 0x0
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: app 0, timeout 60s, curr ageout 60s
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: packet dropped, denied by policy
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: denied by policy default-policy-logical-system-00(2), dropping pkt
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: packet dropped, policy deny.
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:flow_first_install_session: Loopback session processing aborted
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:first path session installation failed
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: flow find session returns error.
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:flow_proc_rc: -1.
Feb 13 15:29:54 15:29:54.008539:CID-0:RT:flow_process_pkt_exception: Freeing lpak 0x208cf78 associated with mbuf 0x5ee71e80
Feb 13 15:29:54 15:29:54.008539:CID-0:RT: ---- flow_process_pkt rc 0x7 (fp rc 0)

Solution

The Issue is seen when traffic is routed over different routing instances. If the destination is one that is configured on the device, traffic should ideally be routed to an internal zone junos-host and no policy would explicitly need to be defined for the same.

But because of this behavior seen in version 20.4R3-S2, Junos does not perform the route lookup correctly and hence looks for a LAN-to-LAN policy. 

Workaround: Create a LAN-to-LAN policy to allow such traffic. 

This issue has been fixed in Junos OS Releases 20.4R3-S7, 22.3R3, 22.4R3, 23.1R2, and 23.2R1.

Modification History

2023-05-18: Initial version