Regular multicast is known as Any Source Multicast (ASM). It is based on a many to many
model where the source can be anyone and only the group is known. For some applications
like stock trading exchange this is a good choice but for IPTV usage it makes more
sense to use SSM as it will scale better when there is no need for a RP.

ASM builds a shared tree (RPT) from the receiver to the RP and a
Shortest Path Tree (SPT) from the sender to the RP. Everything must pass through the RP
until switching over to the SPT building a tree directly from receiver to sender.
The RPT uses a (*,G) entry and the SPT uses a (S,G) entry in the MRIB.

SSM uses no RP, instead it uses IGMP version 3 to signal what channel (source) it wants
to join for a group. IGMPv3 can use INCLUDE messages that specify that only these
sources are allowed or they can use EXCLUDE to allow all sources except for these ones.

SSM has the IP range allocated and it is the default range in IOS but we can
also use SSM for other IP ranges. If we do we need to specify that with an ACL.

SSM can be enabled on all routers that should work in SSM mode but it is only
really needed on the routers that have receivers connected since that is the place
where the behavior is really changed. Instead of sending a (*,G) join to the RP
the Last Hop Router (LHR) sends a (S,G) join directly to the source.

This is the topology we are using.

It is really simple. R1 is acting as a multicast source and R2 will both simulate a client
and do filtering. R3 will simulate an end host. R1 will source the traffic from its loopback.
OSPF has been enabled on all relevant interfaces.

We will start by enabling SSM for the range on R2.

R2 will now use SSM behavior for the range. R2 will join the group
We will debug IGMP and PIM to follow everything that happens. When using igmp join-group
on an interface the router simulates IGMP report coming in on that interface. We will see
later why this is important. So first we enable debugging to the buffer.
Also we must enable multicast routing and enable PIM sparse-mode on the relevant interfaces.

Then we join the group on the Fa0/0 interface and look at what happens.

We take a look at the log.

R2 is receiving an IGMP report (created by itself) and then it generates a PIM join and
sends it to R1. We look how R1 is receiving it.

Then we verify by looking at the mroute table and by pinging.

Now we do a regular ping which should fail since we are not sourcing traffic from the loopback.

This is expected and what is good about SSM is that it makes sending to groups from any
source more difficult which is good from a security perspective.

Now we do an extended ping and source from the loopback.

So our SSM is working and we didn’t even have to enable it on R1! What if we have
clients not supporting IGMPv3? Then we could do SSM mapping. I could do that in
another post if there is interest for it. For now lets look at filtering. If we
were using ASM then we use a standard ACL and match which multicast groups are
allowed to send joins for. The joins would be (*,G) which is the same as
host in an ACL.

To filter SSM we use an extended ACL where the source in the extended ACL
is the multicast source and the destination is which group to match. We will
create an ACL permitting as source for the groups,
and Anything else will be denied which we will see by debugging IGMP.
When we are doing filtering it is important to rembember that the IGMP report
generated by the router itself (igmp join-group) will also be subject to the ACL
so make sure to include that.

Now we make R3 join a group not allowed and look at the debug output on R2.

This is from the log on R2.

As we can see that group is not allowed so the IGMP join will not make it through.
SSM can be very useful and it is not difficult to setup. In fact it is mostly
easier than ASM to setup.

Source Specific Multicast (SSM) and IGMP filtering
Tagged on:                 

16 thoughts on “Source Specific Multicast (SSM) and IGMP filtering

  • June 5, 2012 at 12:22 pm

    Excellent write up mate. Really healpful.

  • June 5, 2012 at 12:32 pm

    “So our SSM is working and we didn’t even have to enable it on R1! What if we have
    clients not supporting IGMPv3? Then we could do SSM mapping. I could do that in
    another post if there is interest for it.”

    There is interest 😀

  • June 5, 2012 at 12:43 pm

    Great. I’ll do a followup in a couple of days unless I’m rushing to the hospital to become a father 🙂

    • June 6, 2012 at 11:09 am

      That has definitely priority 😉 Nice blog post. I liked the review on bascis and then going int o debugs. /me votes for another post on ssm mapping as well 😀

  • June 7, 2012 at 9:47 pm

    Do the followup.

    p.s.: Are you a father now? 🙂

    • June 7, 2012 at 11:38 pm

      I’m working on it 🙂

      I am a father but the second one is still due any day now.

  • July 21, 2012 at 8:20 am

    Dear Daniel Dib,

    Can we summarize this as


    In Any Source Multicast (ASM), it is a Shared Tree (*, G) from multicast traffic recievers to Rendezvous Point (because many multicast recievers may be there) and Shortest Path Tree (S,G) from the sender to the Rendezvous Point.

    Any Source Multicast (ASM) uses Rendezvous Point.


    Source Specific Multicast (SSM) do not use (*,G). Instead of (*,G) Source Specific Multicast (SSM) uses (S,G) to join directly to the multicast traffic source.

    Source Specific Multicast (SSM) do not use a Rendezvous Point. Instead Source Specific Multicast (SSM) use IGMPv3 (IPv4) and MLDv2 (IPv6).

    Thanks a lot for your excellent tech posts.

    By the way, did you complete your CCIE?

    Best wishes

    Tom Sam

    • July 21, 2012 at 8:27 am

      Yes, that is correct. Also note that usually in ASM clients will switch over to SPT after learning where the source is.

      I’m not done with CCIE yet unfortunately. I’ll have another go in a couple of months but things are very busy right now with two kids (one newborn).

      I’m glad that you like my posts 🙂

      • July 21, 2012 at 10:40 am

        Dear Daniel,

        Thanks a lot for the reply.

        I am also planning for my CCIE, may be next year beginning.

        Currently I am CCNA, CCNA Security, CCNP, MCSA (Windows 2000), MCSE (Windows 2003), MCITP (Windows 2008) and Security+.

        I was away from technical field for a couple of years and was working in another field (somewhat management side). Recently came back again to technical side.

        Thanks a lot,


  • October 14, 2012 at 10:20 am

    Hi Daniel, like your lab here and gave it a try. For the normal ping section you mentioned, normal ping should fail since the source is not the loop back. However, same normal ping from my lab was working which really confused me. Any idea?

    • October 14, 2012 at 4:34 pm

      If you do a regular ping it will source with any interface with IP configured. You should be able to see it if you debug ICMP. So it is natural that some pings could succeed.

  • August 28, 2014 at 11:23 pm


    Thank you so much for this article,

    If we have tow differents sources (main and backup) which broadcast the same groupe multicast, is there any way to configure switch to receive both of sources and don’t duplicate the traffic, receive only the traffic from the main or the backup.


    • August 29, 2014 at 5:43 am

      I’m not sure what your scenario is. With SSM, the receiver joins SPT without the need for a RP.

  • August 29, 2014 at 9:14 am

    Hi, thank you so much for your quick reply, yes I know that we don’t need RP just mapping source with its muticast group. The question is can we map both of main source and backup and receive only one ? with ssm we can’t but I’m not sure if we can do it with ASM and RP or others protocols…



Leave a Reply

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

%d bloggers like this: