Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SBR] Authentication Request Rejected after Exceeding Concurrency Limit



Article ID: KB33036 KB Last Updated: 04 Mar 2020Version: 2.0

This article provides reasoning for a user authentication request being rejected when the concurrency limit is exceeded.



SBR Carrier provides a concurrency feature, which allows customers to define a session limit that an individual user may have in the Current Session Table (CST). When this limit is reached, any subsequent authentication requests for that user will be rejected and SBR will write an error in the SBR log.

"user <user-id> has exceeded the concurrency limit of '1'; failing request"

Customers may also notice a log message about concurrency limits being met.

"Usage limit for user <user-id> exceeded. Request denied"

And this would result in an authentication reject back to the NAS device.

It should be noted that due to the customer configuration of concurrency, this could be a valid occurrence of users exceeding their login limits.



Accounting packets may have been dropped between the NAS and the SBR or could have been dropped by the SBR when the flood queue was exhausted.

Once SBR threads and floods become exhausted and drop requests, this can create issues when new authentication requests arrive to SBR. Since accounting stop packets could have been dropped, sessions in CST will remain until an accounting stop is processed by SBR or the session times out/expires, and the session is removed from CST. This will cause new authentication requests for users in the session database to be rejected due to concurrency limits.

In most customer environments where concurrency is failing with exceeding concurrency limits, it is due to external entities, such as latency in the RADIUS response time from proxy targets or SQL response time from an external database. This will queue new RADIUS accounting packets to be processed by the SBR and eventually overflow to the Flood Queue. Once the flood queue is exhausted, accounting packets will be dropped in the fashion that is configured such as LIFO (Last In First Out) or FIFO (First In First Out).



Verify that accounting starts and stops, which contain the Framed-IP-Address sent to the SBR, are recording in the accounting logs. If accounting start or stop records are not recorded in the accounting log for the affected session, run a packet capture between the NAS and the SBR, along with an SBR debug (LogLevel = 2, TraceLevel = 2) for two to three minutes to assist in isolating where the issue exists.

Examine the RADIUS response time from proxy targets or SQL response time depending on where the RADIUS accounting packets are processed in the SBR Environment.

If these processes do not alleviate the concurrency issue in SBR, contact Support for further assistance.


Modification History:

2020-03-04: Article modified to include more detailed information to assist troubleshooting


Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search