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 22.214.171.124/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 126.96.36.199/24 on R2.
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#access-list 1 permit 188.8.131.52 0.0.0.255 R2(config)#ip pim ssm range 1
R2 will now use SSM behavior for the 184.108.40.206/24 range. R2 will join the group 220.127.116.11.
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 18.104.22.168 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 22.214.171.124 source 126.96.36.199
We take a look at the log.
IGMP(0): Received v3 Report for 1 group on FastEthernet0/0 from 188.8.131.52 IGMP(0): Received Group record for group 184.108.40.206, mode 5 from 220.127.116.11 for 1 sources IGMP(0): Updating expiration time on (18.104.22.168,22.214.171.124) to 180 secs IGMP(0): Setting source flags 4 on (126.96.36.199,188.8.131.52) IGMP(0): MRT Add/Update FastEthernet0/0 for (184.108.40.206,220.127.116.11) by 0 PIM(0): Insert (18.104.22.168,22.214.171.124) join in nbr 126.96.36.199's queue IGMP(0): MRT Add/Update FastEthernet0/0 for (188.8.131.52,184.108.40.206) by 4 PIM(0): Building Join/Prune packet for nbr 220.127.116.11 PIM(0): Adding v2 (18.104.22.168/32, 22.214.171.124), S-bit Join PIM(0): Send v2 join/prune to 126.96.36.199 (Serial0/0) IGMP(0): Building v3 Report on FastEthernet0/0 IGMP(0): Add Group Record for 188.8.131.52, type 5 IGMP(0): Add Source Record 184.108.40.206 IGMP(0): Add Group Record for 220.127.116.11, 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 18.104.22.168, to us PIM(0): Join-list: (22.214.171.124/32, 126.96.36.199), S-bit set PIM(0): RPF Lookup failed for 188.8.131.52 PIM(0): Add Serial0/0/184.108.40.206 to (220.127.116.11, 18.104.22.168), Forward state, by PIM SG Join
Then we verify by looking at the mroute table and by pinging.
R1#sh ip mroute 22.214.171.124 | be ( (*, 126.96.36.199), 00:09:42/stopped, RP 0.0.0.0, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (188.8.131.52, 184.108.40.206), 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 220.127.116.11 re 3 Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 18.104.22.168, 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: 22.214.171.124 Repeat count : 5 Datagram size : Timeout in seconds : Extended commands [n]: y Interface [All]: serial0/0 Time to live : Source address: 126.96.36.199 Type of service : 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 188.8.131.52, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 Reply to request 0 from 220.127.116.11, 52 ms Reply to request 1 from 18.104.22.168, 48 ms Reply to request 2 from 22.214.171.124, 48 ms Reply to request 3 from 126.96.36.199, 36 ms Reply to request 4 from 188.8.131.52, 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 184.108.40.206 as source for the groups 220.127.116.11, 18.104.22.168
and 22.214.171.124. 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 126.96.36.199 host 188.8.131.52 R2(config-ext-nacl)#permit igmp host 184.108.40.206 host 220.127.116.11 R2(config-ext-nacl)#permit igmp host 18.104.22.168 host 22.214.171.124 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 126.96.36.199 source 188.8.131.52
This is from the log on R2.
IGMP(0): Received v3 Report for 1 group on FastEthernet0/0 from 184.108.40.206 IGMP(*): Source: 220.127.116.11, Group 18.104.22.168 access denied on FastEthernet0/0 R2#sh ip access-lists IGMP_FILTER Extended IP access list IGMP_FILTER 10 permit igmp host 22.214.171.124 host 126.96.36.199 (6 matches) 20 permit igmp host 188.8.131.52 host 184.108.40.206 30 permit igmp host 220.127.116.11 host 18.104.22.168 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.
16 thoughts on “Source Specific Multicast (SSM) and IGMP filtering”
Excellent write up mate. Really healpful.
“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 😀
+1 for me as well 😉
Great. I’ll do a followup in a couple of days unless I’m rushing to the hospital to become a father 🙂
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 😀
Good Article, in the below link you can find tools, which can be used in the real world to simulate the SSM source and receivers as well as for ASM.
Do the followup.
p.s.: Are you a father now? 🙂
I’m working on it 🙂
I am a father but the second one is still due any day now.
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?
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 🙂
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,
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?
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.
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.
I’m not sure what your scenario is. With SSM, the receiver joins SPT without the need for a RP.
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…