Wired Intelligent Edge

we are still in the process of testing a deployment of wired network security. We have a couple of newer clearpass VM's set up, on a newer version than our production clearpass servers, where we are setting up policies for wired network security. We have about 4 clearpass VM's. currently, 3 of those servers are down, due to some of our temp licensing expiring. We left the publisher server running and turned off the subscriber servers. We figured this would be a good opportunity to see how failover works

Currently, our MAC auth clients continue to authenticate, via clearpass, to grab their roles, and go back to the switches to grab their local user roles. However, 802.1x clients suffer an authentication timeout on EAP-TLS. The machines complete the EAP portion but never complete the TLS transaction. 

We discovered, when we remove the radius server host definitions for those servers that are down, from both of the CX switches and AOS switches, that all of a sudden, those 802.1x machines no longer timeout and complete their EAP-TLS transactions. 

This seems like either poor design, or some of the default settings in the wired network policy guides are not the correct values we should be using. 802.1x clients should not timeout if there is still at least 1 clearpass server alive.

I'm a little clueless where I should be looking for settings that could resolve this behavior. The behavior is identical on AOS and CX switches.

some possibly relevant config, on the switches

CX switches:

aaa authentication port-access client-limit 12
aaa authentication port-access dot1x authenticator
    eapol-timeout 10
    max-eapol-requests 1
    max-retries 5
    enable

AOS

aaa port-access authenticator <port range>
aaa port-access authenticator <port range> supplicant-timeout 10
aaa port-access authenticator <port range> tx-period 10

The switches (both CX and AOS-S) have support for RADIUS tracking. This will help to mark a RADIUS server as not available and prevent it from being used. 

https://arubanetworking.hpe.com/techdocs/AOS-CX/10.15/HTML/security_5420-6200-6300-6400/Content/Rem_AAA_cmds/rad-ser-hos-10.htm

https://arubanetworking.hpe.com/techdocs/AOS-S/16.11/ASG/WC/content/common%20files/rad-ser-tra-con.htm?Highlight=tracking

we are still in the process of testing a deployment of wired network security. We have a couple of newer clearpass VM's set up, on a newer version than our production clearpass servers, where we are setting up policies for wired network security. We have about 4 clearpass VM's. currently, 3 of those servers are down, due to some of our temp licensing expiring. We left the publisher server running and turned off the subscriber servers. We figured this would be a good opportunity to see how failover works

Currently, our MAC auth clients continue to authenticate, via clearpass, to grab their roles, and go back to the switches to grab their local user roles. However, 802.1x clients suffer an authentication timeout on EAP-TLS. The machines complete the EAP portion but never complete the TLS transaction. 

We discovered, when we remove the radius server host definitions for those servers that are down, from both of the CX switches and AOS switches, that all of a sudden, those 802.1x machines no longer timeout and complete their EAP-TLS transactions. 

This seems like either poor design, or some of the default settings in the wired network policy guides are not the correct values we should be using. 802.1x clients should not timeout if there is still at least 1 clearpass server alive.

I'm a little clueless where I should be looking for settings that could resolve this behavior. The behavior is identical on AOS and CX switches.

some possibly relevant config, on the switches

CX switches:

aaa authentication port-access client-limit 12
aaa authentication port-access dot1x authenticator
    eapol-timeout 10
    max-eapol-requests 1
    max-retries 5
    enable

AOS

aaa port-access authenticator <port range>
aaa port-access authenticator <port range> supplicant-timeout 10
aaa port-access authenticator <port range> tx-period 10

with radius tracking, what user-name and password is to be used? I'm not familiar enough with clearpass to know what to use there. is it one of the admin accounts?

The switches (both CX and AOS-S) have support for RADIUS tracking. This will help to mark a RADIUS server as not available and prevent it from being used. 

https://arubanetworking.hpe.com/techdocs/AOS-CX/10.15/HTML/security_5420-6200-6300-6400/Content/Rem_AAA_cmds/rad-ser-hos-10.htm

https://arubanetworking.hpe.com/techdocs/AOS-S/16.11/ASG/WC/content/common%20files/rad-ser-tra-con.htm?Highlight=tracking

we are still in the process of testing a deployment of wired network security. We have a couple of newer clearpass VM's set up, on a newer version than our production clearpass servers, where we are setting up policies for wired network security. We have about 4 clearpass VM's. currently, 3 of those servers are down, due to some of our temp licensing expiring. We left the publisher server running and turned off the subscriber servers. We figured this would be a good opportunity to see how failover works

Currently, our MAC auth clients continue to authenticate, via clearpass, to grab their roles, and go back to the switches to grab their local user roles. However, 802.1x clients suffer an authentication timeout on EAP-TLS. The machines complete the EAP portion but never complete the TLS transaction. 

We discovered, when we remove the radius server host definitions for those servers that are down, from both of the CX switches and AOS switches, that all of a sudden, those 802.1x machines no longer timeout and complete their EAP-TLS transactions. 

This seems like either poor design, or some of the default settings in the wired network policy guides are not the correct values we should be using. 802.1x clients should not timeout if there is still at least 1 clearpass server alive.

I'm a little clueless where I should be looking for settings that could resolve this behavior. The behavior is identical on AOS and CX switches.

some possibly relevant config, on the switches

CX switches:

aaa authentication port-access client-limit 12
aaa authentication port-access dot1x authenticator
    eapol-timeout 10
    max-eapol-requests 1
    max-retries 5
    enable

AOS

aaa port-access authenticator <port range>
aaa port-access authenticator <port range> supplicant-timeout 10
aaa port-access authenticator <port range> tx-period 10

radius-tracking is not a ClearPass feature. With radius-tracking enable the switch will send dummy RADIUS requests to see if the RADIUS server is working. There are multiple options but the basic option is that the switch will start sending dummy RADIUS packets when the RADIUS server is not responding. 

A sample CX configuration for this 

radius-server host <hostname> tracking enable

with radius tracking, what user-name and password is to be used? I'm not familiar enough with clearpass to know what to use there. is it one of the admin accounts?

The switches (both CX and AOS-S) have support for RADIUS tracking. This will help to mark a RADIUS server as not available and prevent it from being used. 

https://arubanetworking.hpe.com/techdocs/AOS-CX/10.15/HTML/security_5420-6200-6300-6400/Content/Rem_AAA_cmds/rad-ser-hos-10.htm

https://arubanetworking.hpe.com/techdocs/AOS-S/16.11/ASG/WC/content/common%20files/rad-ser-tra-con.htm?Highlight=tracking

we are still in the process of testing a deployment of wired network security. We have a couple of newer clearpass VM's set up, on a newer version than our production clearpass servers, where we are setting up policies for wired network security. We have about 4 clearpass VM's. currently, 3 of those servers are down, due to some of our temp licensing expiring. We left the publisher server running and turned off the subscriber servers. We figured this would be a good opportunity to see how failover works

Currently, our MAC auth clients continue to authenticate, via clearpass, to grab their roles, and go back to the switches to grab their local user roles. However, 802.1x clients suffer an authentication timeout on EAP-TLS. The machines complete the EAP portion but never complete the TLS transaction. 

We discovered, when we remove the radius server host definitions for those servers that are down, from both of the CX switches and AOS switches, that all of a sudden, those 802.1x machines no longer timeout and complete their EAP-TLS transactions. 

This seems like either poor design, or some of the default settings in the wired network policy guides are not the correct values we should be using. 802.1x clients should not timeout if there is still at least 1 clearpass server alive.

I'm a little clueless where I should be looking for settings that could resolve this behavior. The behavior is identical on AOS and CX switches.

some possibly relevant config, on the switches

CX switches:

aaa authentication port-access client-limit 12
aaa authentication port-access dot1x authenticator
    eapol-timeout 10
    max-eapol-requests 1
    max-retries 5
    enable

AOS

aaa port-access authenticator <port range>
aaa port-access authenticator <port range> supplicant-timeout 10
aaa port-access authenticator <port range> tx-period 10

I'm checking how this works. 

Quick question though ... is there a way to avoid this? am i able to create some sort of dummy account in clearpass for the sole purpose of radius tracking?

radius-tracking is not a ClearPass feature. With radius-tracking enable the switch will send dummy RADIUS requests to see if the RADIUS server is working. There are multiple options but the basic option is that the switch will start sending dummy RADIUS packets when the RADIUS server is not responding. 

A sample CX configuration for this 

radius-server host <hostname> tracking enable

with radius tracking, what user-name and password is to be used? I'm not familiar enough with clearpass to know what to use there. is it one of the admin accounts?

The switches (both CX and AOS-S) have support for RADIUS tracking. This will help to mark a RADIUS server as not available and prevent it from being used. 

https://arubanetworking.hpe.com/techdocs/AOS-CX/10.15/HTML/security_5420-6200-6300-6400/Content/Rem_AAA_cmds/rad-ser-hos-10.htm

https://arubanetworking.hpe.com/techdocs/AOS-S/16.11/ASG/WC/content/common%20files/rad-ser-tra-con.htm?Highlight=tracking

we are still in the process of testing a deployment of wired network security. We have a couple of newer clearpass VM's set up, on a newer version than our production clearpass servers, where we are setting up policies for wired network security. We have about 4 clearpass VM's. currently, 3 of those servers are down, due to some of our temp licensing expiring. We left the publisher server running and turned off the subscriber servers. We figured this would be a good opportunity to see how failover works

Currently, our MAC auth clients continue to authenticate, via clearpass, to grab their roles, and go back to the switches to grab their local user roles. However, 802.1x clients suffer an authentication timeout on EAP-TLS. The machines complete the EAP portion but never complete the TLS transaction. 

We discovered, when we remove the radius server host definitions for those servers that are down, from both of the CX switches and AOS switches, that all of a sudden, those 802.1x machines no longer timeout and complete their EAP-TLS transactions. 

This seems like either poor design, or some of the default settings in the wired network policy guides are not the correct values we should be using. 802.1x clients should not timeout if there is still at least 1 clearpass server alive.

I'm a little clueless where I should be looking for settings that could resolve this behavior. The behavior is identical on AOS and CX switches.

some possibly relevant config, on the switches

CX switches:

aaa authentication port-access client-limit 12
aaa authentication port-access dot1x authenticator
    eapol-timeout 10
    max-eapol-requests 1
    max-retries 5
    enable

AOS

aaa port-access authenticator <port range>
aaa port-access authenticator <port range> supplicant-timeout 10
aaa port-access authenticator <port range> tx-period 10

By default de switches will sending radius tracking every 5 minutes. The internal can be changed if needed. It is also possible to send tracking requests only when the radius server is not responding. This can be done use the following config.

radius-server host <radius-server> tracking-mode dead-only

To configure another username and password use the following configuration on the switch. This is a global configuration command.

radius-server tracking user-name <username> password plaintext <password>

I'm checking how this works. 

Quick question though ... is there a way to avoid this? am i able to create some sort of dummy account in clearpass for the sole purpose of radius tracking?

radius-tracking is not a ClearPass feature. With radius-tracking enable the switch will send dummy RADIUS requests to see if the RADIUS server is working. There are multiple options but the basic option is that the switch will start sending dummy RADIUS packets when the RADIUS server is not responding. 

A sample CX configuration for this 

radius-server host <hostname> tracking enable

with radius tracking, what user-name and password is to be used? I'm not familiar enough with clearpass to know what to use there. is it one of the admin accounts?

The switches (both CX and AOS-S) have support for RADIUS tracking. This will help to mark a RADIUS server as not available and prevent it from being used. 

https://arubanetworking.hpe.com/techdocs/AOS-CX/10.15/HTML/security_5420-6200-6300-6400/Content/Rem_AAA_cmds/rad-ser-hos-10.htm

https://arubanetworking.hpe.com/techdocs/AOS-S/16.11/ASG/WC/content/common%20files/rad-ser-tra-con.htm?Highlight=tracking

we are still in the process of testing a deployment of wired network security. We have a couple of newer clearpass VM's set up, on a newer version than our production clearpass servers, where we are setting up policies for wired network security. We have about 4 clearpass VM's. currently, 3 of those servers are down, due to some of our temp licensing expiring. We left the publisher server running and turned off the subscriber servers. We figured this would be a good opportunity to see how failover works

Currently, our MAC auth clients continue to authenticate, via clearpass, to grab their roles, and go back to the switches to grab their local user roles. However, 802.1x clients suffer an authentication timeout on EAP-TLS. The machines complete the EAP portion but never complete the TLS transaction. 

We discovered, when we remove the radius server host definitions for those servers that are down, from both of the CX switches and AOS switches, that all of a sudden, those 802.1x machines no longer timeout and complete their EAP-TLS transactions. 

This seems like either poor design, or some of the default settings in the wired network policy guides are not the correct values we should be using. 802.1x clients should not timeout if there is still at least 1 clearpass server alive.

I'm a little clueless where I should be looking for settings that could resolve this behavior. The behavior is identical on AOS and CX switches.

some possibly relevant config, on the switches

CX switches:

aaa authentication port-access client-limit 12
aaa authentication port-access dot1x authenticator
    eapol-timeout 10
    max-eapol-requests 1
    max-retries 5
    enable

AOS

aaa port-access authenticator <port range>
aaa port-access authenticator <port range> supplicant-timeout 10
aaa port-access authenticator <port range> tx-period 10

yea, I created a local user account in clearpass and added that username into the test switch. it still floods the access tracker with rejects. my best guess is that the access-tracker is looking for some kind of radius service to tie the tracker to

By default de switches will sending radius tracking every 5 minutes. The internal can be changed if needed. It is also possible to send tracking requests only when the radius server is not responding. This can be done use the following config.

radius-server host <radius-server> tracking-mode dead-only

To configure another username and password use the following configuration on the switch. This is a global configuration command.

radius-server tracking user-name <username> password plaintext <password>

I'm checking how this works. 

Quick question though ... is there a way to avoid this? am i able to create some sort of dummy account in clearpass for the sole purpose of radius tracking?

radius-tracking is not a ClearPass feature. With radius-tracking enable the switch will send dummy RADIUS requests to see if the RADIUS server is working. There are multiple options but the basic option is that the switch will start sending dummy RADIUS packets when the RADIUS server is not responding. 

A sample CX configuration for this 

radius-server host <hostname> tracking enable

with radius tracking, what user-name and password is to be used? I'm not familiar enough with clearpass to know what to use there. is it one of the admin accounts?

The switches (both CX and AOS-S) have support for RADIUS tracking. This will help to mark a RADIUS server as not available and prevent it from being used. 

https://arubanetworking.hpe.com/techdocs/AOS-CX/10.15/HTML/security_5420-6200-6300-6400/Content/Rem_AAA_cmds/rad-ser-hos-10.htm

https://arubanetworking.hpe.com/techdocs/AOS-S/16.11/ASG/WC/content/common%20files/rad-ser-tra-con.htm?Highlight=tracking

we are still in the process of testing a deployment of wired network security. We have a couple of newer clearpass VM's set up, on a newer version than our production clearpass servers, where we are setting up policies for wired network security. We have about 4 clearpass VM's. currently, 3 of those servers are down, due to some of our temp licensing expiring. We left the publisher server running and turned off the subscriber servers. We figured this would be a good opportunity to see how failover works

Currently, our MAC auth clients continue to authenticate, via clearpass, to grab their roles, and go back to the switches to grab their local user roles. However, 802.1x clients suffer an authentication timeout on EAP-TLS. The machines complete the EAP portion but never complete the TLS transaction. 

We discovered, when we remove the radius server host definitions for those servers that are down, from both of the CX switches and AOS switches, that all of a sudden, those 802.1x machines no longer timeout and complete their EAP-TLS transactions. 

This seems like either poor design, or some of the default settings in the wired network policy guides are not the correct values we should be using. 802.1x clients should not timeout if there is still at least 1 clearpass server alive.

I'm a little clueless where I should be looking for settings that could resolve this behavior. The behavior is identical on AOS and CX switches.

some possibly relevant config, on the switches

CX switches:

aaa authentication port-access client-limit 12
aaa authentication port-access dot1x authenticator
    eapol-timeout 10
    max-eapol-requests 1
    max-retries 5
    enable

AOS

aaa port-access authenticator <port range>
aaa port-access authenticator <port range> supplicant-timeout 10
aaa port-access authenticator <port range> tx-period 10