Multicast Basic's

[Ben_PP]

Hi,

I have recently installed a new MX Appliance and MS Core switch.

The MS switch is handling all L3 Routing between VLAN's and we have 3 existing C2960 access switches.

Our previous network consultant enabled IGMP snooping on each VLAN of all of the C2960 switches, however, the switches are not detecting a multicast router on the network.

On the new MS core switch, I have not enabled Multicast routing on any of the VLANs.

I don't currently have any complaints from our users and am not seeing any issues, however, I am interested to know what the default recommended setup would be.

1. What happens to multicast traffic in this scenario where there is no multicast router?

2. Should I enable multicast routing on each of the VLAN interfaces on the MS Core switch?

3. or simply enable IGMP snooping querier or leave it disabled if there are no issues.

Thanks for any advice

[Philip D'Ath]

Becase all layer 3 interfaces are located in the MS425 core stack, I think you should enable multicast routing on each of those layer 3 interfaces.

The downstream switches should be able to do IGMP snooping and use the core layer 3 interfaces for sending queries too.

Generally you want the source of the multicast streams to be as close to the core as possible. I think your design should be fine.

[test108]

You will want to make sure there is an IGMP Querier active in each VLAN where multicast flows will be passing through. When an L3 interface is set to enable "Multicast Routing", this interface will also run an IGMP querier, so for VLANs where multicast routing-enabled L3 interfaces exist, there is no need to additionally configure a separate querier interface.

It should be fine if the L3 interfaces are on the L3-enabled core stack but the multicast stream sources are attached to the downstream L2 access stack -- as long as there is L2 visibility.

If you are only doing local inter-VLAN routing for the multicast streams (between VLANs on the core stack) the configuration of the rendezvous point is not as important, but as a good practice, it would be most efficient to assign the RP to the L3 interface which is in the same VLAN as the sources.

When a switch running multicast routing begins to receive a new multicast stream, it will bundle the packets of the stream into an encapsulated unicast packet stream, transmitted directly to the configured rendezvous point. This is to ensure the rendezvous point always knows about the different source streams that exist in the network, no matter where they are. If the native streams are directly received in the VLAN with the rendezvous point from the get go, this unicast-encapsulated transmission to a remote rendezvous point is avoided.

Additionally, it would be highly recommended that your network is configured to have IGMP Snooping enabled, and to disable unknown multicast flooding. Both can be set from the Switch --> Switch settings page in Dashboard.

If you've never touched this, the default settings have IGMP Snooping enabled, but unknown multicast flooding is not disabled by default, so it would be a good step to address this.

Finally, it would also be good to use the current MS 11.x firmware if you are not already, as there are several improvements and issues that have been addressed with respect to multicast routing.

[ahmed-hassan1110]

Hi Andrew,

Thanks for all the valuable info you have provided, generally my setup is fitting into all what you have mentioned except for the RP, which i have changed as per your recommendation.

two points here, first my MS switches SW is MS 10.45 and is shown as up to date on the dashboard so if 11.x has been released, shouldn't it give me an update available status ?

secondly, I think the multicast is acting oddly on my network as there is connectivity disconnections happens when any changes made to multicast settings even on other VLANs/subnets which doesn't have the multicast routing enabled?, also when i go to core switch> Tools> Multicast routing and run this tool which i think should show me something like the multicast routing table it gives me nothing!!??

@test108

[GreenMan]

11.x will become available if you enable Try beta firmware = yes, under Network-wide > General > Firmware upgrades. Have a look under Organization > Monitor > Firmware upgrades for release notes. I'd try not to be too worried by the 'Beta' label, in this instance - I'm pretty sure Support would agree with the recommendation for using 11.x, with your requirement. Support also have access to far more info on Multicast status, if you need to troubleshoot, so don't be afraid of raising a case with them.

[igonzalez001]

Thanks so much for your detailed explanation. Helped me understand how to design our network for QSYS Audio/Video install. One problem I ran into that I couldn't figure out is that IGMP querier did not make it past an aggregated link between Merakis. Traffic passed to the other trunked aggregate port of switch but could not make it to the devices needing to discover or receive. I had to split the LACP port aggregation to get it to work. Had been banging my head against this for hours. I will be reporting this to Meraki support. We really need to port aggregation to work so its an issue that we cannot discover devices with it.

-Isaac

[Stefan Tautscher]

Hi,

seems, that we are running in the same issue.

Have you opened a TAC case?

What was the outcome?

BR Stefan

[DR11]

@igonzalez001Was this problem resolved to your knowledge?

We're now running into the same problem. Its incredibly problematic when considering the significant bandwidth requirements of something like NDI.

[GBaumann1]

Hi,

I've observed something similar, in the deployment of a Dante audio network, as audio specialist, we got mixed answers from the IT company that deployed the Merakis, they even analysed the problem with Cisco support. No fact based answer. The information that came out was a problem with multicast tables synchronisation in a stack. No idea if it is an officially reviewed bad config or a bug, but destacking and setting LAG off solved the problems. Only took 11 months to solve :). Thanks for posting @igonzalez001 as your post was the trigger for a review of the system (the possibility that switching was the problem).

[igonzalez001]

Unfortunately months passed and they promised it would be resolved in an update but I never found that to be the case and I let the support case slip away. They did acknowledge the issue but we had to go with no LACP aggregation since the QSYS core could never multicast discover any of the devices. We had other issues with Meraki surrounding the AV system such as needing to force port speed on the QSYS I/O flex devices to 1Gbps along with needing to set port speed on the QSYS TSCs to 100Mbps...That could have been the devices fault though

[bs33]

I have a mixture of MS225 and MS125s with a MS425 core switch. For my AV VLAN, should I just create one interface for Multicast / IGMP snooping querier or does each switch need an Interface? Here's what my Routing & DHCP screen looks like:

[CMR]

From what I understand, you should only need an interface on the switch closest to the video source, though we actually just put them on the core interfaces...

[igonzalez001]

You only need one of them configured on the switch were your core AV device is that discovers all the A/V devices on the network(and put the querier on the correct vlan). You also only need the IGMP querier if they are on separate switches. We had a Shure vendor tech support try and tell us that the Mics didn't support vlans but that was just them trying to blame our network for audio streams making it to the core device but getting silently ignored(when they had been working for years before without issue).

[engineer467]

Lot of thanks to Andrew and others for their inputs, things got much clearer now.