[RADIATOR] Load Balancers Returning IGNORE Warnings

Wed Sep 17 09:58:58 CDT 2014

If we switch to SYSLOG logging will that help? I'd like to run with debugging on for an extended period of time to learn what radius is doing.

---
Roberto Ullfig - rullfig at uic.edu
ACCC Research Programmer

-----Original Message-----
From: Ullfig, Roberto 
Sent: Wednesday, September 17, 2014 9:35 AM
To: 'Heikki Vatiainen'; radiator at open.com.au
Subject: RE: [RADIATOR] Load Balancers Returning IGNORE Warnings

Hello Heikki, we can't increase the Trace level because apparently it has an adverse effect - preventing users from authenticating to Radius.

---
Roberto Ullfig - rullfig at uic.edu
ACCC Research Programmer

-----Original Message-----
From: Heikki Vatiainen [mailto:hvn at open.com.au]
Sent: Tuesday, September 16, 2014 12:31 PM
To: Ullfig, Roberto Alfredo; radiator at open.com.au
Subject: Re: [RADIATOR] Load Balancers Returning IGNORE Warnings

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.