Patches to improve SYN performance when under attack

Jonathan T. Looney jtl at freebsd.org
Mon May 9 16:16:21 UTC 2016


On 5/7/16, 11:17 AM, "owner-freebsd-transport at freebsd.org on behalf of George Neville-Neil" <owner-freebsd-transport at freebsd.org on behalf of gnn at neville-neil.com> wrote:

>Can folks take a quick look at these?

My quick 2c (since all you asked for was "quick" :-) ):

With SYN cookies, I don't think either of these matter.

With the syncache, both might.

In 11.1, I believe cookies are the default.

Jonathan


>
>Best,
>George
>
>
>Forwarded message:
>
>> From: Robert N. M. Watson <robert.watson at cl.cam.ac.uk>
>> To: George V. Neville-Neil <gnn at neville-neil.com>
>> Subject: Fwd: Patches to improve SYN performance when under attack
>> Date: Wed, 27 Apr 2016 15:31:34 +0100
>>
>> Possibly something for the TCP group to talk about sometime.
>>
>> Robert
>>
>>> Begin forwarded message:
>>>
>>> From: Richard Clayton <richard at highwayman.com>
>>> Subject: Patches to improve SYN performance when under attack
>>> Date: 27 April 2016 at 15:20:20 BST
>>> To: Robert Watson <robert.watson at cl.cam.ac.uk>
>>>
>>>
>>> As discussed, first patch is Oct 2015, second Apr 2016
>>>
>>>
>>> https://lwn.net/Articles/659199/
>>>
>>>     This patch series takes the steps to use normal TCP/DCCP ehash
>>>     table to store SYN_RECV requests, instead of the private per-
>>>     listener hash table we had until now.
>>>
>>>     SYNACK skb are now attached to their syn_recv request socket, so
>>>     that we no longer heavily modify listener sk_wmem_alloc.
>>>
>>>     listener lock is no longer held in fast path, including SYNCOOKIE
>>>     mode.
>>>
>>>     During my tests, my server was able to process 3,500,000 SYN
>>>     packets per second on one listener and still had available cpu
>>>     cycles.
>>>
>>>     That is about 2 to 3 order of magnitude what we had with older
>>>     kernels.
>>>
>>> https://patchwork.ozlabs.org/patch/610370/
>>>
>>>     Last known hot point during SYNFLOOD attack is the clearing of
>>>     rx_opt.saw_tstamp in tcp_rcv_state_process()
>>>
>>>     It is not needed for a listener, so we move it where it matters.
>>>
>>>     Performance while a SYNFLOOD hits a single listener socket went
>>>     from 5 Mpps to 6 Mpps on my test server (24 cores, 8 NIC RX queues)
>>>
>>>
>>>
>>> -- 
>>> richard @ highwayman . com                       "Nothing seems the same
>>>                          Still you never see the change from day to day
>>>                                And no-one notices the customs slip away"
>>
>_______________________________________________
>freebsd-transport at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-transport
>To unsubscribe, send any mail to "freebsd-transport-unsubscribe at freebsd.org"
>






More information about the freebsd-transport mailing list