Hello Robert,
thanks for the careful description of your observations.
If the password log file shows a successful authentication, then I would not
suspect a failure between Radiator and SQL. The password logging happens after
the password has been got from SQL, and toward the end of the authentication
process. After that, it mostly just a matter of getting the reply back to the
NAS.
I suspect that the NAS is not seeing the reply in time, and that might be due
to one of 2 things:
1. The reply is getting lost or dropped. This might be happening if you have a
significant dropped packet rate. However, if this was the case, you would
probably have other problems, so I dont really suspect this.
2. The overall time required to process each transaction (including the time it
waits in the socket buffer) during a heavy load is getting close to the NAS
retransmission timeout. (Many NASs have a default retransmission time of 5
secs). You can deal with this by:
a. Increasing the NAS restransmission timeout to, say 20 secs and/or...
b. Check whether the SQL processing time is unusually long during these times:
try doing some SQL queries on the account or radiusdat tables, and see if they
take a significant time to process. Better still, use the SQL trace program to
see how long each trasnaction is taking. The SQL queries should take a small
fraction of a second. If they are taking a long time (1 sec or more), its time
to do some database tuning. Is it possible that when your operators are using
platypus, their SQL queries are affecting the speed that the SQL server can
reply?
c. Add more CPU power to Radiator and/or SQL. However it seems to me that you
already have sufficient.
Can you send me (privately if you wish)
1. Your current NAS timeout values
2. The average radius request arrival rate at peak times
3. The typical time to do auth and accounting SQL queries at peak time.
Hope that helps.
Cheers.
On Feb 7, 11:48am, Robert Mann wrote:
> Subject: (RADIATOR) Scenario
> We have 2 MS SQL Servers on Dual Pentium Pro's with 512 Megs ram with MS SQL
> v6.5 at our NOC.
>
> 2 Radius Servers on Sparc 5's at our NOC that handles the pops in its area.
>
> 2 Remote Radius Servers on Sparc 5's at another location linked to the NOC
> by a DS3
>
> 2 Remote Radius Servers on Sparc 5's at another location linked to the NOC
> by multiple T-1's
>
> We have approx. 20,000 dialup users spread throughout our coverage area.
>
> Each NAS has a primary a secondary radius server set up for both auth and
> accounting and we are using Platypus for our accounting system.
>
> All of our radius.cfg files are as follows...
>
> ##### Start Of Configuration File #####
>
> Foreground
> LogDir /export/home/radius
> LogFile %L/logfile
> DbDir /usr/private/etc/plat
> include /usr/private/etc/plat/clients
> PidFile /usr/private/etc/plat/pid/radiusd.pid
> Trace 3
>
> <Realm monkeyspank.net>
>
> PasswordLogFileName %L/password.monkeyspank.net
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername tr/-A-Za-z0-9\.\@//cd
>
> <AuthBy File>
>
> </AuthBy>
>
> </Realm>
>
> <Realm kermantel.net>
>
> PasswordLogFileName %L/password.kermantel
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername tr/-A-Za-z0-9\.\@//cd
>
> <AuthBy KERMANPLAT>
> DBSource dbi:Sybase:somehost1
> DBUsername someuser
> DBAuth somepass
>
> DBSource dbi:Sybase:somehost2
> DBUsername someuser
> DBAuth somepass
>
> DefaultReply Service-Type=Framed-User,Framed-Protocol=PPP
> </AuthBy>
> </Realm>
>
> <Realm lightspeed.net>
>
> PasswordLogFileName %L/password.lightspeed
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername tr/-A-Za-z0-9\.\@//cd
>
> <AuthBy PLATTR>
> DBSource dbi:Sybase:somehost1
> DBUsername someuser
> DBAuth somepass
>
> DBSource dbi:Sybase:somehost2
> DBUsername someuser
> DBAuth somepass
>
> DefaultReply Service-Type=Framed-User,Framed-Protocol=PPP
> </AuthBy>
>
> </Realm>
>
>
> <Realm isdn.lightspeed.net>
>
> PasswordLogFileName %L/password.lightspeed.isdn
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername tr/-A-Za-z0-9\.\@//cd
>
> <AuthBy PLATTR>
> DBSource dbi:Sybase:somehost1
> DBUsername someuser
> DBAuth somepass
>
> DBSource dbi:Sybase:somehost2
> DBUsername someuser
> DBAuth somepass
>
> DefaultReply Service-Type=Framed-User,Framed-Protocol=PPP
> </AuthBy>
>
> </Realm>
>
> <Realm test.lightspeed.net>
>
> PasswordLogFileName %L/test
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername tr/-A-Za-z0-9\.\@//cd
>
> <AuthBy PLATTR>
> DBSource dbi:ODBC:somehost1
> DBUsername someuser
> DBAuth somepass
>
> DBSource dbi:ODBC:somehost2
> DBUsername someuser
> DBAuth somepass
>
> DefaultReply Service-Type=Framed-User,Framed-Protocol=PPP
> </AuthBy>
>
> </Realm>
>
> ##### End Of Configuration File #####
>
> The KERMANPLAT, PLATATTR are just minor modified versions of PLATYPUS.
>
> The monkeyspank.net realm is in case the SQL system fails that we have a
> users file that we can authenticate from. The final test.lightspeed.net
> realm is to test the OpenLink Multi Tiered ODBC drivers. Which I must say
> fail miserably under these conditions under any type of load. We are trying
> these in hopes that we can upgrade to MS SQL 7.0 as the Sybase CTLib no
> longer works for MS SQL 7.0.
>
> The problem is this...
>
> Sometimes during peak hours where there is heavy usage we get some failed
> authentication on the user end where Radiator shows successful in the
> logfiles. The only thing that I can come up with is that there is some sort
> of problem between the SQL servers and Radius. It happens to people at all
> locations no matter which radius servers they are in proximity to.
>
> Here is part of a logfile which records the only error's we normally receive
> during these periods...
>
> ##### Beginning Log Entry #####
>
> Sun Feb 7 08:16:31 1999: ERR: do failed for 'insert into radiusdat
> (username, callstart, callend, sessid, userip)
> values ('', 'Feb 7, 99 8:16', 'Feb 7, 99 8:16', '267987926',
> '')': Server message number=2627 severity=14 state=2 line=1
> server=IZANAGI text=Violation of UNIQUE KEY constraint 'UNC_rad_term':
> Attempt to insert duplicate key in object 'radiusdat'.Server
> message number=3621 severity=0 state=0 line=1 server=IZANAGI text=Command
> has been aborted.
> Sun Feb 7 08:16:34 1999: ERR: do failed for 'insert into radiusdat
> (username, callstart, callend, sessid, userip)
> values ('hywood', 'Feb 7, 99 7:22', 'Feb 7, 99 8:16',
> '283527688', '209.165.53.56')': Server message number=2627 severit
> y=14 state=2 line=1 server=IZANAGI text=Violation of UNIQUE KEY constraint
> 'UNC_rad_term': Attempt to insert duplicate key in object
> 'radiusdat'.Server message number=3621 severity=0 state=0 line=1
> server=IZANAGI text=Command has been aborted.
>
> ##### End Log Entry #####
>
> These happen all of the time. I am not real sure why it happens. It
> appears that Radiator try's to enter accounting data multiple times to the
> SQL database and it fails due to the unique key constraint. Does this look
> like the NAS are impatient and are reporting to both Radius servers do to
> slowness in response? What does this mean exactly maybe it will help to
> solve why the auth problems take place. These happen way more often during
> busy periods.
>
> This message is just to see if anyone has any suggestions that might help.
> We are totally open to suggestions at this time. We would really like to
> move to SQL 7.0 so if anyone has had luck with heavy usage and OpenLinks
> drivers I would like to hear your success stories. We also looked at
> Intersolv's SequeLink solution but it is way expensive with this
> configuration some where around 28,000.00 dollars to license 6 clients. I
> am going to test the drivers to check the speed but from what I have heard
> the products are pretty much equal in performance.
>
> Does anyone know if running Intel boxes with NT running Radiator would be a
> performance increase? Our System Administrator would not like this solution
> as he is way pro Sparc but if it would work that is all that matters at this
> point.
>
> Thanks for any and all comments/advise,
> Robert Mann
> Lightspeed Net
>
> ===
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
>-- End of excerpt from Robert Mann
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia Consulting and development
Phone, Fax: +61 3 9598-0985 http://www.open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, external, etc etc etc on Unix, Win95, NT, Rhapsody
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
