Cisco Multicast Lesson 1: Introduction to Multicast through an Easy Example

In a lot of my QoS testing, I have used Gnome M-Player to play an MP4 file, served off of a web server. The cool thing about this approach is that I can easily increase the bandwidth coming across the network by connecting additional clients and using M-Player to download new streams.

In the real world, however, you typically want to conserve bandwidth, and so having multiple clients downloading separate instances of the same data is usually a bad thing. Consider the following network as an example:

In this very simple example, we have a CentOS 6 server (Which will be streaming the file), and three Knoppix clients (which will be playing the file with M-Player). When I start up one of the Knoppix clients and begin a unicast stream, I see 270Kbps through Fa2/0:
R1#sho int fa2/0
...
5 minute output rate 270000 bits/sec, 32 packets/sec
...

(yes, I waited 5 minutes after beginning the stream).

What happens if we clear the interface counters and start up a second video stream from another client (and wait 5 minutes for the average to stabilize)? Will we see 540Kbps (2 streams x 270Kbps per stream)?
R1#sho int fa2/0
...
5 minute output rate 650000 bits/sec, 63 packets/sec
...
Huh...a little over the estimate. What if we fire up a third client downloading the same file?

R1#sho int fa2/0
...
5 minute output rate 907000 bits/sec, 92 packets/sec
...
Again, pretty close to what we would expect (3 x 270Kbps = 810Kbps). I'll chalk up the additional bandwidth to OSPF routing updates, CDP, and other network chatter, but the important thing is that this method of streaming data across a large network doesn't scale well.

Fortunately, there is a solution for this problem. What if there were a way to reduce the number of data streams that each router had to propagate? In a unicast stream, the router opens up a stream of data for each host that connects to the CentOS server. However, with multicast streams, the router only opens up one channel per outbound path. For example, the route from the CentOS server to Knoppix and Knoppix Clone 2 is identical up to R3 (and if Fa1/0 on R1 is shut down, as it was during my testing, it's identical to Knoppix Clone 1, as well). With multicast, R1 would forward a single datastream to R3; R3 would then split that data stream to R5 and to R4. With Fa1/0 shut down on R1, R4 would split its incoming stream also, sending one stream to Knoppix Clone 2 and one stream to R6. Now, suppose that instead of one client on R4, R5 and R6, suppose there were ten...it's not hard to see how multicast can quickly reduce bandwidth consumption on a large network.

So...how do you configure multicast on a Cisco router?

This is actually very easy to do. First, you globally enable multicast on your router:
R1(config)#ip multicast-routing
R1(config)#

Then, you enable PIM on the interfaces that will be participating in multicast streams:
R1(config)#int fa1/0
R1(config-if)#ip pim sparse-dense-mode
R1(config-if)#int fa2/0
R1(config-if)#ip pim sparse-dense-mode
R1(config-if)#int vlan10
R1(config-if)#ip pim sparse-dense-mode

There's a lot more to multicast -- which we'll get to in later labs -- but for a bare-bones configuration, that's it! Pretty easy, isn't it?

At this point, I'm going to chase down a rabbit trail for a few minutes. This is primarily intended as a Cisco lab, but unlike most of the other labs on this blog, this one requires some additional work on the server side in order to test. I started by installing VLC on the CentOS host. For CentOS6, you can install a binary package like this:
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
# rpm -Uvh http://li.nux.ro/download/nux/dextop/el6/i386/nux-dextop-release-0-3.el6.nux.noarch.rpm
# yum install vlc

For CentOS7, the install goes like this:
# rpm -Uvh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-8.noarch.rpm
# rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm
# yum install vlc

Once VLC is installed, you will need to start the multicast stream:
$ cvlc -vvv /var/www/localhost/htdocs/ZNKR_Iaido.mp4 --sout '#rtp{mux=ts,dst=239.255.255.1}' --ttl 12

Then on the Knoppix clients, start up Gnome M-Player (the command line version would probably work, but I used the GUI), click "File," click "Open Location" and in the text window, type:
rtp://@239.255.255.1:5004/

So...what did we just do?

On the CentOS server, we added the repositories that allow you to install VLC through the CentOS package manager. Then, we installed VLC. As a NON-ROOT user (VLC will not run as root), start the command-line version of VLC, telling it to use the RTP protocol, and use the multi-cast address of 239.255.255.1 (a full discussion of multicast addressing is outside the scope of this lab, but for now, feel free to substitute any address in the subnet 239.255.0.0/16).

On the client side, we are again saying to use the RTP protocol, we are referencing the same multicast address, and specifying the port 5004 in the URL.

</rabbit-trail>Back to networking...

Now that we have multicast running, what does that do to our bandwidth usage? Let's find out! Start up two Knoppix clients, start the multicast stream on the CentOS server, clear the counters on FA2/0 on R1, and let's see:

R1#sho int fa2/0
...
5 minute output rate 449000 bits/sec, 43 packets/sec
...

That's much better! There's a little overhead for the multicast protocol itself, but it's still around 30% less than the unicast bandwidth utilization with two clients.

One interesting aspect of multicast is that, from the client's perspective, multicast is much more like broadcast television than video-on-demand. That is, with a unicast stream, when you request a resource, you start at the beginning of the video (or audio or...) stream. With multicast, you are joining a stream already in progress, which means you will be watching (or listening or...) to the exact same portion of the stream as other users.

Look at the two following screenshots. In the first screenshot, the videos are obviously playing at different locations in the video stream:

However, in the second screenshot, you can see that the stream on the right has been playing for 13 minutes and 45 seconds and the one on the left has been playing for only 7 minutes and 50 seconds...but both are playing the exact same point in the video stream:

With that, we'll close out this lab, even though we've only scratched the surface of multicast. More to come!