[AusNOG] {Disarmed} Radius Interim Update Interval

Wed Sep 3 22:37:10 EST 2014

Why limit yourself to a fixed interval?

You may be able to use RADIUS COA to tweak the interim time to ensure that
the user is more closely tracked when they near a limit.

On particularly busy systems, there can be a benefit to stretching the
interim interval if the system is under load, or randomising the interval
to ensure that interim processing after a major outage doesn't result in
peaking issues.

John

On 3 September 2014 21:13, Stuart Low <stuart.low at me.com> wrote:

> Agree with Chris here but I’ll go one step further. Don’t do it (ok, maybe
> do it, but seriously consider why you are)…
>
> If all you need is total data, Start/Stop will track total data usage, you
> don’t really need interim updates. If you need regular updates because of
> bandwidth control requirements (throttling etc) maybe use it BUT realise
> that you will have scale problems. Concurrent updates on database
> accounting records was what I encountered although row-based locking might
> make this somewhat better but even so, daily granularity of accounting *
> say 10,000 subscribers is going to create a massive table quickly that your
> radius server is going to hang around waiting for. You also have no control
> over things like cost free paths. Additionally you’re either going to use
> failover radius servers and hope you don’t get overlapping/out-of-order
> interim updates or accept you might get some transient database corruption
> on failover/failure… Oh… And forget about actually clustering it (once
> again I’m coming from the ‘large’ deployment scenario) cause then your
> going to be moving the concurrency issues into the database itself.
>
> To be honest unless you’re talking super large and maybe I’m just being a
> biased sysops guy:
> a) Do some simple netflow export (no real need for the full one),
> flowtools and some code reporting on traffic lining up to IPs (based on
> Start/Stop times or Radius auth responses initiating sessions or DHCP
> leases, you get the drift) and gain “freezone” capability
> b) Use a traffic accounting appliances (this is the “lazy but expensive”)
> solution
> c) Log into your routers (or snmp it) every minute or so and batch update
> to your DB rather
>
> OR, if you really really want to do interim updates with low resolution
> (i’ve been in situations where <5min throttle application was the target)
> consider Radiator and a (potential distributed) memory cache based approach
> to interim updates with a ‘destage’ of the memory cache to DB on some
> scheduled period (say.. every minute but as one big batch update into a
> table you can wait around for rather than holding up your radius server(s)).
>
> Just my 2c,
>
> Stu
>
>
>
>
> On 3 Sep 2014, at 3:00 pm, Chris Gibbs <Chris.Gibbs at gosford.nsw.gov.au>
> wrote:
>
> Sorry but ‘depends’ on the situation….
>
> I’ve had situations where we wanted to enforce bandwidth limits on wifi
> networks and wanted to send CoA back to the wifi controllers when certain
> thresholds have been violated. We used the lowest interim value of 5
> minutes.
>
> If it’s purely for counting traffic, then probably higher is better.
>
> If there are a very high number of concurrent sessions, you will most
> likely make it even higher to reduce the load on the server.
>
>
>
>
> <http://www.gosford.nsw.gov.au/> <http://gosford.nsw.gov.au/>
> <gcc_logo81fd33.png> <http://www.gosford.nsw.gov.au/>
>
> Chris Gibbs
> Network and Security Engineer | Corporate Business Operations
> Gosford City Council
> (PO Box 21)
> Gosford NSW 2250
> P  (02) 43258888
> M  0408 222 496
> E  Chris.Gibbs at gosford.nsw.gov.au
>
>
>
>
>
> <http://confirmsubscription.com/h/i/A752C35C6D10F1BB>
> <econnect_logo25c7d9.png>
> <http://confirmsubscription.com/h/i/A752C35C6D10F1BB>
>
> <http://www.facebook.com/ilikemygosford>
> <http://www.facebook.com/ilikemygosford>
> <http://facebook.com/ilikemygosford><fb_logo08792f.jpeg>
> <http://www.facebook.com/GosfordCityCouncil>
>
> <http://www.twitter.com/gosford_council><twitter_logo907bd8.png>
> <http://twitter.com/gosford_council>
>
> gosford.nsw.gov.au <http://www.gosford.nsw.gov.au/>
>
>
> <enviro_sig5658478883601809937cb81c.gif> <http://thinkbeforeprinting.org/>
>
>
>
>
> *From:* AusNOG [mailto:ausnog-bounces at lists.ausnog.net
> <ausnog-bounces at lists.ausnog.net>] *On Behalf Of *Mark Sergeant
> *Sent:* Wednesday, 3 September 2014 2:52 PM
> *To:* Tony Wicks
> *Cc:* ausnog at lists.ausnog.net
> *Subject:* Re: [AusNOG] {Disarmed} Radius Interim Update Interval
>
> Lowest I’ve done is 5 minutes, largest I’ve seen is many hours. Nowadays
> I’m a fan of a 15 minute inform.
>
> Cheers,
>
> *Mark Sergeant*
> *Operations Manager*
> *Acurus Networks*
>
>
> <image001.jpg>
>
>
>
> *P**:*  +61 3 8376 8720
> *M**: *+61 412 714 263
> *W**:* www.acurus.com.au
>
> DISCLAIMER: This e-mail (including any attachments) may contain
> information which is confidential, proprietary, privileged or private and
> is intended for the sole use of the person(s) to whom it is addressed. If
> this email is sent to you in error, any confidentiality or privilege is not
> wavered or lost. If you are not the intended recipient or the person
> responsible for delivering this message to the intended recipient, please
> notify the sender immediately by return email, delete the email and any
> attachments from your system, destroy any copies and do not use or disclose
> the contents. Any personal information within this email should be handled
> according to the Privacy Act 1988 (Cth). This email is subject to
> copyright, therefore you must not reproduce, communicate or adapt any part
> of it without the written consent of the copyright owner. Any views
> communicated in this email are those of the individual sender, unless
> clearly stated to be the views of a member of Acurus Pty Ltd.
>
>
> On 3 Sep 2014, at 1:47 pm, Tony Wicks <tony at wicks.co.nz> wrote:
>
> I have used between 15 and 60 minutes over the years.
>
> *From:* AusNOG [mailto:ausnog-bounces at lists.ausnog.net
> <ausnog-bounces at lists.ausnog.net>] *On Behalf Of *Tristram Cheer
> *Sent:* Wednesday, 3 September 2014 1:10 p.m.
> *To:* ausnog at lists.ausnog.net
> *Subject:* {Disarmed} [AusNOG] Radius Interim Update Interval
>
> Hi All,
>
> I’m doing some work with freeradius at the mo and looking at our
> accounting interim update interval, We have ours set low but I thought I’d
> ask the group and see what intervals if any others use for radius based
> traffic accounting
>
>
> Cheers
> --
>
>
> Message protected by MailGuard: e-mail anti-virus, anti-spam and content
> filtering.
> http://www.mailguard.com.au/mg
>
> Report this message as spam
> <https://login.mailguard.com.au/report/1KjZ4B5SOp/2TpBusL9HKNi5TpteNbVTO/0.002>
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
> ------------------------------
> Message protected by MailGuard: e-mail anti-virus, anti-spam and content
> filtering.
> http://www.mailguard.com.au
>
>
> The information contained in this email may be confidential.
> You should only disclose, re-transmit, copy, distribute, act in reliance
> on or commercialise the information if you are authorised to do so.
> Gosford City Council does not represent, warrant or guarantee that the
> communication is free of errors, virus or interference.
> Gosford City Council complies with the Privacy and Personal Information
> Protection Act (1998). See Council's Privacy Statement
> <http://www.gosford.nsw.gov.au/about-council/governance-and-strategy/access-to-information/gipa-documents-listing/privacy>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140903/92c8db66/attachment.html>