Thereafter
http://status.ovh.net/?do=details&id=4339 we have contacted a10 and the setting that we are using.
There might be an improvement to apply to our
setting in order to better use the hardware that we have
in the box.
We are doing a test tonight for about 10 minutes
to see if the CPU is again loaded. If all went OK,
we will remove the routing then reset it tomorrow morning when we have the attack.
Update(s):
Date: 2013-03-20 14:45:15 UTC We are waiting for the feedback of the a10 support
to fix this problem.
Meaningwhile, we are back to the initial configuration.
End of the task :)
Date: 2013-03-20 14:44:15 UTC okey , we found the origin of the problem. It's a type
of attack. We set up a wordaround to make these attacks
ineffective and we'll looking with a10 how to block
them simply
All the trafic is on the 2 boxes.
Date: 2013-03-20 10:11:19 UTC The CPU keeps increasing.
Date: 2013-03-20 10:10:30 UTC Mar 20 2013 10:04:29 Warning [AX]:conn proxy queue depth exceeds
limit (2001)
Mar 20 2013 10:04:27 Warning [AX]:conn proxy queue depth exceeds limit
(1001)
Mar 20 2013 10:04:25 Warning [AX]:conn proxy queue depth exceeds limit
(1)
Date: 2013-03-20 10:09:44 UTC We tried to switch all the traffic to AX. The devices are overloaded. We think about a solution.
We switch a part of the traffic and it works fine. We switch the rest and it doesn't work. We need to find a solution.
We modify the settings on buffers
slb buff-thresh hw-buff 30720 relieve-thresh 15360 sys-buff-low 165000 sys-buff-high 235000
Devices reboot
It works with one device but the buffer line has not resisted the reboot!? So it's not that.
Date: 2013-03-20 00:53:32 UTC Removed. The 1st box seems working properly.
However, the 2nd is not taking connections well.
We'll see if there's a hardware issue with it.
Tomorrow morning, we will reset the traffic on the
1st box only and see if bears it all and if we really
have the attack planned in auto all mornings (that we did not see
as ACE are well bearing the attack).