In this demo,
we'll examine the requirements for a PIM SSM flow and see it in action,
we'll turn on PIM SSM in IGMPv3 to request the flow,
then we'll follow the PIM join up to the source,
and finally, see traffic flow back along the outgoing interface list.
Let's set up the last‑hop router to send queries and process
IGMPv3 reports and also to use PIM SSM groups.
We're telling the router to use the default
232.0.0.0/8 range for SSM groups here.
Unless a great reason exists to change it,
it should probably be left at the default.
The default setting for IGMP on Cisco routers is still version 2,
so we need to activate version 3 on the interface on which
we expect to receive the v3 reports.
This output shows that the interface is now using IGMP version 3 for sending
queries as a router and that it will process v3 reports.
Time to make the change on the receiver.
First things first,
we need to reconfigure the receiver to send an SSM request
that includes the source using IGMPv3.
Now we'll add the group. We can use a group in the SSM
range. And because this is IGMPv3,
we can also request the specific source from which
we want to receive the traffic.
Okay, let's jump over to the last‑hop router and see what happened.
I turned on the debug so that we can see it.
The first thing we see is a version 2 membership report for the group.
The multicast state engine creates an S, G source tree
entry and converts it into a PIM join, which is forwarded up to MCAST5.
If we look at the mroute table, we'll see that exactly.
Just like any source multicast.
We see the S, G entry with an outgoing interface based on the IGMP report and
an incoming interface based on the best path to the source.
Let's go look at the first‑hop router to make sure that
the PIM join made it all the way there.
Interestingly,
we see that an S, G entry is here for this source along with an
outgoing interface list and an incoming interface despite the fact
that the source has sent no traffic.
This is very different than an any‑source multicast where the
FHR wouldn't have any entry until the source started sending.
The flags help us out here.
The lowercase s indicates that this is an SSM group and the capital T
indicates that this flow has the shortest path bit set.
Let's see what happens when we generate traffic from the source.
We see responses here because the receiver is reachable.
Of particular import is the fact that in SSM, this flow could reuse
the same multicast group with a different source entirely and the
two streams would in no way overlap.
This new way of working prompted the writers of the RFC to prefer terms
like subscribe and unsubscribe over join and leave and for those flows to be called channels instead of groups.