Higher Education

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted
Contributor II
Posts: 150
Registered: ‎01-04-2012
802.1X Age time
[ Edited ]

Hello

 

I have wireless users complaning that the 802.1x network is not stable. When i check the 802.1X connections on the controllers

 

show user-table authentication-method dot1x  

 

 00:08:22:24:ef:fb  jd2117           ENET      00:02:28    802.1x

 

I see the age time for all the users is less than 5 minutes. Where do you check the configured user-table interval time o age time? 

 

1, Authentications are successful 

2. Radius rejets are not increasing

3. However users get timeout or have to reconnect after serveral minutes. 

4. A macbook user is showing connecting time of 22 min and no ping drops and from the controller even though the age time is showing 3 min in the user-table I can still ping the user from the controller

 

Any recommendations? 

 

Nils. 

Aruba
Posts: 1,296
Registered: ‎08-29-2007
Re: 802.1X Age time

For reference, that counter is days, hours, mins.

 

Age(d:h:m)


If my post is helpful please give kudos, or mark as solved if it answers your post.

ACCP, ACMP, ACMX #294
mclarke@arubanetworks.com
Contributor II
Posts: 150
Registered: ‎01-04-2012
Re: 802.1X Age time

Michael,

 

Great Now it is making sense. Users are indeed connected for hours, so from the controller perspective is not deleting the users. 

Contributor II
Posts: 150
Registered: ‎01-04-2012
Re: 802.1X Age time
[ Edited ]

I was able to replicate the issue with a computer. From the client the connection time reset around 35 min however the computer reconnected and the timer started from 0. 

 

In the logs i see the following:

 

Mar 26 11:18:20 :527000: <DBUG> |mdns| mdns_parse_packet 2189 mdns query packet received - info; mac=b8:e8:56:10:9c:c2, ip=137.52.248.192, origin=1
Mar 26 11:18:20 :527000: <DBUG> |mdns| mdns_parse_query_packet 1833 There was no response to query from mac:b8:e8:56:10:9c:c2, ip: 137.52.248.192
Mar 26 11:18:29 :527000: <DBUG> |mdns| mdns_parse_packet_from_sos 418 pkt from SOS: vlan 1248, mac b8:e8:56:10:9c:c2 ip 137.52.248.192
Mar 26 11:18:29 :527000: <DBUG> |mdns| mdns_parse_packet 2189 mdns query packet received - info; mac=b8:e8:56:10:9c:c2, ip=137.52.248.192, origin=1
Mar 26 11:18:29 :527000: <DBUG> |mdns| mdns_parse_query_packet 1833 There was no response to query from mac:b8:e8:56:10:9c:c2, ip: 137.52.248.192
Mar 26 11:18:35 :522036: <INFO> |authmgr| MAC=b8:e8:56:10:9c:c2 Station DN: BSSID=9c:1c:12:82:3a:91 ESSID=ENET VLAN=1248 AP-name=NTestRoof
Mar 26 11:18:35 :522234: <DBUG> |authmgr| Setting idle timer for user b8:e8:56:10:9c:c2 to 300 seconds (idle timeout: 300 ageout: 0).
Mar 26 11:18:35 :501080: <NOTI> |stm| Deauth to sta: b8:e8:56:10:9c:c2: Ageout AP 137.52.186.241-9c:1c:12:82:3a:91-NTestRoof Unspecified Failure
Mar 26 11:18:35 :501000: <DBUG> |stm| Station b8:e8:56:10:9c:c2: Clearing state
Mar 26 11:18:35 :501105: <NOTI> |AP NTestRoof@137.52.186.241 stm| Deauth from sta: b8:e8:56:10:9c:c2: AP 137.52.186.241-9c:1c:12:82:3a:91-NTestRoof Reason Unspecified Failure
Mar 26 11:18:35 :501000: <DBUG> |AP NTestRoof@137.52.186.241 stm| Station b8:e8:56:10:9c:c2: Clearing state
Mar 26 11:23:35 :522235: <DBUG> |authmgr| user_age_handler() called for user b8:e8:56:10:9c:c2.
Mar 26 11:23:35 :522236: <DBUG> |authmgr| user_age_byip() called for MAC b8:e8:56:10:9c:c2 IP 137.52.248.192 ageout 1 flags 0x0.
Mar 26 11:23:35 :522005: <INFO> |authmgr| MAC=b8:e8:56:10:9c:c2 IP=137.52.248.192 User entry deleted: reason=idle timeout
Mar 26 11:23:35 :522050: <INFO> |authmgr| MAC=b8:e8:56:10:9c:c2,IP=N/A User data downloaded to datapath, new Role=ENET/139, bw Contract=0/0, reason=Station resetting role, idle-timeout=300
Mar 26 11:23:35 :527004: <INFO> |mdns| mdns_parse_auth_useridle_message 197 Auth User Idle Timeout: MAC:b8:e8:56:10:9c:c2, WIRED:0, FW:0, VLAN:1248, IP:137.52.248.192, BSSID:9c:1c:12:82:3a:91, AGE:1954,
Mar 26 11:23:35 :527000: <DBUG> |mdns| mdns_client_purge 648 Purge mdns client, mac=b8:e8:56:10:9c:c2
Mar 26 11:23:35 :522244: <DBUG> |authmgr| MAC=b8:e8:56:10:9c:c2 Station Deleted Update MMS
Mar 26 11:23:35 :522265: <DBUG> |authmgr| "MAC:b8:e8:56:10:9c:c2: Deallocating UUID: 126.

 

What would the AP send a deatuh? 

 

Thank you

Nils

MVP
Posts: 502
Registered: ‎04-03-2007
Re: 802.1X Age time
In this above example, client b8:e8:56:10:9c:c2 did not send any traffic for 300 seconds (your idle-timeout), at which point the controller has the AP send a 802.11 Deauthentication frame to the station.

If your argument is that b8:e8:56:10:9c:c2 shouldn’t have been kicked off and was a live client, you need to do “show datapath session table ” and observe no traffic coming from the client. If the client IS sending traffic but the controller isn’t seeing it, you need to check where the traffic is being dropped.

Again, the controller only deauths per idle-timeout if the client was not sending traffic through the controller in the time configured for your idle-timeout (300 seconds).

- Ryan -
==========
Ryan Holland, ACDX #1 ACMX #1
The Ohio State University
New Member
Posts: 14
Registered: ‎02-26-2013
Re: 802.1X Age time

Is there a recommended timeout that we should be using?  Or any guidelines?  Are there issues with having a much higher timeout, such as 2 hours?  Obviously there will be the increased client load in the active database, but if that is not an issue or concern, would there be anything else?

 

Thank you.

Occasional Contributor II
Posts: 45
Registered: ‎12-06-2010
Re: 802.1X Age time

My understanding is your timeout should not be longer than your DHCP lease.

MVP
Posts: 502
Registered: ‎04-03-2007
Re: 802.1X Age time
I use the standard 300 seconds in our deployment.
==========
Ryan Holland, ACDX #1 ACMX #1
The Ohio State University
Search Airheads
Showing results for 
Search instead for 
Did you mean: