RE: Accounting causing trouble?

Thu, 23 Apr 1998 13:05:38 -0400

Thanks for the info. I've changed the timeout from 6 to 8, and after a
bunch of failures, it eventually calms down. Every once in a while an odd
SQL request will come by. The original problem very well could have been
Radius being bogged down with accounting packets. We are running Radius on
the same machine as the SQL Server. Is this strongly discouraged?

Heres the big picture: Two Radius servers on separate machines(p-166, Dual
P-200). Each machine is also running SQL Server. Both Radius DSNs point to
the primary (p-166) server which replicates the user information (not
accounting, due to machine stress) to the secondary (P-200's) server in
event of emergency. Should we have a separate machine dedicated to running
the Radius Service? SQL Server has been an extreme pain with little
failures here and there, but I think our size will not allow us to go back.
During peak times the primary server is feeling quite a bit of stress. What
is the general opinion on running a SQL database on mirrored hard drives?
Is the extra write cycle killing performance?

Thanks again,


-----Original Message-----
From: Dale E. Reed Jr. []
Sent: Wednesday, April 22, 1998 2:03 PM
Subject: Re: Accounting causing trouble? wrote:
> We are now trying to get it back to working order. I pointed 4 Maxs to
> authenticate to Radius and send no accounting info. It works. I pointed
> one Max's accounting to Radius and got this:

Most likely the problem is that your RADIUS accounting timeout is
set way to low, and therefore eventually flooding RadiusNT with
requests. Make sure your RADIUS timeouts (both auth and acct) are
set to something like 5-7, and your problems should clear up.

> Resp Time: 62 Auth: 9/0 -> 9 Acct: 0/1/0 -> 1
> radrecv: Request from host ce657114 code=4, id=39, length=44
> NAS-Identifier =
> NAS-Port-Type = Async
> Acct-Status-Type = 7
> Acct-Delay-Time = 6
> SQL Statement: INSERT INTO Calls
> (CallDate,NASIdentifier,AcctStatusType,AcctDel
> ayTime, UserName) VALUES (GetDate(),'',7,6,'NULL')
> ODBC: SQLExecDirect Error 233:
> [Microsoft][ODBC SQL Server Driver][SQL Server]The column NASPort in
> Call
> s may not be null.
> Resp Time: 94 Auth: 9/0 -> 9 Acct: 0/2/0 -> 2
> They come in groups of 4 which I assume is the retry number in the Max.
> did Radius miss the NASPort column?

This is some silly idea that Ascend had to trim down the records
if they are back logged. They've since gone to something a little
better. The above timeout issue will resolve this as well.

--Dale E. Reed Jr.  (       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs Internet Solutions for Today  |

---------------------------------------------------------- RadiusNT Mailing List