Multicast Routing

The main goal of a router is to route packets. In other words: when it receives an IP packet it has to look at the destination address, check the routing table and figure out the next hop where to forward the IP packet to. We use routing protocols to learn different networks and to fill the routing table.

Here’s an illustration to visualize this:

Above we see R1 who wants to deliver an IP packet to destination 2.2.2.2. It checks its routing table, finds an OSPF entry with 192.168.12.2 as the next hop (R2). R1 is now able to forward the IP packet towards the destination.

Everything I explained above applies to unicast traffic. What about multicast traffic? Let’s look at another example:

Above we see R1 who receives a multicast packet from some video server, the destination address is 239.1.1.1. The routing table however is a unicast routing table. There’s no information about any multicast addresses in there. Our router will have no idea where to forward it’s multicast traffic to…

Multicast Routing Protocols

To route our multicast traffic, we need to use a multicast routing protocol. There are two types of multicast routing protocols:

• Dense Mode
• Sparse Mode

We’ll discuss both types, we’ll start with dense mode.

Dense Mode

Dense mode multicast routing protocols are used for networks where most subnets in your network should receive the multicast traffic. When a router receives the multicast traffic, it will flood it on all of its interfaces except the interface where it received the multicast traffic on. Here’s an example:

Above we have a video server sending multicast traffic to R1. When R1 receives these packets, it will flood them on all of its interfaces. R2 and R3 will do the same so our two hosts (H2 and H3) will receive the multicast traffic. In the example above both of our hosts are interested in the multicast traffic but what if there are hosts that don’t want to receive it?

A multicast router can tell its neighbor that it doesn’t want to receive the multicast traffic anymore. This happens when:

• The router doesn’t have any downstream neighbors that require the multicast traffic.
• The router doesn’t have any hosts on its directly connected interface that require the multicast traffic.

Here’s an example:

Above we see R1 that receives the multicast traffic from our video server. It floods this multicast traffic to R2 and R3 but these two routers don’t have any interest in the multicast traffic. They will send a prune message to signal R1 that it should no longer forward the multicast traffic.

There are a number of dense mode routing protocols:

• DVMRP (Distance Vector Multicast Routing Protocol)
• MOSPF (Multicast OSPF)
• PIM Dense Mode

PIM (Protocol Independent Multicast) is the most popular multicast routing protocol which we will discuss in other multicast lessons.

RPF (Reverse Path Forwarding)

Multicast routing is vulnerable to routing loops. One simple loop-prevention mechanism is that routers will never forward multicast packets on the interface where they received the packet on. There is one additional check however called RPF (Reverse Path Forwarding). Take a look at the example below:

Above we have R1 which receives a multicast packet which is flooded on all interfaces except the interface that connects to the video server. I’m only showing the packet that is flooded towards R3 here:

• R1 floods the packet to R3.
• R3 floods the packet to R2.
• R2 floods it back to R1.

We now have a multicast routing loop. We can prevent this by implementing the RPF check:

When a router receives a multicast packet on an interface, it looks at the source IP address and does two checks:

• Do we have an entry that matches the source address in the unicast routing table?
• If so, what interface do we use to reach that source address?

When the multicast packet is received on the interface that matches the information from the unicast routing table, it passes the RPF check and we accept the packet. When it fails the RPF check, we drop the packet.

Let me visualize this with an example:

Above we see R1 which floods the multicast traffic to R2 and R3. R2 also floods it to R3.

R3 will now perform a RPF check for both multicast packets. It sees the source address is 192.168.1.100 and checks the unicast routing table. It finds an OSPF entry for 192.168.1.0/24 that points to R1.

The packet that it receives from R1 will pass the RPF check since we receive it on the Fa0/0 interface, the one it receives from R2 doesn’t. The multicast packet from R2 will be dropped.

R3 will then flood the multicast packet towards R2 who will also do a RPF check. It will drop this packet since R2 uses its interface towards R1 to reach 192.168.1.100.

Another way to look at this is that the RPF check ensures that we only accept multicast packets from the shortest path. Multicast packets that travel longer paths are dropped. For R3 the shortest path to 192.168.1.100 is through R1.

Sparse Mode

At this moment you might be thinking that dense mode is very inefficient with its flooding of multicast traffic. When you only have a few receivers on your network then yes, you will be wasting a lot of bandwidth and resources on your routers.

The alternative is sparse mode which is far more efficient. Sparse mode multicast routing protocols only forward the multicast traffic when another router requests it. It’s the complete opposite of dense mode: