802.1x on Cisco 3750 switch: How to stop retrying the authentication for the un-authorized guests

[Difan Zhao]

Hi experts,

I'm trying to stop the authentication retry for the guests. They won't have the credential to be authorzied and will be put in the guest VLAN. However the switch seems by default always retries the authentication every 15 seconds or so. It's fine if the guests are few but I'm implementing it at a hotel where most users are guests (like 1000 of them at the same time...).

I really need to turn it off or at least find some timer to decrease the frenquency... It's urgent because the hotel is about to open... The following is the config I put on an interface:

switchport access vlan 1055
switchport mode access
switchport nonegotiate
switchport voice vlan 657
ip access-group ACL_PortIso_IDF21 in
authentication event fail action authorize vlan 1055
authentication event no-response action authorize vlan 1055
authentication host-mode multi-domain
authentication port-control auto
authentication violation protect
mab
no snmp trap link-status
dot1x pae authenticator
dot1x timeout quiet-period 300
dot1x timeout tx-period 2
dot1x timeout supp-timeout 2
dot1x max-reauth-req 10
dot1x timeout held-period 300
no cdp enable
spanning-tree portfast
spanning-tree bpduguard enable
no ip igmp snooping tcn flood

Thanks!

[Elly Bornstein · Accepted solution]

I assume this is happening.

dot1x in your configuration fails over after tx-period X (max-reauth-req +1) which for you is 22 seconds.

Auth-MGR (the software that controls (dot1x / MAB / webauth) is probably set to restart every 60 seconds.

You can verify this with:

'show run all | b X/Y'   --- replace x/y with the correct port you are testing with.

Look for the command 'authentication timer restart 60'

Try setting this to 0. If IOS does not let you change it, please post your software version.

[Difan Zhao]

Hi Elly thank you very much for the quick response!

The firmware version is 12.2(53)SE2. I'm also doing MAB if the client is not 802.1x aware.

Anyway I tried the command and set it to 0 as well as 65535 and nothing was changed at beginning! Then I saved the config and "shut/no shut" the port and then the authentication retry (I don't say re-authentication because that's for the authorized client) stopped! Does it make sense that you have to bounce the port for the authentication settings to take effect?

I will try the same setting for a legitimate client and see if it will affect the authorized devices!

Thanks a lot! 5 points for sure!

Difan

[Elly Bornstein]

It would make sense more perhaps if you tried 'clear authentication session interface gx/y/z'.

Most likely just need to clear the current authentication session for this timer to take effect. Let me know if that doesn't work.

[Difan Zhao]

Elly, seems that I'm happy too early... After a long period of time the authentication retry starts to happen again!! Please take a look at the text file I uploaded. It records the output on my SSH session. (I didn't enable any debugging. They are just default level 7 loggings I guess)

I was also suspecting the phone (which is currenly connceted on that port). I thought it might reboot itself after long time idle. However in the logs I don't see the interface went up/down. Anyway I will try a Windows XP laptop and see if it still happens. The following is my config. Thanks!

interface FastEthernet3/0/13
description VoIP & HSIA
switchport
switchport access vlan 1055
switchport trunk encapsulation negotiate
switchport mode access
switchport nonegotiate
no switchport protected
no switchport block multicast
no switchport block unicast
switchport voice vlan 657
no ip arp inspection trust
ip arp inspection limit rate 15 burst interval 1
ip arp inspection limit rate 15
ip access-group ACL_PortIso_IDF21 in
no shutdown
power inline consumption 15400
power inline auto max 15400
authentication control-direction both
authentication event fail retry 2 action authorize vlan 1055
authentication event no-response action authorize vlan 1055
authentication host-mode multi-domain
no authentication open
authentication linksec policy should-secure
authentication port-control auto
no authentication periodic
authentication timer restart 0

authentication timer reauthenticate 3600
authentication timer inactivity 0
authentication violation protect
no authentication fallback
mab radius
snmp trap mac-notification change added
snmp trap mac-notification change removed
no snmp trap link-status
no mka policy
dot1x pae authenticator
dot1x timeout quiet-period 60
dot1x timeout server-timeout 0
dot1x timeout tx-period 2
dot1x timeout supp-timeout 2
dot1x timeout ratelimit-period 0
dot1x max-req 2
dot1x max-reauth-req 2
dot1x timeout start-period 30
dot1x timeout held-period 60
dot1x timeout auth-period 30
dot1x max-start 3
no cdp enable
spanning-tree portfast disable
spanning-tree portfast trunk
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree port-priority 3
spanning-tree cost 3
no ip igmp snooping tcn flood

[Elly Bornstein]

You might want to try setting up wireshark on the end client with MAC 0019.f302.a378, see if they are sending EAP frames even after guest vlan assignment.

Or turn on dot1x debugs and seeing if we RX any dot1x frames from this client.

[Difan Zhao]

Elly,

Soon I will have a Windows laptop plugged in. Then I will be able to run the wireshark. Now I have to run the "debug dot1x packets" since the attached device is a phone.

So first I "clear dot1x session int f3/0/13". After a couple of "failure" eventually it will show this:

"%AUTHMGR-5-SUCCESS: Authorization succeeded for client (Unknown MAC) on Interface Fa3/0/13"

(Weird... why it's showing "success"? Anyway when the authentication restarts again after several minutes there won't be any "sucess" any more, as shown in my previous text file. They are)

Then I have the debug turnned on:

.Jan 25 12:47:21: %AUTHMGR-5-START: Starting 'dot1x' for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41
INDJWSW01-2104#
.Jan 25 12:47:21: EAPOL pak dump Tx
.Jan 25 12:47:21: EAPOL Version: 0x3  type: 0x0  length: 0x0005
.Jan 25 12:47:21: EAP code: 0x1  id: 0x1  length: 0x0005 type: 0x1
.Jan 25 12:47:21: dot1x-packet(Fa3/0/13): EAPOL packet sent to client 0x5600009F (0019.f302.a378)
INDJWSW01-2104#
.Jan 25 12:47:23: EAPOL pak dump Tx
.Jan 25 12:47:23: EAPOL Version: 0x3  type: 0x0  length: 0x0005
.Jan 25 12:47:23: EAP code: 0x1  id: 0x1  length: 0x0005 type: 0x1
.Jan 25 12:47:23: dot1x-packet(Fa3/0/13): EAPOL packet sent to client 0x5600009F (0019.f302.a378)
INDJWSW01-2104#
.Jan 25 12:47:25: EAPOL pak dump Tx
.Jan 25 12:47:25: EAPOL Version: 0x3  type: 0x0  length: 0x0005
.Jan 25 12:47:25: EAP code: 0x1  id: 0x1  length: 0x0005 type: 0x1
.Jan 25 12:47:25: dot1x-packet(Fa3/0/13): EAPOL packet sent to client 0x5600009F (0019.f302.a378)
INDJWSW01-2104#
.Jan 25 12:47:27: %DOT1X-5-FAIL: Authentication failed for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41
.Jan 25 12:47:27: %AUTHMGR-7-RESULT: Authentication result 'no-response' from 'dot1x' for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41
.Jan 25 12:47:27: %AUTHMGR-7-FAILOVER: Failing over from 'dot1x' for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41
INDJWSW01-2104#
.Jan 25 12:47:27: %AUTHMGR-5-START: Starting 'mab' for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41
.Jan 25 12:47:28: %MAB-5-FAIL: Authentication failed for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41
.Jan 25 12:47:28: %AUTHMGR-7-RESULT: Authentication result 'fail' from 'mab' for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41
.Jan 25 12:47:28: %AUTHMGR-7-FAILOVER: Failing over from 'mab' for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41
.Jan 25 12:47:28: %AUTHMGR-7-NOMOREMETHODS: Exhausted all authentication methods for client (0019.f302.a378) on Interface Fa3/0/13 AuditSessionID 0A8F7325000010629B960A41

Then the message will repeat and repeat forever... It seems that the switch Tx the packets first... Any ideas???

Thanks!

[Elly Bornstein]

You might want to start with a service request so someone can do a bug scrub for you. Or see if a newer version gives you the same behavior.

From preliminary searching I saw:

CSCti28252

Which would explain some differences in behavior when you shut/ no shut.