[RADIATOR] Handling surge in connections on proxy radius

[Ryan]

Hi Heikki,


Thanks for the advice.


Have tried setting the OutPort for the various backend radius on proxy
radius however does not seems to help.

On the proxy radius, running 'netstat -u -l -p' shows that the recv
queue averaging at around 40K.

On the back end radius, it is almost zero most of the time.

However running 'netstat -u -s' shows a lot of packet receive errors
on both proxy radius and backend radius.

Have tried to increasing the udp buffer on the radius servers. On the
backend radius, it does helps in reducing the packet receive errors
but not much improvement on the proxy radius.


Best Regards,
Ryan


On 02/11/2014 02:04 PM, Ryan wrote:

>* Two proxy radius servers serving a number of NASes. The proxy radius
*>* servers will forward requests based on realms to sets of backend radius
*>* servers.
*> >* Recently there seems to be a surge in requests whereby logs on the proxy
*>* radius shows that the backend radius are not responding in time. Timeout
*>* set is 10 sec with 3 retries. At times, it result in the unknown reply
*>* from the backend radius.
*
If there are multiple backends, you could try setting a separate OutPort
for some or all of them. This forces radiusd to create a socket for each
bind address and port pair allowing it to spred outgoing requests
between multiple sockets.

>* Logs on the backend radius does not show any issues.
*
You may still want to enable debug logging (Trace 4) with
LogMicroseconds and see if a typical authentication takes longer than
you would expect. For example, if you use SQL, you should check how long
the SQL lookup takes.

>* Does this means that the proxy radius can't handle the traffic? And more
*>* proxy radius are required to handle requests?
*
Most likely the backends are having problems serving all the requests.
Unknown replies could be for example, requests that have spent a lot of
time in the OS's incoming UDP queue. When they eventually get processed
by the backend Radiator, the frontend has already given up on the
request it sent. The timeout is quite long, though, but I'd still take a
closer look at the backend performance.

Try running 'netstat -u -l -p' on the backend and see what Recv-Q shows.
This tells if packets are queued before being processed by radiusd.

Another thing to check is 'netstat -u -s'. If UDP 'packet receive
errors' counter value grows, the OS may be dropping incoming requests
because the socket queue is full.

>* All radiuses are running latest release.
*
Please let us know if the above helps.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au
<http://www.open.com.au/mailman/listinfo/radiator>>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20140212/aeb45540/attachment.html