(RADIATOR) FW: Load Balancing

Harrison Ng Harrison_Ng at hksmartone.com
Mon Sep 10 02:23:30 CDT 2001


BTW, can those time related parameters accepts milliseconds, such as
RetryTimeout, FailureBackoffTime.

Harrison



> -----Original Message-----
> From:	Harrison Ng 
> Sent:	Monday, September 10, 2001 3:21 PM
> To:	'radiator at open.com.au'
> Subject:	Load Balancing
> 
> Hi,
> 
> We are using Ericsson GSN, the primary and secondary failover timer in GSN
> is restricted to merely 6 seconds. After these 6 secs, it drops the call.
> 
> So our radiator server need to respond very fast, I mean fast in doing
> username/password authentication, accounting logging, ip address
> allocation and forward accounting information to 3rd party business
> partners and reply back to GSN at last. If we divide 6 secs into 2 halves,
> there will be only 3 secs for primary radius, and 3 secs for secondary
> radius.
> 
> Our first question is it possible to change the behaviour (perhaps an
> extra parameter) of <AuthBy ROUNDROBIN, VOLUMEBALANCE, LOADBALANCE> so
> that when radius proxy does not receive response from the first radius
> server, then just stop it and let the radius server marked failure and
> reply nothing to GSN. Let the radius server sit still until
> FailureBackupoffTime is reached. Do not even try to forward request to the
> second listed, until the list is exhausted.
> 
> Second can we set the timeout value (perhaps to zero) for the very first
> accounting forward packet. The RetryTimeout only suitable for
> retransmitting packet. Lost accounting packet is not a concern to us, as
> long as the radius server work very fast.
> 
> We tried optimize every things such as using radius proxy to distribute
> loading to several radius server, put database server in another unix box,
> field indexing, lots of memory and etc. Maybe our question is a bit
> strange. Perhaps someone can suggest us a workaround. Thanks.
> 
> 
> Regards,
> Harrison
> SmarTone BroadBand Services Ltd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20010910/96aef797/attachment.html>


More information about the radiator mailing list