# 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 <a href="#id-4ab86b82-7ebd-48fe-863b-37791a64423f" id="id-4ab86b82-7ebd-48fe-863b-37791a64423f"></a>

```
#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 <a href="#id-65dde099-a6e8-42eb-84fe-beaa9c32d826" id="id-65dde099-a6e8-42eb-84fe-beaa9c32d826"></a>

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.

<div align="left"><figure><img src="/files/WPq9MEvWKJW0vcyUC9sr" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/dtOKp2b6HtSHPcg2zlKf" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/W0XtduOhLRScFufB5jkz" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/0js29jvGSYXXQLP5IS42" alt=""><figcaption></figcaption></figure></div>

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.

<div align="left"><figure><img src="/files/V4oZm77O9QrRfljuhxM7" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/OU9VnnhX1JP5YpzFJtws" alt=""><figcaption></figcaption></figure></div>

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.

<div align="left"><figure><img src="/files/ACoOTBZc5u8hxFmi0Pw7" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/WKoJRtUYeArnOlMJLl0G" alt=""><figcaption></figcaption></figure></div>

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.

<div align="left"><figure><img src="/files/D3VM77ZMKff3eZdhTJNq" alt=""><figcaption></figcaption></figure></div>

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.

<div align="left"><figure><img src="/files/zPL2nbpdlvSvFJpQ5KhX" alt=""><figcaption></figcaption></figure></div>

The ipv6 mroute giving us trouble is a /128:

<div align="left"><figure><img src="/files/GnWb7lxUjKYIwbPzKqi8" alt=""><figcaption></figcaption></figure></div>

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
```

<div align="left"><figure><img src="/files/67KhzAKDU1ij8demgSsc" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/iLsAjcfXVgsn1oV5ALEk" alt=""><figcaption></figcaption></figure></div>

Traffic sourced from R2 now gets a reply from R1:

<div align="left"><figure><img src="/files/SZtbTTzgbLsbG753Beai" alt=""><figcaption></figcaption></figure></div>

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.

<div align="left"><figure><img src="/files/tbdZKLYAtQoOqornrZQw" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/OmB06kFV9zDvpdLri5HC" alt=""><figcaption></figcaption></figure></div>

We can verify the RPF check on XR1:

<div align="left"><figure><img src="/files/B8lvTItv050z6cgDPo7g" alt=""><figcaption></figcaption></figure></div>

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

<div align="left"><figure><img src="/files/CMI0kFeZpJXy6Iata7gE" alt=""><figcaption></figcaption></figure></div>

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
```

<div align="left"><figure><img src="/files/6OUclmI8Psz3KkpqeSE7" alt=""><figcaption></figcaption></figure></div>

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

<div align="left"><figure><img src="/files/ZEIngiGa6LX7a3aefpRB" alt=""><figcaption></figcaption></figure></div>

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/multicast/pim-rpf-troubleshooting-1.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.