Home > Multicast > Basic Multicast part 5 – PIM SSM and SSM mapping

Basic Multicast part 5 – PIM SSM and SSM mapping

Continuing with Multicast topic I will talk this time about PIM SSM (Source Specific Multicast RFC 3569) and SSM mapping. In my previous posts on Multicast I demonstrated how to configure PIM DM/SM which uses IGMPv2 for host to router signaling. PIM DM and SM are known as “Any Source Multicast” or ASM. The receivers are willing to receive multicast from any source which is why a RP is needed in order to allow the receivers to discover new sources. With PIM SSM the concept is different as the receivers signal which source they want receive multicast traffic from by using IGMPv3 which means that RPs are not needed and the multicast routers in the multicast domain will only build shortest-path trees (SPT).

 For this post I will use the same topology as the other multicast posts:

Scenario: The Multicast source will send two streams, one for the multicast group 239.10.10.10 and one for the multicast group 239.20.20.20. The first group (239.10.10.10) will be running PIM SM and R4 will be the RP for this group. The second multicast group (239.20.20.20) will be running PIM SSM. The receiver will act as an IGMPv2/v3 receiver. In the second part of this post I will demonstrate how to configure SSM mapping where the receiver will not be IGMPv3 capable.

Source: 150.1.0.4

RP: The RP is R4 with IP: 4.4.4.4

BSR: The Bootstrap router is R3 with IP 3.3.3.3

IGP: EIGRP AS 100

Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services

All the routers in the PIM SM topology are configured with PIM SM.

PIM SSM configuration

 R3 is already configured as candidate BSR router. So let´s configure R4 as a candidate RP for the multicast group 239.10.10.10 only:

Let´s verify that all the multicast enabled routers have the correct information. Let´s take for example R1:

Perfect. So we can assume that the RP/group mapping has been propagated through the entire multicast domain hop by hop with PIMv2. If you want to know more about PIM BSR you can have a look at this post (IP PIM BSR)

 Perfect! Let´s now configure PIM SSM only for the multicast group 239.20.20.20 on all the routers:

 

Side note: if the keyword range is not specified the default range will be used which is 232.0.0.0/8. For the multicast groups included in the SSM range no shared trees are allowed and the PIM (*,G) joins/prunes are dropped.

 It is always a good idea to test that the control plane information is ok before sending multicast traffic. Here are some commands you can use to test:

  •  show ip pim int
  • show ip pim neighbor
  • show ip pim rp mapping
  • show ip rpf <RP>
  • show ip rpf <Source>

You can also use mtrace towards the source/RP to detect eventual RPF failures:

 Side note: the mtrace command shows the RPF neighbor for each router and which method they use to resolve RPF (unicast, mroute or Multicast BGP). In the output above it says static for R2. That means that R2 has an mroute configured for the RP IP address and an mroute will always be preferred over other methods in this case EIGRP or Multicast BGP due the lower AD.

. A failure could mean that PIM is not enabled on the interface or that there is no route to the source/RP for example.

So let´s make the receiver (20.20.20.2) join the multicast group 239.10.10.10:

So the receiver sends an IGMP report for the multicast group 239.10.10.10 and upon receiving it R1 sends a PIM (*,G) join/prune towards the RP 4.4.4.4:

 

Perfect everything is ready for multicast forwarding. Let´s ping from the source to the multicast group 239.10.10.10:

Side note: You should always make sure that you send enough ping packets in order to detect possible switchover failure.

Good! Let´s now make the receiver send an IGMPv3 report for the group 239.20.20.20. First we have to enable the interface of R1 facing the receiver for IGMPv3. The receiver must also be IGMPv3 capable:

Side note: IGMPv3 is compatible with IGMPv1 and IGMPv2.

So let´s generate an IGMPv3 report on the receiver for the group 239.20.20.20 and the source 150.1.0.4:

Straight away the receiver generates an IGMPv3 report and sends it to the multicast IP 224.0.0.22 (specially assigned by IANA for the IGMPv3 membership report). The message type is 0x22 (defined by RFC 3376).  The Wireshark capture bellow shows the IGMPv3 report sends from the receiver:

Now as R1 is running PIM SSM for the multicast group 239.20.20.20, upon receiving the IGMPv3 it will create an (S,G) entry in its multicast routing table for this group and source which in turns will trigger an PIM (S,G) join/prune sent towards the source IP address.

So R1 has now 2 entries in its multicast routing table. One SSM entry denoted sTI and one SM entry denoted SJC (receiver directly connected). We can see that no (*,G) have been created for the SSM entry, only the (S,G) entry is present. The PIM (S,G) join/prune sent by R1 will be relayed up to R3 as we can see in the output bellow:

So let´s generate multicast traffic for that group now that the SPT is built correctly:

Perfect, that´s working. In conclusion we have one multicast group running PIM SM with R4 as the RP and one multicast group running PIM SSM. For the SSM multicast group we don´t need any RP which facilitate the implementation of multicast. This example also demonstrate that SSM can coexist with ASM protocols (PIM SM) by applying the SSM delivery model to a configured subset of the IP multicast group address range as we did in the example.

Side note: An established network in which IP multicast service is based on PIM-SM can support SSM services. SSM can also be deployed alone in a network without the full range of protocols that are required for interdomain PIM-SM. That is, SSM does not require an RP, so there is no need for an RP mechanism such as Auto-RP, MSDP, or bootstrap router (BSR). If SSM is deployed in a network that is already configured for PIM-SM, then only the last-hop routers must be upgraded to a software image that supports SSM

Side note 2: Actually we could have just enabled PIM SSM on R1 and it will have worked as the PIM (S,G) join/prune send by R1 will have been relayed up to the root of the multicast tree effectively building the SPT. So if one of the router in the multicast domain, for example R2, was misconfigured with a wrong RP, we could have solved the problem by configuring R1 to run SSM for example for this multicast group with the misconfigured RP.

SSM MAPPING

Let´s imagine now that the receiver is a STB (Set Up Box) that does not support IGMPv3, only supporting IGMPv1 and IGMPv2 and you are in a SSM transition where you want to get rid of PIM SM and the RPs.

So SSM mapping is a SSM transition solution and only needs to be configured on the last hop router connected to the receivers. No support is needed on any routers in the network.

When the last hop router configured for SSM mapping receives an IGMPv1 or v2 report for multicast group G it uses SSM mapping to determine one or more source IP addresses for multicast group G. The router translates the membership report as an IGMPv3 report and generate a PIM (S,G) join/prune towards the source S.

This transition solution enables you to leverage SSM for video delivery to legacy STBs that do not support IGMPv3.

SSM mapping enables the last hop router to determine the source address either by statically configured table on the router or by consulting a DNS server.

For this example we will only use static SSM mapping. Static SSM mapping takes precedence over DNS mappings

So let´s suppose that the receiver in our topology only support IGMPv2. Let´s configure R1 for Static SSM mapping:

Alright let´s make the receiver sends an IGMPv2 report for the multicast group 239.20.20.20 and let´s see what happen on R1:

 

From the outputs above we can see that R1 is receiving the IGMPv2 report from the receiver and convert it to a IGMPv3 report which in turns triggers a PIM (S,G) join/prune towards the source sent to the RPF next-hop of R1 which is R2.

We verify:

Thanks for reading.

/Laurent

Advertisements
  1. Stefano
    August 7, 2013 at 15:44

    Hi, great post. I’ve got a doubt though. What would happen if we run SSM-Mapping+IGMPv3 on R1 and the Receiver is using IGMPv3 as well? Is the source specified by the Receiver being overwritten by SSM-Mapping on R1 (supposing the source in the ssm-map on R1 is different from the one specified by the receiver for the same multicast group) or not? And in case the Receiver does not specify any source in the IGMPv3 join message, is the source specified by SSM-Mapping on R1 being used?

    NB: It’s important here to notice that on R1 we have SSM-Mapping+IGMPv3. If we had SSM-Mapping+IGMPv2 then it would be different because the receiver using igmpv3 should operate in version 2 compatibility mode, so it couldn’t specify the source anyway.

    Thanks
    Ste

  2. September 23, 2013 at 06:07

    nice one

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: