Wireless Access

About a year or so ago around when client match was coming out we were told to use local probe request threshold settings of about 25 while enabling client match at the time. With client match being out awhile now I'm curious if we should continue using lprt as I've been reading stuff like the following below. Any thoughts?

- Do not enable "Local Probe Request Threshold" with Clientmatch. - ClientMatch should fully replace the functionality of local probe request threshold in the SSID profile.  Enabling lprt unfortunately, will have access points ignoring clients that it should be servicing, unfortunately when ClientMatch is enabled.  Leave it at zero (the default).

I want to say, do not use it, because it adds a variable when troubleshooting.  With LPRT, if you do not have an SSID hidden, the device can also discover and access point through beacons, even if we ignore their probe requests that are too weak.  Enabling LPRT works best for roaming when the SSID is hidden, but it could provide unpredictable results if combined with CM.  I would say do not make LPRT more than 15 and you should be good.

** updating to correct this a bit **

adding to what Colin has said - indeed local probe request threshold (LPRT) of 10-15 is now the best practice - partly due to client match (CM), partly due to a change in the way LPRT is implemented in 6.3 which adds some extra margin that is used to block 802.11 auth frames (which can be too agressive on the fringe of coverage). In early 6.3 the margin was a little agressive, this was eventually fixed. In 6.4 this was split into a separate configuration called "auth request threshold" - but for the purpose of this post, let's leave that well alone, it's one of those "don't change unless advised to" items.

More often than not, people complaining of inability to associate - especially after upgrade to 6.3 or 6.4 for the first time - can be tied back to LPRT=25 or higher hanging around from previous attempts to solve roaming issues.

The other thing that changed was CM got better and handling various edge cases and quirk devices. It was common in some cases in 6.3 to have CM disabled and whatever value of LPRT configured.

Regretfully we have no easy way to handle this on upgrades, so let's put it in a list:

1. AOS is < 6.x  - LPRT whatever value was deemed workable
2. AOS is 6.3.x (early) - best to either turn LPRT off or reduce it to 10-15 due to overzealous padding that got added. This was fixed (reduced) later - but it's still more agressive than older code

3.  AOS 6.3.x (later) - if CM is on, 10-15... if CM is off, you could *maybe* go as high as 20, but 25 would still be considered a bit too high (since the padding is still there).

4. AOS 6.4.x - same a 6.3.x (except more often than not, CM is still on)

>>>>> !! the short answer: 10 to 15 in all recent Aruba OS !! <<<<

10 or 15 ? make a judgement on density and whether you want the worst case client SNR to be 10 or 15. If AP density is good, make it 15; if sparse and maximal coverage is desired make it 10 etc.  Can't make a call, don't know, unsure - then err on the side of caution and use 10.

regards

-jeff