Controllerless Networks

last person joined: an hour ago 

Aruba Instant Wi-Fi: Meet the controllerless Wi-Fi solution that's easy to set-up, is loaded with security and smarts, and won't break your budget.
Expand all | Collapse all

Client match behavior

SethFiermontiJan 02, 2014 05:52 PM

  • 1.  Client match behavior

    Posted Jan 02, 2014 05:45 PM

    I have 6 iAP225 AP's in an instant group. I have client match turned on but it only seems to be working on 2 of the AP's. When i run the command AP client match history  2 of the AP's show what I would expect and the others are all blank. Im having a problem with clients that are sitting in an office randomly jumping to an AP way accross the building and then dropping. Im wondering if this is related.

     

    If I reboot an ap it starts showing client match info but randomly stops.

     

    -Alex



  • 2.  RE: Client match behavior

    Posted Jan 02, 2014 05:52 PM

    Could you please open a case for this issue?  



  • 3.  RE: Client match behavior

    Posted Jan 02, 2014 06:29 PM

    Seth,

     

    Case has been opened, OK if I report what Tac finds here for other users?

     

    Alex



  • 4.  RE: Client match behavior

    Posted Jan 02, 2014 06:30 PM
    Sure!!

    Sent from my iPhone


  • 5.  RE: Client match behavior

    Posted Jan 02, 2014 10:14 PM

    Hi Seth,

     

    Can you provide topology and show tech-support ( at least one client match 'enabled' and one 'not enabled'.

     

    Thanks



  • 6.  RE: Client match behavior

    Posted Jan 07, 2014 03:34 PM

    This weekend I took a backup of the instant config and wiped clean. I then restored from backup and applied 4.002 that was just released.  Client match appears to be working now. I dont know if 4.002 fixed it or if it was the reimaging of all the AP's I will keep an eye on it and update if it stops working again.

     

    Alex



  • 7.  RE: Client match behavior

    Posted Jan 14, 2014 02:43 AM

    *Update*

    Client match slowly stopped working AP by AP and in about a week was showing an error on every AP but one. The symptom is clients unable to roam without disconnecting and reconnecting to the network as well as instant reporting clients still connected long after then moved to a new AP in another building. Im waiting on a response from Tac and will update with their suggestions. Is anyone else using client match and instant? Any issues?

     

    Alex



  • 8.  RE: Client match behavior

    Posted Jan 21, 2014 04:56 PM

    did the performance improve if you disabled client-match?



  • 9.  RE: Client match behavior

    Posted Jan 21, 2014 05:02 PM

    Yes, once client match was disabled clients were able to roam again. With client match turned on and failing client would roam to the AP with client match working and never leave. For the 2-5days before client match started showing an error clients seemed to roam OK.

     

    Alex



  • 10.  RE: Client match behavior

    Posted Jan 21, 2014 05:29 PM

    ok, that good to know.  I'm having some strange issues with AP225 as well.  First thing I'll do is disable client-match and see how it goes.



  • 11.  RE: Client match behavior

    Posted Jan 21, 2014 06:52 PM

    With the Ap225 I currently have to have both client match and 80mhz channels disabled to get reliable functionality. With 80mhz channels turned on non ac clients connect and disconnect every min or so. Im waiting on a response from TAC after giving them a bunch of logs of the behavior.

     

    Alex



  • 12.  RE: Client match behavior

    Posted Jan 21, 2014 09:24 PM

    Please post more debugging information to help us find the problem.

    Such as your topology (includes which APs enabled client match, and which didn't), 'show tech-support', 'show ap client-match-live', 'show ap vi', 'show ap client-match-hist client-mac XX'



  • 13.  RE: Client match behavior

    Posted Jan 22, 2014 01:18 AM

    Topology:

    Brand new deployment running only Iap225's Just upgraded to 4.003 yesterday I have not had a chance to retest after upgrading but nothing in the release notes indicate any of the problems i'm experincing are fixed in this releases

    Instant cluster on its own Vlan 10.0.x.xx

    SSID Test using WPA2 enterprise pointing at server 2012 for Radius/NPS

     

     

    Logs have been sent to Tac case #1495209

    I can post them here as well if you think that would be helpfull but will need to spend some to sterlilizing them first.

     

    Im still in testing and am happy to try out any ideas you might have.

    Alex

     



  • 14.  RE: Client match behavior

    Posted Jan 22, 2014 11:37 AM
      |   view attached

    I went ahead and sterilized them, they are attached.

     

    Alex

    Attachment(s)

    txt
    aplogs - Copy.txt   387K 1 version


  • 15.  RE: Client match behavior

    Posted Jan 27, 2014 06:09 AM

    We have similiar issues within an environment deployed fully with IAP225. The problems were strange and random and moved from AP to AP and from OS to OS. Random disconnects, highly increased latencies, traffic stops and so on. The first think Aruba support suggested is turn off client match and after that there was minor improvement however the whole infrastructure still facing with serious stability issues. Currently IAP replaced with controller/campus AP's and everything seems stable. Ticket opened and we are waiting for feedback. It seems we are all facing with some strange software issue. Please post any update here as well



  • 16.  RE: Client match behavior

    Posted Jan 27, 2014 05:48 PM

    Thanks for the info Ipal, I updated to 4.003 and TAC wants me to retest to see if there is improvement but Im not very optimistic. I have had 80mhz and client match turned off for a few weeks now and things are OK but today I had an AP stop allowing client to connect to it and had too reboot I also have lots of random DHCP request errors. The logs are full of these runtime errors on all the AP's. Im not sure if they are normal or not.

    Jan 27 14:33:18  cli[2756]: <341102>  |AP 18:64:72:c5:3f:7e@10.0.7.57 cli|  Incorrect format for message type 0:0:1:0:127.0.0.1:15200.
    Jan 27 14:36:52  stm[2773]: <304055>  |AP 18:64:72:c5:3f:7e@10.0.7.57 stm| |ap| Unexpected stm (Station management) runtime error at stm_sysctl_write_param, 10201, Error opening /proc/sys/net/aruba101/ni_inact_reload : No such file or directory
    Jan 27 14:37:47  stm[2773]: <304055>  |AP 18:64:72:c5:3f:7e@10.0.7.57 stm| |ap| Unexpected stm (Station management) runtime error at stm_sysctl_write_param, 10201, Error opening /proc/sys/net/aruba101/ni_inact_reload : No such file or directory
    Jan 27 14:37:47  stm[2773]: <304001>  |AP 18:64:72:c5:3f:7e@10.0.7.57 stm|  Unexpected stm (Station management) runtime error at stm_start_acct_for_post_1xauth_user, 14409, Error sending radius start packet
    Jan 27 14:37:47  stm[2773]: <304055>  |AP 18:64:72:c5:3f:7e@10.0.7.57 stm| |ap| Unexpected stm (Station management) runtime error at stm_sysctl_write_param, 10201, Error opening /proc/sys/net/aruba101/ni_inact_reload : No such file or directory
    Jan 27 14:37:47  stm[2773]: <304001>  |AP 18:64:72:c5:3f:7e@10.0.7.57 stm|  Unexpected stm (Station management) runtime error at stm_start_acct_for_post_1xauth_user, 14409, Error sending radius start packet

     



  • 17.  RE: Client match behavior

    Posted Jan 27, 2014 08:16 PM

    Alex Howard,

     

    Do you have a reauth interval configured on that SSID?

     



  • 18.  RE: Client match behavior

    Posted Jan 27, 2014 09:05 PM

    Ther reauth interval under the security Tab is set to 0

     

    Alex



  • 19.  RE: Client match behavior

    Posted Jan 27, 2014 09:06 PM

    Well,

     

    Only TAC would know if those logs are normal, informational or harmful.



  • 20.  RE: Client match behavior

    Posted Dec 24, 2014 08:24 AM

    Hello ,

     

    Same deployment ( 8 - IAP224 Cluster) on a warehouse , which is a denser than normal but facing same issues ( high latency / dropped clients and no-late handover) . Is there any workaround for this issue ? 



  • 21.  RE: Client match behavior

    Posted Dec 24, 2014 09:12 AM
    Muhtereminair,

    How long has this been happening?
    Who designed the WLAN?


  • 22.  RE: Client match behavior

    Posted Dec 24, 2014 09:24 AM

    This has been happening for like two months , after startup.

     

    This is a warehouse designed by us. There is a 8 IAP-224 Cluster. Hand terminals are working inside the warehouse. After some time , customer had complained about the latency issue. Handterminals are struggling to send data to server , there is a noticable latency issue from the workers. First we were suspicious about handterminals , made some wifi improvments (Channel sens , roam threshold , scan interval and etc. ) but the problems persist. The problem doesnt occur every moment but sometimes of a day , someplace (randomly) on warehouse. As I said this issue not exact but workers face it sometimes. So I cant prove when we do "x" , "y" happens , but customer faced it several times. And he tells , it occurs especially when roaming.

     

    I have opened a case regarding it is a latency issue , and tac had changed some changes. But the problem still arrives. 



  • 23.  RE: Client match behavior

    Posted Dec 24, 2014 09:27 AM

    How high are the access points mounted?

    Are they mounted between stacks or in the open?

    What antennas are you using?

    How far apart are they mounted?

    What handhelds are being used?

    Are the handhelds using 2.4ghz?

    What technology was being used before and how high and how far apart were the access points mounted?  What was the power?

     



  • 24.  RE: Client match behavior

    Posted Dec 24, 2014 09:35 AM

    @cjoseph wrote:

    How high are the access points mounted?

     

    Like 9-10 meters high 

     

    Are they mounted between stacks or in the open?

     

    Warehouse have some stacks also half of the warehouse is open.

     

    What antennas are you using?

     

    Ant-1w is used.First the wrong polarization being use , as they were vertical to the ground make too much interference , then it changed to horizontal to the ground.

     

    How far apart are they mounted?

     

    There are at least 20 meters between them.

     

    What handhelds are being used?

     

    Called Dcom

     

    Are the handhelds using 2.4ghz?

     

    Yes haldhelds are using 2.4 Ghz

     

    What technology was being used before and how high and how far apart were the access points mounted?  What was the power?

     

    There are 2 engenius APs on the warehouse. One of them is sitting on a table in from of the warehouse other one is lying behind stacks but not that high as now.

     


     



  • 25.  RE: Client match behavior

    Posted Dec 24, 2014 09:58 AM
    Have you done a post installation survey to see how much coverage you are getting with the ant-1ws at 9 to 10 meters?
    Have you done a spectrum analysis to see if there is any interference in the warehouse?
    What type of goods are there in the warehouse? Paper, Metal or Frozen?

    What is the ARM Min and Max power for your access points?
    How many ssids are being broadcast?


  • 26.  RE: Client match behavior

    Posted Dec 24, 2014 05:35 PM

    Yes I have done post installation survey and doesnt see any coverage problem / black hole and etc. Have seen -75dbm worst.

     

    There are mainly office supplies in the warehouse , so many kinds of goods there are (liquid , paper , metal cans etc.)

     

    ARM min 9dbi , max 24dbi , just one SSID is broadcasting.



  • 27.  RE: Client match behavior

    Posted Dec 24, 2014 06:28 PM
    Muhteremonair,

    It is entirely possible that you have too much coverage. RF propagates pretty well in open spaces, so you might have to space your access points at every 33 meters in open space to avoid this. You could also first lower the max power to 18.

    On your survey you might want to see how many access points you can see on the same channel in an area that has slowness. You could also do a packet capture on a single channel and see if you see traffic from access points that should be far away. That will determine if you have to consider reducing coverage to avoid slowness.

    You can also make sure Broadcast Filtering is on "all" to make sure that excess broadcasts on the network are not hurting your performance.

    The only thing I did not see you mention is spectrum analysis; interference could be playing a part here.

    Everything I mentioned could contribute to the slowness you are seeing...


  • 28.  RE: Client match behavior

    Posted Dec 27, 2014 02:32 AM

    Thank you for your help 

     

    Warehouses are hard places to position APs. At 10 Meters high all APs show the other. 

    But in this case i think problem is different , my main problem is not slowness because the amount of data sent is very low , only barcode information queried from server that is all. I opened a topic (which I couldnt find now) in airheads forum and also a TAC case.Slowness just result of the issue. Not a constant slowness , ping goes constant at 3-4ms then a suddenly waves to 100+ msecs.Also handhelds are not clever enough to overcome at that situation then boom connection lost. 

     

    At last , i put a test controller to the system and convert all them to CAP and it is now significantly better. Will try to reposition some APs to get better results.



  • 29.  RE: Client match behavior

    Posted Dec 27, 2014 05:46 AM

    Sir,

     

    If in any given spot, all 8 other access points can be seen, you have to lower the ARM Maximum Transmit power, or choose one or more more access points in open space to turn into an Air Monitor(s).  You might have to do both.

     

    Access points can easily be seen at 100 meters in open space.  The problem is that if they can see each other they will pause or slow down the traffic because they can see each other talking.  

     

    If you can hold down the keys on the scanner gun and there are pauses, that is another way to determine if you could afford to possibly reduce coverage.

     

    If you can put the scanner in "site survey mode" you might be able to see how many access points your scanners can see at any one time to determine what your coverage is.  Some  scanners have limited association tables, and might try to associate with access points that are no longer in range if they can see too many, and that could create an issue while they are roaming.  Some scanners are expecting very, very thin coverage with access points on very high power on 2.4ghz.  

     

    If you have other devices that are 5ghz, you can still deploy an  SSID on 5ghz only on all access points and it should work just fine.

     

    These are all just individual ideas, and they do not all have to be done; your customer just has to be happy.