question on algorithm for radius based accouting
nanog at ian.co.uk
Tue Aug 21 05:39:59 UTC 2007
On 19 Aug 2007, at 02:57, Hugh Irvine wrote:
> On 17 Aug 2007, at 23:35, Alex Rubenstein wrote:
>>> Seriously, can I also add that RADIUS interim accounting is almost
>>> essential in this scenario. Real world accounting and session
>>> mis-match badly making it almost mandatory to use interim accounting
>>> records to get an approximation of what the figures look like from
>>> a billing perspective. I'll also add "watch out for missing records"
>>> - I've found RADIUS to be the lossiest network protocol per foot of
>>> cabling that I've ever used.
>> I can't say I've seen this.
> This sort of thing tends to happen in "wholesale" operations where
> the downstream has a congested link.
I've mostly seen it when loss of a link (voice trunks, L2TP tunnels)
causes a lot of sessions to bounce at once. I possibly misspoke by
saying RADIUS protocol when I probably ought to have said RADIUS
subsystem. In these cases I strongly suspect a limit on buffer space
at the NAS (or equivalent) end of things for keeping track of ACKs. I
definitely used to see this on Max 4000s when I used to have a voice
carrier who had a habit of dropping several trunks at a time losing
me 100s of sessions simultaneously - it'd only be a few packets but
it was enough to make the books not balance which is why it got
spotted. And as the physical links involved were often in the 10s of
>> Having collected hundreds of millions of radius packets in my years
>> (hell, we were running PM-2e's in 1996), and have written several
>> accounting collectors, I can't say I agree.
>> If you follow the specifications properly, unless you have issues
>> the transmitting device (read: BUG), RADIUS accounting has always
>> good to me.
> You can sometimes improve this situation by transporting the RADIUS
> requests over some form of TCP tunnel.
>> And, I've not seen the behavior you describe that requires interim.
> DSL and/or cable systems usually have long-held connections that
> often cross billing boundaries - interim accounting is useful in
> this scenario.
> Dialup connections are not usually long enough to warrant interim
More information about the NANOG