IGMP Snooping / Querier and jumbo frames

[roesljas]

Hello all,

I wanted to ask some questions regarding the IGMP snooping and querier functions in Meraki MS switches. We only really use the MS120 / MS125 series as we do small networks to support out AV installations , we are an AV not an IT company.

A lot of our projects just use one switch but we have more and more coming up with 2 x MS125s and we aren't providing our own router, instead we will uplink to a trunk on their (IT company's) core Fortinet switch.

My questions are:

1) IGMP is enabled by default on meraki switches but not querier, do I need to setup an interface on one of the switches in a system to become the querier for the whole network? I'm unclear on how this works and how the switches / client devices know who is the querier.

2) Do you need an MX for IGMP querying to work, or is it handled entirely within the MS switches?

3) One of the network audio protocols we are using is called Q-LAN which is based on AES67. Supposedly, this protocol doesn't like jumbo frames / large MTUs, but we need it for the video encoders / decoders. And the manufacturers documentation says to disable jumbo frames on any switch ports that have Q-LAN devices attached. In meraki the MTU size is set on a per switch basis meaning I can't disable large MTUs on these ports only. Theoretically, if all Q-LAN devices are on their own dedicated VLAN and only communicate to each other, would it mean they'd never receive a large MTU despite the MTU size of the switch being set high?

Thank you in advance,

[PhilipDAth]

You require a layer 3 switch to have an IGMP querier configured.  The MS125 is a layer 2 switch, so that option will not be available.

The MX can be an IGMP querier.

If you are using a single VLAN (which I suspect since there are no layer 3 components mentioned), you shouldn't need an IGMP querier.  Simple IGMP snooping should be enough.

This link talks about the IGMP support:
https://documentation.meraki.com/General_Administration/Other_Topics/Multicast_support 

Check out this detailed post for more info:
https://community.meraki.com/t5/Switching/Multicast-Basic-s/m-p/209257 

[Ljackson85]

Hi Phil, 

Thanks for this, very informative! This is very similar to a situation we find ourselves (full Meraki stack, running AES67 audio devices) but have decided to go for a full ms120 stack. Will the MX IGMP querier capability be sufficient enough for it to enable a stack (x7) of layer 2 devices to create the multicast community? 

Can I ask where you set the IGMP querier on the MX as I cannot find it in the dashboard nor the documentation? 

Thanks in advance,

[PhilipDAth]

Is all the Multicast traffic, both servers and consumers, contained in a single VLAN?

A stack of 7 makes me a bit nervous.  The larger the stack, the more likely you are to run into stability bugs.  I prefer not to run a stack bigger than 4 or 5 switches.

[Ljackson85]

Sorry, bad use of terminology. A block of switches. 7 Daisy chained with an uplink to Mx from top and bottom of the block. 

Mx

Switch 1

switch 2

Switch 3 

So on.

If we put source of multicast on switch 1 and then subscribers across the rest of the switches, my logical head says it will work but as we found at another building (larger with a layer 3 aggregation switch between switch block and Mx) we had to put a querier on the layer 3 agg switch for same block but different switches to see each other. We have gone for ms120s which can't do layer 3. So I found hope in your comments about Mx being able to be there querier but I can't find where to set it. 

I saw your other post regarding this and how querier is needed to be seen on trunk link to send inter switches which was very helpful btw! 

Hope that all makes sense and thanks in advance! 

[Ljackson85]

And yes all in the same vlan

[PhilipDAth]

If it is all in the same VLAN this will work ... but unless the multicast streams are light, I think you are undercooking the hardware.  Everytime a port subscribes to a multicast stream, the silicon has to duplicate a packet to go to it.

Lets say you had 168 ports subscribed to a multicast stream - that means every source packet has to be replicated 168 times.  That is a lot of silicon punch that is required.

I would be more tempted to:

• Use a stacked pair of MS250 switches as the network core (do not daisy chain).
• Create a stack consisting of 2 x MS225, and 3 x MS210 (no daisy chain).  Uplink the stack using the 10Gbe ports.
  
  • You could potentially use 5 x MS125s.  Connect them only to the network core - not to each other.

If you are multicasting something heavy, like video, use higher spec models again.

ps. Check out the MS130 (preferably the "x" variant) instead of MS125.  I expect the MS130 silicon is likely to have more "punch".

pps. You could also check out the C9300-M instead of an MS250.  It is likely to have more power as well.

[Ljackson85]

Thanks Phil, some food for thought on the design/architecture! 

[roesljas]

Hi Ljackson85,

I woke up this morning with a million update emails from Meraki Community in my inbox. I did this original post ages ago so I had forgotten all about it.

I had issues with AES67 and IGMP which I haven't specifically revisited because I don't use pure AES67 often. However, I recently did a deployment of Q-sys Q-LAN audio (AES67) and had the same problem with the Core not discovering the QIO expanders. My system will grow over time, however for now it's just 2x MS120-8LP with a UniFi USW (soon to be MX). When uploading a new design in q-sys designer, the core simply couldn't discover the QIOs until I turned off IGMP snooping. So what I did was create a new Interface for IGMP querier (Switching > Routing and DHCP) on the MS120-8 closest to the USG (essentially the core switch), re-enabled snooping and would you believe it, everything started working as expected. The MS120 series does support interfaces for DHCP relay and IGMP snooping - it says so in the documentation and the dashboard. Furthermore, IGMP snooping is required for multiple switches to share port subscription/ membership data between each other, even if it's all within the same VLAN / L2 segment i.e. no requirement for routing.

I have been a big fan of Meraki for a while, but truth is that it's not well suited to AVoIP applications. Issues such as no per port MTU configuration, no cost effective high SFP count switch hardware etc mean you may not be able to resolve some issues that arise. I have been eyeing up the Netgear M4350 series as an alternative for our larger dedicated AV projects. It's a nice range of edge to core switches that are specifically engineered for AVoIP. But they aren't cloud managed which will take some getting used to.

I hope this is of some use and I'd be keen to know how you go.

Thanks,

Jas

[Ljackson85]

Hi mate, 100% the same situation as us with qsys and the discovery of needing to do an igmp querier for it to work, even if it's in a single vlan. I can't say I completely understand why it's needed for a single layer 2 vlan but is what it is!

[Ljackson85]

Our main concern was that we couldn't enable igmp querier as it's a layer 2 only switch, turns out routing and DHCP option appears in dashboard and can create one. You've given us hope Jas, testing later but sounds like you have it working on ms120s so should be fine for us too! 

[roesljas]

Hi mate,

Well fingers crossed it works for you. Also i sense another Aussie.... I'm Brisbane based.

Just a bit more detail if it's helpful, create the new snooping interface on the most central switch, so you'll need to allocate a new IP address which is in addition to the management interface of the switch. Then reboot all your switches if possible, then do all your end points / cores / DSPs.

The reason you need a querier on layer 2 only or single VLAN deployments is because the IGMP querier switch is what all other switches look to for the membership subscription information etc. Without a querier, all switches will just do their own thing.

Jas