Re: Site Local Scope on Wifi

benjaminriggenbach · ‎02-25-2019

Hello.

We use some devices wich are able to transmit uncompressed audio. The protocol is Dante by Audinate.

The protocol can send data via unicast and multicast, if more devices are feed with the same stream.

The multicast mode uses the Site Local Scope 239.255/16 Addresses.

I do not want to transmit the stream over wifi, but i would like to know, why this stream does not get transmitted over the wifi?

I couldn't find a hint in the rfc2365 standard, that this scope is blocked anyway on wifi connections.

The AP i used for that is a Air-SAP702I-E-K9. I configured it myself and i did not explicit allow multicast nor deny it.

Some of the control data and device detection process is transmitted via mdns and this works fine. So i figured it can't

be a general multicast issue.

Is there a general rule about this site local scope that it can't be transmitted over wifi anyway or something?

Thanks for the help.

Regards,

Benjamin

patoberli · ‎02-25-2019

It seems that Multicast isn't supported in Autonomous mode.
Check here for some details: https://community.cisco.com/t5/other-wireless-mobility-subjects/enabling-multicast-on-standalone-mode-ap/td-p/3066766
It seems there is some hope for the WGB mode that you could try.

benjaminriggenbach · ‎02-26-2019

Thank you patoberli for the response.

I've read the linked tread.

Like i said, i do not want to achieve that this multicast traffic is transmitted. It is more the question why this traffic is not transmitted?

Anyway, it lead me again to my testing setup. I use a 3750g as a main switch. The audio device is connected to it and the AP as well. Same vlan, nothing else on this setup. Now when i want to remote the audio device via my controller software on the computer (which is of course connected to the AP and usually works fine when no multicast stream is on) i can't even reach the audio device. And again, no 239.255/16 traffic is passing the AP (verified with wireshark). So i don't think it is a troughput problem. This stream would only be about 10mbps.

When i enable igmp snooping on the 3750g, everything works as expected. This leads me to the adoption, that the AP has difficulties to process this data.

By the way, igmp snooping was the whole point of testing this connection and it lead me to this topic, why this traffic is not transmitted over the wifi in the first place.

For the record, enabling igmp snooping on the AP didn't help that a connection could be established between the controller an the device.

So is there a difference of forwarding rules/processing rules between these certain multicast scopes? I mean mdns is passed through the AP when igmp snooping is enabled. For me again, it can't be a general multicast issue, that the AP can't handle this "flood" of the site local scope for whatever reason?!

Am i missing a major issue here?

Thank you for your help.

patoberli · ‎02-26-2019

Is that 10 mbps for a single client? As soon you have 2 or 3 the AP will probably be overloaded as it lacks multicast functionality without a WLC.
In wireless, multicast is (normally) handled as Unicast traffic, because that's how wireless works. Cisco has a special extension, when used with a WLC, that allows multicast on wireless with some caveats.

benjaminriggenbach · ‎02-26-2019

Well, i think now we're getting closer to an explanation.

The 10mbps are the multicast flow (that's how they name it in their protocol) that a sending device is generating.

Obviously it sends it out once on the interface over a multicast address. All devices who want to receive the flow have to register to that multicast. So when igmp snooping is turned off, there is this one flow entering the interface of the AP.

But now comes the sticking point i guess..

I thought when i just monitor my wireless interface on the controller computer with wireshark, i have to see this traffic like i do when i just connect to any other interface on that vlan with a cable. There i can obviously see all this traffic because it is a multicast and it is sent out on a connected interface whatsoever. Long story short, there is no receiving device on the other side of the wireless connection, just my monitoring computer.

The developer of this protocol points out, that it is not usable with a wireless connection. I never 100% understood technically why but i think now i'm getting there as well. It is a protocol used in the pro audio industry and of course we would never want it to use over a wireless connection because it would not be reliable enough anyway.

Since you mentioned that the multicast traffic on wireless is handled as unicast, this is certainly why it wouldn't work.

Back to the topic, the bandwidth entering the port on the AP is really just about 10mbps in this case. I think it should be able to handle that :-) but i think then it comes- what should it do with this traffic when it is not able to generate multicast on the radio interface, right?! The thing i still don't understand is; why does this affect my controller traffic when snooping is still disabled? I mean, the troughput on the gigabit interfaces can't be overloaded by just that one flow?!

You are really helping me getting closer

patoberli · ‎02-26-2019

I'm not sure I understand your second question :(

But I'll give you some more insight about how wireless works.

An access point works like a Hub, so only one attached device at a time can either send or receive data. This changes for 802.11ac Wave2 and newer, but requires compatible devices and has various other limitations. That is why multicast never was implemented on wireless. There are some functions that work, like mDNS, but in the end, it will be unicasted between the AP and the client.
See here for way more details and restrictions: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/ch6_Mcst.pdf

benjaminriggenbach · ‎02-26-2019

An access point works like a Hub, so only one attached device at a time can either send or receive data. This changes for 802.11ac Wave2 and newer, but requires compatible devices and has various other limitations. That is why multicast never was implemented on wireless. There are some functions that work, like mDNS, but in the end, it will be unicasted between the AP and the client.

This definitely cleared my mind. I get this one.

When igmp snooping is disabled on the 3750g and the audio device is still sending his multicast stream to a receiving device by a cable on the same vlan, i'm not able to connect to it properly via the wifi connection. When igmp snooping is enabled on the 3750g, i can connect without any problems trough the wireless connection. This means the LAN interface of the AP does not get any multicast traffic which is fine of course. But i wonder why i can't connect my controller to the device when igmp snooping is disabled and the LAN interface gets flood with the multicast traffic, since it is not that much data?

It seems to me, the AP can't handle the traffic for whatever reason. Is there a certain debug command i could try to verify if the AP has some difficulties with the multicast stream? It almost looks like the AP is overtaxed with the multicast data, but i can't really believe that, even though it is a AP without controller.

I do not understand why a multicast stream would affect the rest of the traffic, since igmp snooping is the only thing i change that controlling works or works not?

I know this sounds probably a bit unusual but i hope i could ask the question more clearly.

patoberli · ‎02-26-2019

I'm still not entirely sure I understood your issue.
With igmp snooping enabled, the switch will listen to multicast joins and forward packets to the multicast ip address in both directions. It will add the physical port (or actually the client attached to it) to be added into the multicast group. The ap should then get those packets from your audio-controller and forward them in unicast to the client.
Normally, the AP learns about a client by ARP, but Multicast (as far as I remember) doesn't use any ARP and there's the crux.

Also, multicast is often UDP and doesn't work well with packet loss, something which is "normal" on the Wi-Fi. I'm not sure if your audio device works well with packet loss, or requires a certain latency (also something you can't guarantee on wireless).

For checking if the switch/AP gets the traffic, mirror (SPAN Port) the LAN port to another port and use a pc on that port with Wireshark running.

benjaminriggenbach · ‎02-26-2019

No, my device doesn't handle packet loss very well of course since it is used for live shows :-)

I've attached a (very simple) sketch of how it is hooked up.

I'm not concerned, that the AP can't send the multicast anymore. This is clear now why and there is no need, that this traffic would be sent over wifi.

I found out about it by mirroring and monitoring the "int gi3" according to the sketch after all.

So in other words, when "int gi3" transmitts the multicast to the AP, my controller data from the computer is not even getting trough to the sending device. It seems this happens just because the interface gets flooded by the multicast traffic. And since it is just about 10mbps this shouldn't be too problematic for the throughput of the interface since these are all gigabit interfaces.

Controller data is transmitted directly from sending device to controller on a udp port, not through multicast. Probably i should've mentioned that earlier. So these are 2 different stories.

So i don't understand, why this multicast traffic that goes to the AP on "int gi3" would or could affect the AP in a way that also any other data does not get trough properly?

Obviously when i turn on snooping, the "int gi3" and therefore the AP's LAN interface does not get flooded with multicast and controlling works perfectly.

patoberli · ‎02-26-2019

I think we have reached now the limits of my multicast understanding.

Just that I follow you correctly, if igmp snooping = disabled on gi3, the wireless connection is unreliable for all types of traffic?

If yes, then we probably have to start the default wireless client troubleshooting, starting at software version running on the AP (show version) and by making sure (if just one client is affected) that the wi-fi adapter driver on the client is up to date.

Is the client connected with 2.4 or 5 GHz? What is the clients reported connection speed?

benjaminriggenbach · ‎02-26-2019

@patoberli wrote:
I think we have reached now the limits of my multicast understanding.
Just that I follow you correctly, if igmp snooping = disabled on gi3, the wireless connection is unreliable for all types of traffic?

Exactly.

There are a a few controller packets coming through every now and then according to wireshark (monitoring int gi3) but the controller becomes useless.

The client is on the 2.4GHz interface. The AP is programmed on both 2.4 and 5GHz with the same SSID.

The client reports a speed of 144mbps.

I've just tried it with one client but these are the same symptoms like we had on the filed a lot and couldn't figure out why that happened.

So i suspect that it is not on the client side. And since the multicast doesn't get passed on the wifi interface troughput shouldn't be the issue between at least client and AP, right?! Alltough 144mbps is not very much, but the controller data is literally nothing.

Like i mentioned, a debug command would be helpful i guess, since i really suspect the AP to be the problem. Like something that the ios of this AP can't handle very well.

So this is what leaves me devastated..

It comes to my mind, that i could simply test the same setup but with a different brand AP.

I will try that tomorrow.

Thank you so much for hanging in :-)

patoberli · ‎02-26-2019

Multicast can be nasty, because it also loads the CPU of routers and in some cases switches. I don't know about access points though.
Anyway, can you please provide me with the software version running on the AP? (show version) Maybe it's a version containing a bug like that.
I would need to re-read the multicast theory, about what happens if a client sends an IGMP join, when the switchport has disabled IGMP snooping (there is no reason to disable it normally). I wonder if the traffic will then simply be broadcasted out of the lan port, if it's in the same vlan.

benjaminriggenbach · ‎02-28-2019

Hi patoberli.

Sorry for the delay. I was kinda busy yesterday.

If understand your concern about the multicast correctly, i can assure you this: When my sending device sends out the multicast and igmp snooping is disabled on the switch, every active port (on the same vlan of course) sends out the multicast traffic, whether the other end could be a subscriber or not.

I was able to check out different AP's. Funny thing now is, with an Apple Airport (i don't know the exact model, it's about 5years old) the same thing happens; my controller gets useless if igmp snooping is disabled. I also tried it with an Aeronet1242 and with this AP, the controller works fine, no matter if igmp snooping is disabled or enabled (meaning the interface is flooded with traffic or not). So i'm guessing it handles the flood differently than the newer AirSap 702

I've attached both configurations, because i do not have enough knowledge what command could be the difference or if it's just the different ios version or even the hardware. So the version number is implied in the "show run" command, please let me know if it would be helpful to see the whole "show version" output?

patoberli · ‎02-28-2019

Yes please add the show version, because only that output will show the exact running version.

Btw. is there a reason for having IGMP snooping on the switch disabled?

Just discovered that your AP might actually support multicast, but it's currently disabled.

Enter 'ip igmp snooping' on the AP, that might enable it, but I'm not sure.

benjaminriggenbach · ‎02-28-2019

Yes, the enabling igmp snooping command on the AP (702) works, but does not have an affect in my setup whether the controller works or not.

No, there is no reason it has to be disabled. But the fact that it was disabled all the time (i think it is disabled by default) made me think a lot and i will enable it from now on of course. It might have caused a lot of other phenomenons we couldn't explain ourself.

I'd like to understand why or what the differences are between certain AP's. What does the one do better than the other and it seems that even the 1242 does handle this multicast traffic different/ better than the 702. In our business we use a lot of and wireless equipment and literally nobody understands a **bleep** thing about it, despite using it all the time. There are a few people out there who are just going: "I use this brand/model and i never had any problems!" And the devastating part is often, they are right. They're **bleep**ty equipment sometimes work better than our Cisco device. So i try to understand where the problems are and how to solve them with knowledge, not by just swapping the whole equipment. This is not a solution i accept, this is lack of knowledge :-)