[RADIATOR] Load Balancers Returning IGNORE Warnings

Heikki Vatiainen hvn at open.com.au
Tue Sep 16 12:30:37 CDT 2014


Hello Roberto,

to see who long SQL queries take, you could do this:

- configure one Radiator instance with LogMicroseconds option
- turn on Trace 4
- let it run for a while
- back to your normal Trace level

LogMicroseconds is a top level boolean option that adds microsecond
resolution to log messages. This allows you to see who long the SQL
queries take. We can also take a look at the logs if needed.

If the logging is taking too long, the incoming RADIUS messages start
filling the operating system UDP receive queues. This means that they
are processed, but they may have spent considerable time in the OS queue.

If the queue grow long enough, the OS will start dropping requests. If
you do this:

% netstat -s -u

The output may indicate 'package receive errors' for UDP. This counter
gets incremented for each dropped UDP request. There might be other
reasons too, but failure to add to UDP queue will cause the counters
increase.

Thanks,
Heikki


On 09/16/2014 05:23 PM, Ullfig, Roberto Alfredo wrote:
> Well, I suspect that the bottleneck is in our SQL logging. We have 7 instances logging to one table in a slow database. The table is locked by each instance while it's logging. The big question is how do I determine that SQL is the bottleneck from the radius logs?
> 
> ---
> Roberto Ullfig - rullfig at uic.edu
> ACCC Research Programmer
> 
> 
> -----Original Message-----
> From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au] On Behalf Of Heikki Vatiainen
> Sent: Tuesday, September 16, 2014 6:01 AM
> To: radiator at open.com.au
> Subject: Re: [RADIATOR] Load Balancers Returning IGNORE Warnings
> 
> On 09/15/2014 09:24 PM, Ullfig, Roberto wrote:
>> Hello, we are running 3 HASHBALANCE load balancers and are getting 
>> many of these messages.
>>
>> Mon Sep 15 13:14:02 2014: DEBUG: AuthBy HASHBALANCE result: IGNORE,
> 
> This is normal. The request was forwarded to the remote host and the processing is done for now. In other words, IGNORE means that no reply should be sent now even if the AuthBy has done its job.
> 
> Later when the reply is received from the next hop, it is returned back to the original sender. The processing happens asynchronously in two
> parts: forward first, do something else meanwhile and then send back the reply when the next hop replies.
> 
>> Mon Sep 15 13:14:02 2014: WARNING: Unknown reply received in 
>> AuthRADIUS for request 145 from ...
>>
>> What would be the cause of this? Could this be related to an 
>> Accounting Response? Thanks!
> 
> Hmm, it might be the next hop replied too late or this was a duplicate reply for some reason.
> 
> If it seems the next hop servers are having problems processing all requests, you could consider taking a look at their logs.
> 
> Another idea might be to have separate instances that handle accounting.
> This allows you to split the load and usually this helps to keep the configuration files more simple since you do not need to handle both accounting and authentication with the same configuration.
> 
> However, it might be worth taking a look at the next hop performance first.
> 
> Thanks,
> Heikki
> 
> --
> Heikki Vatiainen <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
> http://www.open.com.au/mailman/listinfo/radiator
> 


-- 
Heikki Vatiainen <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.


More information about the radiator mailing list