Security

Hi gurus,

I have two questions about ClientMatch technology, please your comments:

1. Can ClientMatch prevent a roaming event triggered by the client when is not optimal? I mean, I know or think ClientMatch can trigger a roaming event when the client isn't on the best AP. Taking about sticky client, ClientMatch can steer the client to a better AP, say AP "z", via deauth for example (if the client doesn't support 802.11v), and then the rest of APs will ignore and don't respond to the client's probe requests, only the AP "z", and then the client will be associated to AP "z" eventually. What happens when the client triggers this roaming event? Let's say client is on AP "a" and sees better signal strength on AP "b", but AP "b" is fully loaded with a lot of clients, so according to ClientMatch is better to keep connected to AP "a". When client broadcast probe requests, will AP "b" ignore these probe requests to make client stay on AP "a"? Or will it respond to these probe requests and then client will roam to AP "b"? Or how does ClientMatch handle this situation?
2. The controller builds VBRs with the probe requests reports received from the APs, and then sends the VBRs back to the APs every 30 seconds. But 30 seconds is too much time for mobile devices. I mean, if a user is walking, it can easily moves more than 60 meters in 30 seconds, therefore it can pass through 2 APs, then, the last VBR the controller and APs have is not updated and can lead to poor ClientMatch roaming decisions. Doesn't make sense to reduce this interval to much less than 30 seconds?

Regards,

Julián

Hi guys,

Any idea?

Regards,

Julián

1.  Client Match does not interrupt any client-initiated roams.

2.  Client Match does not interrupt any client-initiated roams.  If a device has not been associated to the same access point for 2 minutes, Client Match would not  consider initating any action.

Hi,

Then, if both ClientMatch and clients can initiate roaming events, we can't say that in Aruba roaming is managed by the controller/APs, but ClientMatch tries to influence the clients' roaming process, doesn't it? Like you said here:

https://community.arubanetworks.com/t5/Wireless-Access/Client-Match-testing/td-p/415630

On the other hand, I know ClientMatch is Aruba's patented technology. Do you know if other vendors have something similar to influence the roaming process or they let the clients all the process?

Regards,

Julián

I honestly don't understand your point.

Sometimes clients attempt to roam on their own.  Other times Client Match will force a roam with 802.11v or deauths.

Client Match is not a roaming technology. First you must remember that the client decides when/if it is going to roam. There is no 802.11 standard for this. Each PC/radio vendor has their own thresholds for roaming. So if the client decides it's time to roam, it will.

Client Match will not move a client from one AP to another unless that client has been connected to the AP for at least 4 minutes. So Client Match is a technology that will move a client from one radio to another if the client has settled in on a radio for at least 4 minutes and Client Match determines that there is a better radio.

Client match has 3 different algorithms; sticky client, band steering, and load balancing. Sticky client is processed first, and it is processed by the AP. Band steering is processed next, and it is also processed by the AP. Load balancing is processed by the controller.

If you would like to see the algorithms, I wrote an Aruba OS 6 book 2 years ago and you can download 15 free PDF images from that book that I think should be available to anyone. This download includes the 4 algorithms (the 4th algorithm is the one that processes the directed steer/move). If you want the files, go to www.westcott-consulting.com and select download. You will be signing up for my mailing list (which I rarely use), which you can remove yourself from if you want. You will receive an email (check your junk folder) which will provide a link to download the files.

I hope this helps,