RE: (RADIATOR) Multiple Accounting Stop Records
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:[EMAIL PROTECTED]] 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
Re: (RADIATOR) Multiple Accounting Stop Records
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:[EMAIL PROTECTED]] 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
Re: (RADIATOR) Multiple Accounting Stop Records
Hello William and all orher! WH We're having a problem with multiple accounting stop records. The WH stop records have exactly a 1 minute difference between them, WH .i.e, a stop record at 09:00:00 is followed by another stop WH record at 09:00:01. As I see - all this records have one same value of attribute Acct-Session-ID. We was had same problem, but localise it on billing level - i.e. query from accounting base (MySQL, Linux) to billing base (IB-6, WinNT)copy only first record from all other with same Acct-Session-ID. -- Best regards, Alexeymailto:[EMAIL PROTECTED] === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
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 = W228|171292442322022464;208219132 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 = W228|171292442322022464;208219132 173
