i m getting sbr error 24575
1. Radius: The Auth flood queue has dropped 1 packet(s).
2. Radius: Dropping one new request from due to overload.
Also in user logs.
1. Inner authentication failed.
but when i restart IC services it works fine for sometime..but after that same behavior...
what should i do...??
plz help me in this regard..
Regards,
Raja
Hello Raja,
I would suggest that you open a ticket with JTAC, this sounds like a bug.
Regards,
Rich
Hi Raja,
This message indicates that your system is getting more authentication requests then it can handle. Either there was a flood of requests and the system was overloaded or your network is generating more requests then the system is configured to handle.
If the message does not go away after a while, it might also indicate some other system or memory problem.
What version of SBR are you running?
Check the documentation for information about setting the threads to handle these requests. What you want to check on adjusting are:
Max-Acct-Threads = X
Max-Acct-Floods = X
Max-Acct-Threads-In-Flood = X
If you thread counts are high, you probably also want to set:
WorkerThreadStackSize=128000 - this reduces the meory used by the OS for threads **for UNIX system
Cheers,
Scott
Kamran,
Dev has refined our handling of L3 authentication requests to help prevent the overload condition you described. This fix is based on PR470726: Webserver/SBR improvements to handle overload conditions.
UAC versions UAC3.1R5, 4.0R1 and 4.0R2 and later should handle the load better for you.
If after upgrading to UAC 4.0R2 you are still seeing this issue, please open a JTAC ticket ASAP so that we can find out the root cause and have it addressed by Dev.
Thanks and regards,
Rich
Was a resolution ever found for this issue? We are experiencing a very similiar problem, and are using SBR 4.0R2.
Supplicant is XP 32bit, Authenticator is SSG5 6.3.0r5.0, Authentication Server is IC 4500.
Thanks,
Paul
Hi Paul,
The error means that the device is being overloaded. The best course of action is to determine if the ssg5 is definitely the source of the traffic, and then to figure out why it is spamming the IC.
I would open an SSG JTAC case to have them troubleshoot the connection issue with you.
Regards,
Rich
I have a ticket open now but was hoping that others have experienced something similar. Any ideas on what could be the source? Has an SSG been the source of such an overload in the past?
Thanks,
Paul