Multicast: rather than dense, sparse it and let’s meet at rendez-vous point… Part 5

Client1 is configured to join multicast destined for group 226.0.0.1 and sent from Server1

Instead of PIM-Dense (flood and prune) we use PIM-Sparse to build the forwarding path from the server to the client

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

We use RIP for unicast routing and multicast ping from the source for test purpose

At R1 we check that Client1 is registered to the group


The interface facing Client1 is configured for PIM-Sparse

The details…

All interfaces are configured for PIM-Sparse

We check PIM neighborship established between R2 and R1

Let’s enable multicast routing and check the mroute table

After a while the mroute table get populated by group 226.0.0.1 information

The RP Rendez-vous Point is set to local

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

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

Now the packet is accepted for forwarding

But because of no forwarding interface the packets are 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 beaucause of the outgoing interface list is empty

Let’s configure the RP on the other routers

At R1 as soon as we configure the RP address

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

At R3 the mroute table shows

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

At R2 we add a new link to R4

The ping from the server stop working

Any idea?

atlink'admin

Learn More →

Leave a Reply

Translate »