From owner-freebsd-pf@FreeBSD.ORG Sat Mar 9 15:11:57 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81FDBE46; Sat, 9 Mar 2013 15:11:57 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by mx1.freebsd.org (Postfix) with ESMTP id 350727FA; Sat, 9 Mar 2013 15:11:57 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id j8so295744qah.0 for ; Sat, 09 Mar 2013 07:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t8tBgO4mi0deOXxY60/CPlmuTr33/GZM/wLwrlvJua4=; b=DyMck+jw/XdCiePMWTFnQtBCr4St/A9AfdkCSSV75ALyi1Zp526hzee3Es+ZlSBMLH h8gWhjtI1wCgdIDzOtoiI1hLSL0VPSq9Ug3lWfrW68EzLI45PDdDMDWXGzEx8zW13SbL GdlnY0qsIDVw/ZuIWXtUpaEnubEFqLh57N1tJncoS0tAeOOBNx0XMwADeIZ47UzEA2LO FKO35jtOhIfAZe78ldaqx+6W1rqxVNYnyvOz/KC0ALcdbdRByLIYi3PtmSejYLY+IMA/ 5MfpdfbJ3Y9WrDOxVyBlcYdHtnOyVfkmebTk5egIOVK+m2zmJoGfftaXvTsvUm+6p9/e aVvA== MIME-Version: 1.0 X-Received: by 10.224.178.77 with SMTP id bl13mr9338639qab.13.1362841916475; Sat, 09 Mar 2013 07:11:56 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.27.197 with HTTP; Sat, 9 Mar 2013 07:11:56 -0800 (PST) In-Reply-To: <201303091437.51945.vegeta@tuxpowered.net> References: <201303081419.17743.vegeta@tuxpowered.net> <201303082151.00895.vegeta@tuxpowered.net> <201303091437.51945.vegeta@tuxpowered.net> Date: Sat, 9 Mar 2013 16:11:56 +0100 X-Google-Sender-Auth: SDQcnfZIop-Qf76jdAFs98G2DVc Message-ID: Subject: Re: [patch] Source entries removing is awfully slow. From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Kajetan Staszkiewicz Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "freebsd-pf@freebsd.org" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 15:11:57 -0000 On Sat, Mar 9, 2013 at 2:37 PM, Kajetan Staszkiewicz wrote: > Dnia sobota, 9 marca 2013 o 13:14:16 Ermal Lu=E7i napisa=B3(a): > > On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz > > > > wrote: > > > Dnia pi=B1tek, 8 marca 2013 o 21:11:43 Ermal Lu=E7i napisa=B3(a): > > > > Is this FreeBSD 9.x or HEAD? > > > > > > I found the problem and developed the patch on 9.1. > > > > > Can you please test this more 'beautiful' patch. > > Oh, somehow I did not notice an existing implementation for doubly linked > list. > I'm quite new to kernel programming. > > > Its similar to yours but also delays src state removal to the proper > purge > > thread. > > I'll try it right after the weekend. > > > Though the src node removal option through pfctl -K does a lot of job t= o > > cleanup things > > Still need to undertand why it takes so much time for you to loop throu= gh > > 500K states. > > That is because the loop will not be called just once. > > `pfctl -K 0.0.0.0/0 -K ip.of.internal.server.behind.this.loadbalancer` > will > match multiple Source entries, up to a thousand of them in normal > conditions > ("normal" for my loadbalancers) and many many more when under a DDoS > attack. > > I would expect from a proper software to kill states from those clients and then kill the srcnode for the backend server. It does not make proper sense to not kill state before src nodes since that is what will impact your connectivity. Though the patch improves your use case a lot still would be better to even kill those states during this step, with an extra option, since otherwise you'd have to create for each of those client a separate request. Do you control the application to test an extra addition to this patch to allow killing the linked states as well? > > The purge thread does that every tick by partitioning it to a few per > time > > slot but still minutes is way loong. > > > > Can you please try to give a top -SH view of the time when this happens > and > > a pfctl -vvsa output? > > I'll try on Monday, although as far as I remember the machine was quite > frozen > during this operation. > > -- > | pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD | > | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | > | Vegeta | www: http://vegeta.tuxpowered.net | > `------------------------^---------------------------------------' > --=20 Ermal