(RADIATOR) Server load balanced radius service - suggestions please

[Hugh Irvine]

Hello Alex -

As Claudio has already mentioned, the load balancer should be  
transparent to the Radius server.

regards

Hugh


On 11 Apr 2006, at 21:16, Alex Sharaz wrote:

> Hi,
> We are looking at implementing 802.1X wired authentication on our  
> campus
> network starting with our halls of residence.
>
> With this in mind I'm looking at providing a resilient radius service
> based round the foundry ServerironXL load balancing platform and a
> number of Linux boxes running Radiator. This setup will support all  
> our
> Radius authentication requirements ranging from dial-in service to web
> cache authentication to 802.1X wired and wireless.
>
> All radius requests are directed at a Virtual IP address handled by a
> pair of Serveriron platforms (running in active/standby mode) which  
> then
> forward the request off to a Radiator server based upon some form of
> load balancing algorithm (round-robin, least connection ..etc). Sticky
> persistence ensures that once an incoming request from a particular
> RAS-Client connects to a particular Radiator server subsequent
> connections go to the same server.
>
> I've got the above working quite happily for one or two switches  
> and our
> web caches but am wondering how to get my configuration to scale up to
> covering a LOT of switches.
>
> My config file used to have a number of client statements - 1 per  
> switch
> and then a handler clause that used a Client-Identifier argument of  
> the
> form
>
> <Client-Identifier=HP*  NAS-Ip-Address=a.b.c.* .... other args >
>
> in order to group manufacturer/service  types in a particular address
> space.
>
> With the load balanced solution however, the client-Identifier is  
> always
> going to be related to the ServerIron load balancing device and not  
> with
> the edge device so, as far as I can see, I'm going to have to move  
> over
> to specifying handlers based upon the NAS-Ip-Address e.g.
>
> <Handler NAS-Ip-Address=a\.b\.c\.d realm=hull\.ac\.uk>
> ...
> </Handler>
>
> Etc....
>
> That's an awfully large config file if I'm going to have to specify
> individual IP addresses. I did initially think about using the
> ClientListSQL but I don't think I can use that in this situation.
>
> I do need to group things based upon manufacturer type.
>  For example, HP support radius accounting and Foundry don't so  
> I've got
> a handler that processes accounting records from hp switches. For out
> Foundry kit, I use a pre processing/post auth hook combination to get
> some form of information regarding the user into a database.
>
> Anyone else load balancing radius requests into multiple Radius  
> servers?
>
>
> How do you manage/group large numbers of dissimilar devices.
>
> Alex
>
>
>
>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.