With PIM-SM configured on the MikroTik router, the router will only forward the multicast traffic when another router requests it. On Cisco there is PIM-DM (Dense mode) where the multicast is flooded once received; however, this mode is not available on MikroTik so the only option we have is PIM-SM, which in my opinion, is more scalable than PIM-DM.

For a point, you think that is a great solution to use PIM-SM; that’s partially true. Think of it, if a router receive a multicast traffic and he has PIM-SM configured, how can other routers know that they should request the traffic from that router if they want the multicast traffic. In fact, there is no any mechanism which can tell them this. For this reason, spare mode uses a special router called RP (Rendezvous Point). In this way, once any router in our network wants to have multicast traffic, he can request that from the RP router to get it. Let’s visualize this:

Above you can see that R1 is the Rendezvous Point (RP). It is us who choose which router should be the RP. He is receiving the multicast traffic from the video server but for the time being no one is interested in this traffic, so R1 will not send the multicast traffic on the network.

In 2 cases the RP will send the multicast traffic as following:

[mepr-show rules=”319″ unauth=”message”]

• When the RP receives an IGMP join message from a host that is directly connected to it
• When the RP receive a request from another router

Let’s visualize this!!!

Here is an explanation of what is happening:

1. The video server is sending the multicast traffic to R1 with destination 239.1.2.3
2. R1 is always the RP on the network.
3. Host 2 wants to receive the multicast traffic so it has sent the IGMP join message (which is the IGMP membership report) for the multicast group 239.1.2.3
4. R3 receives the IGMP join from Host 2 and will request R1 to start sending the multicast traffic to him by sending him a PIM join message (I will speak later about that message).

In this way, R1 will start forwarding the multicast traffic to R3 as the following:

 Host 2 is able now to receive the multicast traffic and we didn’t waste any of the resource by sending the multicast traffic to other hosts (such as Host 1).

Just to mention, when we use PIM on MikroTik then all routers need to know the IP address of the RP. This is mandatory for the multicast traffic to flow in our network when a host requests it.

This is the global idea about PIM, but I would like to dig in deep about PIM protocol.

Let’s image we have the following network:

The video server is connected to R1 and we have decided that R5 to become the RP. In this way, R1 will also has to send the multicast traffic to RP. In the following 2 cases the routers need to communicate with the RP:

• Each router that received multicast traffic from a source will forward it to RP (which applied in our scenario)
• Each router that wants to receive the multicast traffic will go to RP.

Think of RP like a meeting point for the multicast traffic, then you understand its role.

To even go more in deep about what is happening in the background between R1 and R5 (RP) router, let’s imagine that no one in the network is interested in the multicast traffic, then R1 will only send the first multicast packet to the RP. This packet is encapsulated in a PIM register message and forwarded to the RP as following:

Once the RP receive the PIM register message, he has two options:

• In case no one is interested in the multicast traffic then the RP will reject the PIM register message.
• In case there is at least one receiver interested in the multicast traffic, then the RP will accept the PIM register message.

Let’s take the 1^st option and think that there is no one interested in the multicast traffic, this what would happen:

As you see above, the RP has sent a PIM Register Stop message to R1 informing him to stop forwarding any multicast traffic for now because no one is interested in this traffic. R1 will remain silent, and will start a suppression timer as the following:

Once the timer is finished, R1 will send another PIM register message but this time it doesn’t carry the encapsulated multicast packet, it is just a simple request asking the RP is he is interested in the multicast traffic now. The packet that is sent is called PIM register null. Same, in case the RP is not interested in the multicast traffic he will send a PIM register stop message to R1. In case R1 doesn’t hear the PIM register stop message from the RP then it will start forwarding the multicast traffic.

Let’s think that now Host 1 is interested in the multicast traffic, we will have the following output:

As you see above, Host1 will send IGMP Membership report message to R6 for the multicast group that it wants. R6 needs to get to the RP to request from him to start forwarding the multicast. R6 will check in its unicast routing table how to reach to the IP address of the RP and then send the PIM join from the interface which takes him to the RP. A very important point here to mention, you should have already configured a unicast routing protocol so the routers can know how to reach to the RP, otherwise the PIM join messages can never be able to reach to the RP IP address.

Now the PIM join message has reached to R4. In turn, R4 has to send a PIM join to the RP asking him to start forwarding the multicast traffic to him. It will also check its unicast routing table to check how it can reach to the RP, then it will send the PIM join message from the interface which lead him to the RP.

This means that PIM join message can be send on the following 2 cases:

• The router has received an IGMP membership report from a host on a directly connected interface.
• The router has received a PIM join from a downstream router.

Finally, when the RP receives the PIM join message, it will start forwarding the multicast traffic.

The whole concept that you have seen up to now is called RPT (Root Path Tree). The RP in this case is the root of our tree and he decided where to forward the multicast traffic to.

So, the end result will be as the following:

Enough of theory, let’s apply some a LAB to see how to configure PIM on the MikroTik routers and see if the multicast would work.

[/mepr-show]