Source Specific Multicast (SSM)

Lessons Discussion
21

Hello Sean

Keep in mind that just because the SSM multicast range is being used, it does not mean that SSM is actually employed. Cisco devices can apply SSM to any range, simply by using the config found in this particular lesson. The SSM configuration is necessarily configured on a Cisco IOS router.

In order to get SSM to function correctly, the receivers (hosts) must support IGMPv3. The multicast source (and thus the application you have that attempts to utilize multicast SSM) cannot enable it. It must be enabled on the network by an IOS router, and on the hosts themselves.

It is likely that your network is not employing SSM at all, and is running all multicast applications using any source multicast. As you investigate further, let us know how you get along, and if we can be of further help.

I hope this has been helpful!

Laz

22

Thanks Laz,
In SSM multicast Iā€™m wondering about IGMPV3. Where exactly it is needed ? As you say ā€œIn order to get SSM to function correctly, the receivers (hosts) must support IGMPv3ā€ and thats fine but what about the SVIā€™s on the subnets on the switches that the hosts are connected to.
Do these need to also run IGMPV3 ?
Lets say for example in a strict Layer 2 multicast network (Not multicast routing).
Lets say in this layer 2 multicast network I have 10 switches daisy chained in a row numbered from left to right switch 1 to switch 10.
Lets say on switch one (the furthest left) I have my multicast source and switch 5 in the middle is the Querier and switch 10 (the furthest right) I have my receiver lets say a windows server.
If the windows server (receiver) is running IGMPV3 and configured for SSM does the SVI on that subnet on the switch 10 have to be running IGMPV3 also or can it run IGMPV2 and same for all the switches in between source and receiver ? Also with the Querier, Does the querier have to be running IGMPV3 for SSM to work or can it to be running IGMPV2 ?
Iā€™m trying to understand the relationship between the IGMP version on the SVIā€™s and IGMP version on the receivers (hosts) in a real world scenario as a lot of the examples here use routers and switches to simulate end devices.
Is IGMP version 3 needed on all the SVIā€™s in the subnet or just the querier or none and just the host or its required on everything ?
Thanks Laz.

23

Hello Sean

IGMPv3 includes a field within the IGMP message for the source address. This information is needed to enable SSM. Which devices need this information? Well, the multicast receiver uses that field to specify from which source it is expecting multicast traffic. The last hop router must also support IGMPv3 so it can determine if a host should or should not receive multicast traffic from a particular source.

Now, do your layer 2 switches need to support IGMPv3 to achieve IGMP snooping? No they donā€™t. IGMP snooping simply keeps a record of multicast IP group and host MAC address so that multicast traffic is not flooded to all hosts, but goes only to those hosts that have requested it. Because IGMPv3 is backward compatible with v2 and v1, any switches receiving v3 messages will be able to interpret them as v2 or v1 if needed. However, enabling IGMPv3 snooping on switches will add one more parameter to the mapping of host MAC addresses to multicast groups. In other words, it will use source-based filtering as well. More on this can be found in the following Cisco documentation:

Now you asked about SVIs. SVIs are essentially the last hop router because they are Layer 3 interfaces. Also, the example you described was a strict layer 2 multicast network, but if you have SVIs on each switch, then there is Layer 3 as well, so the example given is not quite clear. However, I hope your question has been answeredā€¦ If not please clarify, and we can continue the conversation.

I hope this has been helpful!

Laz

24

Many thanks Laz,
I always appreciate the time you put into this site.
I read through that document but its still not 100% clear.
In the example I was giving it is strictly layer two multicast (not multicast routing).
I understand the last hop router would need IGMPV3 for SSM but in the strict layer two multicast setup with zero routing, I have one querier on the Core switch in the middle of the network. This querier is not a gateway for any of the receivers and neither are the SVIā€™s on any of the switches along the way. The SVIā€™s on all the switches are in the same subnet as the multicast traffic but they are not gateways or anything. They are just for in band management purposes.Given that scenario would the SVIā€™s still be classed as last hop routers and needs IGMPV3 configured on them ? Its all just one big flat layer two network with one vlan. The default gateway on the network is a firewall but it does not participate in multicast.
So Iā€™m wondering where if anywhere would IGMPV3 need to be enabled if the receivers were set for SSM and running IGMPV3.
For example is it needed on the SVI on the Querier ? or perhaps it is needed on the default gateway for all the receivers and switches that being the Firewall interface ?
But then again maybe not as the senders and receivers are all on the the same subnet so the default gateway (Firewall) should not even be involved ?
Would the SVIā€™s still count as last hop routers in this situation as they are not routing any of the multicast traffic ?
Thanks

25

Hello Sean

First of all, if you have a single flat Layer 2 topology, then any SVIs on the switches themselves donā€™t play the role of a gateway, as you mention. That means that they donā€™t play the role of the last hop router. Now in your scenario, you are also saying that we are not using a multicast router, but weā€™ll be using a querier instead, much like in the IGMP snooping without a router lesson.

You are correct, if the firewall is not involved in multicast at all, since it is not configured to do so, so multicast only takes place within your Layer 2 segment. The firewall is simply the default gateway for unicast traffic of the network, but it does not play any role in multicast.

Now in such a scenario, without having gone into the lab to check this out, my hunch is that IGMPv3 is needed at the receivers, as you mention, and also at the querier. Only an IGMPv3 querier will be able to process the source addresses included in the IGMPv3 messages. It would be a great exercise to set this up in the lab to check it out and examine the behavior. Recreating the lab in the IGMP snooping without a router lesson employing IGMPv3 would probably be the definitive test to determine the behavior.

If youā€™re up to it, it would be a great experiment, and if you do it let us know your results.

I hope this has been helpful!

Laz

26

Hey rene ,thank you very much
I dont understand one thing:
Why i need to config ip igmp version 3 on the d.g of the source? I think i enable ip igmp version 3 on the d.g the lisseners
Thank you

27

Hello Daniel

According to this Cisco documentation:

To run SSM with IGMPv3, SSM must be supported in the Cisco IOS router, the host where the application is running, and the application itself.

The application in this case is the source of the multicast traffic. So, for an SSM deployment to work correctly, both the source and the receivers need to support IGMPv3. The source needs to send IGMPv3 membership reports to specify the source address of the multicast traffic, and the receivers need to process these reports and join the desired multicast groups.

I hope this has been helpful!

Laz

28

Hey lagapides , thank you very much
If i understand coorectly, if the source dont run the application so i dont have to configure igmpv3 only on the d.g on thr lisseners .
If the source run the application so i have to configure igmpv3 on the d.g on the source
I understand correctly?
Have a good week

29

Hello Daniel

Yes, you got it! I hope you have a good week too!

Laz

30

Hi,

I set up a lab and found that the router interfaces on which I ran the join command (to simulate a host, like in your example) didnā€™t actually need to have IGMP v3 configured.

(R5)-----Gi0/1.58--------(R8)--------Gi0/1.108-------(R10)

Joining the group:

R10(config)#int Gi0/1.108
R10(config-subif)#ip igmp join-group 232.1.1.1 source 150.1.9.9

Verifying IGMP version on the interface:

R10# sh ip igmp inter
GigabitEthernet0/1.108 is up, line protocol is up
Internet address is 155.1.108.10/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2

Confirming the interface has joined the group:

R10#sh ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
232.1.1.1 GigabitEthernet0/1.108 00:28:09 stopped 155.1.108.10

Upstream router R8ā€™s mroute table:

R8:
(150.1.9.9, 232.1.1.1), 00:23:05/00:03:02, flags: sT
Incoming interface: GigabitEthernet0/1.58, RPF nbr 155.1.58.5
Outgoing interface list:
GigabitEthernet0/1.108, Forward/Sparse, 00:23:05/00:03:02

In fact, even if I try to join a group without specifying a source, it complains, despite that interface still being v2:

R10(config-subif)#ip igmp join-group 232.1.1.1
Ignoring request to join group 232.1.1.1, SSM group without source specified

I can a ping from the source to 232.1.1.1 and that interface was responding:

R9#ping 232.1.1.1 repeat 1000 source Lo0
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.9.9

Reply to request 0 from 155.1.108.10, 16 ms
Reply to request 1 from 155.1.108.10, 13 ms

Could it be working because the router itself is running multicast and as a result not actually truly representing a host receiver? Thatā€™s the only thing I can conclude.

And by the way, for the sh ip igmp interfaces output, what is the difference between IGMP host version and router version?

Thanks,

Sam

31

Hello Samir

Doing some more research, I have found the following:

When you issue the ip pim ssm default command, you tell the routers that the default SSM addresses will be used for SSM. When the router sees these addresses, it automatically assumes SSM is active for any communications to those addresses. So, it will assume that any IGMP join message will also include the source. If it is not included, it complains because it knows that the destination address by definition requires a source address. If you statically assign it, then under these conditions, it is possible to run SSM without the use of IGMPv3.

This approach works as long as all the receivers connected to the router are interested in multicast traffic from the same source. However, it is less flexible than using IGMPv3, as you cannot specify different sources for different receivers within the SSM range. In addition, this approach does not provide the dynamic behavior and flexibility that using IGMPv3 with SSM can offer.

For a truly dynamic SSM configuration on the receiver, you would typically use an application that can handle multicast traffic, join/leave SSM groups, and dynamically change the source address based on user input or other factors. For such flexibility, IGMPv3 must be enabled.

I hope this has been helpful!

Laz

32

Great lesson, but what if I want to introduce SSM in parallel with another multicast method currently running in the network? Can I create a VRF to achieve this? And if so which portions of the SSM config are in the VRF and what remains global?

The default Multicast must be set to SSM, but my goal for using VRFs means I must configure SSM within the VRF?

I have to ensure I configure the VRF to use multicast routing w/ the command,
ip multicast-routing vrf <vrf name>

I have to ensure the switch is configured for IGMPv3 globally (which I believe also covers VRFs). As such I should be able to configure IGMPv3 globally. Can you share the commands for both NX-OS and Catalyst for configuring a router/L3 switch to use IGMPv3?

Each interface must have the following for being associated with my desired VRF and for essential SSM

vrf member VRF NAME
ip pim sparse-mode

ip igmpv3

ip igmp VRF name join-group group IP source source IP

The current unicast underlay ensures my source and receivers all have known routing to one another, but if I build my SSM within a VRF, do I need to include VRF-specific routing as well?

Additionally do only the receivers and Senders M-Cast routers need IGMP snooping, with the routers traversed in transit simply needing to be set for IGMPv3 and multicast?
I.e. in a network where the source is two hops away from the receivers, to what extent do the two transit hop routers need to be configured to pass SSM traffic between source and receivers?

Finally, please explain the optional address-family ipv4 multicast command when creating VRF?

33

Hello Chad

If you have a topology on which you run multicast, and you want to introduce SSM in parallel with Any Source Multicast (ASM), then it is possible to introduce VRFs in order to segregate the multicast operations. When implementing multicast in an environment where VRFs are used, each multicast instance remains contained within the VRF. Specifically keep in mind that:

  • When you enable a multicast routing protocol like PIM within a VRF, that instance of PIM operates independently of PIM instances in other VRFs or in the global routing table. PIM neighbors, the RP, and multicast distribution trees are all specific to the VRF.
    *Similarly, IGMP operates independently within each VRF. IGMP reports from hosts are processed by the IGMP instance in the VRF to which the hosts belong.
    *By default, multicast traffic is not shared across VRFs. A source in one VRF cannot send multicast traffic to receivers in another VRF. If sharing of multicast traffic across VRFs is required, Multicast VPN (MVPN) or similar solutions would need to be implemented.

So it is possible to introduce VRFs to segregate SSM from ASM. However, the question is, do you really want to do this?

Introducing VRFs will introduce a level of complexity to your network that may be counterproductive. VRFs are applied to interfaces, so unicast traffic will be affected by VRF configurations. You must ensure that routing for unicast traffic is also taken care of.

I would avoid using VRFs in this situation because it is possible to allow both SSM and ASM multicast to operate simultaneously over the same infrastructure. Both ASM and SSM can coexist in the same network, with some groups being serviced by ASM and others by SSM, depending on the needs of the receivers. The network can distinguish between ASM and SSM groups based on the group addresses. A specific range of group addresses can be set aside for SSM, and this can be configured using an access list. For more info on this, take a look at the NetworkLessons note on how to configure ASM and SSM on the same network.

I hope this has been helpful!

Laz

34

Hi Team,

i dont see the flap for SSM in the receiver , what could be the issue ?
I have enabled SSM globally and IGMP version 3 as well, but still the flag has not been set at the receiver. However, in the multicast route table, I can see the ST flag for this group.

image
image951Ɨ628 22 KB

35

Hello Sathish

Based on your description it is not immediately clear as to what the specific problem may be. Youā€™ve enabled SSM globally and set IGMP version 3, which are prerequisites for SSM operation. However, the lack of the SSM flag in the receiverā€™s IGMP group table (even though you can see the ST flag in the multicast routing table) could point to a few potential issues:

  1. IGMP Snooping or Filtering: If IGMP snooping or filtering is enabled on your network switch, it may be interfering with the proper registration of the SSM group. Verify that IGMP snooping is configured correctly or try disabling it temporarily to see if the SSM flag appears.

  2. Source-Specific Group Membership: Ensure that the specific source IP youā€™ve configured (192.168.15.1 for 239.1.1.1) is reachable and properly advertised in the multicast routing table. SSM relies on both the group and source, so any issue with the source announcement might prevent the flag from showing up at the receiver.

  3. PIM Configuration on All Interfaces: Make sure PIM Sparse Mode (PIM-SM) is enabled on all relevant interfaces on the network devices in the path, including the receiverā€™s interface. Inconsistent PIM configuration can sometimes cause multicast traffic to not reach the receiver correctly.

  4. Verification of IGMP Membership Reports: Check if the receiver is indeed sending IGMPv3 membership reports with the correct source-specific information. Debugging IGMP membership reports on the receiver might help confirm that the correct SSM join messages are being sent and received.

  5. IGMP Querier Election: Verify that the IGMP querier is correctly elected in the network. In some cases, issues with the IGMP querier can cause unexpected multicast behavior.

You could try enabling debugging for IGMP and PIM on the receiver to gather more detailed insights into whatā€™s happening with the group membership. The command debug ip igmp and debug ip pim should help provide additional information.

One other issue that may be relevant is the fact that this is being setup on a switch (I see the relevant prompt). Some switch platforms may not fully support all the features of multicast, so even if you have configured it, its behavior may be unpredictable. This should be discovered with the troubleshooting processes described above, especially the debugs indicated. Let us know how you get along!

I hope this has been helpful!

Laz