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:

R1 R2 Unicast Routing Table

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:

R1 R2 Video server multicast routing

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:

Multicast Dense Mode Flooding

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:

Multicast Dense Mode Pruning

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:

Multicast Dense Mode Loop

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:

Multicast Dense Check RPF

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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 799 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

576 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Rene: multicast ip range is 224.0.0.0 - 239.255.255.255, i think you had a typo under the “administrative scoping” ??

    Correct me if i am wrong. Thanks

  2. Hi Siva,

    That’s the entire multicast range (class D) but the administratively scope is the range from 239.0.0.0 through 239.255.255.255.

    You don’t want to filter the 224.x.x.x range, this is also used by protocols like OSPF, EIGRP, HSRP, VRRP, etc.

    Rene

  3. Clear explanation.
    Thanks Rene.

    Davis

  4. hi, it’s good to understand concept of multicast

    i have one question,

    if shared tree path is equal to shortest tree path(first hop router is rp) , dose the last hop router send s,g join message to first hop router(RP) ?

    when spt-threshold is set to infinity, does it work efficiently than now applied?

  5. Hi Rene,

    Absolutely sound tutorial !

    Just a small observation…
    When the TTL value of the IP packet is below or equal to the threshold then the packet will be forwarded dropped, otherwise it will be forwarded.

    Ody

41 more replies! Ask a question or join the discussion by visiting our Community Forum