Hi In the past I have asked regarding this message that appears in the radius log Tue Sep 27 17:01:06 2016 : Error: Received conflicting packet from client XXXXXX port 33542 - ID: 47 due to unfinished request 885176866. Giving up on old request. and you explained that this is a problem probably because of my Mysql that is not managing to write quickly enough to the DB, and I understand that. However after changes we have made to other processes that run on the MySQL we have reached the point that we are only loosing messages for 2 or 3 seconds every 15 minutes when our scheduled processing runs. What I want to do is try and configure the radius to have a large enough cache to be able to handle this short spikes without losing messages, as I don’t have shortage in RAM. I have played around with the following parameters in the radiusd.conf file but they don’t see to be helping . max_requests max_request_time cleanup_delay we are not sending a reply ack to the GGSN for any message so cleanup delay as I understand it isn’t critical. is there a solution for me to “force” freeradius to be able to handle the MySQL problem without dropping messages? Thanks in Advance. Liran Kessel
On Tue, Sep 27, 2016 at 06:12:33PM +0300, liran kessel wrote:
Tue Sep 27 17:01:06 2016 : Error: Received conflicting packet from client XXXXXX port 33542 - ID: 47 due to unfinished request 885176866. Giving up on old request. ... is there a solution for me to “force” freeradius to be able to handle the MySQL problem without dropping messages?
Nothing to do with FreeRADIUS. Your NAS got fed up waiting, so sent the request again. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi, that is strange, as the NAS is configured to not resend requests, as we are managing the Radius for Monitoring purposes only. For this reason we also aren’t sending an ACK back to the NAS.
On 27 Sep 2016, at 6:19 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Tue, Sep 27, 2016 at 06:12:33PM +0300, liran kessel wrote:
Tue Sep 27 17:01:06 2016 : Error: Received conflicting packet from client XXXXXX port 33542 - ID: 47 due to unfinished request 885176866. Giving up on old request. ... is there a solution for me to “force” freeradius to be able to handle the MySQL problem without dropping messages?
Nothing to do with FreeRADIUS. Your NAS got fed up waiting, so sent the request again.
Matthew
-- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 27, 2016, at 11:12 AM, liran kessel <lirankessel@gmail.com> wrote:
However after changes we have made to other processes that run on the MySQL we have reached the point that we are only loosing messages for 2 or 3 seconds every 15 minutes when our scheduled processing runs.
Which is still terrible. If you want RADIUS to work well, then don't take the MySQL server down while the RADIUS server is running.
What I want to do is try and configure the radius to have a large enough cache to be able to handle this short spikes without losing messages, as I don’t have shortage in RAM.
I have played around with the following parameters in the radiusd.conf file but they don’t see to be helping . max_requests max_request_time cleanup_delay
If you read the documentation for those configuration items, you'll see that they have nothing to do with SQL, or with caching requests.
we are not sending a reply ack to the GGSN for any message so cleanup delay as I understand it isn’t critical.
You're not sending accounting ACKs to the GGSN? That's weird.
is there a solution for me to “force” freeradius to be able to handle the MySQL problem without dropping messages?
No. Fix your MySQL server so that it doesn't go down. The best way to do this is to use MySQL replication. Have a master + slave. FreeRADIUS writes to the master. The master replicates to the slave. And the complex processing runs on the slave, not the master. No amount of poking FreeRADIUS will fix the problem. You might be able to mask the problem for a while, but the problem will still exist. Alan DeKok.
Might be a silly question Can't you dump the sql statements into a file and have a separate process (radsqlrelay) updating your database? A On 27 September 2016 at 16:26, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 27, 2016, at 11:12 AM, liran kessel <lirankessel@gmail.com> wrote:
However after changes we have made to other processes that run on the MySQL we have reached the point that we are only loosing messages for 2 or 3 seconds every 15 minutes when our scheduled processing runs.
Which is still terrible.
If you want RADIUS to work well, then don't take the MySQL server down while the RADIUS server is running.
What I want to do is try and configure the radius to have a large enough cache to be able to handle this short spikes without losing messages, as I don’t have shortage in RAM.
I have played around with the following parameters in the radiusd.conf file but they don’t see to be helping . max_requests max_request_time cleanup_delay
If you read the documentation for those configuration items, you'll see that they have nothing to do with SQL, or with caching requests.
we are not sending a reply ack to the GGSN for any message so cleanup delay as I understand it isn’t critical.
You're not sending accounting ACKs to the GGSN? That's weird.
is there a solution for me to “force” freeradius to be able to handle the MySQL problem without dropping messages?
No.
Fix your MySQL server so that it doesn't go down. The best way to do this is to use MySQL replication. Have a master + slave. FreeRADIUS writes to the master. The master replicates to the slave. And the complex processing runs on the slave, not the master.
No amount of poking FreeRADIUS will fix the problem. You might be able to mask the problem for a while, but the problem will still exist.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
The MySQL server isn’t going down, its just running high CPU aggregations and so it isnt’ able to handle the load of writing new events . I agree that the problem is the MySQL but was hoping I could buffer events within freeRadius for a few seconds during these short windows in order to handle the load without needing to add hardware. Thanks for the explanation.
On 27 Sep 2016, at 6:26 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 27, 2016, at 11:12 AM, liran kessel <lirankessel@gmail.com> wrote:
However after changes we have made to other processes that run on the MySQL we have reached the point that we are only loosing messages for 2 or 3 seconds every 15 minutes when our scheduled processing runs.
Which is still terrible.
If you want RADIUS to work well, then don't take the MySQL server down while the RADIUS server is running.
What I want to do is try and configure the radius to have a large enough cache to be able to handle this short spikes without losing messages, as I don’t have shortage in RAM.
I have played around with the following parameters in the radiusd.conf file but they don’t see to be helping . max_requests max_request_time cleanup_delay
If you read the documentation for those configuration items, you'll see that they have nothing to do with SQL, or with caching requests.
we are not sending a reply ack to the GGSN for any message so cleanup delay as I understand it isn’t critical.
You're not sending accounting ACKs to the GGSN? That's weird.
is there a solution for me to “force” freeradius to be able to handle the MySQL problem without dropping messages?
No.
Fix your MySQL server so that it doesn't go down. The best way to do this is to use MySQL replication. Have a master + slave. FreeRADIUS writes to the master. The master replicates to the slave. And the complex processing runs on the slave, not the master.
No amount of poking FreeRADIUS will fix the problem. You might be able to mask the problem for a while, but the problem will still exist.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, used buffered-sql - the accounting gets buffered and server writes it asynchronously. oh, and accounting packets should be ACK'd - or the NAS is likely to either resend or think the server dead. alan
Thanks I will try this as it makes sense for our needs.
On 27 Sep 2016, at 7:40 PM, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
used buffered-sql - the accounting gets buffered and server writes it asynchronously.
oh, and accounting packets should be ACK'd - or the NAS is likely to either resend or think the server dead.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alex Sharaz -
liran kessel -
Matthew Newton