Wireless Access

Hi,

I've just upgraded a Controller from 6.1.3.2 to 6.3.1.10. On this suite we have WiFi-Phones and they was working perfect. But since the Upgrade we have big roaming issues. The calls are ok but when you are in motion then you have several problems (breaking calls, you can't understand the other).

Again, before the Update all things went fine. The customer did have other clients which was having issues after the update, too. I could fix this by changing the max-retrie counter to a higher value.

Is there anything that was changed regarding to roaming?

I've already tried a firmware-Update on the phones but it don't fixed the errors. What can I do now? The Dashboard says that there are 0 issues but the SNR-Rates of a few clients are not good. Voice is operating at 5 GHz only.

Are there any known issues? I don't found something in the release-notes.

Have ArubaOS 6.3 Best practice been applied to the config ?

6.3.x.x contains numerous new parameters that are not present in the older ArubaOS, these should be documented in the various release notes, and in the ArubaOS CLI Reference Guide.

There are numerous changes between 6.1.3.2 and 6.3.x, I'd recommend to look in detail at the client-to-AP behavior to see if one can identify what is going wrong.

Always start with a stationary client to characterize the basic behavior with a good signal.

Here, one is usually looking for retries, or dropped frames.

Once this is established as acceptable, the roaming function is really up to the client to decide, but we can view the AP perception of the client, and check delays to re-auth, which might have an impact.

Here is an outline of an appropriate client test:

-enable user-debug for a selected client.
conf t
logg level user-debug <client mac>

- position the client stationary near a selected AP

- begin icmp echo to at least 1 or 2 known targets, the client's default gateway, etc..Larger frames are interesting in some cases, 1400 bytes for example.

- Gather stationary performance stats:

UI dashboard - focus on the client

-CLI data, showing RF background, checking noise and interference levels, as well as ARM events which coincide with client reported problems. (show log wireless is also helpful)

show ap arm state ap-name
show ap arm history ap-name
show ap arm rf-summary ap-name
show wms ap list
show wms client

- Client specific data&colon;

show user-table verbose | include CLIENT MAC

show user ip

- run the following commands multiple times, it is much easier to perform the comparison live, noting the deltas

show ap debug client-stats adv | inc rop,etr,iss,ail,SNR,Trans
show ap debug radio-stats ap-name radio 0 advanced (where radio 0 is 802.11a and 1 is 802.11g)
show ap debug client-table ap-name | include
show ap monitor stats ap-name mac verbose

- if frame loss and retries are within reason, move to roaming the client between APs, noting the signal strength that the client hears from each AP, and the reverse -

show ap debug client-table CLIENTMAC

shows the SNR at which client frames are received. Critical is the half-way point where AP_2 signal/rates should be superior to AP_1 - again, this is a client decision, but one can get a general idea of the signal strength at this point.

- Check roaming re-auth

- here, we're looking for delay in the roaming process show auth buff Another consideration is when a client roams from AP_1 to AP_2, these APs may be connected to different layer 2 switches, which in some cases might require setting:

fdb-update-on-assoc within the virtual-ap profile to ensure the client MAC is learned on the new AP and associated switch ports.

Further, air captures near the client, or using the AP packet capture may help, if one can boil the symptoms down further, Aruba Networks TAC may be of assistance.