Wireless Access

Hello i got a question regarding this...

I already  knows what it does but i was reading on the arubanetworks site and on the AP 135 description it says

 

"Wi-Fi Client Optimization
To eliminate sticky client behavior, every Aruba AP comes with ClientMatch™ technology, which continuously gathers session performance metrics and utilizes this data to steer mobile devices to the best AP and radio on the WLAN, even while users roam."

 

This brough my attention i though or think its something on the controller not like int he AP hardware or something...

Im confused... can someone enlight me here? where do i actually get the client match feature? it is something that will come in the upcoming releases of aruba OS or its something hardcoded on the AP?

 

Cheers

Carlos

#AP135

Clientmatch is a feature of AOS 6.3 which will be out soon.

this will work with all the APS not with just AC aps? right?

 

Cheers

Carlos

802.11n and 802.11ac only. Legacy APs do not get Clientmatch.

Last question Marcus

 

So AP 93 AP 105 and AP 135 will work client match

 

If the client is not capable of 802.11n even if the ap support it, it will not work for that specific client?

 

Thanks

Carlos

ClientMatch will work on legacy clients but legacy 802.11a/b/g-only APs will not support ClientMatch since they don't have the CPU and memory required to support the feature.

So my clients having aps 105 and 135 will get benefit of it as long as i get the new firmware right?

 

Cheers

Carlos

Correct.

Thank you very much for enlight me one more time Marcus :)

 

Cheers

Carlos

Hi Marcus,

 

Do you know if thye client match feature will be on the Instants aswell or is it going to just be on the controller based units?

 

Thanks,

Mike

ClientMatch is on the roadmap for IAP.  I don't, however, have an ETA.

Ok Thanks for getting back to me so quickly. I've a client who is falling for the usual ruckus bs about how there kit will wipe the floor with aruba when roaming ect so going to send him a load of documentation and test reports ect but didn't want to send him one on client match if they didn't support it

Also remind them that L3 roaming has been supported since September 2012 (v.3.1)

Is there a configuration guide available, or is it just the checkbox in the ARM profile?

 

You can find it here 6.3 User guide should help you:

 

http://support.arubanetworks.com/DOCUMENTATION/tabid/77/DMXModule/512/EntryId/11362/Default.aspx

 

I have attached it

 

 

Thanks.  That helps a bit.  I've been playing around a bit with it this afternoon and I still can't get some of my sticky clients to move.  Client match doesn't show any attempts to move either.  I get the client's snr down below 20 and it's dropping almost 100% of the frames and still no attempts to move.  The client is within 6 ft. of a different ap.  I think it may have something to do with the fact that when I do a "show ap arm client-match neighbors" on the sticky ap it returns nothing.  

 

A "show ap arm client-match history" shows that client match is moving an occasional client, just not the ones I'm testing or on the APs I'm trying it on, even though it should be within the threshold for a move.

 

Any ideas?

Check to see if this client was deemed "unsteerable".  If the system tries to steer a client and it fails to move 5 consecutive times (default) then it is flagged as unsupported / unsteerable.

 

Try this command to see if it shows your sticky client:

 

show ap arm client-match unsupported

ajohnsonwdc,

 

 

The client would have to be "seen" by the target access point stronger by a factor before being steered over to that access point.  If that access point is NOT on the same channel as the client, it would have had to have scanned the same channel the client is on at some point and have seen traffic from the client  in a certain timeframe to be eligible.  ClientMatch is very new, so there is no specific documentation on how to troubleshoot your specific situation.  If this is a mission critical environment, you can turn it off and leave regular ARM on and simultaneously open a support case so that they can attempt to understand and replicate your situation.

 

It will certainly be painful to troubleshoot this behavior on this forum.

We're a school on summer break, so now is a great time to try and work through this issue.  I'll open a support case and see if they can help.  We have 200 of these laptops in carts and they have always refused to roam properly.  That's why I'm so eager to try and get ClientMatch working.  It's disruptive when half the laptops in a classroom won't let the kid logon because they're stuck on an AP that's just out of range.

 

On a side note, never buy laptops with a realtek chipset for use in an enterprise wireless environement and mobile users.

A couple of things:
- just in case but make sure 802.11k is enabled in controller settings
- make sure that the wireless card on your device supports 802.11k and .11v (this is how the AP/controller are able to get necessary information to steer the client to the best AP )
- do show ap debug client-table <APNAME> to get more info about the client
- also do a show ap virtual beacon report <client Mac> and run the debugging arm-user-debug <client Mac>
- also understand that because the AP is closer it means it has a better connection for that client</APNAME>

We will use 802.11k and .11v as part of the steering process if the client supports it.  Otherwise, ClientMatch will use Aruba's own methods.

Marcus can you please elaborate more on those methods

Thanks for the replies.

 

Nothing's showing as unsupported for steering.

 

.11k is enabled in the VAP, and supported in the client.  I can't find anything on .11v (realtek rtl8192se in a Lenovo T410)

Turned on debugging arm-user-debug for the mac and saw this:

 

Client Match: Skip steer for client f0:7b:cb:a4:35:72 from 6c:f3:7f:a5:a9:02 to d8:c7:c8:4d:f6:a0, Stale entry for dst or src: Src 1372125410 dst 1372124284 now 1372125434

 

 

 

---

@ajohnsonwdc wrote:

Turned on debugging arm-user-debug for the mac and saw this:

 

Client Match: Skip steer for client f0:7b:cb:a4:35:72 from 6c:f3:7f:a5:a9:02 to d8:c7:c8:4d:f6:a0, Stale entry for dst or src: Src 1372125410 dst 1372124284 now 1372125434

---

 

can you run the show ap virtual beacon-report <client mac> not completely sure about the actual command but if do a show ap virtual ? and that should give the actual one 

 

These are the 2 APs : 6c:f3:7f:a5:a9:02 to d8:c7:c8:4d:f6:a0 , right ?

 

Are you familiar with these entries : 1372125410 dst 1372124284 now 1372125434 ?

 

Virtual beacon report:

 

STA Beacon Report
-----------------
AP IP address Radio ESSID Signal (dBm) Last update Add time Channel/Clients Flags
-- ---------- ----- ----- ------------ ----------- -------- --------------- -----
HS-1-Choir 10.14.1.18 d8:c7:c8:4d:f1:60 WDC-Member -76 Jun 25 03:22:19 Jun 25 03:22:19 6/0 S
HS-Comm-NW 10.14.0.41 d8:c7:c8:4d:eb:40 WDC-Member -73 Jun 25 03:23:58 Jun 24 21:04:02 1/0 S
HS-1-Office-W 10.14.0.27 6c:f3:7f:a5:a9:00 WDC-Member -45 Jun 25 08:33:25 Jun 24 18:02:58 11/3 *
HS-Comm-NE 10.14.0.42 d8:c7:c8:4d:ec:20 WDC-Member -77 Jun 25 03:26:15 Jun 24 21:04:02 11/2 S
HS-1-Forum-S 10.14.0.13 d8:c7:c8:4e:16:60 WDC-Member -71 Jun 24 21:04:50 Jun 24 21:04:02 1/0 S
HS-Comm-NC 10.14.0.38 d8:c7:c8:4d:ec:c0 WDC-Member -80 Jun 25 03:26:14 Jun 24 21:04:02 11/0 S
HS-MC-NW 10.14.0.189 d8:c7:c8:4d:f1:c0 WDC-Member -67 Jun 24 21:04:50 Jun 24 18:01:03 1/0 S
HS-1-Hall-S-2 10.14.0.79 d8:c7:c8:4d:f5:00 WDC-Member -70 Jun 24 21:05:36 Jun 24 21:03:50 6/0 S
HS-1-Hall-S-6 10.14.0.75 d8:c7:c8:4d:f3:80 WDC-Member -61 Jun 24 21:05:21 Jun 24 17:19:06 6/0 S
HS-1-Hall-S-1 10.14.0.80 d8:c7:c8:4d:f1:20 WDC-Member -61 Jun 24 21:05:20 Jun 24 21:03:53 11/0 S
HS-Comm-SE 10.14.0.43 d8:c7:c8:4d:ea:c0 WDC-Member -78 Jun 25 03:25:54 Jun 24 20:37:25 1/0 S
HS-Comm-SW 10.14.0.40 d8:c7:c8:4d:ec:40 WDC-Member -66 Jun 24 21:04:54 Jun 24 21:04:02 1/0 S
HS-MC-NE 10.14.0.108 d8:c7:c8:4d:b5:20 WDC-Member -71 Jun 24 21:04:54 Jun 24 20:37:25 11/0 S
HS-Comm-SC 10.14.0.37 d8:c7:c8:4d:ec:00 WDC-Member -74 Jun 25 03:26:15 Jun 24 21:04:02 11/0 S
HS-1-Office-E 10.14.0.28 d8:c7:c8:4d:f6:a0 WDC-Member -71 Jun 25 03:26:14 Jun 24 21:03:54 1/1 S
HS-1-Hall-S-5 10.14.0.76 d8:c7:c8:4d:f4:60 WDC-Member -63 Jun 24 21:05:15 Jun 24 21:04:02 1/0 S
VBR Flags *-Associated S-Stale

show ap arm client-match neighbors isn't showing any neighboring APs again.  Now the arm-user-debug log shows this:

 

Jun 25 08:52:09 :507013: <DBUG> |AP HS-1-Office-W@10.14.0.27 sapd| Client Match: Detected client f0:7b:cb:a4:35:72 Assoc BSSID 6c:f3:7f:a5:a9:02 channel 11 with low RSSI 22 dB
Jun 25 08:52:09 :507004: <DBUG> |AP HS-1-Office-W@10.14.0.27 sapd| Client Match: Other radio 6c:f3:7f:a5:a9:00 not strong enough: Min Signal 60 Sticky thresh 5, cur signal 45 new signal 45 (-dBm)
Jun 25 08:52:09 :507007: <DBUG> |AP HS-1-Office-W@10.14.0.27 sapd| Client Match: For client f0:7b:cb:a4:35:72 Trigger Sticky No better candidate AP

 

 

STA Beacon Report gives you an idea of all the APs that the client is able to see so the AP/Controller based on the information provided (Signal/SNR/etc) it will determine the right AP to move the client to.

 

HS-1-Choir 10.14.1.18 d8:c7:c8:4d:f1:60 WDC-Member -76 Jun 25 03:22:19 Jun 25 03:22:19 6/0 S
HS-Comm-NW 10.14.0.41 d8:c7:c8:4d:eb:40 WDC-Member -73 Jun 25 03:23:58 Jun 24 21:04:02 1/0 S
HS-1-Office-W 10.14.0.27 6c:f3:7f:a5:a9:00 WDC-Member -45 Jun 25 08:33:25 Jun 24 18:02:58 11/3 *
HS-Comm-NE 10.14.0.42 d8:c7:c8:4d:ec:20 WDC-Member -77 Jun 25 03:26:15 Jun 24 21:04:02 11/2 S
HS-1-Forum-S 10.14.0.13 d8:c7:c8:4e:16:60 WDC-Member -71 Jun 24 21:04:50 Jun 24 21:04:02 1/0 S
HS-Comm-NC 10.14.0.38 d8:c7:c8:4d:ec:c0 WDC-Member -80 Jun 25 03:26:14 Jun 24 21:04:02 11/0 S

 

And looking at that log the controller didn't find a better AP compare to the one the client is currently attach to :

HS-1-Office-W 10.14.0.27 6c:f3:7f:a5:a9:00 WDC-Member -45 "has the better signal"

 

"For client f0:7b:cb:a4:35:72 Trigger Sticky No better candidate AP"

" Client Match: Skip steer for client f0:7b:cb:a4:35:72 from 6c:f3:7f:a5:a9:02"

 

Maybe it didn't find a better one because all of the other APs info is stale.  All of the other APs listed were last updated at least 5 hours earler.  The only time it updates the beacon report is when it's searching for the initial connection.  Looking at the log, the other radio it was trying to switch to was on the same AP, just the other radio.

 

Jun 25 08:52:09 :507013: <DBUG> |AP HS-1-Office-W@10.14.0.27 sapd| Client Match: Detected client f0:7b:cb:a4:35:72 Assoc BSSID 6c:f3:7f:a5:a9:02 channel 11 with low RSSI 22 dB
Jun 25 08:52:09 :507004: <DBUG> |AP HS-1-Office-W@10.14.0.27 sapd| Client Match: Other radio 6c:f3:7f:a5:a9:00 not strong enough: Min Signal 60 Sticky thresh 5, cur signal 45 new signal 45 (-dBm)

 

The controller monitor the clients and APs.  If it is determined that a client is no longer on the best AP, from a signal strength or load perspective, it will push the client to the best AP.  It does this by telling all APs in the area that they are not the best AP for the client except for the best AP.  When the client gets steered it will only have one AP that it can associate to as all others will ignore the association request.

This sounds extremely useful, is it available yet?

ClientMatch is available on the controllers with AOS 6.3 which is already available.

 

ClientMatch will be available on the InstantAP platform with the release of v.4.0 at the end of October.