Testing Source Specific Multicast

A student on OSL recently requested information on how to test SSM. He was testing with ping as we would with typical Multicast configurations and it wasn’t working.

Unfortunately Source Specific Multicast doesn’t work with this test as SSM relies on the requester to specify the Unicast Source to receive the multicast traffic from. I responded with this same information on OSL but am posting it here to have a more readable format and better archiving for access in the future.

Here is the setup I will work with for this example:

So we will have three Routers and a Sender and Receiver. To allow the sender and receiver to communicate there are a few requirements for this setup.
1. All Router interfaces should be configured for PIM Sparse-Mode. (I could also use Sparse-dense-mode but there really is no reason to have dense in the topology)
2. Enable PIM SSM default on all the routers. Although only the receiver’s closest router requires this command I would recommend adding it to the entire topology.
3. Enable IMGPv3 on client facing interfaces. I also have added this to all my interfaces as it quicker for me to copy and paste the same commands on all interfaces but only the client interface requires it.

I am not going to describe the other configuration such as routing and base configuration as that is not relevant to this setup. So let’s Do the configuration.

R2

ip multicast-routing
!
interface Serial0/1/0.256
 ip pim sparse-mode
 ip igmp version 3
!
interface Virtual-Template 1
 ip pim sparse-mode
 ip igmp version 3
!
ip pim ssm default

R4

ip multicast-routing
!
interface FastEthernet0/1
 ip pim sparse-mode
 ip igmp version 3
!
interface Virtual-Template 1
 ip pim sparse-mode
 ip igmp version 3
!
ip pim ssm default

R5

ip multicast-routing
!
interface FastEthernet0/1
 ip pim sparse-mode
 ip igmp version 3
!
interface Serial0/1/0
 ip pim sparse-mode
 ip igmp version 3
!
ip pim ssm default

Now to send the traffic. As I have already mentioned ping isn’t going to work for us in this instance. So I have downloaded a few free tools I found on the internet to assist me in completing this test.

http://www-personal.umich.edu/~bdr/et/mcast-windows.html#download

http://www.videolan.org/vlc/download-windows.html

The Multicast tool from the University of Michigan website is useful for generating the Multicast traffic into the network and seeing if it is received. The shortcoming of the tool is it only supports IGMPv2. Since SSM relies on IGMPv3 messages for communication I needed the second VLC tool to generate the IGMPv3 membership messages so that the XP workstation would make the request to receive multicast traffic for the group. Without using VLC I would see messages as follows on the receiving router:

R4(config-if)#
Feb  5 01:37:26.187: IGMP(0): Received Group record for group 232.10.45.10, mode 2 from
192.1.49.100 for 0 sources
Feb  5 01:37:26.187: IGMP(0): Group Record mode 2 for SSM group 232.10.45.10 from 192.1.49.100
on FastEthernet0/1, ignored
R4(config-if)#

Now lets run the test configuration

On the Server I installed the application and changed to the directory and ran the test.

c:\mcast\bin\msender 232.10.45.10 10000
send multicast packet 1 to 232.10.45.10 10000 bytes 32
send multicast packet 2 to 232.10.45.10 10000 bytes 32
send multicast packet 3 to 232.10.45.10 10000 bytes 32
send multicast packet 4 to 232.10.45.10 10000 bytes 32
send multicast packet 5 to 232.10.45.10 10000 bytes 32
send multicast packet 6 to 232.10.45.10 10000 bytes 32
send multicast packet 7 to 232.10.45.10 10000 bytes 32
send multicast packet 8 to 232.10.45.10 10000 bytes 32
send multicast packet 9 to 232.10.45.10 10000 bytes 32
send multicast packet 10 to 232.10.45.10 10000 bytes 32
send multicast packet 11 to 232.10.45.10 10000 bytes 32
send multicast packet 12 to 232.10.45.10 10000 bytes 32
send multicast packet 13 to 232.10.45.10 10000 bytes 32
send multicast packet 14 to 232.10.45.10 10000 bytes 32
send multicast packet 15 to 232.10.45.10 10000 bytes 32

Now I will check R5 and see if he is receiving the traffic from the sender. It won’t be sending out any interface yet as the client hasn’t requested to join the group and we are running Sparse-Mode.

R5(config-router-af)#do sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(4.4.4.4, 232.0.0.1), 1w2d/00:02:48, flags: sTIZ
  Incoming interface: Serial0/1/0, RPF nbr 100.100.100.2
  Outgoing interface list:
    MVRF VRFA, Forward/Sparse, 1w2d/00:02:35

(5.5.5.5, 232.0.0.1), 1w2d/00:03:07, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1/0, Forward/Sparse, 1w2d/00:02:47

(10.1.1.100, 232.10.45.10), 00:01:23/00:02:56, flags: sPT
  Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(*, 224.0.1.40), 1w2d/00:02:37, RP 0.0.0.0, flags: DPL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

R5(config-router-af)#

So we know the multicast traffic is being received by the originating router. Now we can configure The receiver to request the group traffic. First I can turn a debug on R4 to see the Join Request using the command “debug ip igmp”:

 R4(config-if)#
Feb  5 01:39:58.275: IGMP(0): Received v3 Report for 1 group on FastEthernet0/1 from 192.1.49.100
Feb  5 01:39:58.275: IGMP(0): Received Group record for group 232.10.45.10, mode 3 from
192.1.49.100 for 1 sources
Feb  5 01:39:58.279: IGMP(0): WAVL Insert group: 232.10.45.10 interface: FastEthernet0/1
Successful
Feb  5 01:39:58.279: IGMP(0): Create source 10.1.1.100
Feb  5 01:39:58.279: IGMP(0): Updating expiration time on (10.1.1.100,232.10.45.10) to 180 secs
Feb  5 01:39:58.279: IGMP(0): Setting source flags 4 on (10.1.1.100,232.10.45.10)
Feb  5 01:39:58.279: IGMP(0): MRT Add/Update FastEthernet0/1 for (10.1.1.100,232.10.45.10) by 0
R4(config-if)#
Feb  5 01:39:59.187: IGMP(0): Received v3 Report for 1 group on FastEthernet0/1 from 192.1.49.100
Feb  5 01:39:59.187: IGMP(0): Received Group record for group 232.10.45.10, mode 3 from
192.1.49.100 for 1 sources
Feb  5 01:39:59.187: IGMP(0): MRT Add/Update FastEthernet0/1 for (10.1.1.100,232.10.45.10) by 0
Feb  5 01:39:59.187: IGMP(0): Updating expiration time on (10.1.1.100,232.10.45.10) to 180 secs
R4(config-if)#

Notice that the receiver with the VLC player makes the Group request for 232.10.45.10 now

Looking at the MROUTE table for R4 I see the following

R4(config-if)#do sh ip mroute ssm
(5.5.5.5, 232.0.0.1), 1w2d/00:02:55, flags: sTIZ
  Incoming interface: Virtual-Access3, RPF nbr 100.100.24.2
  Outgoing interface list:
    MVRF VRFA, Forward/Sparse, 1w2d/00:02:51

(4.4.4.4, 232.0.0.1), 1w2d/00:03:25, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Virtual-Access3, Forward/Sparse, 1w2d/00:02:37

(10.1.1.100, 232.10.45.10), 00:07:44/00:02:56, flags: sTI
  Incoming interface: Virtual-Access3, RPF nbr 100.100.24.2
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse, 00:00:31/00:02:43

R4(config-if)#

Notice that R4 is receiving the stream now from the originating PIM router

R5(config-if)#do sh ip mroute ssm
(4.4.4.4, 232.0.0.1), 1w2d/00:02:36, flags: sTIZ
  Incoming interface: Serial0/1/0, RPF nbr 100.100.100.2
  Outgoing interface list:
    MVRF VRFA, Forward/Sparse, 1w2d/00:02:05

(5.5.5.5, 232.0.0.1), 1w2d/00:03:26, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1/0, Forward/Sparse, 1w2d/00:03:05

(10.1.1.100, 232.1.1.100), 03:36:15/00:02:56, flags: sPT
  Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(10.1.1.100, 232.10.45.10), 01:04:03/00:03:27, flags: sT
  Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/1/0, Forward/Sparse, 00:20:17/00:02:36

R5(config-if)#

And for a very brief time I can use the multicast tool from University of Michigan to test receiving traffic from the sender as well.

C:\mcast\bin>mreceiver 232.10.45.10 10000
packet 1 - received group 232.10.45.10 from 10.1.1.100:10000 32 bytes
packet 2 - received group 232.10.45.10 from 10.1.1.100:10000 32 bytes
packet 3 - received group 232.10.45.10 from 10.1.1.100:10000 32 bytes
packet 4 - received group 232.10.45.10 from 10.1.1.100:10000 32 bytes
^C
C:\mcast\bin>

So we were able to successfully send and receive Multicast packets through our PIM SSM Sparse-Mode domain.

I hope this helps to show sometimes you need to do a little digging to find ways to test technologies to better understand what you are configuring for the CCIE Exam.

Regards,

Tyson Scott – CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor – IPexpert, Inc.
Mailto: tscott@ipexpert.com

Testing Source Specific Multicast, 4.0 out of 5 based on 5 ratings

Tags: CCIE, CCIE R&S, CCIE Routing & Switching, CCIE Service Provider, CCIE SP, Source Specific Multicast, SSM