There were many times during my CCIE Lab preparation that I wanted to have an actual Multicast server to lab up multicasting but I had always been left with ping to test and troubleshoot multicasting. There were 2 problems to it. The first is that it is a dull and boring multicast source which can be easily switched from one router to the other which if you think, is not a good thing because multicast sources are servers which remain steady in one place. When you shift your multicast source, clarity is lost about where the source is and where the destinations could be. The second is that a receiver is simulated using an IGMP join group which again is a simulation and not an actual receiver. It could be useful in testing but not perfect. With the release of GNS3 with Virtualbox, we can simulate the whole Internet over it, if we wished (and obviously if we had resources for it). By using GNS3 and Virtualbox, we are going to send Multicast Traffic from multicast source to any multicast receiver who intends to listen to it. In this blog, we will see how to send and receive actual multicast traffic through a routed network. I could have just put a multicast source and receiver on the same router to show that multicasting works on GNS3 and Virtualbox but it wouldn’t help anyone of us gaining knowledge. So I decided to run multicasting on a 6 Router topology so that we could run multicast routing, pim sparse mode and maybe look into some issues which multicasting can give us.
A fast PC with i7 processor and sufficient ram to run 6 routers and 2 Virtualbox guests.
Virtualbox with 2 graphical OSes having VLC installed. I have used Win XP and Ubuntu Studio
GNS3 Virtualbox Edition
The topology consists of 6 7200s as represented in the diagram. Cisco 7200 has been used as for some reason 3700 was losing connectivity as soon as multicast load would come. The ip addressing of the links is 1.1.x.x/24 where the 3rd octet is the router number combination of the link and the 4th octet is the router number. The Loopbacks have been numbered as 1.1.x.1/32 where the 3rd octet is the router number. OSPF is run on all links of all routers using network 0.0.0.0 255.255.255.255 area 0 command. I am using only one interface on the virtualbox host for connecting it with the GNS3. If you are using a NAT interface simultaneously, the reachability will not be complete as then both interfaces will have default route, so shutdown the NAT interface. I am using Ubuntu Studio as Multicast source and it is connected to R1. Windows XP is used as Multicast receiver (I have tried vice versa but Ubuntu is having problem in receiving multicast stream) and is connected to R5. R2 is the pim rp and it is advertised using Auto RP. R4 is the mapping Agent for the rp.
I will not cover OSPF configuration as it is pretty straightforward. We will begin by enabling multicast routing on all routers
This enables IGMP on all interfaces. Since we are using PIM Sparse mode, we will enable it on all interfaces.
Ip pim sparse-mode
Since we are running PIM Sparse mode, we require a Rendezvous Point (RP). We will announce this RP using Auto RP. We will configure Auto RP on R2 with loopback100 as the interface.
Ip pim send-rp-announce lo100 scope 15
ip pim sparse-mode
The command makes R2 the RP with loopback 100 as the source and with maximum hop reachability of 15 (TTL perimeter). 2 important things to note, one is that the loopback100 interface ip address must be reachable via IGP and second is that loopback100 interface must have PIM enabled.
Now we will configure R4 as the Mapping Agent
ip pim send-rp-discovery lo100 scope 15
This command advertises loopback100 ip address as the mapping agent for the RP. Both requirements must be met which has been mentioned for Auto RP here as well.
Since we are using sparse-mode, the non connected routers will not be able to listen to RP and MA announcements. For that we will have to make these routers run PIM dense mode for 22.214.171.124 and 126.96.36.199 which is done using the following command.
ip pim autorp listener
Mapping agents hear about RPs via the 188.8.131.52 multicast group and send RP-to-group mappings in a discovery statement via 184.108.40.206.
Before starting the multicast source or receiver, ensure that you have unicast reachability to each other and the Auto RP loopbacks. Now that our Unicast and Multicast network is up and running, we will turn our attention to the Multicast end points. We will begin with a multicast receiver first to see how it works.
Configuring Multicast Receiver
Start VLC on Windows XP and Choose Media/Open Network Stream. In address, enter rtp://@220.127.116.11:5004 (I am choosing to receive on this address and port) and Click “Play”. Now when you do a show ip igmp groups on R5, you will get 18.104.22.168 in the list which means host 192.168.10.2 (Windows XP) wants to listen to stream on group 22.214.171.124.
Configuring Multicast Source
We will start the multicast source by starting VLC on Ubuntu Studio and In the Media menu, choose “Stream”. In the Open Media dialog file tab, click “add” and choose the file you want to stream and click “Open”. At the bottom, click the “Stream” button. This opens the “Stream Output” dialog showing the source file you have chosen. Click Next to set destination. In “Destinations”, choose “RTP /MPEG Transport Stream” and click the “Add” button. In the “Address” box, enter the multicast address 126.96.36.199 and set the port at 5004. The click Next for “Option Setup” and select “Stream all elementary streams” and be sure to increase the TTL as our topology has more than 6 hops and then click stream. If you do a show ip mroute 188.8.131.52 on R1, you should see the group. Go to your windows XP VLC window and you should see a video stream.
The following image shows VLC streaming on Ubuntu Studio
The following image shows VLC getting the video stream on windows XP.
Note: It will be better to start with a video file with less resolution because GNS3 interfaces are simulated and not actual. Their bandwidth is very less as compared to actual interface bandwidth. If you wish, you can increase the resolution and see but it might pixelate but you will get the stream nonetheless. Also, click on the loop button on VLC which will make it a continuous stream.
Multicast Traffic Flow
As you might be knowing that in PIM Sparse mode, the Root path tree works only for sometime and switches to Shortest Path tree. I have purposefully placed the RP such that it is sub optimal. Later on, the traffic from Source will switch over through best path bypassing RP. This graphical view will show us how that goes about.
As soon as you start the VLC on windows XP, it will request for multicast to the router. Since R5 does not have the source, it will forward the request to R6, R4 and then R2 which is the RP. Every Router it traverses, it makes a (*, 184.108.40.206) entry as it does not know the source. Now, you could be wondering why the request only went through R5>R6>R4>R2 and not through R5>R3>R4>R2 or R5>R3>R1>R2 as all the links are equal costs and the path to RP i.e. R2 220.127.116.11 is redundant. The reason RPF check is passing only through the first path is because since both links have equal costs the next thing to be checked is neighbor ip address and R6 has a higher ip address as compared to R3. The RPF can be checked by show ip rpf 18.104.22.168 command.
When you start the Multicast source on Ubuntu Studio, the Multicast traffic goes to R1. Upon receiving the first multicast packet from the source, R1 consults the RP mapping cache and finds the RP address for the group (22.214.171.124). R1 then encapsulates the data in a Register message and sends it as a unicast directly to the RP. The RP already has a shared tree state for the group and de-encapsulates the data from the Register and forwards it down the shared tree.
Also, RP reacts with the (192.168.20.2, 126.96.36.199) Join message towards the source.
When (192.168.20.2, 188.8.131.52) Join reaches R1, the shortest-path tree (SPT) is built between the RP and R1, and the multicast packets arrive natively at the RP. Now 2 streams are coming from R1 to RP, one is through unicast and one is through multicast. The RP sends a Register-Stop message to instruct R1 to stop registering (i.e. sending stream as unicast).
R5 after receiving first multicast traffic via RP knows the source address of multicast traffic and decides to switch to SPT based on IGP reachability of source 192.168.20.2. It sends a join message via R3 to R1 for (192.168.20.2,184.108.40.206). R5 also sends a prune to RP via R6 for (192.168.20.2,220.127.116.11) telling it stop the stream via RP. The RP forwards the prune to R1 and thus multicast traffic is stopped via RP and it goes directly to receiver via R3.
The following Diagram shows the path of the multicast traffic after switching to SPT.
You can find the configurations of the 6 routers here.
I hope my post has been helpful in your life but the only guide which can help you in the hereafter is the Qur’an. You can download the English translation of the Qur’an here.