CBS350 IGMP and filtering unregistered multicast

[jonathan.levesque]

Hi.
We have issues with CBS350 and SG350 switches when it comes to deal with multicast in the following ranges:

Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))
Internetwork Control Block (224.0.1.0 - 224.0.1.255 (224.0.1/24))

We use those switches for AV application (Audio, video, lighting). A lot of the traffic that travels on our networks is multicast traffic. To make sure that the switches don't get flooded with that multicast traffic, we enable IGMP  snooping on all switches and we elect an IGMP querrier on one of the switches. We also enable "filter unregistered multicast" on all ports so the network don't get flooded by unregistered multicast (multicast traffic that does not have a listener).
The problem that we have when we activate "filter unregistered multicast", is that it also filters some of the  224.0.0.x and the 224.0.1.x traffic that is used for discovery, clocking and other protocoles that should be treated as broadcast due to purpose of that traffic. In my understanding, no device sends IGMP join or IGMP leave messages for those specific multicast groups.
Also, I sometimes have to disable "filter unregistered multicast" on my ISL ports (uplinks) to make sure that the discovery/clocking/other traffic can get to other switches. By doing this, I generate more traffic on my ISL while reducing my bandwith overhead.

Does anybody have any experience with that kind of issue?

[train_wreck]

I know it's 2 years later but I am dealing with the exact same thing, on both a CBS220 and CBS250. Did you ever figure this out?

[patrickAVTECH]

Hi Guys, 

I am a former AV Commissioning Tech with experience in large scale AVoIP Deployments throughout Australia. 

The Filter Unregistered Multicast Tick boxes will - by design - block the discovery multicast packets that you are looking for. We saw this most commonly when staging (preparing) a number of boxes for a deployment using a bench CBS/SG switch that had AVoIP configuration - IGMP Snooping/querying/Bridge Multicast Filtering/Filter Unregistered Multicast/No flooding - enabled while simultaneously trying to stage (for example) a dante product that relies on discovery. 

There is a simple solution for this that involves statically adding the multicast addresses addresses that you require onto the switch so that they are not filtered entirely and discovery will function. 

Docs are your best friend - I have found Shure proves some great information for switch preparation for AVoIP w Dante deployments that will assist you going forward - see below.  It will help with configuring the DSCP QoS values as well and not just in cisco land, other switch vendors as well. You could buy Netgear AV but...gross. 

Happy AV'ing!

https://service.shure.com/Service/s/article/configuring-sg350-switch-for-shure-devices-and-dante?language=en_US

[train_wreck]

Hey thanks for the input. In my case at least I was seeing some IPTV services fail to pass through a firewall device with the multicast filtering option enabled. I saw through some tedious log management that the mDNS/SSDP reflector on the firewall was dynamically creating multicast groups "on the fly" as it seemed, with hundreds of different 224.x.y.z groups being created and torn down. This made it pragmatically impossible to input all the required multicast groups statically, and so the multicast filter feature had to be disabled.

I'm aware of the headaches of the interoperation between Dante and smart switches, though I've never worked with it personally. And I share your distaste for Netgear, there's a reason Gartner removed them from the magic quandrants some years ago in the enterprise route/switch categories! Some absolutely brain-dead bugs in their products.