Hi all, I wonder whether RADIUS can be easily extended to track the usage in every hour (or 30 mins) of the day? The current ACCT START/STOP and INTERIM UPDATE INTERVAL are per-session basis and hence it is hard to track the usage of each session in every hour. I can imagine that this would face some performance issue with many flows, but I think this feature will be very useful for time-dependent usage charging. It would be great if anyone gives me some insight on this. Thanks, DataWizApp Team
On Fri, Sep 14, 2012 at 7:51 AM, DataWizApp <datawizapp@gmail.com> wrote:
Hi all,
I wonder whether RADIUS can be easily extended to track the usage in every hour (or 30 mins) of the day? The current ACCT START/STOP and INTERIM UPDATE INTERVAL are per-session basis and hence it is hard to track the usage of each session in every hour. I can imagine that this would face some performance issue with many flows, but I think this feature will be very useful for time-dependent usage charging.
It would be great if anyone gives me some insight on this.
What you're asking for isn't a function of a Radius server, but of the NAS (the box that is sending the requests) and the backend database you use with FreeRadius. What you would need to do is have frequent Interium updates being sent to FreeRadius, then it checks the usage and if it's outside the time sends a CoA/DM to disconnect the subscriber. Otherwise writing a cron job on the server to check the session information and send CoA/DM messages when the subscriber has gone over their limits. This is standard functionality of FreeRadius, just need to configure it to your needs.
On 09/13/2012 08:51 PM, DataWizApp wrote:
Hi all,
I wonder whether RADIUS can be easily extended to track the usage in every hour (or 30 mins) of the day? The current ACCT START/STOP and INTERIM UPDATE INTERVAL are per-session basis and hence it is hard to track the usage of each session in every hour.
This is better done by polling, such as with SNMP or other APIs. RADIUS doesn't let you control the time of an accounting packet - just the interval. In any case, as others have said, this would be something the NAS did, not FreeRADIUS.
Thank you both. I have another question below. Suppose that we have many NAS devices supporting INTERIM UPDATE and one main RADIUS server. Rather than changing all the NAS servers update their usage regularly using some cron jobs or scripts, it may be useful that the RADIUS server puts an intended INTERIM UPDATE interval to each Access-Accept message. I may be wrong or it may not be supported from the current standard, but want to hear your opinions. The RFC 2866 describes that "If the server wishes to receive interim accounting messages for the given user it mush include the Acct-Interim-Interval RADIUS attribute in the message, which indicates the interval in seconds between interim messages. It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept." For example, assume that we have 5 NAS devices, one RADIUS server and five user sessions connect to five NAS devices respectively, and we would like to charge users based on the usage in each hour. User 1 initiates the connection at 01:01 User 2 initiates the connection at 01:11 User 3 initiates the connection at 01:21 User 4 initiates the connection at 01:31 User 5 initiates the connection at 01:41 For this case, what I think is that the RADIUS server can sends an INTERIM-UPDATE with different interval to each session -- e.g., 59, 49, 39, 29 and 19 mins. I wonder whether we can do like this way. Certainly if the flow ends before that it will send a STOP message. On Thu, Sep 13, 2012 at 4:11 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 09/13/2012 08:51 PM, DataWizApp wrote:
Hi all,
I wonder whether RADIUS can be easily extended to track the usage in every hour (or 30 mins) of the day? The current ACCT START/STOP and INTERIM UPDATE INTERVAL are per-session basis and hence it is hard to track the usage of each session in every hour.
This is better done by polling, such as with SNMP or other APIs. RADIUS doesn't let you control the time of an accounting packet - just the interval.
In any case, as others have said, this would be something the NAS did, not FreeRADIUS. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Fri, Sep 14, 2012 at 4:19 AM, DataWizApp <datawizapp@gmail.com> wrote:
Thank you both. I have another question below.
Suppose that we have many NAS devices supporting INTERIM UPDATE and one main RADIUS server. Rather than changing all the NAS servers update their usage regularly using some cron jobs or scripts, it may be useful that the RADIUS server puts an intended INTERIM UPDATE interval to each Access-Accept message.
Yes, you can do that. Acct-Interim-Interval reply attribute.
I may be wrong or it may not be supported from the current standard, but want to hear your opinions.
It works just fine.
The RFC 2866 describes that "If the server wishes to receive interim accounting messages for the given user it mush include the Acct-Interim-Interval RADIUS attribute in the message, which indicates the interval in seconds between interim messages. It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept."
For example, assume that we have 5 NAS devices, one RADIUS server and five user sessions connect to five NAS devices respectively, and we would like to charge users based on the usage in each hour.
User 1 initiates the connection at 01:01 User 2 initiates the connection at 01:11 User 3 initiates the connection at 01:21 User 4 initiates the connection at 01:31 User 5 initiates the connection at 01:41
For this case, what I think is that the RADIUS server can sends an INTERIM-UPDATE with different interval to each session -- e.g., 59, 49, 39, 29 and 19 mins. I wonder whether we can do like this way. Certainly if the flow ends before that it will send a STOP message.
Why would you want all interim update packets to come at the same time? Usually what you do is: - Set the limit (if you know any) using Session-Timeout, ChilliSpot-Max-Total-Octets, or whatever attribute that tells the NAS "hey, this is the max time/volume that this user can use" - Set Acct-Interim-Interval to something acceptable (1 hour is a good start), so that if you have some kind of usage display for the customer, it will be updated. -- Fajar
On Thu, Sep 13, 2012 at 05:19:52PM -0400, DataWizApp wrote:
For example, assume that we have 5 NAS devices, one RADIUS server and five user sessions connect to five NAS devices respectively, and we would like to charge users based on the usage in each hour.
User 1 initiates the connection at 01:01 User 2 initiates the connection at 01:11 User 3 initiates the connection at 01:21 User 4 initiates the connection at 01:31 User 5 initiates the connection at 01:41
For this case, what I think is that the RADIUS server can sends an INTERIM-UPDATE with different interval to each session -- e.g., 59, 49, 39, 29 and 19 mins. I wonder whether we can do like this way.
That's clearly wrong. User 1's accounting will arrive at 01:01, 02:00, 02:59, 03:58, ... User 2's accounting will arrive at 01:11, 02:00, 02:49, 03:38, ... ... User 5's accounting will arrive at 01:41, 02:00, 02:19, 02:38, ... In any case, NASes don't give accounting at *exactly* the interval you ask for. It will drift one way or the other. For long-lived sessions, as are often the case on DSL, this simply won't work as you want. If you need to charge for usage within particular clock hours, you'll have to set the interim update very frequently (say every 1-5 minutes). Or you could probably do some sort of SNMP query on the hour, asking the NAS to list all active sessions and their usage. You would have to process accounting records such that those which stopped before the hour were handled using accounting data only, but those which started before the hour and stopped after the hour were split using the SNMP information. This sounds doable, but depends on the availability of MIBs for the NAS which expose the information you need (Acct-Session-Id and octet counts) Regards, Brian.
participants (5)
-
Brian Candler -
DataWizApp -
Fajar A. Nugraha -
Peter Lambrechtsen -
Phil Mayers