in this post let’s detail the operation of PIM (Protocol Independent Multicast) in sparse mode. Previous posts tackled the operation of PIM dense mode. Let’s recall that PIM is the multicast routing protocol that allows PIM routers exchange information needed distribute multicast traffic to receivers.

lab setup

In our setup, Client1 is configured to join multicast destined for group 226.0.0.1 and sent from Server1. Server1 is five hops far from Client1 and this is why we’re required to use the multicast routing protocol (PIM).

Instead of use PIM-Dense (flood and prune), seen in the previous post of this serie on Multicast operatoin, we use PIM-Sparse to build the forwarding path from the server to the client.

PIM-Sparse

PIM-Sparse is enabled on R1, R2, R3 and R4 routers

RIP for unicast routing (and RPF)

We use RIP for unicast routing and multicast a ping from the source for test purpose toward the group of receivers

IGMP

At R1 we check first that Client1 is registered to the group which is the case

The interface of router R1 facing Client1 is configured for PIM-Sparse

enable PIM in sparse mode

The details of this PIM interface are given in the following figure. We can check that PIMv2 is enable at interface level in sparse mode, that the RP or Rendez-vous point for this mode is the router itself (R1). We have also counters for PIM neighbors, in/out multicast packets. We check also that multicast switching is fast (at hardware level) and not process switched (at CPU level).

All interfaces are configured for PIM-Sparse mode of operation

PIM neighborship

We check PIM neighborship established between R2 and R1 using the command show ip pim neighbor. We could check that now R2 is the DR (designated router) of this multicast link.

Now that PIM is enabled and neighborships established, let’s enable multicast routing and check the mroute table for effective multicast traffic forwarding

mroute table

After a while the mroute table get populated by group 226.0.0.1 information. From the show ip mroute command output, we check the R1 is the RP for this group (marked as 0.0.0.0) that outgoing interfaces for this group are populated with fa0/0 towards Client1 as receiver. But nothing is the list of the incoming interface (Server1 has not yet sent any traffic). The RPF check is what guarantees the the source IP is resolvable the the same interface using our unicast routing protocol (in our case connected or RIP)

The RP Rendez-vous Point is set to local

source trafic

Let’s send trafic from the server

At R4,

The router receives trafic from the source but fails routing it

The mroute table is empty of 226.0.0.1 group information

debug multicast forwarding

We activate PIM on the fa0/0 interface (to enable multicast packets processing) and run a debug ip mfib pak

A debug on R1 shows the packet from the server fails the acceptance check. Is it due to sparse mode? Or in general? We put the interface into dense mode

the debug shows the output in the following figure. The flow is now accepted but fails because of no forwarding interface.

We configure back the interface into sparse mode

In addition, we configure R4 to be a RP (static) instead of R1.

Now the packet is accepted for forwarding

But because of no forwarding interface the packets are still dropped

We check also that R4 initiates the register process with the RP (which is R4 in our case)

At R4,

The mroute table is populated by (S,G) entry but it is pruned because of the outgoing interface list is empty

Let’s configure the RP on the other routers to match R4

At R1 as soon as we configure the RP address to match R4

We check that R1 build a join message for 226.0.0.1 and put it in R2 queue

At R2,

The router has no idea about RP and consequently invalidates the join received from R1

We configure the RP information on the remaining routers R2 and R3

Now the server is getting response from the client to the ping sent from the server to the multicast group

At R3 the mroute table shows

The RP information is correct and the RPF is set to R4 on the fa1/0 interface

rpf operation

At R2 we add a new link to R4 so that we create a shorter path from R4 to R2

problem

The ping from the server stop working

Any idea?

as conclusion

in this post we’ve checked the operation of PIM in sparse mode. The configuration of the RP is central to this mode of operation. From there all PIM routers build the forwarding tree toward the RP (using RPF rule to validate PIM exchanged messages). After this half of path is built, the second path is build from the server to the RP to join the first half of path already built. RPF is also in action to check that the source of the multicast traffic is also in the RPF path in terms of the unicast routing table.