[RADIATOR] Unknown reply received in AuthRADIUS
Jim Tyrrell
jim at scusting.com
Fri May 3 06:34:49 CDT 2013
OK, I increased the timeout of the AuthBy RADIUS to 20 seconds and had
to add 'UseExtendedIds', which just delays the issue occuring.
It looks like the issue is with the MySQL server in the new AuthBy
RadiusSessionUpdate which is slow in responding. I suspect a backlog is
building up here which is delaying processing of the RADIUS proxy
replies. If I truncate the new MySQL tables then the RADIUS proxy is
happy, until the table builds up again and performance of the MySQL
AuthBy is degraded.
I need to fix the MySQL server performance, but it has identified I need
to allow for a slow MySQL server so it does not impact the RADIUS proxy
AuthBy. I thought a Fork in the MySQL authby should do the trick?
<AuthBy SQL>
Identifier RadiusSessionUpdate
Fork
DBSource dbi:mysql:Radius:10.10.4.12
DBUsername <user>
DBAuth <pass>
Timeout 2
AcctSQLStatement CALL RadiusUpdate(<statement>)
</AuthBy>
However I'm still getting the RADIUS proxy taking longer and longer to
process and eventually 'Unknown reply received in AuthRADIUS'. Should
the Fork not cause Radiator to fork a new process for this AuthBy so
that it does not delay any other processing?
This is running on a CentOS 6.4 box and also has 'MaxChildren = 100'
defined. Can I tell if it is forking? I dont see any more radiusd
processes..
I just need to ensure that any slowness to a MySQL update does not
impact any other authby's. I'm not seeing any timeouts to MySQL so I'm
guessing that the updates are taking less than 2 seconds, but long
enough for a backlog to build up on a busy box.
Appreciate any ideas.
Jim.
On 02/05/2013 08:18, Hugh Irvine wrote:
> Hello Jim -
>
> You need it in *both* AuthBy RADIUS clauses.
>
> regards
>
> Hugh
>
>
> On 2 May 2013, at 15:56, Jim Tyrrell <jim at scusting.com> wrote:
>
>> I already have IgnoreAccountingResponse in my AuthBy RADIUS below, is that the correct place for it?
>>
>> Jim.
>>
>> On 02/05/2013 00:38, Hugh Irvine wrote:
>>> Hello Jim -
>>>
>>> Just add "IgnoreAccountingResponse" to your AuthBy RADIUS clauses.
>>>
>>> See section 5.32.30 in the Radiator 4.11 reference manual ("doc/ref.pdf").
>>>
>>> regards
>>>
>>> Hugh
>>>
>>>
>>> On 2 May 2013, at 04:49, Jim Tyrrell <jim at scusting.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a default accounting handler which currently formats a few
>>>> attributes via a hook, updates a MySQL database with session info, and
>>>> then relays the RADIUS packet onto a couple of Cisco management servers
>>>> (so they can maintain a mapping of user to IP).
>>>>
>>>> We have always had a few "Unknown reply received in AuthRADIUS", but
>>>> quite rarely and then only a handful at a time so ignored them. I had
>>>> assumed it was down to the remote RADIUS replying after Radiator had
>>>> timed out the request (RetryTimeout 5) and so it was no longer valid -
>>>> is that a correct assumption?
>>>>
>>>> However, I then added another AuthBy between the MySQL update and the
>>>> RADIUS proxy to update a 2nd MySQL server (that will eventually replace
>>>> the current MySQL), and now I get floods of "Unknown reply received in
>>>> AuthRADIUS" approx 10 seconds after starting the RADUS process. I have
>>>> 'Retries 2' so 10 seconds would be the time taken before giving up the
>>>> AuthBy RADIUS.
>>>>
>>>> I dont understand why adding in an AuthBy before the AuthBy RADIUS could
>>>> have an impact? Even if the new AuthBy is slow, and I dont believe it
>>>> is as I have seen no timeouts for it, then wouldnt that just delay the
>>>> RADIUS proxy sending rather than effect its performance? My accounting
>>>> handler is as follows:
>>>>
>>>> <Handler>
>>>> AuthByPolicy ContinueAlways
>>>> AccountingHandled
>>>> PreProcessingHook file:"%D/scripts/format_attributes.pl"
>>>>
>>>> ## Log User session status to MySQL servers via insert/update/delete
>>>> statements
>>>> AuthBy RadiusOnline-Start
>>>> AuthBy RadiusOnline-Alive
>>>> AuthBy RadiusOnline-Stop
>>>>
>>>> ## NEW AuthBy to log to new MySQL server via stored procedure
>>>> AuthBy RadiusSessionUpdate
>>>>
>>>> ## Proxy accounting packet to Cisco management server 10.153.253.1
>>>> AuthBy Proxy-to-CiscoSM
>>>>
>>>> ## Proxy accounting packet to Cisco management server 10.153.253.12
>>>> AuthBy Proxy-to-CiscoSM_lab
>>>>
>>>> </Handler>
>>>>
>>>> The remote RADIUS servers are defined as such:
>>>> <AuthBy RADIUS>
>>>> Identifier Proxy-to-CiscoSM
>>>> <Host 10.153.253.1>
>>>> Secret mypassword
>>>> RetryTimeout 5
>>>> Retries 2
>>>> </Host>
>>>> IgnoreAccountingResponse
>>>> NoDefault
>>>> </AuthBy>
>>>>
>>>> The messages I get are:
>>>> Wed May 1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
>>>> for request 26 from 10.153.253.1:1646
>>>> Wed May 1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
>>>> for request 26 from 10.153.253.12:1646
>>>> Wed May 1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
>>>> for request 27 from 10.153.253.1:1646
>>>> Wed May 1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
>>>> for request 27 from 10.153.253.12:1646
>>>> Wed May 1 19:18:54 2013: WARNING: Unknown reply received in AuthRADIUS
>>>> for request 29 from 10.153.253.1:1646
>>>>
>>>> I thought about changing the order of the AuthBy's and tweaking the
>>>> timeouts but want to try and understand how the additional AuthBy could
>>>> of resulted in this issue before blindly try other things. I guess
>>>> ideally I need to do trace 4 debugs and packet captures to verify delays
>>>> in the remote RADIUS replying, but the server is very busy and its hard
>>>> to piece the incoming and outgoing Radius packets together in all the noise.
>>>>
>>>> Thanks.
>>>>
>>>> Jim.
>>>>
>>>> _______________________________________________
>>>> radiator mailing list
>>>> radiator at open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>>> --
>>>
>>> Hugh Irvine
>>> hugh 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.
>>>
>
> --
>
> Hugh Irvine
> hugh 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