Wireless Access

Im trying to make this work as a client is interested in looking a demo of this... as they got problems with roaming right now with their solution...

 

But i just cannot make the clients change from one AP to another one... it just not roam...

 

Anyone got ideas? or made this work?

 

Cheers

Carlos

Is the client getting listed with the output of this command?

 

show ap arm client-match unsupported

 

If yes, the likely the "Last steer Reason" should be noted, if it says 'Sticky',

Even though the controller is trying to temporarily blacklist the non-best-match BSSID for that specific client,

the client NIC still does not want to associate to a new (read 'Better') BSS.

 

Additional debugging can be enabled for more granular details for this client by using the following command,

 

logging level debugging arm-user-debug all

 

to view the logs, use - 

 

show log arm-user-debug all

 

 

Thx.,

-barath

Hi, # show ap arm client-match summary ... Total clients:52 Sticky Moves (T/S):85/52 Bandsteer Moves (T/S):191/142 Load Balance Moves (T/S):0/0 I've seen many band steering events but with all my efforts no single lb move :-( Is this feature really already implemented? Regards.

In order for the LB move trigger to get initiated, A given AP's radio must have a minimum of 10 clients associated to it. You could change this config in the arm profile to a lower value, if you're testing LB with ClientMatch.

Additionally, the client must be able to view another neighbor radio with a minimum SNR of 30 and it should have relatively lesser load in order for the client to get moved.

Unless all of the above factors match, the client will not qualify for an LB move.

What i want to make work is not the client match load balancing

I want to make work the Client match Sticky client

 

As far i know there are 3 types

1-Load Balancing

2-Sticking Client

3-Band Steering

 

If it need to acomplish the LB rules to make work the sticking client please tell me

 

Cheers

Carlos

The client is not in the unsuported clients!

@NightShade1 - the LB related answer was to address 'fn's query on - '...but with all my efforts no single lb move'.

 

--

 

Here's how sticky client works,

The client's SNR (as monitored by the AP) is supposed to be a minimum of atleast </= 25dB SNR (default value) in order for this

particular steer type to get implemented. Additionally, the client has to be able to hear a neighbor AP at a minimum of -70dBm SNR and also the neighbor AP SNR must be a minimum of 10dB greater than the client's existing SNR.

 

ONLY if all these three parameters match, the client will get steered due to sticky client.

However, the good news is that all of these values are configurable in the ARM profile.

 

You may have to calibrate the ARM settings of the test environment (using these values as a baseline) depending on what criteria you want the controller to steer the client due to sticky behavior. Theoretically, there would be no situation where the sticky move is not completed, as long as the values are matched as per the design, neighbor/client SNR and follows the logic mentioned above.

 

(.:SpIkE:.) #show ap arm client-match  summary

Client Match Summary
---------------------
MAC  Sticky (T/S)  Bandsteer (T/S)  Loadbal (T/S)  Moves (T/S)  Last Move (Time/Rsn/Dur))  Device Type


With this command, (where, T = Total & S = Successful) you would be able to check whether the login is getting triggered for the specific client mac, although it has not been successful. You'll have to use the debugging command i mentioned above to get more granular details on which exact factor it has failed.

 

(.:SpIkE:.) #configure terminal
(.:SpIkE:.) (config) #rf arm-profile clientmatch

(.:SpIkE:.) (Adaptive Radio Management (ARM) profile "clientmatch") #

 

 

cm-sticky-min-signal   -  Client Match Sticky Min Signal Level required for
                                            target AP ( -dBm)

cm-sticky-snr                 -  SNR of client that triggers sticky move(dB)

cm-sticky-snr-delta       -  Min SNR improvement between current AP and desired
                                             target AP (dB) for sticky move

 

Here are the default values of these config parameters:

Client Match Sticky Min Signal                             70

Client Match Sticky client check SNR (dB)        25

Client Match SNR threshold(dB)                        10

What values you would recommend in each  client match setting for a really aggressive roaming just for a lab testing?

i have been playing with it and i cannot make it work properly

 

I got 2 AP 105  one controller 620, i have been playing with the values also with the output power of the APS with no luck.... it randomly does it but its randomly  really really rarely...

 

Or what can i do to make it roam with client match something that i can see... or the client can see like hey its works!

For now i cannot see anything... :(

 

Cheers

Carlos

Nightshade1,

 

The signal from the client would have to be 10db different as seen by the access point, so adjusting the output power of the access point does not matter.  You could try to lower the client output power in the driver, but it is very difficult to make a client seem 10db weaker in the same room.

Okay

Is there is something i can tweak with the client match setting to amke it work aggresively?

Like for example if one AP see the AP at -55 dbm and the other AP see it at -40dbm switch to the other AP with better signal?

or there is no simple way to do it?

Not sure how far it is between the two lab AP's but, i'd recommend the following,

 

1) Put atleast a distance of 20ft between the two AP's.

2) Set min & max tx eirp to 9 in the arm profile.

3) Set the 'Client Match SNR threshold' to 2dB (you can gradually increase this value if roaming becomes too aggressive).

4) Set the 'Client Match Sticky Min Signal' to 90

 

NOTE:

This will create a config for very agressive roaming, it completely depends on how clean the channels are in the testing conditions to actually have an effect on the roaming itself since SNR on one channel may widely differ from another even on the same band.

Hello Thanks for the reply

I noticed that with these settings the bandsteer works!

 

But  if my AP 105 i configure just one radio for example the 5ghz radio only and i turn off the 2.4ghz radio to make it roam with sticky client not with the steer band it doesnt work... with this settings

 

Any clue?

 

Cheers

Carlos

So How does this work with Aruba Instant and Client match ?? Cant seem to find those parameters ?

 

Serge

@barath wrote:

 

Here's how sticky client works,

The client's SNR (as monitored by the AP) is supposed to be a minimum of atleast </= 25dB SNR (default value) in order for this

particular steer type to get implemented. Additionally, the client has to be able to hear a neighbor AP at a minimum of -70dBm SNR and also the neighbor AP SNR must be a minimum of 10dB greater than the client's existing SNR.

 

ONLY if all these three parameters match, the client will get steered due to sticky client.

However, the good news is that all of these values are configurable in the ARM profile.

 

 

 

cm-sticky-min-signal   -  Client Match Sticky Min Signal Level required for
                                            target AP ( -dBm)

cm-sticky-snr                 -  SNR of client that triggers sticky move(dB)

cm-sticky-snr-delta       -  Min SNR improvement between current AP and desired
                                             target AP (dB) for sticky move

 

Here are the default values of these config parameters:

Client Match Sticky Min Signal                             70

Client Match Sticky client check SNR (dB)        25

Client Match SNR threshold(dB)                        10

---

 

Those parameters are not supposed to be changed.  The person in the thread wanted to do testing to force clients to roam when the access points are very close together, as a test.