(RADIATOR) Load balancing radiator part 2

[Hugh Irvine]

Hello Alex -

I should have been a bit more precise in my previous comments.

The loadbalancer you are using I suspect is doing source/destination  
address pair load distribution - ie. all of the requests from a  
particular NAS are going to the same target Radiator host.

Per-request load balancing will not work with EAP due to the state  
that is maintained by the target Radiator host while processing a  
series of EAP radius requests, which is what I was referring to.

regards

Hugh


On 7 Jun 2006, at 06:23, Alex Sharaz wrote:

> Chaps,
> As of yesterday we've got a Foundry serveriron providing a load  
> balanced
> RADIUS service against 4 radiator servers that works irrespective the
> authentication type that's thrown at it.
>
> I'm currently using eap-peap/eap-mschapv2 and eap-ttls /mschapv2  
> against
> it from a number of ras clients and it works a treat
> Alex
>
>
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Thursday, April 27, 2006 6:41 AM
> To: Alex Sharaz
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) Load balancing radiator part 2
>
>
> Hello Alex -
>
> As you have discovered, you can loadbalance simple radius requests,
> because they are single packet send, single packet response.
>
> However, you have also discovered that you cannot do the same thing
> with EAP, due to the multiple exchanges of radius requests required
> for EAP. Therefore you cannot use loadbalancing for EAP.
>
> regards
>
> Hugh
>
>
> On 27 Apr 2006, at 02:43, Alex Sharaz wrote:
>
>> Chaps,
>>
>> A while back I sent a mail message to the list about load balancing
>> auth/accounting to multiple radiator servers via a serverironXL box.
>>
>> The config at the time had the serveriron performing source address
>> translation so all the radiator server saw from a client point of  
>> view
>> was the ip address of the serveriron.
>>
>> I've now configured the serveriron not to perform source address
>> translation and each radiator server now sees the ip address of the
>> ras
>> client.
>>
>> Well, it sort of works.
>>
>> Our web caching service is configured to use radius pap auth and that
>> works just fine via the assigned virtual ip address for the load
>> balancing radius service.
>>
>> Using a dot1x client (Meetinghouse and the Odyssey, one on a laptop
>> and
>> one of a desktop) I can configure a switch to point to each of the
>> real
>> servers in succession and eap-ttls /mschapv2 and eap-peap/eap- 
>> mschapv2
>> both work just fine
>>
>> However, if I go via the vip assigned to the load balanced service  
>> for
>> either of the eap-XX methods, you get prompted for a userid and then
>> nothing. The clients time out and ask for the userid again a  
>> couple of
>> times and then give up.
>>
>> In the radiator logfile, I've got single line entries ( Resuming
>> session
>> for Radius:context......)
>> that I don't see if I go directly to the real servers.
>>
>> It only affects the eap type connections. I'm running radiator 3.14
>> with
>> a patch set from 07/04/06
>>
>> Is there anything else I should be configuring at the Radiator end?
>> Alex
>>
>>
>> Tue Apr 25 12:38:06 2006: DEBUG: Handling with Radius::AuthFILE:
>> eapAuth
>> Tue Apr 25 12:38:06 2006: DEBUG: Handling with EAP: code 2, 9, 25
>> Tue Apr 25 12:38:06 2006: DEBUG: Response type 1
>> Tue Apr 25 12:38:06 2006: DEBUG: Resuming session for
>> Radius::Context=HASH(0x9d9147c)
>>
>> Tue Apr 25 12:38:06 2006: DEBUG: EAP result: 3, EAP TTLS Challenge
>> Tue Apr 25 12:38:06 2006: DEBUG: AuthBy FILE result: CHALLENGE, EAP
>> TTLS
>> Challenge
>> Tue Apr 25 12:38:06 2006: DEBUG: Access challenged for
>> anonymous at hull.ac.uk: EAP TTLS Challenge
>> Tue Apr 25 12:38:06 2006: DEBUG: Packet dump:
>> :******************************************************************** 
>> *
>
>> ********************
>> To view the terms under which this email is distributed, please go
>> to http://www.hull.ac.uk/legal/email_disclaimer.html
>> ********************************************************************* 
>> *
>
>> *******************
>
>
> 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.
>
> ********************************************************************** 
> *******************
> To view the terms under which this email is distributed, please go  
> to http://www.hull.ac.uk/legal/email_disclaimer.html
> ********************************************************************** 
> *******************


NB: I am travelling this week, so there may be delays in our  
correspondence.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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.