Hi Jim-
Have you tried FarmSize instead of Fork?
-Frank
On May 3, 2013, at 7:34 AM, Jim Tyrrell wrote:
> 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 <j...@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 <j...@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@open.com.au
>>>>> http://www.open.com.au/mailman/listinfo/radiator
>>>> --
>>>>
>>>> Hugh Irvine
>>>> h...@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
>> h...@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@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
