This article describes why traffic originating from source IP addresses that are learned via a default route and that are not added as an entry in the routing table may be dropped on the EX4600 Series devices when uRPF loose mode is configured. It also clarifies that this behavior is expected.

 

Consider the following Scenario:

• The PE-DEVICE advertises a default route "::/0" towards the EX4600 device via BGP.

• The EX4600 device advertises the "::/0" route to the LAN via ospfv3.

root@LAN# run show route 
::/0               *[OSPF3/150] 00:09:46, metric 0, tag 0
                    > to fe80::e86:1000:537c:b00 via irb.329

In this case, if you start one-way traffic from the LAN to "internet" (in this case 2707:f9d0:700:db3::11), that traffic will flow without any problems.

However, if you send traffic that needs a response (a ping for example), the return traffic will be dropped by the EX4600 device and not forwarded to the LAN if you have loose uRPF configured on the device.

Example

• EX4600 is a BGP neighbor to the PE-DEVICE.

• Internal devices have OSPF3 connections between them (EX4600, LAN).

• The PE-DEVICE generates a static route pointing "::/0" towards the "Internet" and advertising it through BGP to the EX4600 device.

• The EX4600 device advertises the route to the LAN through OSPF3.

• When initiating a ping from the LAN to Internet, traffic will enter the EX4600 device through VLAN 329 and exit it through VLAN 350.

This part goes on fine. The traffic actually hits the destination but the reply enters the EX4600 device and it is not sent to the LAN.

• This is the traffic that you see from the destination (PE-DEVICE):

17:24:07.948492  In IP6 2607:f9d0:700:db3::10 > 2707:f9d0:700:db3::11: ICMP6, echo request, seq 0, length 16
17:24:07.948526 Out IP6 2707:f9d0:700:db3::11 > 2607:f9d0:700:db3::10: ICMP6, echo reply, seq 0, length 16
17:24:07.948569  In IP6 2607:f9d0:700:db3::10 > 2707:f9d0:700:db3::11: ICMP6, echo request, seq 1, length 16
17:24:07.948581 Out IP6 2707:f9d0:700:db3::11 > 2607:f9d0:700:db3::10: ICMP6, echo reply, seq 1, length 16

• Across the PE-DEVICE, the counters in ingress and egress interfaces match:

                         Input                          Output
 xe-2/0/0      Up        82499558        (440)          77935177        (440)
 xe-2/0/1      Up               0          (0)                 0          (0)
 xe-2/0/2      Up        39039552        (440)          42187412        (440)

• Across the EX4600 device, we do see drops in the return traffic coming from the external address in the "Internet" to the LAN.

                            Input                        Output    
 xe-0/0/0      Up        52498762       (440)           2531205         (0)
 xe-0/0/1      Up        47856123       (440)           8067788       (440) 

• If in the PE-DEVICE, instead of exporting a "::/0" default route, a more specific "::/1" route is exported to the EX4600 device, it all works:

root@4600# run show route receive-protocol bgp 2507:f9d0:700:db3::10 

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

inet6.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* ::/1                    2507:f9d0:700:db3::10                   32222 I

• If instead of advertising the routes from PE-DEVICE, a "::/1" static route is configured on the EX4600 device, which points towards PE-DEVICE, it works.

root@EX4600# show routing-options                 
rib inet6.0 {
    static {
        route ::/1 next-hop 2507:f9d0:700:db3::10;
{{

• However, when a default "::/0" route is configured in the EX4600 device, it has the same effect: uRPF ignores the default route and the return traffic fails to reach the LAN:

root@EX4600# show routing-options                 
rib inet6.0 {
    static {
        route ::/0 next-hop 2507:f9d0:700:db3::10;
{{

 

This happens because in loose mode, the uRPF check does not verify whether the receiving interface is the best return path to the packet's unicast source (hence loose) but it does check to see if the packet has a source address with a corresponding prefix in the routing table. Also, in Juniper devices, uRPF is designed to ignore default routes.

• If there is a match in the L3_Table and loose mode is enabled, then the uRPF check results in a PASS.

• If there is no match in the L3_Table for the SIP search, then the results from the L3_DEFIP table are used.

• If the L3_DEFIP search results in a miss, the unicast RPF check will not consider the default route for its reverse path checking. This means that the packet will be accepted only if at least a route prefix is present in the routing table.

There are two ways of implementing loose uRPF.

• Loose Reverse Path Forwarding

Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar to strict RPF, but differs in that it checks only for the existence of a route (even a default route, if applicable), not where the route points to. Practically, this could be considered as a "route presence check" ("loose RPF is a misnomer in a sense because there is no "reverse path" check in the first place).

• Loose Reverse Path Forwarding Ignoring Default Routes

Loose RPF ignoring default routes is like an "explicit route presence check". In this approach, the router looks up the source address in the route table, and preserves the packet if a route is found. However, in the lookup, default routes are excluded. Therefore, the technique is mostly usable in scenarios where default routes are used only to catch traffic with bogus source addresses, with an extensive (or even full) list of explicit routes to cover legitimate traffic.

 

In the case of EX4600 devices with uRPF configured, all packets whose source IP address is not present in the routing table are dropped on the PFE and the default route is ignored by the loose uRPF. This behavior is expected and is to avoid any IP address on the internet from sending unicast packets to devices inside the LAN.

Juniper encourages the creation of more specific routes to handle traffic coming from the internet towards an internal device inside the local LAN and usage of non-default routes when using uRPF check.