Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About DanZ
Community Record
27
Posts
1
Kudos
0
Solutions
Badges
https://community.meraki.com/t5/Wireless-LAN/MR-27-4-released-plenty-of-fixes/td-p/94876 Bug fixes: Interoperability issue with Dynamic SMPS on certain Intel clients would result in poor performance (802.11ax MRs) I'm running 27.5.1, so it should include this fix. But this issue sounds very similar. Our clients were set to Auto SMPS not dynamic. But we do have 802.11ax MR56s.
... View more
That makes sense. I just don't understand why the issue happens only roaming to some specific Meraki APs. At first I thought it was based on channels but now it just seems random. But it's always the same APs on the floor where the issue occurs.
... View more
A driver update didn't improve things. In Medium Power Saving mode the issue still happened when on battery. But I did find a driver setting that solved the issue as well: Changing MIMO Power Save Mode from Auto SMPS to No SMPS Intel site describes that feature as this: MIMO power save modeMIMO power save mode, also known as spatial multiplexing power save (SMPS) mode, allows the client to save power by keeping one antenna in a receive idle state. Auto SMPS (default): The client decides automatically what SMPS mode to apply depends on different conditions. Dynamic SMPS: The client keeps only one antenna active. The access point (AP) must send request to send (RTS) packet to trigger the client to wake the sleeping radios/antenna before sending MIMO packets. Static SMPS: The client keeps only one antenna active and the AP cannot send MIMO packets to the client. No SMPS: The client always keeps all antennas active and the AP can send MIMO packets to the client. Note Some legacy APs may have compatibility issue with supporting the SMPS mode and may cause various link quality problems such as low throughput. Change this setting to No SMPS may help to work around the issue.
... View more
Also changed the Advanced Power Setting for the Power Plan. The Wireless Adapter Settings > Power Saving Mode > On Battery setting was set to Medium Power Saving. When I changed it to Maximum Performance, the issue went away instantly while on battery: So is this some compatibility issue with Meraki and this wireless card when going into Power Saving Mode? Also, the issue does not seem to happen on all APs. I will roam and some connections will seem stable. So I can't say I fully understand why this is happening and if there is anything on the Meraki side that could be at fault here.
... View more
I got a T470s to test with. Plugging in the laptop into power made the issue go away almost instantly. Also the issue does not seem to be related to UNII-3 channels only. I see it on an AP on channel 36 as well. Testing with a user who also had the problem, plugging in the T470s to a power supply also fixed it. So it does seem related to power save somehow.
... View more
The wireless card on these t470s laptops is an Intel Dual Band Wireless-AC 8260.
... View more
This is what the client pings look like when they are on APs with channels 149, 153, 157, 161.
... View more
Wireless spectrum, interference, and channel utilization on the APs are all good. My laptop and others are fine on those APs. I will try adjusting the power-saving on the laptop card. Good advice.
... View more
This did not help on one of the T470s laptops we tried.
... View more
I've got a strange issue we are seeing. We have Meraki MR56s deployed with UNII-1, UNII-2, UNII-2 extended, and UNII-3 channels enabled for 5 Ghz. Most clients are fine but I've got some Lenovo laptops with horrible performance only on APs on UNII-3 channels 149, 153, 157, 161. *Edit - I have since seen the issue on other channels. Not sure why it seems to appear on some APs not others. Only see it on 5 Ghz though. The specific laptop model seeing issues is a T470.
... View more
May 3 2021
1:34 PM
Just to close the loop on this. It appears Microsoft Intune still does not support Fastlane whitelisting for Apps. We had to open a case with Meraki to disable Fastlane on our network. That was a change that support could make but we could not.
... View more
Nov 16 2020
1:39 PM
Interesting. So by default, without an MDM that can set QoS (which Microsoft cannot), iOS apps cannot mark QoS on a Fastlane network. Native apple apps are an exception. And the Cisco Fastlane test app also seems to be an exception. Another thing not totally clear is how the SSID signals that it is a Fastlane network. On Cisco there is a dropdown option. Enabling this option: Will do a bunch of stuff on the controller. Enables WMM, DSCP to 802.11e maps, an AVC profile, etc. On Meraki I think it is just on by default. But some part of enabling it "tells" the clients that this is a Fastlane network I am assuming.
... View more
Nov 16 2020
1:30 PM
https://apps.apple.com/us/app/fast-lane-qos/id1217974755 this Cisco app also can set QoS with no issue
... View more
Nov 16 2020
10:45 AM
You may be right about needing the MDM to allow apps to set QoS. But I still don't get why some apps (Facetime) can set QoS without the MDM setting and other (Zoom) can not. This app also sets QoS just fine without an MDM https://apps.apple.com/us/app/fast-lane-qos/id1217974755
... View more
Nov 16 2020
6:33 AM
That does make sense. But our MDM is Microsoft Intune and it's doesn't support pushing Fastlane QoS profiles like other MDMs do. But even without an MDM, how do apps like FaceTime set QoS? And when we have Fastlane disabled on the wireless network, we do see the Zoom app setting QoS.
... View more
Nov 12 2020
1:27 PM
1 Kudo
I have a strange issue. We have the Zoom app deployed on our corporate iPhones. We have a mix of Meraki APs and Cisco APs. We are trying to verify that QoS is set for all Zoom traffic. We found doing packet captures that we were seeing iPhones with Zoom mark QoS appropriately on Traditional Cisco Controller managed APs. Video is AF41 and voice is EF. When those clients were on Meraki APs, we did not see the traffic marked. All Zoom traffic was CS0. It was almost as though the iPhone detected the access point it was on and stopped marking QoS (both DSCP and 802.11e). We thought it might be Fastlane related as Fastlane is on by default on Meraki and we had it off on our Cisco controllers. Sure enough, when we enabled Fastlane on the Cisco controller SSID, the Zoom iOS app stopped marking traffic via DSCP or 802.11e. Anyone seen anything like this? Other iOS apps such as Facetime seem to mark QoS no matter what. Also Zoom on Android marked QoS no matter what. Can you turn Fastlane off on Meraki? QoS working - no Fastlane QoS not working - Fastlane enabled QoS not working - Meraki
... View more
Aug 5 2020
1:55 PM
Did the Wireless Health > Latency feature disappear? I logged into Dashboard today with the hopes of seeing data now that I upgraded to 26.8.1. The feature seems to be gone. I only see Overview, Map, and Connection log as my choices. I used to see Overview, Connections, and Latency.
... View more
Jul 28 2020
6:27 AM
Thank you for the response. We are running 26.6.1. I checked the firmware notes for the next release 26.7 and it has this fix: "Wireless Health Latency only displayed Best Effort traffic (802.11ac Wave 2 MRs)" That sounds exactly like our problem so I think you are right! Thank you.
... View more
Jul 27 2020
12:31 PM
Did anyone ever figure out how to get this fixed? I have the same issue. We have lots of voice and video traffic at all our sites, but we never see any metrics in Wireless Health > Latency for Voice and Video traffic.
... View more
May 21 2020
11:44 AM
I just rebooted a stack of 3 MS390 switches and timed it. It took 19 minutes. I thought they were broken and suddenly they came back up. That is nuts.
... View more
May 15 2020
11:44 AM
I am doing a trial of the MS390. They do take a long time to boot compared to the 355s. Code upgrade also took about an hour! I ran into the 1000 VLAN limit too. That seems like a bizarre limitation and surprising that it's not fixed yet. I am stacking 3 together and that behavior is also different. They all seem to share the same management IP instead of 3 separate management IPs. Although it lets you configure 3, only 1 will show on the Dashboard for each switch. None of this is documented anywhere that I can find. The MS390 initial startup guide makes it sound just like an MS355. I also am trying to figure out why they keep losing their connection to dashboard every 20 minutes or so.
... View more
Jan 22 2019
10:14 AM
That is how I read the document as well. I am hoping you are right that it would work. You are correct the MX would not be behind the same IP. That is back at our corporate data center. Only the Z3s would have the same public IP. - MX 1 armed concentrator - data center - ISP #1 - Single Public IP - Z3 #1 and Z3 #2 at Regus location. - ISP #2 - Single Public IP. Another possibility is to try to get the Regus office to cross connect an MR22 AP from one office to the Z3 LAN port in another office. They might be able to patch that for us. That would solve the problem. I'm not sure if they will do custom wiring for us like that though. Can you have an MR22 behind a Z3?
... View more
Jan 22 2019
10:03 AM
In my scenerio, the private IPs wont be able to communicate to each to establish a tunnel since there is not a private MPLS link. In the example they are describing bringing a tunnel up using those private IPs: "In this example, the Dashboard knows that the two devices can’t form a VPN Tunnel through the same SRC IP address, so it will try the IP addresses of the Interfaces. The routing through the MPLS allows the MX devices to communicate using these Private IP addresses, and the tunnel is dynamically established."
... View more
Jan 22 2019
10:00 AM
That is what I am hoping would work. Just trying to see if anyone knows for sure. I guess we could buy some Z3s and test it locally.
... View more
Jan 22 2019
7:54 AM
That is helpful info but I don't think it applies to this case. The Z3s in my case will only be connecting over the Internet to a head end MX64 in 1 armed concentration mode. There is no second path over MPLS.
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 1 | 5468 |
© 2024 Cisco Systems, Inc.
