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 232.0.0.0/8 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 225.0.0.0/24 on R2.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#access-list 1 permit 225.0.0.0 0.0.0.255
R2(config)#ip pim ssm range 1

R2 will now use SSM behavior for the 225.0.0.0/24 range. R2 will join the group 225.0.0.1.
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.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip multicast-routing
R1(config)#int s0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#do debug ip pim
PIM debugging is on
R1(config-if)#
R2(config)#ip multicast-routing
R2(config)#int s0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#int f0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#ip igmp version 3
R2(config-if)#
*Mar  1 00:18:37.595: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 23.23.23.2 on interface FastEthernet0/0
R2(config-if)#do debug ip igmp
IGMP debugging is on
R2(config-if)#do debug ip pim
PIM debugging is on

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

R2(config)#int f0/0
R2(config-if)#ip igmp join-group 225.0.0.1 source 1.1.1.1

We take a look at the log.

IGMP(0): Received v3 Report for 1 group on FastEthernet0/0 from 23.23.23.2
IGMP(0): Received Group record for group 225.0.0.1, mode 5 from 23.23.23.2 for 1 sources
IGMP(0): Updating expiration time on (1.1.1.1,225.0.0.1) to 180 secs
IGMP(0): Setting source flags 4 on (1.1.1.1,225.0.0.1)
IGMP(0): MRT Add/Update FastEthernet0/0 for (1.1.1.1,225.0.0.1) by 0
PIM(0): Insert (1.1.1.1,225.0.0.1) join in nbr 12.12.12.1's queue
IGMP(0): MRT Add/Update FastEthernet0/0 for (1.1.1.1,225.0.0.1) by 4
PIM(0): Building Join/Prune packet for nbr 12.12.12.1
PIM(0): Adding v2 (1.1.1.1/32, 225.0.0.1), S-bit Join
PIM(0): Send v2 join/prune to 12.12.12.1 (Serial0/0)
IGMP(0): Building v3 Report on FastEthernet0/0
IGMP(0): Add Group Record for 225.0.0.1, type 5
IGMP(0): Add Source Record 1.1.1.1
IGMP(0): Add Group Record for 225.0.0.1, type 6

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.

PIM(0): Received v2 Join/Prune on Serial0/0 from 12.12.12.2, to us
PIM(0): Join-list: (1.1.1.1/32, 225.0.0.1), S-bit set
PIM(0): RPF Lookup failed for 1.1.1.1
PIM(0): Add Serial0/0/12.12.12.2 to (1.1.1.1, 225.0.0.1), Forward state, by PIM SG Join

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

R1#sh ip mroute 225.0.0.1 | be (
(*, 225.0.0.1), 00:09:42/stopped, RP 0.0.0.0, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(1.1.1.1, 225.0.0.1), 00:01:49/00:01:40, flags: T
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0, Forward/Sparse, 00:01:49/00:02:39

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

R1#ping 225.0.0.1 re 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:
...

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.

R1#ping
Protocol [ip]:
Target IP address: 225.0.0.1
Repeat count [1]: 5
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: serial0/0
Time to live [255]:
Source address: 1.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1

Reply to request 0 from 12.12.12.2, 52 ms
Reply to request 1 from 12.12.12.2, 48 ms
Reply to request 2 from 12.12.12.2, 48 ms
Reply to request 3 from 12.12.12.2, 36 ms
Reply to request 4 from 12.12.12.2, 40 ms

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 0.0.0.0 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 1.1.1.1 as source for the groups 225.0.0.1, 225.0.0.2
and 225.0.0.3. 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.

R2(config)#ip access-list extended IGMP_FILTER
R2(config-ext-nacl)#permit igmp host 1.1.1.1 host 225.0.0.1
R2(config-ext-nacl)#permit igmp host 1.1.1.1 host 225.0.0.2
R2(config-ext-nacl)#permit igmp host 1.1.1.1 host 225.0.0.3
R2(config-ext-nacl)#deny igmp any any
R2(config-ext-nacl)#int f0/0
R2(config-if)#ip igmp access-group IGMP_FILTER

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

R3(config)#int f0/0
R3(config-if)#ip igmp version 3
R3(config-if)#ip igmp join-group 225.0.0.10 source 1.1.1.1

This is from the log on R2.

IGMP(0): Received v3 Report for 1 group on FastEthernet0/0 from 23.23.23.3
IGMP(*): Source: 1.1.1.1, Group 225.0.0.10 access denied on FastEthernet0/0
R2#sh ip access-lists IGMP_FILTER
Extended IP access list IGMP_FILTER
    10 permit igmp host 1.1.1.1 host 225.0.0.1 (6 matches)
    20 permit igmp host 1.1.1.1 host 225.0.0.2
    30 permit igmp host 1.1.1.1 host 225.0.0.3
    40 deny igmp any any (7 matches)

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
    Permalink

    Excellent write up mate. Really healpful.

    Reply
  • June 5, 2012 at 12:32 pm
    Permalink

    “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 😀

    Reply
  • June 5, 2012 at 12:43 pm
    Permalink

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

    Reply
    • June 6, 2012 at 11:09 am
      Permalink

      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 😀

      Reply
  • June 7, 2012 at 9:47 pm
    Permalink

    Do the followup.

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

    Reply
    • June 7, 2012 at 11:38 pm
      Permalink

      I’m working on it 🙂

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

      Reply
  • July 21, 2012 at 8:20 am
    Permalink

    Dear Daniel Dib,

    Can we summarize this as

    1)

    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.

    2)

    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

    Reply
    • July 21, 2012 at 8:27 am
      Permalink

      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 🙂

      Reply
      • July 21, 2012 at 10:40 am
        Permalink

        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,

        Thomas.

        Reply
  • October 14, 2012 at 10:20 am
    Permalink

    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?

    Reply
    • October 14, 2012 at 4:34 pm
      Permalink

      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.

      Reply
  • August 28, 2014 at 11:23 pm
    Permalink

    Hi,

    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.

    Thanks

    Reply
    • August 29, 2014 at 5:43 am
      Permalink

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

      Reply
  • August 29, 2014 at 9:14 am
    Permalink

    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…

    Thanks

    Reply

Leave a Reply

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

%d bloggers like this: