Solved!
Go to SolutionN3048P - Decrease MAB failover timeout after Dot1x
I've setup a N3048P (Access) switch to do Dot1x and Mac Authentication Bypass (MAB) using ClearPass as a RADIUS server. This works all fine as I see authentication requests getting allowed / denied in ClearPass. On the interface config, i've setup to first try dot1x, and if that fails, try MAB for authentication. The only problem i'm facing is that the timeout between a Dot1x failure and MAB authentication is taking too long (1.45 minutes).
I've tried to configure the failover timeout using: dot1x timeout tx-period, dot1x max-req and dot1x max-reauth-req. This resulted in the same outcome: the client authenticates using MAB only after 1.45 minutes, every time.
Im using the following global config:
aaa accounting dot1x default start-stop radius
aaa accounting update newinfo
authentication enable
dot1x system-auth-control
aaa authentication dot1x default radius
aaa authorization network default radius
dot1x dynamic-vlan enable
aaa server radius dynamic-author
client server-key 7 " "
auth-type any
exit
radius server attribute 4
radius server attribute 6 on-for-login-auth
radius server source-ip
radius server key 7 " "
radius server auth
primary
name "CLEARPASS-RADIUS-VIP1"
exit
radius server auth
name "CLEARPASS-RADIUS-VIP2"
exit
radius server acct
name "CLEARPASS-RADIUS-VIP1"
exit
And the following interface configuration:
N3048P(config)#show running-config interface gigabitethernet 1/0/24
spanning-tree portfast
switchport access vlan
dot1x port-control mac-based
dot1x reauthentication
dot1x timeout tx-period 5
dot1x max-req 3
dot1x max-reauth-req 3
mab
authentication order dot1x mab
authentication priority dot1x mab
My question: What configuration is required to decrease the timeout of MAB authentication, after trying dot1x first?
DELL-Erman O
Moderator
•
2984 Posts
•
14874 Points
1361
0
Posted October 22nd, 2021 06:00
Hello,
What is the firmware version of the switch? default timeout should be 30 secondsdot1x timeout tx-period seconds
Set the number of seconds that the switch waits for a
response to an Extensible Authentication Protocol (EAP)-
request/identity frame from the client before resending the
request.
dot1x max-reauth-req count
no dot1x max-reauth-req
• count — Number of times that the switch sends an EAP-Request/Identity
frame before restarting the authentication process. (Range: 1–20)
Default Configuration
The default value for the count parameter is 2as far as i know dot1x timeout tx-period and dot1x max-reauth-req should be affecting timeout
like (max-reauth-req +1) * tx-periodCan you check if there is a difference by changing these values?
Also you can check pg 1085 dot1x timeout https://dell.to/30H6jBw
Let us know how it goes!
DELL-Erman O
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell
Did I answer your query? Please click on ‘Mark as Accepted Answer’. ‘Thumbs up’ the posts you like!DiegoLopez
6 Operator
•
2668 Posts
1354
0
Posted October 22nd, 2021 07:00
Hi Erman,
Thanks for your reply. Earlier i've tried playing with these settings and lowering the failover timeout using:
dot1x timeout tx-period 3
dot1x max-reauth-req 1
Yet, not luck unfortunately. The switch is running on firmware version 6.5.4.17 (active). Any ideas on where the long timeout (still 1.45 minutes) is based on?
Hi all,
I've checked the logs myself using the following commands:
debug dot1x packet
debug authentication all
debug aaa authorization commands
debug aaa authorization exec<189> Oct 26 08:35:19 N3048P PP04-1 TRAPMGR[trapTask]: traputil.c(721) 27999 %% NOTE Gi1/0/24 is transitioned from the Learning state to the Forwarding state in instance 0
<189> Oct 26 08:35:19 N3048P PP04-1 TRAPMGR[trapTask]: traputil.c(721) 27998 %% NOTE Gi1/0/24 is transitioned from the Forwarding state to the Blocking state in instance 0
<189> Oct 26 08:35:19 N3048P PP04-1 TRAPMGR[trapTask]: traputil.c(721) 27997 %% NOTE Gi1/0/24 status is authorized
<189> Oct 26 08:35:19 N3048P PP04-1 DOT1X[dot1xTask]: dot1x_radius.c(1594) 27996 %% NOTE Client authenticated successfully using default port PVID on the port Gi1/0/24.
<188> Oct 26 08:35:19 N3048P PP04-1 DOT1X[dot1xTimerTask]: dot1x_control.c(1457) 27994 %% WARN MAB timer (90) seconds expired for client on port Gi1/0/24
<189> Oct 26 08:33:50 N3048P PP04-1 TRAPMGR[trapTask]: traputil.c(721) 27976 %% NOTE Gi1/0/24 status is Unauthorized
<189> Oct 26 08:33:49 N3048P PP04-1 TRAPMGR[trapTask]: traputil.c(721) 27974 %% NOTE Link Up: Gi1/0/24The 90 seconds timeout explains the waiting time.. but what is triggering this 'dot1xTimerTask'?
DiegoLopez
6 Operator
•
2668 Posts
1299
0
Posted October 26th, 2021 08:00
Hello again @lk2819,
The dot1xTimerTask is a 802.1x authentication task.
So it is a system trask triggered by the system itself.
Regards.
DELL-Erman O
Moderator
•
2984 Posts
•
14874 Points
1287
0
Posted October 27th, 2021 01:00
Hi, Can you send me a private message of service tag and where is the location of the unit, please?
DELL-Erman O
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell
Did I answer your query? Please click on ‘Mark as Accepted Answer’. ‘Thumbs up’ the posts you like!
lk2819
32 Posts
923
0
Posted May 2nd, 2022 00:00
For anyone facing the same issue; after a long search, we reviewed the interface configuration with command: 'show running-config interface gigabitethernet 1/0/1 all' and noticed a the following config: 'dot1x timeout guest-vlan-period 90'.
After reviewing the CLI manual this was causing the 90 second delay mentioned in my post. Dell's description: "Use the dot1x timeout guest-vlan-period command in Interface
Configuration mode to set the number of seconds that the switch waits
before authorizing the client if the client is an 802.1X unaware client. Use the
no form of the command to return the timeout to the default value."
After decreasing this to 10 seconds, we noticed 802.1x unaware clients authenticated using MAB after failing 802.1x within 10 seconds. Because this was a default config parameter, it was not shown in the running config unless issuing the '.. all' command. Shame no one at Dell could tell me this!..