Hello Rob -
On Tue, 23 May 2000, rob wrote:
> Hi,
> We're having a few problems with Radiator dropping radius requests from
> our POP routers, and Customer routers. Around 4,000 Routers in all.
>
> Running Radiator v2.13 on a Sun Netra T 1120 (single 300Mhz UltraSPARC-II
> CPU), 128Mb RAM, Perl v5.005_02, using a Sybase SQL database on another Sun
> box over 100BaseTX/FDX switched ethernet.
>
> The database can perform upwards of 60 transactions a second
>
> I have a plan for splitting up the load on the Radius server, as Perl is
> not reliably multi-threaded, we cant use that just yet, but we can have
> several instances of Radiator running.
>
> I'm posting this out to see how viable this is, and if anyone else has a
> similar setup, also as a plan if anyone else wants to increase performance
> similarly.
>
> Current config;
> - Single radiator process, doing both Authentication and Accounting
>
> Option 1;
> - Set up 4 new IP Aliases on the ethernet card
> - On each IP Alias, have a new Radiator process bound to it, servicing both
> Authentication and Accounting
> - Reconfigure all Radius clients to use a Timeout of say 2 seconds, and a
> Retry of 2, and to use the new radius servers
> - Let the Unix server do the processor scheduling between the Radiator
> processes
>
> Option 2;
> - Same as above, but for each IP Address, launch two Radiator processes.
> One for the Authentication port, and one for the Accounting port.
>
>
> A few questions;
> - Are there going to be any problems with having 5 or 10 simultaneous
> connections to the Sybase database from the same machine?
> - Is there a better way to improve performance with Radiator ?
>
Before embarking on either of the options outlined above, I think you should
ascertain exactly where the problem lies. If the Sun that is running the
Radiator process is CPU-bound to the point of dropping packets, adding more
Radiator processes to the box will only make things worse. I would suggest
first of all verifying the CPU load on the Sun to see how the system itself is
performing. I would then check Radiator itself to see how it is performing -
how many radius requests per second it is handling and where the processing
time is being spent. The best method for doing this is to run with a Trace 4
debug and check the logfile to see what is going on.
I would then make sure that the radius packets are really on the wire (with
tcpdump or snoop or your moral equivalent) both on this host and on a seperate
host on the same segment (you may have to tweak the switch to get it to forward
all packets).
I will be happy to check the trace 4 logs with you, but I will need a copy of
your configuration file (no secrets) to understand what is going on.
In general, your mention of two Radiator processes, one for Authentication and
the other for Accounting is a good one, and to do this you will need the latest
version of Radiator (2.15). As a more reliable approach, many of our customers
run multiple Radiator hosts, each with two Radiator processes as above, and
either configure the NAS equipment differently to use one or the other (with
the second as backup), or they employ a load balancer of some description in
front to distribute the load.
BTW - there are some performance figures in the latest manual and there are
some descriptions of largish Radiator installations on the web site:
http://www.open.com.au/radiator
regards to the crew at vicone
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
