The ISE user guides suggest to use a username called 'test-radius' as option to the 'radius-server host' commands. This will cause the respective NAD (a Cat3560 in my case) to make an authentication check on each configured ISE every 60 minutes.
The problem is that every hour I see an authentication failure for this user, but ONLY on my second ISE (I'm running a Standalone HA deployment). Since both hosts should replicate the same user DB, why would it only fail on the second ISE? When I direct end-user login authentications to the second ISE exclusively, they will be passed normally.
See the attached screenshot of the failed authentication attempt for the test-radius user. I've been seeing this with ISE 1.1 as well as 1.1.1.
The relevant config on the switch is:
username test-radius secret 5 <snipped>
radius-server host 172.26.10.35 auth-port 1812 acct-port 1813 test username test-radius key 7 <snipped>
radius-server host 172.26.10.36 auth-port 1812 acct-port 1813 test username test-radius key 7 <snipped>
- How can I get rid of that error?
- Is that test-radius option of much use at all in an ISE setup? As far as I could find out, it would be a measure to figure out if the second ISE policy server is running at all as long as the first one hasn't failed.
Thanks for any help.
I personally do not user this configuration in my ise deployment. However it should work fine since you have replication turned on. Do you experience any failures from users (or when you use the test aaa ... command?) If so, then try to force a sync up on the nodes and see if that fixes it.
*Please rate helpful posts*
I believe you do not see any Access-Requests with the 'test-radius' on your primary ISE PDP server at all. The reason is simply that this server is already known as alive due to the regular Access-Requests for user authentication, so there is really no reason for checking its availability.
Obviously this does not explain the behavior why the test request is failing. Anyhow,sniffing the RADIUS request packets from your switch towards the ISE should bring light into the darkness.
However, this whole behavior does not affect user authentication at all and is hence only cosmetic. For the switches itself it only matters if it gets a response from the ISE (RADIUS) to know if it is alive or not.
Testing with the 'test aaa...' command does not result in the 'Authentication Failure', that Toni had mentioned.
Kind regards and hth,
*Please rate helpful posts*
Hi Tarik and Stephan
Thanks for both your replies. Stephan's findings are interesting (though I haven't found time yet to do the sniffing with Wireshark), whereas I can confirm that I'm running it with IOS 12.2(55)SE6 on a Cat3560 (non-X). And yes, 'test aaa...' results in successful authentication attempts towards both policy servers. Just the error remains the same for that hourly check, only popping up for the second policy server.
I'd be fine with the fact that it's just a cosmetic thing if it only was a green entry and not a red one...customers don't like to see red in their logs As I can't upgrade the switching hardware or software right now (12.2 is the latest supported release train for the legacy Cat3560 platform) I guess I have to live with it...
Thank you guys anyway