PIM RPF Troubleshooting #1

Load pim.rpf.tshoot.cfg

#IOS-XE
config replace flash:pim.rpf.tshoot.cfg
 
#IOS-XR
configure
load bootflash:pim.rpf.tshoot.cfg
commit replace
y

CSR2 has joined two SSM groups:

• (7.1.7.1, 232.1.1.1)

• (2007:7:1:7::1, FF35::1)

CSR1 has joined two SSM groups:

• (9.2.5.2, 232.1.1.1)

• (2009:9:2:5::2, FF35::1)

None of this traffic is working. Troubleshoot the issue and find a way to fix it.

Answer

#R10
no ip mroute 0.0.0.0 0.0.0.0 10.10.11.11
no ipv6 route 2009:9:2:5::2/128 FD00:10:10:11::11 multicast

#XR1
multicast-routing
 address-family ipv4
  no static-rpf 7.1.7.1 32 GigabitEthernet0/0/0/0.501 10.10.11.10
 !
 address-family ipv6
  no static-rpf 2007:7:1:7::1 128 GigabitEthernet0/0/0/0.501 fd00:10:10:11::10

Explanation

As a first step, we can verify that the LHRs have the proper state entries. Each LHR should have the locally-joined (S, G) entries, and the (S, G) entries that were initiated from the remote receiver.

All we see are the locally-joined (S, G) trees, not the trees built from the receiver at the other end. This means that the PIM signalling must not be working somewhere in the path between R1 and R2.

Let’s go to the next routers upstream, R10 and XR1. We’ll look at R10 first.

Notice above that both entries point to the same RPF interface, which doesn’t make sense. Also, one entry has an OIL that is null.

Let’s look at the routing for the entries with the null OIL.

We see that R10’s unicast route towards the R2 source addresses and the RPF interface do not match. The output also tells us that the RPF check is using a static mroute.

We can further verify this by looking at the multicast RPF routing table. Notice that the IPv4 table is only populated with a 0/0 route and connected/local routes.

This is due to an interesting caveat with IPv4 mroutes. IPv4 RPF checks do not use a longest-prefix-match like you might expect. Instead, a static route overrides all longer-matches that are a worse admin distance.

Checking the IPv6 RPF table reveals that mroutes do not override longer matches. We can see a ::/0 static mroute, but all longer-matches are still present.

The ipv6 mroute giving us trouble is a /128:

Removing these static RPF routes will solve our issue:

#R10
no ip mroute 0.0.0.0 0.0.0.0 10.10.11.11
no ipv6 route 2009:9:2:5::2/128 FD00:10:10:11::11 multicast

Traffic sourced from R2 now gets a reply from R1:

We’ll now move on to XR1. XR1 shows that the R1 source addresses have an RPF interface of the interface facing R10, which is incorrect.

We can verify the RPF check on XR1:

A clue that this is wrong is that these are matched against host routes, while the unicast route match is a subnet:

IOS-XR only allows host routes for RPF “mroutes.” These are considered static RPF entries. If we remove these, the RPF check should resolve to the unicast route again, and the PIM Join should be directed to R7 instead of R10.

#XR1
multicast-routing
 address-family ipv4
  no static-rpf 7.1.7.1 32 GigabitEthernet0/0/0/0.501 10.10.11.10
 !
 address-family ipv6
  no static-rpf 2007:7:1:7::1 128 GigabitEthernet0/0/0/0.501 fd00:10:10:11::10

Traffic sourced from R1 is now getting a reply from R2:

In summary, the RPF static override routes behave differently on IOS-XE and IOS-XR:

• For IOS-XE, the IPv4 RPF table uses admin distance instead of a longest-prefix-match. A shorter match but better admin distance overrides a longer match.

• For IOS-XE, the IPv6 RPF table uses longest-prefix-match, which is more intuitive and more inline with how normal routing works.

• For IOS-XR, a static RPF entry must only be a host route (/32 or /128). So there is no concern about longest-prefix-match behavior.