[RADIATOR] Loadbalancing requests from Proxy
Christopher Bongaarts
cab at umn.edu
Fri May 17 11:50:44 CDT 2013
IIRC, this is the symptom we saw when our wireless controllers weren't
returning all of the State attributes (see the thread from Neil at
Iowa). For diagnosis, bump your Trace level up to 4 for a while, and
observe the State attributes being sent and returned.
On 5/17/2013 7:12 AM, Michael Hulko wrote:
> One note after implementing EAPBALANCE. I am getting this in the logs
> with a specific user at the moment.
>
> May 17 07:52:09 riptide-2.vm.its.uwo.pri /usr/bin/radiusd[23274]:
> ProxyAlgorithm HASHBALANCE declines to break up an EAP stream after
> failover from 129.100.160.133:1645:1646 to 129.100.160.144:1645:1646
> May 17 07:52:09 riptide-2.vm.its.uwo.pri /usr/bin/radiusd[23274]:
> ProxyAlgorithm HASHBALANCE declines to break up an EAP stream after
> failover from 129.100.160.133:1645:1646 to 129.100.160.144:1645:1646
> May 17 07:52:14 riptide-2.vm.its.uwo.pri /usr/bin/radiusd[23274]:
> ProxyAlgorithm HASHBALANCE declines to break up an EAP stream after
> failover from 129.100.160.133:1645:1646 to 129.100.160.144:1645:1646
>
> May 17 08:07:39 riptide-2.vm.its.uwo.pri /usr/bin/radiusd[23274]:
> AuthRADIUS IVEY: Could not find a working host to forward
> asnowdon at ivey.ca <mailto:asnowdon at ivey.ca> (79) after 20 seconds. Ignoring
> May 17 08:07:39 riptide-2.vm.its.uwo.pri /usr/bin/radiusd[23274]:
> AuthRADIUS IVEY: Could not find a working host to forward
> asnowdon at ivey.ca <mailto:asnowdon at ivey.ca> (79) after 20 seconds. Ignoring
> May 17 08:07:39 riptide-2.vm.its.uwo.pri /usr/bin/radiusd[23274]:
> AuthRADIUS IVEY: No reply after 20 seconds and 3 retransmissions to
> 129.100.160.133:1645 for asnowdon at ivey.ca <mailto:asnowdon at ivey.ca> (64)
> May 17 08:07:39 riptide-2.vm.its.uwo.pri /usr/bin/radiusd[23274]:
> AuthRADIUS IVEY: No reply after 20 seconds and 3 retransmissions to
> 129.100.160.133:1645 for asnowdon at ivey.ca <mailto:asnowdon at ivey.ca> (64)
>
>
>
> Here is the config snippet I have included.
>
> <AuthBy EAPBALANCE>
> Log errorLogger
> Log western_syslog
> Identifier IVEY
> Retries 3
> RetryTimeout 5
> FailureBackoffTime 20
> AuthPort 1645
> AcctPort 1646
> Secret xxxxxxxxx
> LocalAddress xxxxxx
> <Host 129.100.160.144>
> </Host>
> <Host 129.100.160.97>
> </Host>
> <Host 129.100.160.133>
> </Host>
> </AuthBy>
>
> My interpretation of these messages is that the server the EAPBALANCE
> is trying to send the authentication packets to does not respond in
> the appropriate amount of time, the EAPBALANCE Hash does not want to
> break the authentication stream, but never times out long enough to
> move to another server?
> Any input would be helpful. My thought is to lower the values for
> Retries etc.
>
>
> MH
>
>
> On 2013-05-10, at 11:41 AM, Michael Hulko wrote:
>
>> Thanks for the suggestion.. this seems to alleviate the timeouts that
>> I had noticed previously. (Log file was sent separately).
>>
>> MH
>>
>>
>>
>> On 2013-05-10, at 5:26 AM, Heikki Vatiainen wrote:
>>
>>> On 05/09/2013 11:09 PM, Michael Hulko wrote:
>>>> We have been requested to try and loadbalance requests to a Campus
>>>> department with their own Radius (IAS) server for their wireless users.
>>>
>>> Hello Michael,
>>>
>>> you mentioned campus and wireless LAN which makes me think there is EAP,
>>> such as PEAP or TTLS, involved.
>>>
>>> If so, you would need to use <AuthBy EAPBALANCE> to make sure the EAP
>>> authentication sessions are always handled by the same IAS server.
>>> Otherwise you will see failures and timeouts when the IAS servers
>>> receive requests they are not expecting.
>>>
>>> The Trace 4 log was not included, but I'd first check how it works with
>>> EAPBALANCE.
>>>
>>> Thanks,
>>> Heikki
>>>
>>> --
>>> Heikki Vatiainen <hvn at open.com.au <mailto:hvn 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.
>>> _______________________________________________
>>> radiator mailing list
>>> radiator at open.com.au <mailto:radiator at open.com.au>
>>> http://www.open.com.au/mailman/listinfo/radiator
>>
>>
>>
>> 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> <mailto:mihulko at uwo.ca>
>>
>>
>>
>>
>>
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au <mailto:radiator at open.com.au>
>> http://www.open.com.au/mailman/listinfo/radiator
>
>
>
> 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> <mailto:mihulko at uwo.ca>
>
>
>
>
>
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
--
%% Christopher A. Bongaarts %% cab at umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20130517/7878b026/attachment.html
More information about the radiator
mailing list