Multicast lab 5: Source-Specific Multicast (SSM)

Multicast lab 5: Source-Specific Multicast (SSM)

After giving a two-days training to a customer on multicast technology, I take the opportunity to have my lab and the configurations ready to share with you a suite of five different multicast configurations examples. And, how to make some tests and troubleshooting. These examples are based on the labs I used to practice the CCIE R&S practical exam.

Content of the posts

 

Including, for each topic:

  1. A network drawing
  2. The configuration details.
  3. The tests and debug outputs.
  4. When possible, a failover test and debug outputs.
  5. Some basic troubleshooting.

 

Source-Specific multicast (SSM)

 

Lab design and description

The network design is the same for every scenario:

I use four layer-3 Cisco 3650 catalyst switches running IOS-XE. With layer-3 ptp interfaces between them to create a small layer-3 network. OSPF is running between the switches to advertise all the networks: the ptp networks, the loopback0 interfaces and the VLAN10 of SW-1, where is the multicast source.

For the multicast source, I use a laptop running two VLC instances, sending video stream traffic to 233.1.2.3 and 234.1.2.3, both on port 30’001.

The receiver will be simulated by the loopback0 interface of SW-4.

(Click on the image to see a larger version)

 

On this scenario, we will use PIM SSM.

ASM (Any Source Multicast) is defined as receivers joining groups and receiving traffic from any source. But, SSM instead is utilized to identify a specific source a receiver wishes to receive traffic from. We still use PIM sparse-mode but RP are no longer required since receivers subscribe directly to a source.

Another important point, with PIM-SSM we need to use IGMPv3. IGMP Version 3 supports source filtering, which is required for SSM.

 

 

Configuration

First, we need to configure PIM on the interfaces between the four switches, on the interface where is source is located (VLAN10 of SW-1), the interface of the clients or receivers (in this case, the loopback0 of SW-4) and the loopback0 of SW-2. For this, we use the ip pim spare-mode command.

Do not forget to also configure ip multicast-routing, like below:

SW-1,2,3,4:
SW-X(config)#ip multicast-routing

SW-1,2,3,4: on the ptp interfaces, VLAN10 of SW-1, lo0 of SW-2 and SW-4: 
SW-X(config-if)#ip pim sparse-mode

 

Then, we configure PIM-SSM. Here, I specify the group 234.1.2.3 with the access-list 12:

SW-2#config t
Enter configuration commands, one per line. End with CNTL/Z.
SW-2(config)#access-list 12 permit 234.1.2.3
!
SW-2(config)#ip pim ssm range 12

Important: there are two ways to configure PIM SSM:

  1. With the command ip pim ssm default: in this case the SSM group will be the default multicast-SSM group range 232.0.0.0/8.
  2. Or with the command ip pim ssm range ACL: in this case, the SSM group will be defined by the access-list and can be outside the default SSM range of 232.0.0.0/8.

 

Tests and debugging

 

IGMP join

Now, let’s make an IGMP join for the group 234.1.2.3 on the loopback0 of SW-4.

SW-4#config t
SW-4(config)#int lo
SW-4(config-if)#ip igmp join-group 234.1.2.3 source 10.10.10.10

Here, we use IGMPv3, where we need to specify the source (10.10.10.10).

 

 

Now, if we look at the multicast routing table of SW-4, we can see we use PIM-SSM, because of the “s” flag and the multicast traffic is coming through SW-3, because we use shortest-path tree (T flag):

SW-4#show 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, E - Extranet,
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

(10.10.10.10, 234.1.2.3), 00:00:08/00:02:59, flags: sLTI
Incoming interface: GigabitEthernet1/0/3, RPF nbr 10.10.34.3
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:08/00:02:59

SW-4#show ip mroute count 
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
2 routes using 1352 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 234.1.2.3, Source count: 1, Packets forwarded: 906, Packets received: 906
Source: 10.10.10.10/32, Forwarding: 906/71/686/390, Other: 906/0/0

 

 

Failover test

 

Path failover

Now, let’s see what happens if we cut the link between SW-3 and SW-4.

 

  • Shutdown of the link between SW3 and SW4:
SW-3(config)#int gi1/0/4
SW-3(config-if)#shut

 

  • Result: on the multicast routing-table of SW4 we receive now the multicast traffic from SW-2 (Gi1/0/2), no problem here:
SW-4#show 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, E - Extranet,
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

(10.10.10.10, 234.1.2.3), 00:05:24/stopped, flags: sLTI
Incoming interface: GigabitEthernet1/0/2, RPF nbr 10.10.24.2
Outgoing interface list:
Loopback0, Forward/Sparse, 00:05:24/00:02:48

We continue to receive the traffic.

 

RPF problem

Now, let’s put the link between SW-3 and SW-4 back in service, but without PIM between SW-3 and SW-4.

Here is a drawing of what we will test:

(Click on the image to see a larger version)

 

  • First, let’s remove IP PIM from the interface Gi1/0/3 of SW-4 and Gi1/0/4 of SW-3, and remove the IGMP join on SW-4
SW-4(config)#int gi1/0/3
SW-4(config-if)#no ip pim
!
SW-3(config)#int gi1/0/4
SW-3(config-if)#no ip pim
!
SW-4(config)#int lo0
SW-4(config-if)#no ip igmp join 234.1.2.3 source 10.10.10.10

 

  • Start the mrouting debugging with the command: debug ip mrouting on SW-4, and make the IGMP join again on the Loopback0:
SW-4(config)#int lo0
SW-4(config-if)#ip igmp join-group 234.1.2.3 source 10.10.10.10

MRT(0): Update (*,234.1.2.3), RPF (unknown, 0.0.0.0, 0/0)
MRT(0): Update (10.10.10.10,234.1.2.3), RPF (GigabitEthernet1/0/3, 10.10.34.3, 110/300)
MRT(0): Set 'L' flag for (10.10.10.10, 234.1.2.3)
MRT(0): WAVL Insert interface: Loopback0 in (10.10.10.10,234.1.2.3) Successful
MRT(0): set min mtu for (10.10.10.10, 234.1.2.3) 18010->18010
MRT(0): Add Loopback0/234.1.2.3 to the olist of (10.10.10.10, 234.1.2.3), Forward state - MAC not built
(... after a while ...)
MRT(0): Cancel delete, IGMP members for (10.10.10.10, 234.1.2.3)

It seems there is a RPF problem, right?

If we check the multicast routing table on SW-4, we have a confirmation:

SW-4#show 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, E - Extranet,
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

(10.10.10.10, 234.1.2.3), 00:07:48/stopped, flags: sLTI
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:07:48/00:01:11

We saw on the lab-1: the source IP address in the packet should be reachable via the receiving interface. In this case, the route to reach 10.10.10.10 is via SW-3 (OSPF with higher bandwidth) and the multicast traffic comes from the interface to SW-2. So, we have a RPF failure here.

We can confirm this with the command:

SW-4#show ip rpf 10.10.10.10
failed, no route exists

 

But, 10.10.10.10 is still reachable from SW-4:

SW-4#ping 10.10.10.10 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

 

How can we solve this? The simplest workaround is to configure a static mroute on SW-4 for 10.10.10.10, pointing to 10.10.24.2 (SW-2):

SW-4(config)#ip mroute 10.10.10.10 255.255.255.255 10.10.24.2
!
MRT(0): Triggered RPF check called by Static mrt
MRT(0): (10.10.10.10,234.1.2.3), RPF change from  /0.0.0.0 to GigabitEthernet1/0/2/10.10.24.2
PIM(0): Insert (10.10.10.10,234.1.2.3) join in nbr 10.10.24.2's queue
PIM(0): Building Join/Prune packet for nbr 10.10.24.2
PIM(0):  Adding v2 (10.10.10.10/32, 234.1.2.3), S-bit Join
PIM(0): Send v2 join/prune to 10.10.24.2 (GigabitEthernet1/0/2)

We can see on the debugging, the RPF changes from 0.0.0.0 to 10.10.24.2 via Gi1/0/2.

 

And now, we have the multicast-route on the routing table, with the Mroute argument:

SW-4(config)#do show 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, E - Extranet,
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

(10.10.10.10, 234.1.2.3), 00:02:31/00:00:28, flags: sLTI
Incoming interface: GigabitEthernet1/0/2, RPF nbr 10.10.24.2, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 00:02:31/00:00:28

 

 

Troubleshooting

Most of the troubleshooting and debugging methods are similar as the multicast lab-1. Please refer to the multicast lab-1.

 

 

Others posts of this series

 


Did you like this article? Please share it…

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *