From owner-freebsd-net@FreeBSD.ORG Sat Mar 9 16:15:47 2013 Return-Path: Delivered-To: freebsd-net@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 B5042E2B for ; Sat, 9 Mar 2013 16:15:47 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 33C94E02 for ; Sat, 9 Mar 2013 16:15:46 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id z7so579293eaf.14 for ; Sat, 09 Mar 2013 08:15:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id:x-gm-message-state; bh=87U5I1ti2Xiokb1uoM/2wytuL6lompIPNW4nwc8R2X8=; b=bpzguDRGogILgT5DTgJVShj4mbcVP47Bygb8Qo1ienaMCs9mPvcJM/BMRncKqo6Uwo sdxVk8Q4MlATwzBOeKBwgJjbSAaXMfehbS4DyCGoKe1+UtX3KJKD5T3VboQy62Y5HmeY 6IeXX3rqjwbhKq6k9BJ6Fy9ioCsdvy8qtaUFzzDQPyXq3Ti05KufFe02ReImImMJeTSa hh1D2PdZSehEdKDB5Bzja5SmsxvbN1Oqylmz/Q00jUoA8Tyl8Js+iNg6vn8Cb6W9UOX7 CZ2SStJ3PwzRYnOYZ5ZcvK4rGeiUtDnNQU2nBNvgDi5+qib6wXKnGo0BMWc7uIlbw4MI fm2w== X-Received: by 10.14.4.69 with SMTP id 45mr17622104eei.0.1362845745816; Sat, 09 Mar 2013 08:15:45 -0800 (PST) Received: from zvezda.localnet ([37.81.64.97]) by mx.google.com with ESMTPS id 3sm13797558eej.6.2013.03.09.08.15.43 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 09 Mar 2013 08:15:44 -0800 (PST) From: Kajetan Staszkiewicz To: Ermal =?utf-8?q?Lu=C3=A7i?= Subject: Re: [patch] Source entries removing is awfully slow. Date: Sat, 9 Mar 2013 17:15:42 +0100 User-Agent: KMail/1.13.5 (Linux/3.6.6-vegeta.1; KDE/4.4.5; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201303091437.51945.vegeta@tuxpowered.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201303091715.42624.vegeta@tuxpowered.net> X-Gm-Message-State: ALoCoQmKh3qvj6TlKdybwlU8fvTHcwi2t84HCc2J6fSoQ2inHWVn75kU0MrAhiWpCdSRyo/Pm4b3 Cc: "freebsd-net@freebsd.org" , "freebsd-pf@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 16:15:47 -0000 Dnia sobota, 9 marca 2013 o 16:11:56 napisa=C5=82e=C5=9B: > > > Though the src node removal option through pfctl -K does a lot of job > > > to cleanup things > > > Still need to undertand why it takes so much time for you to loop > > > through 500K states. > >=20 > > That is because the loop will not be called just once. > >=20 > > `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. >=20 > I would expect from a proper software to kill states from those clients a= nd > then kill the srcnode for the backend server. =46irst of all, I do not know which clients are affected. I know which serv= er is=20 dead. But I can not remove states to this server using pfctl, as states are= =20 from clients' public IP addresses to loadbalancer's public IP address. Sour= ces=20 on the other hand point to the internal IP address of the broken server. And the second thing is, that under normal conditions removing just a bit o= f=20 states would not help the performance. Also the server health checking soft= ware=20 is unaware of DDoS attacks and will not remove states resulting from the at= tack=20 in advance. > It does not make proper sense to not kill state before src nodes since th= at > is what will impact your connectivity. I agree, it makes only sense to remove both sources and linked states at th= e=20 same time. With removing sources only, states are still pointing to the bro= ken=20 server and clients are still connected to it in existing tcp connections. I= f=20 states would be also removed, clients will loose all connectivity (which I= =20 prefer rather than them seeing wrong data) and (hopefully) reconnect to ano= ther=20 live server. > Though the patch improves your use case a lot still would be better to ev= en > 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. That would be in updated version of the patch I hope to send to the list on= =20 Monday. =2D-=20 | pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------'