Unexpected Flows of Multicast Streams

[Brash]

I'm setting up a network with a bunch of AV equipment.

Essentially, all of the AV equipment sits on a stack of MS225 switches which are connected via Port-Channel to a Meraki managed Catalyst 9300 core switch. To try to limit the amount of multicast in the network, I've configured L3 interfaces with IGMP querier on the stack of MS225 switches, with flood unknown multicast disabled.

With this configuration, I would expect all multicast streams to be contained within the switch stack as all equipment sending and consuming streams are connected there.

However, when I look at port utilisation, I can see that multicast streams are being forwarded upstream to the Catalyst 9300. It's totalling to around 1Gbps of traffic on the port. Looking at all of the other ports on the 9300, their bandwidth usage is minimal (<10Mbps) and from some intermittent captures, I don't see any multicast streams being forwarded out any other ports.

Am I correct in expecting the multicast traffic to remain on the access layer switch stack (switched between switches in the stack via the stack ports) rather than all of the streams being sent upstream to the core?

[RWelch]

MS Multicast Routing Configuration

Certain Cisco Meraki Switches support multicast routing; specifically, Protocol Independent Multicast - Sparse Mode (PIM-SM).  PIM-SM on Cisco Meraki switches conform to the RFC7761 standard.  A firmware upgrade may be required to enable this feature, as detailed in each section. 

Supported Models for PIM-SM: MS250, MS350, MS355, MS390, MS410, MS420, MS425, MS450, C9300/L/X-M

Caveats

• For CS switches, enabling IGMP snooping also enables the IGMP Querier functionality on all VLANs. 

Where is the RP set at (or is it set)?

Multicast Overview, Configurations, and Best Practices 

There is a well laid out explination on another post if interested:
Multicast Basic's 

On the MS210, MS225, and MS250 series switches, Flood Unknown Multicast should be enabled for MLD snooping to work.

[Brash]

(Thankfully) we're not doing any multicast routing, so no PIM and no RP.

[PhilipDAth]

This is my favourite Merai Multicast config post of all time on the community.

https://community.meraki.com/t5/Switching/Multicast-Basic-s/m-p/25867/highlight/true#M2125

[Brash · Accepted solution]

Circling back on this one, I worked with the US support team (shoutout to Caleb) who helped confirm the following.

As @RWelch pointed out, Catalyst switches do have the caveat about IGMP snooping also enabling querier functionality. This I had read but figured wasn't applicable as I didn't have any L3 interfaces on the C9300.

As it turned out the management IP address of the C9300 is applicable, and because it was a lower IP address than that of the SVI on the MS225 stack (even though it's a different VLAN), the C9300 Mgmt IP won the IGMP querier election.

We resolved this by creating an SVI on the C9300 (in the VLAN that the multicast traffic is coming from), enabling IGMP querier on it but setting its IP address high than that of the SVI on the MS225.

After setting that and waiting for the IGMP querier election to occur (260 seconds?) the MS225 SVI won and took over as querier and multicast stopped being sent up to the C9300.

[RWelch]

Nice job Caleb and @Brash!