Troubleshooting Multicast RPF Failure in Control Plane

I have looked into a RPF (Reverse Path Forwarding) issue in data plane here. In this post let's look into an issue where the control plane may have an impact of RPF. This is basically the RP (Rendezvous Point) is learnt from a different interface on unicast routing table while the multicast feed is coming from another interface. Of course this example is in PIM Sparse Mode and I am configuring the RP manually.

OSPF is configured for all links in routers but PIM is not enabled on E0/2 of R1 and R3.
RP is configured to be the R1.

Let's join PC to the group 239.1.1.1

PC(config)#int e0/0
PC(config-if)#ip igmp join-group 239.1.1.1

Looks like the feed does not get replies..
Let's look at the multicast routing table of R3;

Looks like RPF issue is there to the RP because RPF neighbor seems to be 0.0.0.0 and incoming interface as Null.

So the issue is clear now. Unicast routing table shows 1.1.1.1 can be reached via 192.168.13.1 (E0/2) but the multicast packets can traverse through E0/0 only.

To fix this with a multicast static route, let's find out what can be the interface,

It should be via 192.168.23.2 (E0/0) so the command should be;

R3(config)#ip mroute 1.1.1.1 255.255.255.255 192.168.23.2

The RPF issue is resolved.

As soon as I hit this command, feed got the replies..

Now what can be the routing table looks like?

Now there is a new entry for (192.168.1.10, 239.1.1.1) group which is the Source Path Tree (SPT). But looks like the traffic is not using it because the incoming interface is Null and RPF neighbor is 0.0.0.0 So the traffic is using the old entry which is (*, 239.1.1.1) which I guess is the Root Path Tree (RPT).

Why can it be like this?

Because surely there must be a RPF issue in Data Plane with the source 192.168.1.10

This can also be solved by entering another static mroute for 192.168.1.10