We've noticed the users online report in Emerald is sometimes not accurate. With concurrency control enabled customers are sometimes denied access for being online while they are not actually logged on. What is going on and how can I fix it?
May 7 2018
Starting Emerald v6 new options are available for verifying online list.
If session manager is installed access servers supporting dynamic authorization can enable 'Verify Session Status' feature from Emerald Admin / RADIUS / Access Servers to have session manage periodically verify status of sessions using CoA request containing only session identifying attributes.
For access servers with interim accounting enabled you may run the following query from Emerald Admin / Database / SQL Query menu or schedule it to run periodically from Emerald Admin / Scheduler / Configure schedules.
{CALL RadClearInterim(3,NULL)}
This automatically clears any sessions from the online list missing more than three consecutive interim update periods.
Dec 15 2004
If all else fails and you have administrative control of the access device, and they support the ability to send an SNMP query to check the online status of users you can use RadiusNT's SNMP concurrency feature which sends an SNMP query to verify the user is actually online while performing concurrency checks. This eliminates false positives. Please see the RadiusNT/X and Emerald admin guide for information on configuring SNMP concurrency.
Another solution is to contact IEA support about custom concurrency checking procedure for Emerald 4.5 which requires at least RadiusNT/X version 5 to implement. The procedure uses CallerID information if avaliable as an additional check when enforcing concurrency control. If the user calling has the same callerid as an existing session - the existing session is ignored.
Dec 15 2004
RadiusNT/X has several features which allow it to tolerate intermittent periods where the database server is not able to respond in time or is unavaliable. These features such as the authentication smart cache and accounting spooler allow RadiusNT to continue to authenticate and accept accounting data without the database server being immediatly avaliable. Accounting data is uploaded to the database server has conditions improve. However if the database server is unavaliable for an extended period of time or is so overworked that the accounting upload consistantly lags behind demand the result can be the accounting spooler fills up causing RadiusNT to stop acknowledging accounting requests. Without a backup RADIUS server to send accounting data some accounting requests may very well exceed their retry settings and be discarded. You can increase the size of the accounting spooler by increasing the 'Max spooled items' field in the accounting section of the RadiusNT/X admin. Each 10,000 spooled records requires about a megabyte of main memory for RadiusNT. Increasing the max spooled items field allows RadiusNT to store more accounting records for upload allowing it to be detached from the database server or account for periods of being 'overworked' for a longer period of time. Generally these problems are rare. If a database capacity problem is suspected it can ususally be resolved by adding more memory to the database server. If the accounting spooler fills up it will long a message to this effect to the acct.log file located in the RadiusNT/X or Emerald directory.
Dec 15 2004
Another cause of an inconsistant online view are NAS devices which don't support or are not configured to send Accounting-On and Accounting-Off messages to the RADIUS server upon shutdown and startup. These messages are important as they signal the RADIUS server to clear any sessions currently marked online by that access device.
Dec 15 2004
On a rare occassion we encountered a custom access device which sent RADIUS Acct-Session-ID fields larger than the length normally reserved for them in the Calls table. As a result RadiusNT/X logs a size warning in the acct.log file and truncates the SessionID attribute to fit the Calls table. When the attribute is truncated its possible that the truncated portion contained all of the unique differences from other sessions - in effect producing several sessions with the same session id and leading to the same problems discussed earlier in this article.
If this is occuring you can simply increase the size of the AcctSessionID column in the Calls table to match the increased size requirement. When this is done you must also change the AcctSessionID column in the ServerPorts table to match any changes made to the Calls table. After making such a change - restart RadiusNT/X.
Dec 15 2004
Another possible cause is a network access device which fails to provide adequate uniqueness in the Acct-Session-ID attribute over time. Acct-Session-ID is a required RADIUS accounting attribute used to uniquely identify a session from start to finish.
Concider a fictional NAS device which simply increments a numeric field for each new session starting at 1 on startup and uses only this number as a session identifier. When such a device is rebooted the Acct-Session-ID field restarts from 1 causing duplicate session ids to be recorded. While Acct-Session-ID is not exclusivly used to identify sessions it plays a major role. Over time such a system will very likely cause at least some accounting records to be concidered duplicates and therefore not logged or updated in the online list. An example of a system which provides good Acct-Session-ID data also includes a timestamp with the numeric counter or long strings of letters and numbers that seem to change at random.
If there is not a firmware or configuration change avaliable to address a NAS device which behaves in this way you can implement the workaround of including the CallDate field as part of your Calls tables primary key. Note doing this may take a long time to complete depending on the size of the Calls table and will use an increased amount of disk space on the database server. This should be done during a scheduled maintenance window as while the primary key is being altered the calls table may not be accessable for normal accounting and authentication functions. We strongly recommend having an IEA support engineer assist with this task.
Note that including CallDate will guarantee accounting records from a NAS with poorly choosen Acct-Session-IDs will not be dropped as duplicates by Emerald or RadiusNT. However the drawback is that it may open up a relatively small possibility duplicate accounting records will be incorrectly logged as separate valid Calls. We recommend working with the access device vendor if at all possible to provide better uniqueness in the Acct-Session-ID attribute.
Dec 15 2004
To get a rough feel for the quantity of total accounting stop records being missed within the last day, run the following query against your Emerald or RadiusNT database.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED SELECT c.NASIdentifier,COUNT(*) AS Missing FROM Calls c WHERE c.CallDate > DATEADD(dd,-1,getdate()) AND c.AcctStatusType = 2 AND NOT EXISTS (SELECT * FROM Calls WHERE NASIdentifier = c.NASIdentifier AND AcctSessionID = c.AcctSessionID AND AcctStatusType = 1 AND NASPort = c.NASPort AND Username = c.Username) GROUP BY c.NASIdentifier ORDER BY 2 DESC SET TRANSACTION ISOLATION LEVEL READ COMMITTED
Note this query provides only a general estimate of the number of missing account stop records per NAS device within the last 24 hours. It is not and cannot be relied on to produce exact results. The query requires RadiusNT/X to be configured to log both accounting start and stop records to the database and a NAS which supports accounting start and stop.
Restricting the CallDate parameter in this query can be useful for correlating spikes in missing online records with known events that may have contributed to the problem.
Dec 15 2004
The most common cause of this problem is accounting packets being lost while transiting over WAN or Internet links where congestion and packet loss is likely or common. Since RADIUS accounting data is sent via UDP the access server is responsible for resending any accounting record for which it does not receieve an acknowledgement from the RADIUS server. Some NAS devices and port providers in particular default to a retry policy that is insufficent for WAN or Internet links. You should investigate confiuring your access hardware or contact your port provider to increase the number of accounting retries and if possible the time period between each.
