Controllerless Networks

First ever deployment of IAP 105 (three of them).  Have virtual controller configured, and the other two, once powered up, pulled their config from the virtual controller so I see all three APs in the controller interface.  I am not associating from one AP to the other when roaming.  I have verified with various apps (inssider being one of them) that the signal strenth at AP B is significantly stronger than at the original AP A, yet client (lenovo laptop, android tablet) stay associated with AP A, past AP B, and even (WAY) down the hall at AP C.  Have gone through the 'check for updates' on the controller and it looks like each AP did indeed update/reboot.

---

@HammelBrau wrote:

First ever deployment of IAP 105 (three of them).  Have virtual controller configured, and the other two, once powered up, pulled their config from the virtual controller so I see all three APs in the controller interface.  I am not associating from one AP to the other when roaming.  I have verified with various apps (inssider being one of them) that the signal strenth at AP B is significantly stronger than at the original AP A, yet client (lenovo laptop, android tablet) stay associated with AP A, past AP B, and even (WAY) down the hall at AP C.  Have gone through the 'check for updates' on the controller and it looks like each AP did indeed update/reboot.

---

Is it possible that the strength at APA is good enough, even though APB is stronger?  Try setting the ARM MAX power to only 18.

 

Thanks for the reply/suggestion.  Much appreciated.  I did try your suggestion.  Same symptoms.  I even continued dropping power settings in ARM to where min was 3 and max was 6 (or whatever lowest two ratings were).  I sat about 6 feet from AP C and about 50 feet from AP B and stayed connected to AP A which was about 200 feet away.  Signal was horrible (red in virtual controller UI) and, when doing continuous PING to my default gateway, dropped at least 20%, closer to 40% of them.  I have same results with android tablet and also my win7 laptop.  on win7 laptop I have 'tinkered' with roaming agressiveness and it is now at the default of medium-high.  Both android and win7 devices show same behavior. 

 

Thanks in advance for any other suggestions...

HammelBrau,

Try to make the Arm min 12 and the Arm Max 18 and make the minimum transmit and basic rate 11. (Basic rate of only 11 and transmit rates on that said 11 and above only).

Thanks CJoseph!

Just to make sure I'm doing what you recommend:

On virtual controller, go to RF (in top right) and set (in advanced options > ARM) min/max at 12/18  (min 12, max 18).

 

Then, for each (of two) SSID, edit those and, in advanced options > WLAN settings, set 2.4 GHz at min 11, max (54???). Oprions for 5 GHZ is 12 (not 11) also max is 54.  I assume do this for each of the two SSID (one corporate, one for guiest).

 

Thanks again for your input...

---

@HammelBrau wrote:

Thanks CJoseph!

Just to make sure I'm doing what you recommend:

On virtual controller, go to RF (in top right) and set (in advanced options > ARM) min/max at 12/18  (min 12, max 18).

 

Then, for each (of two) SSID, edit those and, in advanced options > WLAN settings, set 2.4 GHz at min 11, max (54???). Oprions for 5 GHZ is 12 (not 11) also max is 54.  I assume do this for each of the two SSID (one corporate, one for guiest).

 

Thanks again for your input...

---

I was trying to get a screenshot, but i cannot.  Basically if you edit your WLAN and go to Advanced you will see:

 

Basic rates 1,2 checked

Transmit Rates 1,2,5,11......54 checked.

 

On basic rates uncheck 1 and 2 and only check 11

On transmit rates uncheck all rates lower than 11 and leave the rest checked.

 

Only do it for one SSID for now to test.  Start a constant ping and attempt to roam from AP to AP, and see if things have improved.  

 

The client really controls when it will roam or not, so all we can do is try to influence that.  Above, we are limiting the rates at which a client can connect so that it would roam sooner.  If it does not work, you can try lowering the rates, by enabling the 9, basic rate and the 9 transmit rate and trying again...  This is definitely trial and error and wil not work in every environment....

I hate to use the 'C' word on this forum, but what you speak of with checkboxes I know is on (competition that starts with a C) interface.  With the IAP105 I go to Network > (choose one of my two configured networks) > edit > advanced > wlan settings > and for Transmit Rates I have a MIN and MAX - dropdowns only for 2.4 and 5 GHz.  No listed checkboxes for each rate.  I'll start with 11, though, and see if that 'kick starts' the roaming a little earlier.  I understand what you're suggesting I do.

 

On a similar note, you'r suggesting I make some changes to (advanced) settings on the WLAN which would lead one to believe the sales pitch of 'totally seamless, totally easy to set up out of the box' isn't necessarily all the way true.  Or, maybe I should ask, do you find yourself dealing with roaming/stickiness issues or making these changes standard with every Instant deployment?

 

Regradless, thanks much for your support.  I've been to boot camp, but never got to play with the Instants, or dealing with (troubleshooting) roaming, like I am now.  I do appreciate your time....

On a side note......IAP v. 4.0 will be out in the next week or so and will include ClientMatch for the IAP.  ClientMatch already exists in AOS on our controllers.  It helps dealing with sticky clients as it attempts to steer a client to the best AP on initial association as well as post-association.

 

As mentioned earlier, though, even with ClientMatch, ultimately which AP to associate to is up to the client.

OK.  It looks like making changes to the Transmit Rates (Networks > edit > WLAN settings (advanced options) really helped out.  I need to look at what the default is for this.  I currently have min set at 18 and max at 54 and, in my test building (my office), this sseems to be a good balance.  Will be deploying these in their new home (customer's building) next week and will make changes as needed.  Thanks CJoseph for your input, for sure, and will keep an eye out, Marcus, for v4.0.  Thanks again...

HammelBrau,

 

To be clear what we just did is a workaround to get things working.  It is not typical. You might want to walk around with Inssider running on a laptop to get an informal survey of your coverage all around.

I understand.  I was trying to test / verify my configuration was going to work and wanted to do this BEFORE I had it installed at customer site.  Customer site is finishing installing furniture, cabling, etc. this week, so next week will be my install/test time and then the customer moves from old office to new (aruba-populated) office end of next week.  I did a very vanilla 'employee' and 'guest' network pretty much using default out of box configuration.  My 'test' environment (my office) is really just a very long corridor.  Maybe I was giving an unfair test, but, even with inSSIDer running, the difference between AP-a and AP-c is very significant to the point that I would have expected dis-association/reassociation with another AP.  PINGs were dropping, the AP-a was even dropping off the screen in inSSIDer.  As it is, although I understand the dis/reassociate happens with the client, the changes made on the AP is what helped with the client being overly sticky to one AP.

 

I'll see how it goes at the production environment.  I'd love to hear if this is at all common.  I saw a (pretty ugly) thread from back in 2011 about similar situation and was getting nervous since my go live time is next week.

 

I appreciate your time and efforts.  If you have other suggestions, I'm open to any and all.  I have worked with multiple other vendors with multiple AP deployments and this is the first I've seen of this kind of roaming issue where a client was WAY too sticky to an AP.

 

Thanks for the help.  Cheers...

HammelBrau,

 

Every environment is different.  The difference between Wlan yesterday and today is that people now depend on it, so anything that affects performance is noticeable.  Sometimes simply spacing access points better offers better roaming, so what works in that current space is might not work in others.  That is simply the nature of more spectrum being consumed by many more devices and the different materials in individual building construction.  I would read the Indoor 802.11n site survey and planning VRD here http://www.arubanetworks.com/technology/reference-design-guides/ to understand the principles of making a WLAN deployment successful.  Since you have deployed a number of WLANs you can appreciate how small things can make a difference in performance and the design guide will tell you what to look for.

 

In general, clients need to be able to see the next access point at a certain signal strength to roam smoothly, so spacing them out too far will cause roaming issues.  I think using the VRD. Combined with testing will give you a good starting point.