On the backend, I had Meraki support disable 802.11ax capabilities on all AP's since it was causing an issue and we didn't anticipate utilizing it yet fully.
I do have L3 roaming configured. It is the worst thing ever and Meraki support has confirmed that there are known issues with it.
Right now, I am finding a very odd behavior with a user who has a Samsung galaxy 10 + phone that is displaying a number 6 next to the wifi symbol when connected to my network. why is this happening? what does it mean? all 802.11ax capabilities on my access points are disabled.
it only happens when the user connects to one specific access point in their area. all aps have the same setting. same as ssid.
Not that exact problem, but I've read about similar ones. See this one for example:
In that case even a reset didn't help, but for your case it's definitely worth a try. I see no other reason why the one AP would behave differently than the others.
Thank you all for the recommendation - this resolved the issue.
1. removed AP from network
2. factory reset AP
3. placed AP back into network and let it continue to download configurations
4. tested and confirmed 6 symbol no longer appears next to wifi icon on users Samsung galaxy 10 plus phone. tested text messaged sending successfully.
Agreed that a factory reset sounds like a good plan here. We've had APs get "stuck" before and that was the only way to get them to pull a clean config.
any idea what causes this? is Meraki aware of the issue? I wish there was a way to tell on the dashboard side whether a config is clean or not.
Well - that was short lived. To remount it, I needed to disconnect the cable. once I did that and the ap rebooted/grabbed the config again, it went back to the same behavior.
Hmm. At this point I'd get it RMA'd. Maybe there's an intermittent problem with the memory chip of the AP causing something to go wrong occasionally during boot.
I'm a parrot. Please consider this another vote for RMA. You removed it from the network, wiped it clean, added it back, it pulled a config... and then it still went back to bad behavior?
What firmware version is running on your MR? If it's on 26.5 or 26.6, try toggling the "Disable 802.11ax" back on, wait a minute, then off again and see if it resolves the issue. If it does, then to workaround this you can either have Meraki Support roll you back to 26.4 or wait for 26.7 which will have a fix for this.
The problem is if the AP running 26.5 or 26.6 has the config to disable 802.11ax when it boots up, it will ignore that config. However if the MR45/55 is online and you modify the config to disable 802.11ax, it will take effect. If the AP reboots though, you will have the same problem again. A factory reset or RMA should not be required.
we are currently on 26.6. we have the wifi 6 capabilities disabled on the backend for both 2.4 and 5GHZ across all APs and network. We did toggle the disable 802.11ax in the dashboard. We even created a new ssid. None of those options alleviated the issue and it is only isolated to one AP out of 17. The user affected by it considers it a high priority and we had been working with support since November. We have an RMA coming to us this week. 🙂 If that doesn't resolve the one AP issue, then we will wait for 26.7 and probably have Meraki support on the backend re-enable the wifi 6 capabilities on all MR55 devices in our network.
If Meraki Support disabled 802.11ax on the backend, then it actually won't matter what you do with the UI toggle since what they've done overrides the UI option. If you're running 26.6 and they've disabled it and the AP has since rebooted, you'll hit the condition for the bug which is 11ax being disabled in the config upon boot. If it's only affecting one AP it could be that this one rebooted after disabling 11ax but the others haven't rebooted after Support applied the config.
Also - I have been troubleshooting this issue with Meraki Support since November 22nd. How come no one mentioned to me anything about a possible condition bug? I find that super odd.
Also "If it's only affecting one AP it could be that this one rebooted after disabling 11ax but the others haven't rebooted after Support applied the config." - If that is so, how come after it was disabled and ALL access points were rebooted, that there was only 1 AP that was affected?
I would confirm with Support in your case that all the APs are indeed running 26.6. There might also be something else going on with that one AP which they can take a look at if it's online. The AX HE advertising issue doesn't exist in 26.4 (I just tested this on my MR55 to confirm) so if this is a pressing issue for you, 26.4 could serve as a workaround until 26.7 is released.
Regarding the layer 3 roaming point in your original post, there is only one use case for that and that's if your APs' management IPs are on different subnets. If your APs are all on the same subnet then there's no need for L3 roaming. There is a bit of a performance hit in using it due to the overhead in maintaining the tunnel to the anchor AP you initially connect to. How it works is you connect to the original (anchor) AP, then as you roam around the environment all your client's traffic is tunneled back to the original anchor AP and spit out there. The best roaming performance will be observed using bridge mode.
For example, if AP1's management IP is 10.0.0.10/24 and AP2's management IP is 10.0.0.11/24, use bridge mode. However if AP1 is 192.168.50.10/24 and AP2 is 10.0.0.11/24 and you need your clients to maintain IP connectivity as they roam from one part of the infrastructure to another (another floor in a building, another building, etc.), use layer 3 roaming.
Probably just the problematic one for now. One other thing to note about disabling 11ax is that currently it doesn't work when using the "Per SSID" band selection setting on the RF profile. If you're using the "Per AP" setting, then it'll work on 26.4 (all the time), 26.5 and 26.6 (until a reboot).
so we re-enabled 802.11AX across entire network SSID/AP for both 2.4 and 5.
Wifi 6 capable phone (Samsung galaxy 10+) is still having the same behavior when trying to send texts across different access points.
meaning starting position would be at the datacenter ap - sends text (texts goes through)
a few minutes later, walks upstairs to hr area ap - sends text (text goes through)
a few minutes after that, walks back downstairs to the datacenter ap - sends text, text fails to send
Only way text will send is if user manually disconnects and reconnect to datacenter ap
we are on Meraki dhcp NAT for client IP assignment.
can someone help me to understand the process of how each client on Meraki DHCP Nat is handled from AP to AP? Is the IP address supposed to change when I walk from one AP to another. How does the AP determine pass off? is it supposed to be a seamless hand off? How come it isn't?
should our band selection be different? We currently have it set to dual band operation with steering
NAT mode 'breaks' roaming and isn't recommended if you need to roam. See https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/NAT_Mode_with_Meraki_DHCP#Common_.... It hearkens back to the early Meraki days and was designed for guest Wi-Fi in hotels and coffee shops, etc. since it's an easy setup that provides DHCP (no server on the LAN needed) and client isolation (security). Fun fact: This used to be the ONLY mode of IP addressing available in the Pro days, before Enterprise licensing was a thing and introduced bridge mode. There's nothing wrong with it per se, whether or not to use it just depends on the requirements at hand and what's available on your network (i.e. a DHCP server, VLAN aware switches).
If you need seamless roaming, it's best to use bridge mode. If you're using the latest MR 26.X firmware (I wouldn't recommend using L2 isolation on 25.13 due to some known issues), you can use the Layer 2 LAN isolation feature with bridge mode on the Wireless > Configure > Firewall & traffic shaping page for your guest SSID in order to prevent the wireless clients from talking to each other, just like in NAT mode. You can also add a "Deny Local LAN" rule to deny those guest clients access to the LAN resources and only allow them to the Internet.
Are the APs on different VLANs between the floors? You might need to tag the SSID with a VLAN and make sure that VLAN is trunked between the floors.
We have similar issues with these model access points. These are very unstable. We have the same setup in other buildings but with the 802.11ac models. We thought going to 802.11ax and disabling it would be good at first. Huge mistake 400 users always complaining of random issues is not a good thing. Cisco meraki should not of released these access points not having stable code. Support suggested us to go to 26.x beta code. We experience voip packet loss and tons of issues. I wish we can return these for more stable we have 42 of these.
Simply adding my feedback to this thread and confirming what have been said earlier as I'm facing similar issue since October.
We have several devices that don't support WIFI6 at a point they dont even see our SSID being broadcasted but only neighbors SSID which is really odd to me (known issue on several intel chipset apparently)
Meraki support did deactivate 802.11ax on both 2.4G & 5G Radios. However if you reboot the AP, 802.11ax is enabled back on 5G so you have to ask them to reapply the fix, time for their new 26.7 firmware to be released.
Finally, you can end up with some Access Points with WIFI6 enabled on 5G and either not visible or creating issues with specific endpoints.
There is a known issue with the aps broadcasting wifi 6 even being in disabled mode on both radios.
The firmware update is already out. Have you tried to update yet? Or is the newest firmware update causing you issues?
Also, we put everything in bridge mode. Roaming just caused us widespread issues.
26.7 which has the fix for the issue isn't yet released. 26.6.1 was released but it does not contain the fix. 26.7 should be ready soon.
Will the 26.7 fix wifi on 5G and wifi 6 enabled cellular phones. We are seeing random disconnects on user phones with 5G and WIFI6 capabilities. It appears that the phone can't handle the connection and drops from time to time.
I wouldn't do that just yet. Our environment has repaired itself on its own. we moved everything from roaming to bridge mode. the phone issue is no longer a problem and we have wifi 6 enabled. The only issue we see are with Windows 7 devices - the drivers are too old for connecting to the access points for some devices. No new WIFI driver updates for a long time now. Also - when vendors come on site, if their WIFI drivers aren't updated by their IT, they cannot get on.
I just patiently wait for news firmware upgrade and anyconnect support. we are in a much better place now than where we were originally.
What version are you running? They are suggesting us to downgrade... we are in bridge mode. iPhones won't stay connected to the network.
Have you reached out to support regarding the issues for on site visits by vendors? Try doing that and let me know what they recommend. I am curious.