PIM-SM Multicast Routing IGMP, Headaches

[Deviant]

Hi Community

I was wondering if anyone has managed to get Multicast routing working on Meraki MS?

I seem to run into walls the whole time and I have an IPTV Vendor installing a system and ATM it seems that it is the Meraki keeping them back.

So we have a headend appliance on an HP switch that the AV manages and supplies. They do PIM-SM and connect to the Meraki using vlan 1201. When they put a client on vlan 1201 on their switch the multicast works exactly as it should. So we connect vlan 1201 to Meraki and the PIM-SM relationship forms no issues. Then I retreive a stream lets say 239.1.2.1 and it works no issues. But as soon as I start a second stream the issues start, then nothing works. Have to start resetting the Meraki PIM settings to get it back up.

So further to this I thought, ok let me put a laptop of my own in vlan 1201 as well. So in this case we have headend behind HP switch in VLAN 120 with PIM. AV Laptop on HP switch in vlan 1201 and my laptop in vlan 1201 on Meraki.

Surely enough, the AV Laptop connected to the HP switch receives the stream no issue. My laptop on the Meraki does not but I am in the same VLAN now as the AV Laptop on the HP switch. So I started with disabling IGMP and then PIM all together. To have just a standard VLAN, still cant retrieve the streams.

So I said, lets move the headend onto the Meraki to get rid of HP/Meraki interoperabilities. So now we have the headend spitting out Multicasts on the Meraki switch in VLAN 120, my client laptop on the same vlan also. Now I open the multicast but there is no content which is odd as I am now in the same VLAN. The same test done on the HP switch works perfectly fine.

So now I enable PIM again for that VLAN and an access vlan 63.

Now I have headend still on vlan 120 with PIM and laptop on same switch vlan 63.

IP Address	Subnet	Flags	Neighbors
10.0.1.110	10.0.1.96/28	DR PIM	
1 neighbor

Source	Group	Rendezvous Point	Incoming Interface	Outgoing Interfaces	Flags
Any	239.1.2.1	10.0.1.110	PIM Register	
1 interface
WC RP
192.168.120.2	239.1.2.1	10.0.1.110	192.168.120.1	
1 interface
CACHE SG
192.168.120.2	239.1.2.2	10.0.1.110	192.168.120.1	
-
CACHE SG
192.168.120.2	239.1.2.3	10.0.1.110	192.168.120.1	
-
CACHE SG

So now, I do the same test and it seems the stream opens I can see on a sniff also surely I am receiving the multicast streams but it simply does not have any content.

I am so confused/frustrated by this.

Hence the question, has anyone been able to successfully implement this yet?

[PhilipDAth]

The 10.x firmware has massive improvements around multicast.  If you are not using that make that your first thing to change.

What model Meraki switch are you using?

Have you tried enabling the option to flood unknown multicast traffic?

Is the Meraki switch just doing layer 2, or is it configured to do layer 3 with VLAN interfaces?

[Deviant]

Hi @PhilipDAth

Thanks for the response. The IPTV system integrates on a MS250.

I run a ring OSPF network, some areas MS250's and others MS410's.

I was on 10.26, but upgraded to 10.37 yesterday to test. Still the same.

So the idea is to have it routed, but the interesting thing here is even if I have the client on the same vlan of the headend it does the same as behind a vlan. So in essence it seems that the multicast is working. I think something is dropping some packets. For example, when I do a capture on the test laptop and on the switch port. The laptop's pcap file is 1.2MB and the Switchports is 4.1MB.

Flood unknown multicast traffic is enabled, I have tried with various on off settings and for Snooping as well.

[PhilipDAth]

On the layer 3 interface are you using "Enable IGMP Snooping querier" or "Enable multicast routing group"?  Perhaps try the other option.

I think this is going to end up being a support cast because it is sounding like a bug to me.

[PhilipDAth]

Is the MS410 running as the multicast router?

Is the MS250 running as an IGMP querier?

I suspect the multicast origin should be plugged in at the multicast router.  I am wondering if this is related to how the multicast tree is being built.

It would be an interesting test to plug the multicast source into the MS410 (assuming it is the multicast router).

[Deviant]

So for this conversation we can cut the MS410 out of the picture at least for now as that is 1 hop away.

So the IPTV Vendor is leaving today so I reverted to our initial setup.

So on the MS250, I have vlan 1201 which links to HP on Vendor side.

Vendor can see streams on vlan 1201 on HP no issues observed.

Then I have a test laptop on vlan 1201 also on the Meraki side, streams seems ok for a little bit and then starts going bad. Then I move the laptop to an access vlan 63 for example for PIM to kick in, same issue seems to work a bit then starts going bad.

So on the igmp querier. What I read is it should be as close to the source as possible. So do I then apply that on vlan 1201? Yesterday during testing the headend was on vlan 120 directly connected to meraki and when I did igmp querier on vlan 120 I had no entries in my PIM table. Vlan 120 was just testing it moved back to the vendor HP now.

So currently I have multicast routing enabled on vlan 1201 and on vlan 63. Unknown unicast flooding and igmp snooping enabled.

[Deviant]

Another thing I thought of was MTU

The HP runs MTU 1522, the Meraki default is 9578. So I do not think it should necessarily be an issue as the MTU will only be relevant if frames is received larger than the port MTU in which case the switch will buffer frames right?

It is the only logic in my mind that could cause something like this but at the same time I am not sure as to why since the frames should be smaller than that.

[PhilipDAth]

The the device configured for generating the multicast source is using the standard MTU of 1500 then anything else along the path with a higher MTU will not contribute to the issue.

[PhilipDAth]

>Then I have a test laptop on vlan 1201 also on the Meraki side, streams seems ok for a little bit and then starts going bad. Then I move the laptop to an access vlan 63 for example for PIM to kick in, same issue seems to work a bit then starts going bad.

Are you sure the links between the switches are configured for auto/auto (or at least have matching speed/duplex)?

You are reminding me of another job I did (long ago, using Cisco Enterprise switches).  When the streams go bad - do they simply fail?

I was helping a radio station once.  They were generating a huge number of multicast streams, and the streams would work for a while and then simply stop.  After doing some Wireshark captures for a while I found the IGMP queries downstream where sending a query to the multicast originator to verify that the stream was still valid (specifically a member) (otherwise if the multicast originator software crashes the stream will continue to exist until the switches next get rebooted).

What was happening was the multicast originator failed to respond to these queries asking if the stream was still active, and after a period of time (can't remember, something like 3 to 5 minutes) the switches cut off the streams because of no response.

It worked on some other switches that didn't do regular IGMP member query checks.

It ended up having to go back to the multicast originator vendor to get their software fixed.

[Deviant]

I do have a case open so support is looking at it.

At this stage we moved the headend onto the Meraki directly, a client now on the same vlan streams perfectly well as expected. As soon as I move the client to vlan 63, the streams goes slow and bad. But the PIM table is fine and traffic is going through but it is almost like there is packet loss. Now on the same switch even so I suspect it will end up being a bug or something.

[Kapil · Accepted solution]

Hello!

On the Meraki side, can you confirm if Multicast Routing has been enabled on the L3 interface that is configured to be the RP? 

[Deviant]

Hi @Kapil

Great question, when I moved VLAN 120 to the Meraki side I disabled Multicast Routing on my integration vlan 1201.

This was the RP vlan, I never changed it over to VLAN 120.

So, I just did that and it seems to work. I feel kind of stupid with this oversight.