Playing with Multicast – Part 2.

The part 1 of multicast was simply doing the streaming within a local area network. This time, I will put my multicast lab to a level higher and put a router between the sender and receiver.

The test bed for this time will involve a simple routings. Please refer to the topology below.

To keep the multicast lab simple, it will be running on Sparse mode and using static RP instead of dynamic.

TOPOLOGY:

Components:
1x Ubuntus as sender
1x Windows XP as receiver.
1x Junos router

Installation:
The software for both sender and receiver are remain the same from part 1. Please refer to multicast – part 1 for detail:
https://networkingnotesblog.wordpress.com/2015/12/12/playing-with-multicast-part-1/

Configuration:

– Router:
The router for this test bed is a virtual MX. It configures with minimum configuration to keep the multicast running, and it has the interface and PIM configured.
The interface of ge-0/0/0.101 is connecting to the sender, and ge-0/0/0.102 is connecting to receiver. Both connections are separated by VLANs.
The lt-0/0/0 are the interfaces to inter connect to other virtual routers. It is not required for this test bed.
PIM (Protocol Independent Multicast) are enabled and assigned the upstream and downstream interfaces to multicast transfer. The PIM mode is configured as spare-dense, since it allows me to switch between 2 different mode with couple more commands. But we are running sparse mode for this lab. The Rendezvous Point is set as static and the address is pointing at the sender.

Testing:

We will be testing the connectivity to ensure both sender and receiver can reach to each other.

– Windows XP:
The IP address of XP is set as 192.168.102.15/24. Based on the traceroute result to Ubuntu, it routes via the Junos router and reach to the destination on the second hop as expected. In this case, we can ensure the sender is able to reach the receiver in both direction.

– On router:

This is the output of “show interface terse” and we can ensure the first hop of receiver was routed via this router.

*If we do not input the command of “set protocol pim rp static ……” the “show pim join” does not have any result, and the streaming of multicast won’t work without the “set protocol pim rp static ……”.

Therefore, the following is the expected result.

Testing different behaviours:

– If we turn on the streaming on the Ubuntu streaming server only and keep the receiver VLC shut, the router has the following information. It means there is a traffic sending to the group of 224.0.1.40 from the source of 192.168.101.10. It ensures there are active multicast data sending out.

– If the receiver has the VLC player activated and sending the request for steaming single, and the Ubuntu server is not sending out any multicast traffic, the router will result with the following.
The router will have an entry with a requested group IP shown and with a * as source. When we see this message, we can definately ensure there is a receiver waiting for the single but out multicast traffic shows up.

Once the VLC player on XP is waiting for the multicast stream and the Ubuntu server is sending out multicast traffic, the router will have the output of following. The first entry from the receivers and the second entry from the sender will be listed out as expected. If we are looking for a successful multicast streaming, we are expected to have both entries shows up.

 

 

 

 

 

 

 

 

 

The snapshot below is from Windows XP and receiving the multicast data stream from Ubuntu that is 1 hops from the router.

 

 

 

 

 

 

Part 1 of the multicast post starts with 1x receiver and 1x sender in a local area network.
https://networkingnotesblog.wordpress.com/2015/12/12/playing-with-multicast-part-1/

Part 3 of the multicast post is describes the lab with 3 routers and one for each sender and receiver.
(still organizing the information)

Part 4 of the multicast post is putting the lab from part 2 onto a MPLS VPN platform.
(still organizing the information)