ACS 5 gives alert after 20,000 radius probes: Bug CSCtj69797

Ive been meaning to blog about this bug on the ACS 5.x platform, but forgot until this week when the alert surfaced again.

This bug is cosmetic only and doesn't impact performance. ACS sends a nice orange alert when 250,000 cached sessions are cumulated and should delete 20,000 sessions. I was worried at first, when I think “sessions” I think EAP.

I opened up a TAC case and got a rockstar ACS TAC engineer.  Sorry, but I cant share his name, somethings need to be kept confidential, especially a great resource !  In short, a “probe” counts as a session.

Say for example a device wants to authenticate it will send a probe and sometimes it will send multiple probes. Not to be confused with 802.11 probe request / response frames.  Rather, its a radius probe.

A wireless example would be a client that doesn't support PMK cache / OKC. Every time this client would roam, he would probe the radius server again to re-authenticate. So you can see, you could rack up the session pretty quickly in a large environment.

What happens is that every time a user tries to authenticate using radius the device will send a probe in order to see if the ACS is up and running we can also have this configured to happen even if there is no authentication going by doing radius-server retransmit command. So if for example 20 user try to authenticate using radius than 20 radius probes are send to the ACS. It is not dependent on the amount of devices it more with the amount of user and the amount of authentication request they generate.
 
Remember that the reason you are receiving the alarm is because the ACS doesn’t delete the 20000 sessions which he should do automatically therefore the bug was opened.

                                                                                                                          -TAC

CSCtj69797 Bug Details

ACS 5 gives alert after 20000 radius probes

Symptom:

ACS View giving alert when 20 000 sessions are reached.
The problem is that it seems to be triggered also with "radius probes", i.e. authentication packets with no accounting done.
So for example with several ACE appliances doing radius probes, this alert is reached very quickly

Conditions:

Radius authentication packets with no accounting happening in a frequent way

Workaround:

Only an alert.

**** There is another work around whereby you make a filter so that you no longer get the alerts. Consult TAC *** - George

Status  
Terminated

Severity  
3 - moderate

Last Modified  
In Last month

Product  
Cisco Secure Access Control Server Solution Engine

Technology  

1st Found-In  
5.1(0.44)

Comments

[Andrew vonNagy]

George,
I'm confused by what the source of this probing is. Is it the wireless client or the access point probing the RADIUS server? I know Cisco and other vendors have a proactive RADIUS probe feature so they can determine if a server is responding without trying to pass actual authentication traffic. And since I am not aware of any RADIUS probe frame sent by wireless clients, you have me confused.

If it's the wireless client, could this be the EAP-Response-Identity, which is the first frame sent to the RADIUS server that originates from the client?

Can you clarify?

Thanks,
Andrew

[George]

As I understand it, the client probe is the auth request, not a probe in a general sense. And as you roam, if you dont use OKC for exmaple, you then create a cache session each time. This is how I understand it.. I hope this helps.