topic Re: Prioritizing Local PSN Radius Server in Network Access Control

Prioritizing Local PSN Radius Server

biswajit.pradhan — Fri, 24 Apr 2020 13:10:13 GMT

We have a distributed ISE deployment with one PSN in local office, two in local regional datacenter and two in remote data center. Intention is to make site switches use local PSN always with 1st degree failover to local DC and 2nd degree failover to remote DC. Is there a way achieve this? Will 3 different radius groups solve this?

Re: Prioritizing Local PSN Radius Server

Mike.Cifelli — Fri, 24 Apr 2020 13:29:06 GMT

You can accomplish this by using one aaa server group. You will need to add each radius server one by one with the first (highest) priority server being entered first. For example:
radius server SVR1
address ipv4 x.x.x.x auth-port 1812 acct-port 1813
...(excluding additional cfg)
radius server SVR2
address ipv4 x.x.x.x auth-port 1812 acct-port 1813
...(excluding additional cfg)
aaa group server radius TEST_GRP
server name SVR1 (highest priority)
server name SVR2 (lowest priority)
Then in your AAA statements reference TEST_GRP. Tweak configs in each respective area to meet your needs. Note that #sh aaa server will return priorities/status from global config. HTH!

Re: Prioritizing Local PSN Radius Server

biswajit.pradhan — Sat, 25 Apr 2020 19:21:56 GMT

Hi Mike,

This is our current configuration, 2 servers in one group. Yes, the priority shows as you have described. However, the switch is sending request to both the servers. 51% of requests sent to priority 1 server while 49% sent to the second one.

Is it possible to make the switch sends any requests to 2nd priority server only when first server is unavailable ?

Re: Prioritizing Local PSN Radius Server

poongarg — Mon, 27 Apr 2020 11:45:01 GMT

Hi Biswajit,

At a given time, normally switch send request to one server only. It will use second server in the group only when the first server is marked "DEAD".

Kindly attach the switch config here to check further along with "show aaa servers" output.

Re: Prioritizing Local PSN Radius Server

Mike.Cifelli — Mon, 27 Apr 2020 13:26:21 GMT

As @poongarg mentioned you could look into tweaking the DEAD timers. The config mentioned earlier will function in a top down approach. Maybe your timers are causing some requests to hit SVR2? If a server in your group is assumed to be alive then this server will be used for AAA requests. The secondary server will become active once the switch determines it is DEAD. This link may be helpful: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_rad/configuration/xe-3se/5700/sec-usr-rad-xe-3se-5700-book/sec-rad-aaa-server-groups.html . HTH!

Re: Prioritizing Local PSN Radius Server

biswajit.pradhan — Mon, 27 Apr 2020 17:43:41 GMT

The priority looks good. We have a global dead timer of 15 for all.

RADIUS: id 1, priority 1, host 10.211.xx.xx, auth-port 1812, acct-port 1813
State: current UP, duration 4294967s, previous duration 0s
Dead: total time 0s, count 0
Platform State from SMD: current UP, duration 950046s, previous duration 900s
SMD Platform Dead: total time 6300s, count 7
Platform State from WNCD: current UP, duration 0s, previous duration 0s
Platform Dead: total time 0s, count 0
Quarantined: No
Authen: request 2952101, timeouts 2565, failover 29, retransmission 2508
Response: accept 189138, reject 634082, challenge 2126316
Response: unexpected 17, server error 0, incorrect 0, time 64ms
Transaction: success 2949536, failure 66
Throttled: transaction 0, timeout 0, failure 0
Author: request 0, timeouts 0, failover 0, retransmission 0
Response: accept 0, reject 0, challenge 0
Response: unexpected 0, server error 0, incorrect 0, time 0ms
Transaction: success 0, failure 0
Throttled: transaction 0, timeout 0, failure 0
Account: request 347975, timeouts 5215, failover 34, retransmission 5119
Request: start 153811, interim 0, stop 153735
Response: start 153794, interim 0, stop 153715
Response: unexpected 4782, server error 0, incorrect 0, time 79ms
Transaction: success 342760, failure 96
Throttled: transaction 0, timeout 0, failure 0
Elapsed time since counters last cleared: 35w5d9h43m
Estimated Outstanding Access Transactions: 0
Estimated Outstanding Accounting Transactions: 0
Estimated Throttled Access Transactions: 0
Estimated Throttled Accounting Transactions: 0
Maximum Throttled Transactions: access 0, accounting 0
Requests per minute past 24 hours:
high - 19 hours, 41 minutes ago: 840
low - 9 hours, 17 minutes ago: 0
average: 0

RADIUS: id 2, priority 2, host 10.137.xx.xx, auth-port 1812, acct-port 1813
State: current UP, duration 4294967s, previous duration 0s
Dead: total time 0s, count 0
Platform State from SMD: current UP, duration 947383s, previous duration 900s
SMD Platform Dead: total time 4500s, count 5
Platform State from WNCD: current UP, duration 0s, previous duration 0s
Platform Dead: total time 0s, count 0
Quarantined: No
Authen: request 2701417, timeouts 3048, failover 46, retransmission 2998
Response: accept 189693, reject 504993, challenge 2003683
Response: unexpected 23, server error 0, incorrect 0, time 197ms
Transaction: success 2698369, failure 68
Throttled: transaction 0, timeout 0, failure 0
Author: request 0, timeouts 0, failover 0, retransmission 0
Response: accept 0, reject 0, challenge 0
Response: unexpected 0, server error 0, incorrect 0, time 0ms
Transaction: success 0, failure 0
Throttled: transaction 0, timeout 0, failure 0
Account: request 366580, timeouts 1356, failover 89, retransmission 1318
Request: start 175469, interim 0, stop 175523
Response: start 175455, interim 0, stop 175504
Response: unexpected 1, server error 0, incorrect 0, time 191ms
Transaction: success 365224, failure 38
Throttled: transaction 0, timeout 0, failure 0
Elapsed time since counters last cleared: 35w5d9h43m
Estimated Outstanding Access Transactions: 0
Estimated Outstanding Accounting Transactions: 0
Estimated Throttled Access Transactions: 0
Estimated Throttled Accounting Transactions: 0
Maximum Throttled Transactions: access 0, accounting 0
Requests per minute past 24 hours:
high - 9 hours, 17 minutes ago: 0
low - 9 hours, 17 minutes ago: 0
average: 0

Re: Prioritizing Local PSN Radius Server

poongarg — Tue, 28 Apr 2020 06:10:05 GMT

I still need to check the aaa and radius configuration on your device.

Re: Prioritizing Local PSN Radius Server

biswajit.pradhan — Sun, 03 May 2020 14:20:38 GMT

@poongarg wrote:
I still need to check the aaa and radius configuration on your device.

Here it is:

radius server SRV1
address ipv4 10.211.xx.xx auth-port 1812 acct-port 1813
key 7 xxxx
radius server SRV2
address ipv4 10.137.xx.xx auth-port 1812 acct-port 1813
key 7 xxxx

aaa group server radius ISE_radius_servers
server name SRV1
server name SRV2

radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server dead-criteria time 30 tries 3
radius-server retry method reorder
radius-server retransmit 1
radius-server timeout 3
radius-server deadtime 15

aaa authentication dot1x default group ISE_radius_servers
aaa authorization network default group ISE_radius_servers
aaa authorization auth-proxy default group ISE_radius_servers
aaa accounting dot1x default start-stop group ISE_radius_servers
aaa accounting system default start-stop group ISE_radius_servers
aaa server radius dynamic-author
client 10.211.xx.xx server-key 7 xxxx
client 10.137.xx.xx server-key 7 xxxx
ip radius source-interface Vlan69

Re: Prioritizing Local PSN Radius Server

poongarg — Mon, 04 May 2020 07:31:59 GMT

Biswajit,

Regarding your query:

This is our current configuration, 2 servers in one group. Yes, the priority shows as you have described. However, the switch is sending request to both the servers. 51% of requests sent to priority 1 server while 49% sent to the second one.

Is it possible to make the switch sends any requests to 2nd priority server only when first server is unavailable ?

This is exactly how the switch behaves. At a time it can send request to only one server which is having higher priority. Not sure what you meant by 51% request sent to priority 1 server and 49% sent to second one, probably due to request and response count on both the servers in the group.

You have configured the command: radius server retry method reorder

Without this command in place, switch will always send the request to first server, if the first server will be marked as DEAD, then it will send the request to second server and once the first server will be back online, switch will again start sending request to first server in the list.

With this command in place, as soon as first server is DEAD, it will send start sending request to second server but when the first server will be back online, switch will keep on using second server in the list until it will be marked as DEAD.

If you want that RADIUS request should always be served by first server in the group, remove this command to have first server respond always if it's status is UP.

HTH