North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: K K
  • Date: Thu May 03 14:02:15 2007
  • Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V+eaKkl8jXch30sliobPT0We+R7CECdU7cBPsD6PfhJbwYIpyGRWMAFP1WtZkXhnpj+w5qEU8mSyxlO078mayyN24pJwL6gS1Dham04p7T1Z+5T1IhxXkAmkyn9/Jk8NqaOWlbcHaLO3K4OjNSapSGxsjaaXZ7ePccx4Mda43ao=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EbIGW5Y2lO/+JRQvdROYmgrJR1i7FogucG0rLw/bVLM7P94dq5NGLeFjQS4U5IYw9lX4mdLGTmRi8eCQLtrXXKXsNOonXuimiANxJUQ6rrg/+HckHaByP+gftdyXaVekya39ikaurM96xI0EpiNM8Ejb0opScE8sDCfBYhsv05w=

On 5/3/07, Joe Shen <[email protected]> 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/