PIM-SSM (Source-Specific Multicast)
Last updated
Last updated
PIM-SSM (Source-Specific Multicast) requires a host to specify the source they wish to receive traffic from. The LHR joins a (S, G) tree rooted at the source specified in the Membership Report. For example, a host could join (1.1.1.1, 232.1.1.1). The LHR then builds an (S, G) for (1.1.1.1, 232.1.1.1) and sends PIM-Joins towards the source.
The (S, G) tree that is built as a result is no different from the tree that would result in PIM-SM after SPT switchover. The difference with PIM-SSM is that the source already knows which host they want to receive traffic from. Therefore, traffic doesn’t need to initially flow through the RP in order for the LHR to glean the source IP. The LHR will know the source IP before any traffic begins flowing.
How does a host already know which source it wishes to receive traffic from? The software is programmed to know this information. If the host does not know, there are some workarounds you can do using DNS or SSM-mapping, but we won’t get into that in this article.
In PIM-SSM, IGMPv3 must be used. IGMPv3 allows a receiver to specify the source IP and group when sending a Membership Report. IGMPv3 allows for backwards compatibility with IGMPv2 as well.
In PIM-SSM, the only major change compared to PIM-SM is the host signaling. Because the LHR has the source IP from the IGMP Membership Report, an RP is not needed. In fact, if you are only running PIM-SSM in your network, you can forgo configuring an RP altogether. This greatly simplifies PIM operations.
PIM-SSM uses the group range 232.0.0.0/8. This is configurable, but is typically left at the default range. You can run PIM-SM with PIM-SSM at the same time. In this case, only multicast groups in the range 232.0.0.0/8 must have a specified source. All other traffic will use the RP and use normal PIM-SM operations.
Let’s see how PIM-SSM is configured in the lab.
We’ll use the same topology we have been using in the previous articles. First remove pim-bidir from all routers and configure R6 as the RP using BSR. R6 should be both the C-BSR and C-RP. Try to configure this on your own, and check the config below if you get stuck.
Test that your configuration is working by pinging 239.100.100.100 from Source1. Host4 should still be joined to this group.
We’ll now setup PIM-SSM in conjunction with the PIM-SM configuration we have already. To enable PIM-SSM we must do two things:
Configure the PIM-SSM range using the command ip pim ssm default
If you want to use a range besides the default 232/8, you would specify this using ip pim ssm range <ACL>
Set host-facing interfaces to use IGMPv3 with ip igmp version 3
Just like PIM-SM, FHRs don’t need to run IGMP on interfaces facing a source
ip pim sparse-mode also needs to be configured on all interfaces, but this should be present already in your lab.
Currently we have IGMPv3 enabled on the querier (LHR) but IGMPv2 still enabled on all hosts. If we take a pcap, we can see that the LHR is now sending IGMPv3 general queries, and the hosts are responding with v2 membership reports.
The IGMPv3 type field is the same as in IGMPv2, allowing IGMPv2-only hosts to still work with an IGMPv3 querier.
Let’s configure Host4 to join the group 232.1.1.1 with source 10.10.10.10.
The source parameter is ignored and Host4 sends an IGMPv2 Join for *, 232.1.1.1. This is because the interface is still running IGMPv2 (the default).
Let’s enable IGMPv3 on Gi0/0:
IGMPv3 allows a host to batch multiple Joins into a single Membership Report. In IGMPv2 these would have to be separate Membership Reports.
IGMPv3 allows ASM (any source multicast) to function by using a record type trick. Here the record type is “Exclude” but there are zero sources. This effectively “excludes nothing” and therefore “allows any source.” It’s a bit confusing at first, but it is an interesting way that IGMPv3 allows IGMPv2 Joins/Leaves to interwork with IGMPv3 SSM Joins/Leaves. Notice that the Join for 10.10.10.10, 232.1.1.1 is “Include” mode with the single source address, which is a bit more intuitive.
R5, the LHR, creates state for both (*, 239.1.1.1) and (10.10.10.10, 232.1.1.1). These are created in response to the IGMPv3 Membership Report sent by Host4.
Can you guess what the state looks like on the RP? What about on R1?
The RP only has state for the ASM group 239.1.1.1. It is not on the shortest path to the SSM group. R1 only has state for the SSM entry. Notice the lowercase s flag indicating SSM. The (S, G) tree is built all the way from the LHR to the FHR even before the first multicast packet is sent.
If Source1 begins sending to 232.1.1.1, Host4 should reply.
What will happen if Source2 pings 232.1.1.1?
As you can see, the traffic does not work. In PIM-SSM, each (source, group) entry is a unique flow. In an IP TV deployment, each TV channel could have a separate source IP, but the same multicast group. (S1, G) could be one channel, and (S2, G) could be another channel, where G is a single group address. Because each flow is uniquely identified by the source IP and group together, this allows you to re-use the same multicast IP.
On Host4, we’ll leave both the ASM 239.100.100.100 group and SSM (10.10.10.10, 232.1.1.1) group to examine the IGMPv3 Leave message.
The IGMPv3 Leave for an ASM group involves a mode change to “Include” mode. The inclusion is zero sources though, so it is saying “include nothing.” This can be a little tricky the first time you see it.
The IGMPv3 Leave for the SSM entry says to “block old sources.” 10.10.10.10 was the only source, so the LHR will remove the entry in response to this message:
You could say that PIM-SSM uses a subset of PIM-SM in addition to IGMPv3 between the receiver and LHR. IGMPv3 adds the ability for a host to specify the source it wishes to receive multicast traffic from. The LHR then can build a (S, G) SPT rooted at the source that the host specified in the IGMPv3 Membership Report.
In PIM-SM, the network must take on the responsibility of source discovery. A FHR must register the source with the RP, and the RP must pull in the traffic by creating a (S, G) SPT rooted at the source. In PIM-SSM, the host takes on the responsibility of providing the source information, relieving the network of this task. In PIM-SSM, the RP is not needed.
This concludes the series of articles on intradomain multicast. The following articles will touch upon interdomain multicast and multicast VPN services.
