(RADIATOR) Multiple Accounting Stop Records
Hugh Irvine
hugh at open.com.au
Thu Oct 18 18:59:33 CDT 2001
Hello William -
As mentioned in my previous email, the very first thing to do is find out
what exactly is happening. In other words, fix the real source of the problem
by finding out why the retransmissions are happening in the first place.
Then, my suggestion would be to change to using an SQL database for your
accounting and only log accounting stops. You can also use an
AcctSQLStatement in the AuthBy SQL clause to make sure you only get a single
copy (there was a posting about this a year or so ago - check the archive).
In this scenario, the configuration file would look like this:
# define AuthBy clauses
.....
<AuthBy SQL>
Identifier SQLAccounting
.....
AccountingStopsOnly
AccountingTable .....
AcctColumnDef .....
......
AcctSQLStatement .....
</AuthBy>
# define Handlers
<Handler Request-Type = Accounting-Request>
AuthBy SQLAccounting
.....
</Handler>
<Handler>
.....
</Handler>
The advantage of doing it this way is that you won't have any post-processing
to do at all - it is all done automatically.
Note that you can always keep a copy of the accounting records in a flat file
too if you would like to keep an archive copy.
hth
Hugh
On Friday 19 October 2001 06:46, William Hernandez wrote:
> Hello everyone,
>
> After some checking we've found out that the TotalControls cannot
> be configured to not retransmit accounting records. The problem
> is that we have these multiple stop records in the detail file
> which create a billing problem for us. Right now I run a perl
> script to cleanup the detail file, but I'm wondering whether the
> following will work.
>
> The idea is to only write to the accounting detail files the
> accounting start records and the accounting stop records that
> have an Acct-Delay-Time of 0. All other accounting requests would
> be ignored.
>
> Right now I use Handlers. In this setup I would replace each
> Handler in my current radius.cfg with 3 Handlers. This would be a
> one time pain, but I wouldn't have to run the perl script and
> everything would be right in the radius.cfg.
>
> Here goes:
>
> <Handler Realm=domain.com Request-Type=Access-Request>
> as before.....with the AcctLogFileName line removed
> </Handler>
>
> <Handler Realm=domain.com Request-Type=Accounting-Request
> Acct-Status-Type=1>
> AcctLogFileName /var/log/radacct/detail
> </Handler>
>
> <Handler Realm=domain.com Request-Type=Accounting-Request
> Acct-Status-Type=2 Acct-Delay-Time=0>
> AcctLogFileName /var/log/radacct/detail
> </Handler>
>
> Does it make sense? Do I need an AuthBy clause if I'm only
> handling Accounting-Request?
>
> Thanks in advance,
> William
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Monday, August 27, 2001 7:43 PM
> To: William Hernandez; Radiator
> Subject: Re: (RADIATOR) Multiple Accounting Stop Records
>
>
>
> Hello William -
>
> What you are seeing is NAS retransmissions because the NAS has
> not received
> an Accounting-Response in reply to an Accounting-Request (or
> possibly a NAS
> bug). The radius retransmission timeout on the NAS must be set to
> 60 seconds
> if that is what you are seeing in the log file.
>
> Note that it is pretty simple to recognise the retransmissions
> simply by the
> fact that the Acct-Delay-Time is not 0. In other words, the first
> transmission of an accounting packet will have an Acct-Delay-Time
> of 0, the
> second will have an Acct-Delay-Time of whatever the radius retry
> timeout is
> set on the NAS, the third will have an Acct-Delay-Time of twice
> the radius
> retry timeout, etc. etc.
>
> The way to find out what is happening is to check a trace 4 debug
> from
> Radiator to verify that the first accounting packet in the series
> is indeed
> being replied to, and then use your favourite packet sniffer
> along the
> transmission path back to the NAS to verify whether the reply is
> getting back
> to the NAS.
>
> In our experience the vast majority of problems like this are the
> direct
> result of saturated links somewhere in the transmission path that
> cause
> packets to be dropped.
>
> hth
>
> Hugh
>
> On Tuesday 28 August 2001 04:04, William Hernandez wrote:
> > We're having a problem with multiple accounting stop records.
>
> The
>
> > stop records have exactly a 1 minute difference between them,
> > ..i.e, a stop record at 09:00:00 is followed by another stop
> > record at 09:00:01.
> >
> > We starting seeing these multiple accounting stop records about
>
> a
>
> > month ago. This coincides with some changes we made to our
> > systems, namely, upgrading to RedHat 7.1, upgrading to Radiator
> > 2.18.1, and switching to TotalControl (HiperArc) NASes.
> >
> > I need help determining why we're getting there multiple stop
> > records. Everything was working fine with Radiator 2.16 and
>
> with
>
> > the Ascend Maxes we were previously using.
> >
> > I found some messages in the archives about Acct-Delay-Time,
>
> but
>
> > they're rather old and had to do with Radiator 2.14 and MAXes.
> > The manual seems to indicate that the default value of
> > Acct-Delay-Time is 0, but as you can see from the accounting
>
> log
>
> > the second stop record has a value of 60 which is exactly the 1
> > minute difference between stop records that we're seeing.
> >
> > In this a Radiator problem or a Total Control problem or should
>
> I
>
> > be looking elsewhere.
> >
> > Thanks in advance.
> >
> > William Hernández
> > ESS/PR Webmasters
> > San Juan, P.R.
> > Tel: 787-723-5000
> > Fax: 787-722-6242
> >
> > -------------------------From the dictionary
> > file----------------------
> > ATTRIBUTE Acct-Delay-Time 41 integer
> >
> > -------------------------From the Accounting detail
> > file-----------
> > Wed Aug 15 08:59:29 2001
> > User-Name = "pijuan"
> > NAS-IP-Address = 208.249.78.12
> > NAS-Identifier = "208.249.78.12"
> > Acct-Status-Type = Stop
> > Acct-Session-Id = "35455064"
> > Acct-Delay-Time = 0
> > Acct-Authentic = RADIUS
> > Service-Type = Framed-User
> > NAS-Port-Type = Async
> > NAS-Port = 549
> > USR-Modem-Training-Time = 17
> > USR-Interface-Index = 1805
> > Chassis-Call-Slot = 3
> > Chassis-Call-Span = 2
> > Chassis-Call-Channel = 37
> > Unauthenticated-Time = 4
> > Calling-Station-Id = ""
> > Called-Station-Id = "6419000"
> > VPN-ID = 0
> > Modulation-Type = v90Digital
> > Simplified-MNP-Levels = ccittV42
> > Simplified-V42bis-Usage = ccittV42bis
> > Connect-Speed = 48000_BPS
> > Framed-Protocol = PPP
> > Framed-IP-Address = 63.124.21.132
> > VTS-Session-Key =
> > "W<228>|<171><29><244><232><202><246>4;<208><219><132>
> > "<173>"
> > Call-Arrived-time = 177418488
> > Call-Lost-time = 177425969
> > Acct-Session-Time = 7464
> > Acct-Terminate-Cause = User-Request
> > Disconnect-Reason = 8
> > Speed-Of-Connection = 48000
> > Acct-Input-Octets = 1050588
> > Acct-Output-Octets = 2531954
> > Acct-Input-Packets = 7333
> > Acct-Output-Packets = 7891
> > Timestamp = 997880369
> >
> > Wed Aug 15 09:00:29 2001
> > User-Name = "pijuan"
> > NAS-IP-Address = 208.249.78.12
> > NAS-Identifier = "208.249.78.12"
> > Acct-Status-Type = Stop
> > Acct-Session-Id = "35455064"
> > Acct-Delay-Time = 60
> > Acct-Authentic = RADIUS
> > Service-Type = Framed-User
> > NAS-Port-Type = Async
> > NAS-Port = 549
> > USR-Modem-Training-Time = 17
> > USR-Interface-Index = 1805
> > Chassis-Call-Slot = 3
> > Chassis-Call-Span = 2
> > Chassis-Call-Channel = 37
> > Unauthenticated-Time = 4
> > Calling-Station-Id = ""
> > Called-Station-Id = "6419000"
> > VPN-ID = 0
> > Modulation-Type = v90Digital
> > Simplified-MNP-Levels = ccittV42
> > Simplified-V42bis-Usage = ccittV42bis
> > Connect-Speed = 48000_BPS
> > Framed-Protocol = PPP
> > Framed-IP-Address = 63.124.21.132
> > VTS-Session-Key =
> > "W<228>|<171><29><244><232><202><246>4;<208><219><132>
> > "<173>"
> > Call-Arrived-time = 177418488
> > Call-Lost-time = 177425969
> > Acct-Session-Time = 7464
> > Acct-Terminate-Cause = User-Request
> > Disconnect-Reason = 8
> > Speed-Of-Connection = 48000
> > Acct-Input-Octets = 1050588
> > Acct-Output-Octets = 2531954
> > Acct-Input-Packets = 7333
> > Acct-Output-Packets = 7891
> > Timestamp = 997880369
> >
> > ===
> > Archive at http://www.open.com.au/archives/radiator/
> > Announcements on radiator-announce at open.com.au
> > To unsubscribe, email 'majordomo at open.com.au' with
> > 'unsubscribe radiator' in the body of the message.
>
> --
> Radiator: the most portable, flexible and configurable RADIUS
> server
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS
> X.
> -
> Nets: internetwork inventory and management - graphical,
> extensible,
> flexible with hardware, software, platform and database
> independence.
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list