[RADIATOR] Radiator LoadBalancing Optimization

[Michael Hulko]

Thanks for the response.... too bad though.  Unfortunately, we can only have one radius server instance per NAS (and a backup), but this particular NAS supports the radius proxy clients which are the problem.

M

On 2013-09-13, at 6:39 AM, Sami Keski-Kasari wrote:

> Hello Michael,
> 
> CachePasswords doesn't work with EAP, it works only with PAP authentication. So it won't help you in this situation.
> 
> My advice is that you should add more hosts for authentication or if you have a lot of accounting traffic then it might a good solution if you have separate instances for accounting and authentication.
> 
> Best Regards,
> Sami
> 
> On 09/12/2013 05:37 PM, Michael Hulko wrote:
>> In a previous discussion regarding Loadbalancing radius requests, we instituted the <AuthBy EAPBALANCE> method to proxy requests to departmental radius servers.  We have been running this method for close to 6 months and have been pretty satisfied with the result.  Of late, however, the client traffic has increased, and the time for an authentication to complete is a tad longer than the users are willing to accept.  My reading of the documentation provided by OSC, suggests the use of CachePasswords; CacheOnNoReply; and CachePasswordExpiry would assist in the performance.
>> 
>> I understand that the trade-off of implementing these features is memory.  So to that end, first, is anyone using these parameters?.  What is the number of clients supported and related memory usage?  I anticipate approx. 3-4K simultaneous users for the particular AuthBy clause.  What would be the recommended Password expiry timer be?
>> 
>> Any info would be appreciated.  Below is the current config snippet of the AuthBy we are using.  User connections are retried after a 45 min. period.
>> 
>> #IVEY
>> # Proxies auth requests to the IVEY IAS radius servers using a loadbalance algorithm.
>> <AuthBy EAPBALANCE>
>>  	Identifier IVEY
>>         Retries 3
>>         RetryTimeout 5
>>         FailureBackoffTime 20
>>         AuthPort 1645
>>         AcctPort 1646
>>         Secret xxxxx
>>         LocalAddress xxxxxxxxxx
>>  #
>>         <Host xxxxxxx>
>>         </Host>
>>  #
>>         <Host yyyyyyyy>
>>         </Host>
>>  #
>>         <Host zzzzzzzz>
>>         </Host>
>> 
>> </AuthBy>
>> 
>> 
>> The last server is the slower of the 3 hosts available which I believe is the bottleneck.
>> 
>> Thanks
>> 
>> 
>> Michael Hulko
>> Network Analyst
>> 
>> Western University Canada
>> Network Operations Centre
>> Information Technology Services
>> 1393 Western Road, SSB 3300CC
>> London, Ontario  N6G 1G9
>> 
>> tel: 519-661-2111 x81390
>> e-mail: mihulko at uwo.ca <mailto:mihulko at uwo.ca>
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>> 
> 
> 
> -- 
> Sami Keski-Kasari <samikk at open.com.au>
> 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
> NetWare etc.



Michael Hulko
Network Analyst

Western University Canada
Network Operations Centre
Information Technology Services
1393 Western Road, SSB 3300CC
London, Ontario  N6G 1G9

tel: 519-661-2111 x81390
e-mail: mihulko at uwo.ca <mailto:mihulko at uwo.ca>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20130913/f3a0b8b1/attachment.html