Multicast: Hold ASM for a moment, let’s do SSM!… Part 4

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…

atlink'admin

Learn More →

Leave a Reply

Translate »