I've just upgraded a Controller from 220.127.116.11 to 18.104.22.168. 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 22.214.171.124 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 tlogg 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-nameshow ap arm history ap-nameshow ap arm rf-summary ap-nameshow wms ap listshow wms client
- Client specific data:
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,Transshow 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 | includeshow 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.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.