Overview

This article provides an overview and explanation for the following Alarms that can be observed in the EAAA Server:

-DBQUERYTIMEOUT
-HIGHAAARESPONSETIME
-RADIUS_ESI_HIGH_RESPONSE_TIME
-RADIUS_SERVICE_POLICY_NOT_SATISFIED
-THREADNOTAVAILABLE
-UNKNOWN_USER

Information

Below is the alarms list and analysis/feedback/Remarks have been provided from the logs and PCAPs :

DBQUERYTIMEOUT

The DB table 'tblmconcurrentusers' query execution may take the time up to 30 to 50 milliseconds. As there are application-side queries this table has more SQL queries than any other DB Table. So it takes a higher amount of time because of query throughput over this table. 

HIGHAAARESPONSETIME

It is seen that Accounting request processing is taking time as the accounting requests are broadcasted to interfacing servers and there is a timeout. Due to this duplicate packets are sent by AAA. We need to check the reason for the no response from the interfacing servers.

 

RADIUS_ESI_HIGH_RESPONSE_TIME

Couldn’t observe RADIUS_ESI_HIGH_RESPONSE_TIME in the current logs however there is a high number of radius_ESI_Request Timeout observed on all AAA. We need to check the reason for the no response from the interfacing servers.

RADIUS_SERVICE_POLICY_NOT_SATISFIED

During authentication, when none of the Radius service policies is satisfied, AAA will send an 'access-reject' with a response message as 'No Policy Satisfied'. This is the expected call flow and no action is required.

THREADNOTAVAILABLE 

At a particular time stamp, We observed a sudden spike in Accounting requests. There are duplicate Accounting packets sent by AAA to the Sandvine servers, as there is a timeout when the original packet was broadcasted to the respective interfacing server. As a result, the AAA worker thread queue gets full. We need to check the reason for the no response from the interfacing servers. Below is the snap for reference :