Wired Intelligent Edge (Campus Switching and Routing)

Reply
Highlighted
Regular Contributor II

DUR fails after reboot

Hi there,

 

I'm currently testing a 2930F with ClearPass and Downloadable user roles.

Everything works fine, until I reboot the switch.

After the switch boots, I can see the log saying it could not download the role, and all devices get a DenyAll  role.

If I then disable and re-enable the ports, they all get their role properly.

Any idea what can be the problem?

 

Thanks


Accepted Solutions
Highlighted
Aruba Employee

Re: DUR fails after reboot

 

There are multiple ways you can deal with this problem:


Personally I would recommend point 2 and 3 from the following list:

 

1. Lower (S)NTP snyc time from the default 720s=20min to 120s=2min that time get synchronized quickly after a reboot. Otherwise you may have to wait 20min before DUR will work if the first SNTP request failed.

 

2. Set an approximate time which is used by the switch after a a power loss or reboot using job-scheduler command, e.g.:

 

job "set_time" at reboot "time 12/24/2018 00:00:00"

 

This is a least more accurate before the time is successfully updated via S(NTP) than the default date (01/01/90 00:00:00) which is used after a power loss .

 

3. Create a new user-role to be used as the initial role with a reauth-period defined. Otherwise failed authentications when the radius server is not reachable in time after a reboot cause clients to get stuck in the default initial role (denyall).

 

class ipv4 "denyall-ipv4"
  10 match ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
exit

 

class ipv6 "denyall-ipv6"
  10 match ipv6 ::/0 ::/0
exit

 

policy user "denyall"
  10 class ipv4 "denyall-ipv4" action deny
  20 class ipv6 "denyall-ipv6" action deny
exit

 

aaa authorization user-role name "denyall-reauth"
  policy "denyall"
  reauth-period 60
exit

 

aaa authorization user-role initial-role "denyall-reauth"

 

 

View solution in original post


All Replies
Highlighted
Moderator

Re: DUR fails after reboot

It’s likely that time sync hasn’t occurred yet.


If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
Regular Contributor II

Re: DUR fails after reboot

And how can I overcome the problem?

How can I delay the port authentications to that I can ensure everything is Ok by the time the first request is sent to ClearPass?

Highlighted
Moderator

Re: DUR fails after reboot

Unfortunately you can’t today. I would recommend reaching out to your Aruba team to inquire about potential changes in the future.


If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
Aruba Employee

Re: DUR fails after reboot

 

There are multiple ways you can deal with this problem:


Personally I would recommend point 2 and 3 from the following list:

 

1. Lower (S)NTP snyc time from the default 720s=20min to 120s=2min that time get synchronized quickly after a reboot. Otherwise you may have to wait 20min before DUR will work if the first SNTP request failed.

 

2. Set an approximate time which is used by the switch after a a power loss or reboot using job-scheduler command, e.g.:

 

job "set_time" at reboot "time 12/24/2018 00:00:00"

 

This is a least more accurate before the time is successfully updated via S(NTP) than the default date (01/01/90 00:00:00) which is used after a power loss .

 

3. Create a new user-role to be used as the initial role with a reauth-period defined. Otherwise failed authentications when the radius server is not reachable in time after a reboot cause clients to get stuck in the default initial role (denyall).

 

class ipv4 "denyall-ipv4"
  10 match ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
exit

 

class ipv6 "denyall-ipv6"
  10 match ipv6 ::/0 ::/0
exit

 

policy user "denyall"
  10 class ipv4 "denyall-ipv4" action deny
  20 class ipv6 "denyall-ipv6" action deny
exit

 

aaa authorization user-role name "denyall-reauth"
  policy "denyall"
  reauth-period 60
exit

 

aaa authorization user-role initial-role "denyall-reauth"

 

 

View solution in original post

Highlighted
Occasional Contributor I

Re: DUR fails after reboot

This only work for MAC-AUTH service, how would you do re-auth to dot1x service for client in deny_all role?

Highlighted
Contributor II

Re: DUR fails after reboot

Hi,

 

You can apply the configuration below on the switch port:

 

aaa port-access authenticator <port number> reauth-period 86400

 

Or you can configure clearpass to return the radius attribute "session-timeout" with the desired timeout value.

 

Highlighted
Occasional Contributor I

Re: DUR fails after reboot

Thanx for the reply. The default role deny_all normally happens when the site has a power failure and the CP server is not available when the switch has booted. 

The only way this will work is reauth-period on the switch config. CP is not assigning this role to having the attribute returned in CP will not work, if my thinking is correct? Also the time you set for reauth, you would need very low in order for the reauth to trigger after the site is fully up after power failure, normally 20-40min after the power is restored.

Will the radius-server tracking assist to do the reauth as soon as it discovers that the CP server is reachable?

Highlighted
Occasional Contributor I

Re: DUR fails after reboot

The devices getting stuck in denyall initial role is fixed in firmware v16.10.  

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: