I have been banging my head on this issue for quite a while now and I have read through all the other posts I could find here related to Multicast configuration. You would think it wouldn't be this hard, after all, as I have 25+ years of network engineering experience, achieved my CCIE in R&S, have the Cisco Press Multicast Routing book which I have read and studied cover to cover, and even took a Cisco bootcamp on Multicast Routing.
It feels like there is either a bug or an IGMP version mismatch going on, possibly. I am trying to get my four AT&T U-verse TV set top boxes working through an MS210-24P running MS 11.31 firmware. I have my AT&T gateway router (Arris/Motorola BGW210) connected to the switch on a port auto-negotiated to 1Gig set for Access mode on VLAN 192. The set top boxes are connected at 100Meg to access ports on VLAN 192. I have enabled the global IGMP snooping setting and disabled Flood Unknown Multicast traffic. I have also configured an L3 interface on VLAN192 and enabled the IGMP snooping querier option.
No matter what I do, the TV streams always end up timing out. Sometimes they fail when the box tries to switch from unicast to multicast after the first ten seconds. Other times it lasts until the default multicast dead timer hits at 240-270 seconds. Even stranger is twice when I was testing last night, the stream kept running past the normal dead timer and made it to approximately 7 and a half minutes. I thought I had finally fixed the issue only to run into failure yet again.
Is there a bug or IGMP version issue or am I doing something wrong? I used to have this working without any issues on a Cisco Catalyst 3524XL switch and I did nothing more than enable IGMP snooping. It can't be this complicated, can it?
Not yet. I wanted to make sure I wasn't missing something before I went down that path.
I have multicast working - streaming 4K UHD HDR without hiccups, no packet leakage, entirely reliable and buttoned down.
I put another brand security appliance that runs a configurable igmp-proxy, ahead of the MX, which doesn't handle IGMP-proxies, configurable or otherwise.
Meraki has shown zero interest in making single source multicast IPTV, as used in most of the world, work on their hardware.
Could be a bug. I think you could consider opening a ticket and or exploring other firmware options. In my experience with Meraki it works, it's not support or it's firmware.
I don't know the answer, but I have always found this post to be really good. I have referred back to it often.
https://community.meraki.com/t5/Switching/Multicast-Basic-s/m-p/25867/highlight/true#M2125
Yep, thanks. I have read through that, as well. Still no dice. I have a case open and will try to work through it. I'll post here if anything of value actually comes out of it.
Have you captured incoming IGMP queries and how often they come down, together with the membership reports going up?
It's always handy to see what the packets are both on your link towards the TV as the link towards the multicast provider.
Maybe also set the packet slicer on Wireshark so you only get the first 64bytes of each packet and just capture the entire multicast range.
I had no time the past week to get on the phone and deal with this between my day job and home schooling my 4 kids and trying to keep up with the honey-do list. 😉 I finally called yesterday morning and continued debugging.
As I expected, my suspicions were confirmed and I was not losing my mind. The switch is behaving unexpectedly with IGMP snooping. It initially works when I relocate all the multicast receiver hardware onto the switch and I reboot my gateway router. It even makes it past the typical IGMP dead timer of 270 seconds. For unknown reasons at around the 7 minute mark, the receiver sends an IGMP leave report, even though the box is still tuned to the same video stream. At that point, the switch wipes all of the multicast forwarding and loses track of the router forwarding the source content to the group, even though the switch can still see IGMP reports from the router including the IGMP group in question coming across the uplink port.
The issue has been escalated to development to isolate and hopefully identify a firmware bug fix. I will update when I hear further information.