Source Specific Multicast (SSM) and IGMP filtering

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.