In our test network
R1, R2 and R3 are in the same RIP routing domain
All these routers are configured for a PIM-SM mode operation
The RP address is set to R3’s fa1/0 interface
Notice that each router configured with this information establishes a tunnel towards the RP
At R2
A “show ip interface brief” shows
Digging into the interface tunnel0 details
The tunnel was created by PIM process to join the RP which is R3
The tunnel protocol/transport is PIM/IPv4
It is described as a PIM Register Tunnel for RP 12.1.1.3
A “show ip cef” on the RP address,
enables R2 to determine the tunnel source
before we move on let’s check that Client1 responds to multicast ping from Server2
We add a new direct link between R3 and R1 in the subnetwork 13.0.0.0/24
And include it in RIP domain
Another ping from the server shows that’s something went wrong
At R3,
The flow is accepted and flaged as SPT-bit set
The incoming interface and outgoing interface lists are correct and forwarding
What happens at R1? The last hop router towards the destination (Client1)?
The (S,G) is not there
The outgoing interface information is correct
But the incoming interface information is wrong : set up to Null
The Reverse Path Forwarding neighbor points to 0.0.0.0 which is none
The RP information is correct
What about the tunnel that is built towards the RP?
The tunnel is up! which means that R1 has found a route towards the RP in its routing table
Now the route to get to the RP is directly through the link between R1 and R3
Why PIM fails to install a correct information for 226.0.0.1?
Let’s debug
The debug shows the RP-reach (PIM-SM signalling) was received from a non-RPF interface for the group 226.0.0.1 and consequently was dropped
A “show ip rpf” checks that no entry exists at all for 12.1.1.3 the RP
By default the rpf picks the route dynamically from the ip unicast routing table
But why it does not work in our case?
Why the route through R2 succeeds? But R3 not?
What is special about the direct link between R1 and R3?
What is special about R3-facing R1’s interface?
It is not a pim interface!
Let’s enable pim (either dense or sparse) processing on this interface
Now the rpf shows
The rpf entry should be pim (dense or sparse) enabled and originated (by default) from the ipv4 unicast base…
In the mroute table
The (*,G) entry information is now correct
But the ping is still not working…
In the mroute table, no (S,G) is present: the source is not seen!
In fact,
A debug shows that the packet is received but fails the acceptance checks
Per the precedent rpf, the packet from the source is expected to arrive on the newly added fa1/1 interface
It is only received on the fa1/0 interface
R3 does not send packets on its fa 1/1 interface facing R1 because pim (forwarding part) is not enabled on it
Let’s enable PIM-DM (dense mode) on this interface then,
Now the ping is working…
Per RIP, the direct link between R1 and R3 is optimal but it happens that this link is congested and that eventually it’s more preferable to get through R2
To get the multicast flow through R2 we need that pim sparse mode signalling towards the RP succeeds (building the tunnel and accepting RP-reach messages) and that packets arrives on the new rpf interface
In the mroute table the incoming interface should switch to fa 1/0 and the RPF nbr to 21.1.1.2 (R2)
Let’s try to change the mroute table entry (RP information) statically
Now the entry is marked as “Mroute” to denote a static configuration
The rpf on the RP shows and RPF type of multicast (static) instead of unicast (rip) in the previous snapshot
The rpf on the source ip address shows
The rpf intreface is correct and enabled for pim
The rpf route comes from RIP database
An “ip cef” on this route confirms this information and matches the source flow incoming interface to the interface this route passes by…
We disable pim on the R3 interface facing R1 and redo a show rpf at R1
And nothing has changed!
Rpf still get the RPF neighbor information not from pim process but the rip routing protocol
We check that the pim neighborship is down and that 13.0.0.3 update source is the rpf corresponding rip route
The flow continues to flow directly from R3 to R1
Let’s delete the static mroute entry we’ve configured for the RP
And configure a new one for the source…
And deactivate pim on R3 direct link to R1
In this case is pim needed on R1 interface facing R3? let’s deactivate it and check,
The flow continues…
Which may lead to the conclusion that pim is not necessary on R1 fa1/1 (for rpf on R1)
BUT it is contradictory with our first finding!
It seems that the router keeps working with some wrong information
or a contradictory information between what the rpf table shows and what the mroute entry shows
Let’s “clear ip mroute *” everywhere in the network…
Now things are more coherent and back to our original problem,
And,
Which required us to activate PIM on R1 fa 1/1 interface for it to be included in the RPF table and then validate the corrsponding mroute entry…
