Hi Dmitriy,
On Tue, Jul 26, 2011 at 05:27:10PM +0400, Dmitriy Samsonov wrote:
> > Intel's 10G NICs are fast, but generally hard to tune, you have a hard
> > trade-off between data rate and latency. Basically you tune them for
> > large or small packets but not both. Still for DDoS they might be we
No, this DDoS was from different IPs in 40-50 countries, so it was performed
by zombies. As far as I can tell it was performed with Agressor2.0 botnet,
successor of DirtyJump3.0. This botnet is constructed to let even 3 y.o.
attacker to make serious imact. Each bot not only performs 'http-flood', b
Hi,
> We've tested from the outside. In fact that was a real attack. Botnet
> consisted of ~10-12k bots each opening 1000 connections/second.
This kind of DDoS seems popular lately. Did it originate from a specific
AS, did you try to nullroute? I'm curious because mostly when I see
botnet attacks
Hi!
2011/7/26 Willy Tarreau
> > There is an option in Del''s servers to install Intel's 10Gbit
> > NIC - it is working a way faster (x3, x5) then broadcom.
>
> Intel's 10G NICs are fast, but generally hard to tune, you have a hard
> trade-off between data rate and latency. Basically you tune t
Hi Dmitriy,
On Tue, Jul 26, 2011 at 03:51:20AM +0400, Dmitriy Samsonov wrote:
> Hi!
>
> First of all thanks too all on this list for helping me to setup and
> configure haproxy. Thanks to Willy for haproxy. I thought it is a good idea
> to save somebody like me some time configuring Dell's server
Hi!
First of all thanks too all on this list for helping me to setup and
configure haproxy. Thanks to Willy for haproxy. I thought it is a good idea
to save somebody like me some time configuring Dell's servers for haproxy to
meet DDoS or other traffic-intensive task. Solution is - "get rid of bnx
Hi Dmitriy,
On Wed, Jul 20, 2011 at 06:33:27AM +0400, Dmitriy Samsonov wrote:
> Very strange, but your experience is enourmous so I'd be better to listen to
> you. As I wrote, before disabling HT I've tested all possible combinatrions
> of bindings:
> (haproxy, irq) = (cpu#n, cpu#m) in (0,1), (0,2
Hi!
If you were running with hyperthreading, then it's very likely that the
> working cores were polluted by other activity on their siblings. In our
> appliances we manage to reach high perf even with HT left enabled, just
> because we are very careful to bind only the first thread of each real
>
Hi Dmitriy,
On Wed, Jul 20, 2011 at 12:13:52AM +0400, Dmitriy Samsonov wrote:
> Hi!
>
> I've got stable 70-80k session rate at last:)
Nice!
> I've tried everything, upgraded haproxy to 1.4.15, tried "bind :80
> defer-accept", event wrote a script to try all possible combinations
> for cpu_affin
Hi!
I've got stable 70-80k session rate at last:)
I've tried everything, upgraded haproxy to 1.4.15, tried "bind :80
defer-accept", event wrote a script to try all possible combinations
for cpu_affinity for IRQs/haproxy(it's important note). I've also
removed bond0. Nothing helped.
After that, f
Hi Dmitriy,
On Tue, Jul 19, 2011 at 04:25:29AM +0400, Dmitriy Samsonov wrote:
> Using one/two clients with ab2 -c 250 -H 'Accept-Encoding: None' -n
(...)
> 98% 11
> 99% 13
> 100% 9022 (longest request)
Still some drops. Was this before or after ethtool+somaxconn ?
> Also I've upgr
On 7/18/11 5:25 PM, Dmitriy Samsonov wrote:
My final task is to handle DDoS attacks with flexible and robust
filter available. Haproxy is already helping me to stay alive under
~8-10k DDoS bots (I'm using two servers and DNS RR in production), but
attackers are not sleeping and I'm expecting atta
Hi!
>
> Fine, this is a lot better now. Since you're running at 2000 concurrent
> connections, the impact on the cache is noticeable (at 32kB per connection
> for haproxy, it's 64MB of RAM possibly touched each second, maybe only 16MB
> since requests are short and fit in a single page). Could you
Hi Dmitriy,
On Mon, Jul 18, 2011 at 10:01:47PM +0400, Dmitriy Samsonov wrote:
> defaults
> mode http
> maxconn 79500
> timeout client 20s
> timeout server 15s
> timeout queue 60s
> timeout connect 4s
> timeout http-request 5s
> timeo
Hi!
2011/7/18 Willy Tarreau
> Hi,
>
> On Mon, Jul 18, 2011 at 06:42:54AM +0400, Dmitriy Samsonov wrote:
> > My test setup is three Dell r410 servers (dual Intel(R) Xeon(R) CPU X5650
> @
> > 2.67GHz - 24 threads total, 128Gb RAM) all connected to 1Gbps network.
> >
> > One server is haproxy, con
On Mon, Jul 18, 2011 at 08:54:15AM +0100, John Helliwell wrote:
> Are you running irqbalance? It may help distribute network interface
> interrupts
It's often worse for low-latency processing such as haproxy. irqbalance is
nice when each interrupt induces very long CPU processing, but here we hav
Hi,
On Mon, Jul 18, 2011 at 06:42:54AM +0400, Dmitriy Samsonov wrote:
> My test setup is three Dell r410 servers (dual Intel(R) Xeon(R) CPU X5650 @
> 2.67GHz - 24 threads total, 128Gb RAM) all connected to 1Gbps network.
>
> One server is haproxy, configured to block all requests with
> 'Accept-
Are you running irqbalance? It may help distribute network interface interrupts
Sent from my iPhone
On 18 Jul 2011, at 03:42, Dmitriy Samsonov wrote:
> My test setup is three Dell r410 servers (dual Intel(R) Xeon(R) CPU X5650 @
> 2.67GHz - 24 threads total, 128Gb RAM) all connected to 1Gbps n
My test setup is three Dell r410 servers (dual Intel(R) Xeon(R) CPU X5650 @
2.67GHz - 24 threads total, 128Gb RAM) all connected to 1Gbps network.
One server is haproxy, configured to block all requests with
'Accept-Encoding: none':
global
daemon
maxconn 8
option forwardfor
retries 10
fro
19 matches
Mail list logo
