Controllerless Networks

We have a weird issue with an Aruba Instant network we have installed.

There are 24 IAP-205-RW in a school distrubuted between 3 building. If a client roams between buildings it takes a few minutes before their IP is renewed, if you turn the device radio off and on again they get a new address straight away. Wireless coverage between the building hasn't be planned.

The school has a flat L2 network.

The IAP's are running the latest version of firmware.

Between-building roaming will be poor if there is little to no coverage.  You should measure how well you can see access points between the buildings first.  If you cannot see two APs at -65 at the same time, it is entirely possible that roaming will not be smooth, at all.  When outdoors, you also have to compete with interference, so unless you can do something to improve your coverage outdoors (maybe with outdoor access points), you should not set the expectation that roaming will be smooth between buildings.

Thanks Colin. 

If you do try and roam the device can take up to 10 minutes without user intervention to get a new DHCP address, does this sound normal?

Jason

If you have that problem indoors, I would say you have a coverage issue.  Since you say it is happening outdoors, I would find out what type of coverage you have.

Colin,

The problem is when you move from one building to another your device radio turned on. When you are inside the second building and stood under an AP the user device will not automatically obtain a new IP address unless the the radio is turned off and back on again.

This happens most with iOS devices.

I guess it would be the same sort of scenario if you were in a tower block office and went between floors in a lift with no coverage, you would still expect your device to renew it’s address when you came out of the lift on a different floor?

JazzyT,

There are a number of reasons why this could happen.  The most definitive way to find out what is happening is by doing a packet capture at that AP on the channel the AP is on to see what your client is doing.  Is the client giving up when there is no coverage?  Is the IOS client configured to only manually connect to that network?  Did the client roam to another open SSID before connecting?  Is there too much interference, so the client is giving up? Connection is initiated by the client, unless you have some IDS, IPS configured on the access point that would be preventing the client from connecting.

I would do the roam and then immediately take the tech support from that specific IAP to get a clue what is going on.

Again, there are quite a few things that could be going on, and if you have not looked at the IAP tech support after the incident, we are just guessing the many things that could be wrong.

I assume all the IAPs are in same cluster, and you are not using Zones configuration.

In addition to what Colin described, you can also try the below.

1. V.Imp. This can save a lot of time. find out if the issue is, client/SSID/VLAN/authentication specific. By creating a test SSID on open auth, different VLAN with a windows client and doing the same roam.

2. upon failed roam first figure out, where the client (note down its wireless mac address) got stuck, while associating, while authenitcating, or while doing DHCP. use the below commands to check each phase:

association-
show ap debug mgmt-frames

authentication-
show ap debug auth-trace-buf

DHCP-
debug pkt dump type dhcp
debug pkt dump

Pay careful attention to timestamps to study the logs seen by using the above commands.

all these commands are AP specific, so using them on master IAP will not result into useful info. Use these commands on the slaves in question.

After doing the above you would atleast be able to rule out any IAP issues. 

If i were you, i would also upgrade the cluster to latest supported software for the AP platform.

Hello,

Yes they are all in the same cluster with no zones and it is running the latest firmware.

Do you think turning on 802.11v/k/r could help things here or lowering the Inactivity Timeout on the SSID?

all these are shots in dark, they can work, they might not. but it does not hurt to try them.