MR 55 Firmware 26.5 Beta

SOLVED
SLR
Building a reputation

MR 55 Firmware 26.5 Beta

We have 17 MR55 AP in our environment -

 

Since the implementation on regular stable firmware, there were many devices who could not see the broadcasting SSID coming from the AP. Some devices were HP and some dell mostly either win 7 or win 10. Some not all...

 

I called Meraki support and they had me push out the beta 26.5 version so they can disable the AP for wifi 6 capabilities...

 

Since then - after doing driver updates to a lot of devices, when connecting to different access points, the clients would connect/disconnect. 

When reconnecting - the device would take forever to communicate to the AP, then when it finally communicated, it said no internet, until about 10 to 15 minutes later, It was connected successfully.

 

Some users when connected are seeing slowness when saving documents in excel /such..

 

any ideas..

 

1. currently have layer 3 roaming

2. WPA-2 Enterprise

3. Dual band operation with Band Steering 

 

radio setting show the following for 2.4

 

 

 

 

ap 2.4.PNG

 

Radio for 5

 

 

 

ap 5.PNG

 

to add to this - the access points which I am seeing the issues with are about 100 ft apart from each other, do you think this Is causing overlap/interference or client drop off issues? (slowness)

1 ACCEPTED SOLUTION
NolanHerring
Kind of a big deal

  • Do not use 80MHz, start with 20MHz. If you can get away with 40MHz feel free, but I find it's best to just stick with 20MHz
  • Reign in your TX power levels
  • You'll want to turn off some 2.4GHz radios most likely as well
  • You might want to take a look at 26.6 firmware that came out recently
  • Use DFS channels (if you can)
Nolan Herring | nolanwifi.com
TwitterLinkedIn

View solution in original post

22 REPLIES 22
NolanHerring
Kind of a big deal

  • Do not use 80MHz, start with 20MHz. If you can get away with 40MHz feel free, but I find it's best to just stick with 20MHz
  • Reign in your TX power levels
  • You'll want to turn off some 2.4GHz radios most likely as well
  • You might want to take a look at 26.6 firmware that came out recently
  • Use DFS channels (if you can)
Nolan Herring | nolanwifi.com
TwitterLinkedIn
PhilipDAth
Kind of a big deal
Kind of a big deal

>currently have layer 3 roaming

 

You probably should not be using layer 3 roaming.  This is only for a very specific use case.  If you have 17 AP's you should be looking at using ordinary "bridge" mode.

 

 

Good catch @PhilipDAth , I didn't even notice that snippit

Nolan Herring | nolanwifi.com
TwitterLinkedIn
SLR
Building a reputation

it was the request from Higher up so we don't run out of IP in the scope. Concurrently - we have close to 180 users connected to the access points.

PhilipDAth
Kind of a big deal
Kind of a big deal

180 users will fit into a single /24 - so that really is not a biggy.

 

Are your WiFi users all in a single subnet or multiple subnets at the moment?

Are your users in a single building, or spread out over a campus and many buildings?

SLR
Building a reputation

2 VLANS

 

1 vlan to IDF 2nd floor subnet

1 vlan to IDF first floor subnet

PhilipDAth
Kind of a big deal
Kind of a big deal

Can users roam between these two floors without loosing their WiFi connection, or do they loose and then re-connect when moving between floors?

SLR
Building a reputation

Users are able to roam successfully to other APs between upstairs and downstairs. The only timeout / drop I get is when I am upstairs heading into the stairwell to go downstairs and vice versa but my device immediately connects back to nearest AP.

NolanHerring
Kind of a big deal

stair wells are usually 100% brick/concrete. Your not going to have a smooth roam between floors usually. If you did managed to have smooth roaming, you still might have issues because your going from one subnet to another, by issues i mean with real-time applications. If you can make it a /23 or /22 then that would minimize any disconnects due to having to get a new IP on the new subnet etc.

Not sure if that matters though if there is no smooth roaming between floors.

Actually might matter if the floor to floor seperation is weak. so clients on floor 2 might connect to an AP on floor 1 and vice versa. Floor is just a fancy word for wall afterall 😃

I could see if that happens then it would cause real-time stuff to suffer since its differnet subnets
Nolan Herring | nolanwifi.com
TwitterLinkedIn

Also the reign in your TX power level, to add to that. Create a min/max (usually something like 11-17 dBm for 5GHz for example, and 8-11 for 2.4GHz etc.) Depends on the layout and how the survey was done. You won't want an AP blasting
Nolan Herring | nolanwifi.com
TwitterLinkedIn
Brons2
Building a reputation

You're using L3 roaming so you don't run out of IPs?  If you're using VLAN tagging for your SSID, you'll get the number of IP addresses that happen to live on any IP subnets on that that VLAN regardless of whether it's /30 or /8.  Like the example below, the VLAN which I blacked out, has a /23 on it, it's for our public wireless and is carried on all floors.  I haven't encountered a situation where we needed more than 512 guest IPs - yet. 

 

Which is another thing - you have different SSIDs for different floors?  Why?  If I have a meeting on another floor, I have to go join another wireless network?  That seems unnecessary to me.  Roaming to a different Meraki AP in our network is pretty transparent.

 

meraki-bridge.jpg

BrechtSchamp
Kind of a big deal


@Brons2 wrote:

Which is another thing - you have different SSIDs for different floors?  Why?  If I have a meeting on another floor, I have to go join another wireless network?  That seems unnecessary to me.  Roaming to a different Meraki AP in our network is pretty transparent.

 


I don't think he has different SSIDs per floor. He's probably just using the Per-AP multiple VLAN tagging, see here: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging_on_MR_Access_Points)

SLR
Building a reputation

Previously we were using APs that did not have roaming capabilities. The goal was to have users be able to walk from one area of the building to another for meetings in conference rooms seamlessly without dropping off the network while still holding on to the IP they had.

 

We do not have different SSID names for 1st and 2nd floor. They are all the same name. I am using the Per-AP multiple VLAN tagging. 

 

I changed the channel width from 80 to 40 for the 5GHZ.

 

 

NolanHerring
Kind of a big deal

I've never tested it but I'm pretty sure that the Per-AP VLAN Tagging will not allow smooth roaming. Its going from one subnet to another (one vlan to another), which is forcing the clients to grab a new IP etc.

Your best option (what I do) is use a /23 or /22 for the entire 'building' and the SSID drops onto that VLAN which spans everywhere. Assuming your core-to-access layer allows for such a thing
Nolan Herring | nolanwifi.com
TwitterLinkedIn
SLR
Building a reputation

I just tested this successfully - when I walked upstairs and around the building, my IP from downstairs stayed the same. the only thing that changed was the VLAN Number. I connected to each of the 17 access points.


I have a feeling the TX power is causing an issue with one of our devices disconnecting and reconnecting because a few are 200 feet apart from each other. I have the same two viziocasttvs with two different mac addresses trying to connect to 3 APs...

Mon Oct 28, 2019, 09:54:44
viziocasttv
Association
type='Association attempts' num='3959' associated='true' radio='1' vap='1'
Mon Oct 28, 2019, 09:52:54
viziocasttv
Authentication
type='WPA-PSK auth fail' associated='false' radio='1' vap='1'
Mon Oct 28, 2019, 09:52:34
viziocasttv
Association
type='Association attempts' num='3958' associated='true' radio='1' vap='1'
Mon Oct 28, 2019, 09:51:34
viziocasttv
Authentication
type='WPA-PSK auth fail' associated='false' radio='1' vap='1'
BrechtSchamp
Kind of a big deal


@SLR wrote:
I just tested this successfully - when I walked upstairs and around the building, my IP from downstairs stayed the same. the only thing that changed was the VLAN Number. I connected to each of the 17 access points.

That's thanks to the L3 roaming, with that you keep your original IP address. This is a good article describing L3 roaming more in detail:

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

 

As @PhilipDAth and @NolanHerring already mentioned, L3 roaming is not always the solution. Especially if you have a "smaller" network you'll be better of with one L2 domain. That's when you'll be able to leverage roaming optimizations like OKC and 802.11r.

 

Regarding the Auth failed error. I assume the TVs are using the correct password? I'd try temporarily adding a separate SSID to test the TVs with a really simple password, just to make sure it's not a bug in the TV OS causing it to use a wrong password.

 

Also, what is your minimum bitrate slider set to for that SSID?

SLR
Building a reputation

Slider set at 11 - 54.

 

Should that be changed? Minbitrate.PNG

BrechtSchamp
Kind of a big deal

Should be fine. But if you do setup that test SSID for the TVs, lowering it on that SSID is one of the things you could try if you can't get them to connect.

SLR
Building a reputation

Thank you. I will try that.

Brons2
Building a reputation

I pondered "Per-AP multiple VLAN tagging" a bit more over the weekend.

 

It seems to me that, from a network design standpoint, that this feature would only be desirable if you were running the same SSID across multiple physical sites/branches, something to where a large flat network would not be desirable due to latency.

 

Am I missing something?

Lixxie
Just browsing

Meraki support could never sort the problem with connecting our HP printers with WEP key - we had no problems with MR53s

Had to return the MR55s for a refund a couple of months back

First disappointment with Cisco/Merkai, and seriously put a dent in confidence in Cisco going forward.

Brons2
Building a reputation

WEP key?  WEP has been insecure since, oh, 2001.

 

"Depending on the amount of network traffic, and thus the number of packets available for inspection, a successful key recovery could take as little as one minute"

https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

 

Perhaps you meant WPA.  I hope so. 

 

If not - I'm not surprised Meraki couldn't fix it.  They probably have no interest in fixing it, what with WiFi 6 and WPA3 coming out.  It doesn't make much sense to support deprecated, insecure protocols, in my opinion.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels