High Authentication Latency for Radius

[Amar_Tufo]

Hello everybody,

We are expiriencing lately hughe number of High auth latency alarms on our Ise deployment. Version 3.2 with patch version 3.

The use scenario is as follows. We use ISE as an radius server for ssh logins on remote devices, and on that basis is also our daily device configuration backup configured. An AD account is being used from a server that logs in to the devices and back ups their configuration. That's when multiple alarms occur, because the server does the same to multiple devices. This sometimes occur when we as admins log into devices, but not that often.

The log stats this:

15036   Evaluating Authorization Policy

                15048   Queried PIP - Normalised Radius.RadiusFlowType

                15048   Queried PIP - Network Access.EapChainingResult

                15048   Queried PIP - Normalised Radius.RadiusFlowType

                15048   Queried PIP - Network Access.UserName (step latency=8029  ms Step latency=8029 ms)

                15048   Queried PIP - IdentityGroup.Name (step latency=2696  ms Step latency=2696 ms)

                15048   Queried PIP - Normalised Radius.RadiusFlowType (6 times)

                15048   Queried PIP - IdentityGroup.Name (step latency=2670  ms Step latency=2670 ms)

We never experienced this before, searched online has someone the same problem, but without any lead. Can some please give me a hint where to look at, or at least briefly explain what Quered PIP is about?

Thanks

[adamscottmaster2013]

@Amar_Tufo:  Are you integrating AD with Cisco ISE?  Does it mean your account come from Active Directory?  

I have both ISE 3.1 patch-8 and ISE 3.2 patch-5 running in my environment and I also notice that this is an issue whenever Active Directory has issue or is going under patching/maintenance.  To confirm the issue, I would suggest you run tcpdump on the ISE and filter out all the Active Directory servers.  Then looks at the tcpdump and match the time when the issue occur, it will tell you the culprit, most likely Active Directory.

[Amar_Tufo]

Yes accounts are from Active Directory. Hardly doubt that the AD is under patching and maintenance, as this occurs at time where no one is working and occurs three days in a row. But I'll try your sugestion, thank you.

[adamscottmaster2013]

@Amar_Tufo:  instead of speculating or guessing, you can confirm this by perform tcpdump on the ISE itself and analyze it when the issue occurs.  That way you will know for sure.

[Amar_Tufo · Accepted solution]

Reloading the nodes seems to calmed the situation. Last night we recieved no alarms at all. Thank you for your suggestion, will try tcpdump if the alarm happens again.