nanog mailing list archives

Re: Ratio between Number of Radius Accouting Server and Number of Radiuis Authentication Server


From: Joe Shen <joe_hznm () yahoo com sg>
Date: Fri, 4 May 2007 10:23:31 +0800 (CST)


We establish two server farm which service on two IP. 
BAS use that two IP as AAA server addresses.
Currently , number of accouting server is much less
than authentication server although DB connection
allocated to accouting server is nearly the same to
authentication servers.

The problem is,  radius server responding speed may
become very slow ( more than 100s) at peak time. some
of radius accouting packets overflows when they are
sent to radius server process queue. As radius
responding speed is slow, BAS retransmit those packets
in queue, the system performance worsen for 
duplicated packets. some dial-session is not closed
normally because Accouting-off packets are lost or
overflowed. 

I plan to deal with the problem by starting at
incoming packets rate measurement, and server
structure  optimization. But, there seems to be too
few material available. 

Joe


--- K K <kkadow () gmail com> wrote:


On 5/3/07, Joe Shen <joe_hznm () yahoo com sg> wrote:
Is there any recommendation on Ratio between
number of
 radius accouting server and number of radius
authentication server, if accouting and
authentication
are executed by different hardware platform ?

I generally deploy just two accounting servers,
because (most)
RADIUS-enabled devices deal with
caching/retransmitting accounting
data in a reasonable fashion if the accounting
servers are slow or
unresponsive -- users won't notice if Accounting is
slow, quite the
opposite of Authentication.

Many (most?) RAS/VPN/etc devices only support
configuring two RadAcct
servers, even devices which offer up to 4 total auth
servers might
only allow 2 for accounting.  Also keep in mind that
some devices use
a primary/backup configuration, while other
implementations send all
Accounting records to *both* servers at all times.


Is there any way to estimate the burst rate of
radius
protocol packet in ISP network?

You can calculate your burst rate by either
post-processing the RADIUS
event logs from the servers, or from NetFlow data. 
The real-world PPS
rate and BPS for RADIUS should be very low, even on
a busy ISP -- our
biggest problem with RADIUS traffic isn't the
traffic itself, but
rather giving the protocol priority on congested WAN
links so it isn't
dropped by an oversubscribed router.  Dropped
packets are primarily a
problem for authentication requests, particularly if
you're using
RADIUS with SecurID (due to the built-in
multi-second delay ACE/Server
forces for all authentication requests, RADIUS or
otherwise).

Kevin

--
Moderator, unofficial RSA ACE/Server + SecurID users
group:
http://tech.groups.yahoo.com/group/securid-users/




      
__________________________________ 
Yahoo! Movies - Search movie info and celeb profiles and photos. 
http://sg.movies.yahoo.com/


Current thread: