(RADIATOR) Lost Stop Records

Tue Jun 12 20:02:03 CDT 2001

Hello Scott -

On Wednesday 13 June 2001 02:13, Scott Robinson wrote:
> Hi:
>
> We're currently experiencing a 30% to 50% loss of stop records.  We have
> 45 NAS's (Cisco 5300's and Cisco 5800's) with three different telco's.
> We've determined that stop records are being lost on all 45 NAS's. We
> end up with a lot of orphaned records in our RADONLINE table as a result
> of the lost stop records.
>
> Our radius accounting server is on a separate machine with lots of
> horsepower (running > 80% idle).  I've checked our logs (Trace level 4)
> and there are no errors in processing the stop records it does receive.
> Anybody know of anything I can check before I try bugging the telcos
> (Dealing with Canadian telco's makes the Middle East peace process look
> like a walk in the park).  I know I can place a snooper to see if the
> packets are being received but we process +500,000 logins per day.  If I
> am forced to go to the telcos, is there something I can specifically ask
> them to look for?
>

Well, there are at least three possibilities:

First, the stop packets are getting to the Radiator machine, but are not 
being processed (unlikely, but this can sometimes happen with incorrect 
configuration files). Easiest to check with a sniffer and compare it with a 
trace from Radiator.

Second, the stop packets are being lost somewhere in transit. Again unlikely, 
unless you are also losing similar numbers of logins and starts. The easiest 
way to check is by doing test logins to your own phone numbers and verifying 
that you get on first try and that the accounting is correct. Of course you 
need to do this during busy periods when you can expect to have problems. And 
note that saturated links are a very common cause of dropped packets, 
especially as Radius is a UDP protocol.

Third, the stop packets are not being generated by the NAS equipement in the 
first place. Sadly, NAS bugs are not uncommon, but it would be surprising if 
all 3 of your providers had the same NAS bugs (but stranger things have 
happened).

My suggestion would be to set up a test dialin programme to run every 15 
minutes to a selected number of your telcos' POP's and produce sniffer output 
and Radiator trace data that you can then check to see where the problems are.

Once you have some solid data, you can go to your providers with your 
grievances supported by good documentation.

hth

Hugh

-- 
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' witFrom owner-radiator at open.com.au Tue Jun 12 18:41:15 2001
Received: (from majordomo at localhost)
	by server1.open.com.au (8.11.0/8.11.0) id f5CNfFj21664
	for radiatorzz-list; Tue, 12 Jun 2001 18:41:15 -0500
X-Authentication-Warning: server1.open.com.au: majordomo set sender to owner-radiator at open.com.au using -f
Received: from entoo.connect.com.au (entoo.connect.com.au [192.189.54.8])
	by server1.open.com.au (8.11.0/8.11.0) with ESMTP id f5CNfDD21660
	for <radiator at open.com.au>; Tue, 12 Jun 2001 18:41:14 -0500
Received: from hugo (acc21-ppp18.mel.dialup.connect.net.au [210.10.140.18])
	by entoo.connect.com.au (Postfix) with SMTP
	id 08EBCDE3E4; Wed, 13 Jun 2001 11:33:28 +1000 (EST)
From: Hugh Irvine <hugh at open.com.au>
Reply-To: hugh at open.com.au
Organization: Open System Consultants
To: "Kitabjian, Dave" <dave at netcarrier.com>,
   "'Radiator List'" <radiator at open.com.au>
Subject: Re: (RADIATOR) Safe to <AuthLog FILE> to AcctLogFileName?
Date: Wed, 13 Jun 2001 11:20:57 +1000
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="iso-8859-1"
References: <F55475F2CB7AD411BA9700D0B747AFDE779A23 at lnt4exch.netcarrier.net>
In-Reply-To: <F55475F2CB7AD411BA9700D0B747AFDE779A23 at lnt4exch.netcarrier.net>
MIME-Version: 1.0
Message-Id: <0106131120570C.00904 at hugo>
Content-Transfer-Encoding: 8bit
Sender: owner-radiator at open.com.au
Precedence: bulk

Hello Dave -

On Wednesday 13 June 2001 06:08, Kitabjian, Dave wrote:
> We want to add some "Accounting" records of our own to log, for example,
> when and why users are rejected access. Because we already have a
> sophisticated system in place for collecting accounting data, parsing it,
> and making it available to our TSR's via VB, we want to use the same
> channel to collecting this new data.
>
> Using <AuthLog FILE> and a custom FailureFormat including %r, %0 and %1,
> this works very nicely :) The question is...
>
> Is it safe to write to the same file as AcctLogFileName? I guess another
> way of asking is, is the AuthLog FILE write operation atomic?
>

You are really asking two different questions. In answer to the first 
question above, yes a single Radiator process opens, writes, and closes every 
file it uses for every operation. Hence it is safe to rename, move, write to 
from different clauses, etc.

> The reason I'm concerned is because now, for the first time, I'll have two
> processes accessing that file at once; and since our Authentication and
> Accounting are handled by separate Radiators, and the AuthLog is used by
> Authentication and the AcctLogFileName is used by Accounting, corruption
> could occur.
>

In answer to this second question, no Radiator does no file locking, so 
having two processes writing to the same file could certainly cause problems.

In answer to your implied question, you should either use different files, or 
you should use <AuthLog SQL> instead.

hth

Hugh

-- 
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.
h
'unsubscribe radiator' in the body of the message.