IGMPv3 (RFC 4607) allows the receivers to specify the source they wish in additiont the multicast group trafic
By default we use the 232.0.0.0/8 range for SSM
In our lab setup
We configure Client1 to join SSM specific range @ip address 232.0.0.1 sourced from Server1 (in the same subnet)
Without any other configuration (IGMP default to version 2 on This Cisco router)
Client1 is responding to multicast pings from Server1
and it is configured to join 232.0.0.1 from the wrong server address which is
Client1 records a version 2 IGMP group membership,
the details are given in the next output
the source information is included in the records
and the same if we configure the interface of IGMP version 3
let’s check what happens on the wire,
if IGMPv2, Client1 report includes only the group information…
in IGMPv3, Client1 sends a report including the source it wishes join
We continue our test and multicast ping from Server1 (different from the configured source)
the pings succeed…
let’s try now from Server2
Without any configuration (only pim-dense mode, ASM multicast on R1, R2 and R3, RPF) the ping succeeds from Server2
The mroute tables of routers R3 and the last hop router R1 show
at R3,
at R1,
Let’s enable SSM multicast routing for this group by applying the “ip pim ssm” command on R1 in the global configuration mode (Cisco router)
A “debug ip igmp” on R1 shows
The group record mode 2 for ssm group was ignored
mode 2?
The mode 1 from Client1 was accepted
mode 1?
On R1 the IGMP table shows
an entry for reporter “Client1” that is flagged as version 3, M for SSM (S,G) and aggregate
an expiration timer is set for this entry also
will the mroute table be populated?
yes but there’s somthing wrong with the outgoing interface list
the entry is flagged with a small s that indicate and SSM procedure
a debug on Client1 shows
reports are being sent
Let’s check what happens from the server (Server2) perspective
The ping is no more accurate
at R2,
The (S,G) is correct
The flow is sent over the dense mode interface
What’s wrong at R1?
The outgoing intreface list indicates Null and only Server1 source is present
A “debug ip mrouting” shows,
that the RPF information is incomplete (unknown)
A “debug ip mfib pak”, on the forwarding path, shows that
The flow destined for the group 232.0.0.1 and sourced from Server2 is being dropped due to Acceptance check failed…
Let’s clarify this point
What if I configured a source that is behind R1 (not on the same subnet)?
In R1, the mroute table shows
The entry passes the check because the source is not on the same subnet
And the incoming interface is put to what the ip routing table (unicast) returns
Let’s configure R1 to join this source on Server2
a debug on the Client1, shows that a new source has been created (12.1.1.254), a v3 report sent with this information on R1 subnet, etc.
R1 adds now the mroute to the table
the P flag is suppressed and outgoing interface list updated with the correct information
What happen if I remove the static route to 12.1.1.254 subnet ?
A debug ip mrouting shows a triggered change of RPF to unknown
The ping responses stop and the mfib shows packets being dropped
We put back the route
And multicast flows normally again
In summary,
the multicast ping works because the Client1 is configured to send a version 3 Igmp request of the group trafic from the specific source, SSM is enabled on R1 by mapping the default range to its operation (we could’ve mapped another range), and the source information is RPF checked…