Duplicate RADIUS Sessions
From time to time operators can notice multiple current sessions on a customer account, yet there is only one current session in the NAS. Generally this is not anything to worry about as it is usually due to a session not being closed properly. For example in the majority of cases it is related to networking glitches where the RADIUS server does not receive a packet with the information that a session is down. It does not cause any problems for data usage calculation since octets are counted up only for the actual active sessions.
How the accounting session works
The session information displayed in SIMPLer comes from the RADIUS servers. Normally when a customer comes online an accounting START message is sent by the MikroTik to the RADIUS server and this creates the RADIUS session. The MikroTik then periodically sends accounting update messages (every 5 minutes) which update the information in the RADIUS accounting session. When the customer goes offline the MikroTik should send an account STOP message to the RADIUS server which then closes out the session.
However...sometimes STOP messages are not sent, or get lost. For example if a MikroTik reboots, STOP messages will not be sent for any sessions which were active at the time. If the customer reconnects a new session will be started and both the old (now inactive) session and the new session will display on the customer record. However you will be able to see that the old session is not actually being updated - if you look at the start time and add the session time it should be within 5 minutes of the current time - if not it means that that session is not being updated - it is an "inactive" or "stalled" session:-
Closing stalled session
SIMPLer has a nightly audit which will detect these stalled sessions and automatically close them out - however they must be stale for more than 24 hours before they get closed automatically.
1. Manual intervention
If it is suspected there are stale sessions, these can be closed out manually by going to RADIUS -> Usage Details -> Close Stalled Sessions
Select a "Grace Period" and click Yes to go. The "Grace Period" says how long it should be since a session was updated to class it as stale - typically sessions should be updated every 5 minutes, so allowing for a couple of lost packets a grace period of 15 or 30 minutes is probably OK.
2. Setting up a script
If this is an ongoing problem and find that frequently stale sessions need to be closed out, then the first thing to do is to check connectivity between the MikroTik and the RADIUS servers, and also make sure the MikroTik is not rebooting frequently. It is also possible to add a Cronjob (Settings -> Cronjobs) to run the job to close the stale sessions more frequently - for example set up to run it every 30 minutes like this:
Select how often you want it to run - set Hour to '*' (every hour) and Minute to '*/30' (ever 30 minutes) and for Grace Period set how long you want a session to be idle before it is classed as stalled and automatically closed - 30 Minutes should probably OK. Finally click Update Cronjobs to save.
If issues are experienced with these sessions where they are not closed after 24 hours you could contact email@example.com with an example.
Note: Setting up the cronjob will not have an impact on customers - it just closes the ACCOUNTING session in the RADIUS database, but does not do anything to the customers PPoP session. If an accounting session is accidentally closed, a new one will be automatically opened the next time the RADIUS server gets an interim accounting update message from the MikroTik (typically every 5 minutes).
Useful link to Automated 'Closed Stalled Sessions':
Change History Log:
May 10, 2019
Contact Azotel Support:
Need more help? Save time by creating a maintenance ticket to Azotel through your instance.