Higher Education

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. 

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

 

Age(d:h:m)

Michael,

 

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

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

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 -

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.

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

I use the standard 300 seconds in our deployment.