Security

We are seeing where many clients reauthenticate many times per hour. Sometimes it is only three or four minutes and we see the client reauthenticationg again and again, in our radius logs. All this happens repeatedly with the client attached to the same AP and not even physically moving at all. We wre trying to understand what is triggering this reauthentication process over and over again for some clients. Needless to say the increased load on our radius server is a concern. Viewing the "show station-table" shows the clients have been logged on for only minutes. And for some clients they do not have this problem and they show being connected for many hours in the "show station-table" output.

Thanks,

 Fred

You should probably start by identifying what type of devices are doing that ?

You should pick one device and turn user-debug on for that particular MAC address

Also run the show auth-tracebuf

Have you made any recent changes under 802.1x profile ?

Thanks for the Reply.

Seems to affect all clients, and this may have been going on for over a year and was just now discovered.

We will see if the user-debug for a paticular device shows us anything.

The 802.1x profile has remained the same for years.

Controller has had code upgrades on a regular basis.

Thanks,

 Fred

 

What AOS do you have installed ?

We are running 6.3.1.1 on 7204 controllers.

But we do know this behavior existed on previous versions.

I would choose a single client and enable debugging for that user to see what is going on. That is the best way to Attempt to narrow it down.

We have exactly the same case. 

#7210

We have exactly the same case. 

We are running also 6.3.1.1 but on 7210 controllers.

We got yesteday 164723 requests on clearpass with max of 1838 clients on airwave graphics.

#7210

---

@dsti wrote:

We have exactly the same case. 

We are running also 6.3.1.1 but on 7210 controllers.

We got yesteday 164723 requests on clearpass with max of 1838 clients on airwave graphics.

---

I would then turn on debugging for one client with the issue and collect the logs.  http://community.arubanetworks.com/t5/Technology-Blog/Two-Different-Ways-to-Debug-a-User-on-Aruba-and-Why-You-Would/ba-p/77006

 

That would indicate who is initiating the authentication.

#7210

Interesting facts with your debug procedure. I have two differents wireless device. One Laptop with windows 7 and one Ipod.

MAC address of Windows 7 is: 00:24:2C:08:DC:C1

MAC address of IPOD is: F0:CB:A1:B1:A7:2C

 

You can see output after this explain

 

I noticed IPOD make "station-down and station-up" and he make reauthentication each time. However, it is not not see this on a laptop with windows 7.

I haven't more time to made more troubleshooting on other device. But, Is it possible that we have a behavior problem on Apple side?

 

OUTPUT:

 

 

(CM010108-4) (config) #show debug

DEBUG LEVELS
------------
Facility    Level      Debug Value        Sub Category  Process
--------    -----      -----------        ------------  -------
user-debug  debugging  f0:cb:a1:b1:a7:2c  N/A           N/A
user-debug  debugging  00:24:2C:08:DC:C1  N/A           N/A


(CM010108-4) (config) #show auth-tracebuf

Warning: user-debug is enabled on one or more specific MAC addresses;
         only those MAC addresses appear in the trace buffer.

Auth Trace Buffer
-----------------


Nov 20 14:02:37  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 12     43
Nov 20 14:02:37  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  71     282
Nov 20 14:02:37  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  71     113
Nov 20 14:02:37  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     43
Nov 20 14:02:37  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     43
Nov 20 14:02:37  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65511  282
Nov 20 14:02:37  rad-accept            <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65511  252
Nov 20 14:02:37  eap-success           <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     4
Nov 20 14:02:37  wpa2-key1             <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      117
Nov 20 14:02:37  wpa2-key2             ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      117
Nov 20 14:02:37  wpa2-key3             <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      151
Nov 20 14:02:37  wpa2-key4             ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      95
Nov 20 14:06:24  station-down           *  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      -
Nov 20 14:06:40  station-up             *  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      -     wpa2 aes
Nov 20 14:06:40  eap-id-req            <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 1      5
Nov 20 14:06:40  eap-id-resp           ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 1      20    stephane.goulet
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 65472  229
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65472  76
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 2      6
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 2      152
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  122    391
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  122    1112
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 3      1034
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 3      6
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  31     245
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  31     1108
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 4      1030
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 4      6
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65507  245
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65507  1108
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 5      1030
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 5      6
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  119    245
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  119    1108
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 6      1030
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 6      6
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65426  245
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65426  1108
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 7      1030
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 7      6
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65449  245
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65449  211
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 8      141
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 8      144
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  43     383
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  43     139
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 9      69
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 9      6
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65512  245
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65512  113
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 10     43
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 10     59
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65451  298
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65451  145
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 11     75
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 11     107
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  12     346
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  12     161
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 12     91
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 12     43
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  92     282
Nov 20 14:06:40  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  92     113
Nov 20 14:06:40  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     43
Nov 20 14:06:40  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     43
Nov 20 14:06:40  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65414  282
Nov 20 14:06:40  rad-accept            <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65414  252
Nov 20 14:06:40  eap-success           <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     4
Nov 20 14:06:40  wpa2-key1             <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      117
Nov 20 14:06:40  wpa2-key2             ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      117
Nov 20 14:06:40  wpa2-key3             <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      151
Nov 20 14:06:40  wpa2-key4             ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      95
Nov 20 14:09:50  station-down           *  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      -
Nov 20 14:11:10  station-up             *  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      -     wpa2 aes
Nov 20 14:11:10  eap-id-req            <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 1      5
Nov 20 14:11:10  eap-id-resp           ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 1      20    stephane.goulet
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 65422  229
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65422  76
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 2      6
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 2      152
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  100    391
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  100    1112
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 3      1034
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 3      6
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65467  245
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65467  1108
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 4      1030
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 4      6
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  49     245
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  49     1108
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 5      1030
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 5      6
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65511  245
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65511  1108
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 6      1030
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 6      6
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  103    245
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  103    1108
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 7      1030
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 7      6
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65526  245
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65526  211
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 8      141
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 8      144
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65498  383
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65498  139
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 9      69
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 9      6
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  117    245
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  117    113
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 10     43
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 10     59
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  87     298
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  87     145
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 11     75
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 11     107
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  93     346
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  93     161
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 12     91
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 12     43
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65460  282
Nov 20 14:11:10  rad-resp              <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  65460  113
Nov 20 14:11:10  eap-req               <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     43
Nov 20 14:11:10  eap-resp              ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     43
Nov 20 14:11:10  rad-req               ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  98     282
Nov 20 14:11:10  rad-accept            <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40/SV01-CLEARPASS  98     252
Nov 20 14:11:10  eap-success           <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 13     4
Nov 20 14:11:10  wpa2-key1             <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      117
Nov 20 14:11:10  wpa2-key2             ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      117
Nov 20 14:11:10  wpa2-key3             <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      151
Nov 20 14:11:10  wpa2-key4             ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      95
Nov 20 14:12:22  station-down           *  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      -
Nov 20 14:14:45  station-up             *  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 -      -     wpa2 aes
Nov 20 14:14:45  eap-id-req            <-  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 1      5
Nov 20 14:14:45  eap-id-resp           ->  f0:cb:a1:b1:a7:2c  24:de:c6:a6:39:40                 1      20    stephane.goulet

 

Do you have "Validate PMKID" enabled in your 802.1x profile?  That is for i-devices and mac, where most do not support OKC.

I did it... I attached GUI configuration file

 

Regards

Okay.  Time to measure and see if you are still having problems.  If you have a master/local configuration, this will not take affect on the local controller until you click on "Save Confguration".

 

If this does not make a difference, we have more things to try.  To save the suspense, most of them are in the "Removing the Bottleneck" article here:  http://community.arubanetworks.com/t5/Technology-Blog/Removing-the-Bottleneck-in-Wireless/ba-p/77978

I had already enabled validate PMKID in my 802.1x profile before I beginning to write on this forum :). So I'll read article on "Removing the bottleneck" to try to solve my problem of "excessive reauthentication from many connected clients".

 

Note: I have a Master/local configuration

 

Thanks

dsti,

 

The article is bedtime reading and only general information about what to check.  There are quite a few other users that have MAC issues and it is probably best to open a support case (if you have not already) in parallel, so that they can zero in more closely on your issue.  If you then report back here, others can learn about what specific issue you have related to excessive reauthentication.  If you could narrow it down to a specific client type, we can get others to see if they are/are not having the same issue on that version of code...

hi dsti,

 

What is the value of station ageout configured on the SSID profile of these affected users? also, what is the current value of "User idle timeout" from "show aaa timer" ?

 

regards

-jeff

Not to jump in when you asked dsti; but here are what we have set below:

 #show aaa timer

Global User idle timeout = 600 seconds
Auth Server dead time = 10 minutes
Logon user lifetime = 5 minutes
User Interim stats frequency = 600 seconds

 

Sure sounds like we should take a look at this 600 second interval.

Is this the typical setting or even close to what others have?

Thanks... Fred

hi Fred,

 

can you post the STA ageout value on the SSID profiles too? Probably you have it at default, but it needs to be checked. Post aurbaOS 6.2 this value is the primary ageout mechanism for a client - once it has expired, any delta between it and the user time out (be it global or on per aaa profile basis in 6.3) will apply additionally. If it has been adjusted to a lower value, it could be involved here.

 

Can you confirm from the "show aaa auth-tracebuf" what is the reason the clients are being deleted ? you could also use "show ap client-trail <mac>" as an alternative debugging command in 6.3. Note that too in 6.3 you can use "per user auth tracebuf for all users" by enabling "conf t aaa log" and then "show user-table ip <ip> log" to see the per user auth tracebuf (unlike previous code where we had to enable the logging level debugging user-debug <mac> for all users of interest.

 

regards

-jeff.

Is this the variable youa re asking about:

     sta-ageout-interval 5

 

We have a case open for this issue and so far we have not been able to find a reason for the disconnects.

I would be glad to send you the case number and Aruba engineer but not sure if I should post that info for everyone.

And the output of "show auth-tracebuf " has been looked at.

However the information you provided about the new behavior for 6.3 code is very good to know, as we missed that somehow.

Thanks ... Fred

hi Fred

If that value is from your network, a value of 5 is very agressive - I of course don't know the history of that value, but, I might suggest that you increase that value to match the current setting of the AAA timer (global or the AAA profile if it's set) to see if that stabilises things.

 

The changes to the age out mechanism started in 6.2, but ther per aaa profile ability to set a user idle timeout just arrived in 6.3 - hence I cannot be sure as to the value that is actually being used, but globally you have a value of 600 seconds.

 

How might this value be causing problems ? in the case of say wpa2-aes auth, if the client is not presenting a PMK ID or there is a mismatch (and validate PMK id is enabled on dot1x profile) then client will be re-performing the full dot1x each time it authenticates as it cannot make use of any cached pmkid or OKC etc.

 

This value will also create a drain on battery life of clients - I have seen this in my lab with an ipad2 when I set the sta ageout to something like 60 seconds. Typically ipads (as an example) send out a few packets every few minutes, but with such a low STA ageout, the client was getting disconnected frequently and having to re-auth, which killed the battery.  I would recommend that the STA age out to be set to something a lot closer to the AAA user idle timeout.

 

I must again mention I don't know the history of how or why you have a value of 5 - but I do suspect this is involved in your observations.

 

regards

-jeff

Jeff,

 This is very helpful and we for sure talk to support about changing this value.

I'm relatively new to this job and do not know the history of some of these settings as well.

I will let you and everyone know how it goes.

Thanks .... Fred

Also do you have reauthentication checked in the profile?  If so it will force clients to resend authentication information periodically from what I understand.  You can also still have that checked but increase the interval for how often it does the reauthentication.  Just a thought

We do not have reauthentication checked in the profile.

But We did not know to look at this value so thanks for pointing that out.

We have since discovered issues with connectivity to our LDAP server causing autheintication problems.

We are trying to get that corrected at this point since we do not know if that may have been part of the cause of our problems.

Thankks, Fred

 

Hi I was hoping you could share the solution if you happened to solve this issue? I seem to be running into the same problem with my wireless clients. Thanks in advance.