From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 20:17:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C9EC16A4CE for ; Mon, 22 Nov 2004 20:17:08 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C6DD43D55 for ; Mon, 22 Nov 2004 20:17:08 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CWKcV-0006cu-00; Mon, 22 Nov 2004 21:17:07 +0100 Received: from [217.83.10.145] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CWKcU-00064t-00; Mon, 22 Nov 2004 21:17:06 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 22 Nov 2004 21:16:47 +0100 User-Agent: KMail/1.7.1 References: <20041122182912.GA33296@shellma.zin.lublin.pl> In-Reply-To: <20041122182912.GA33296@shellma.zin.lublin.pl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3120092.GfOCXkcoAV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411222117.35177.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Pawel Malachowski Subject: Re: Large NAT: ipf/ipnat, pf - opinions? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 20:17:08 -0000 --nextPart3120092.GfOCXkcoAV Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 22 November 2004 19:29, Pawel Malachowski wrote: > I'm interested in opinions/comparisons how ipnat and pf perform > on FreeBSD 5.x in real working large NAT setups (about 50Mbit/s, few > thousands of workstations, 300k of mappings or more). Problems noticed, > memory and CPU consumption, mbufs utilization etc. While the state information in pf is slightly larger than that of ipfilter= =20 (and thus the memory consumption). pf offers many functionalities that make= =20 it the "easier-to-manage" tool. There are also a couple of optimizations in= =20 pf that should make it perform better, but only measuring your specific=20 application can tell you which is the better for you. I'd guess that pf can= =20 lift the load described above with an average workstation (good NICs and=20 plenty of RAM provided). Note, however, that for CPU consumption packets pe= r=20 second is the important factor. For pf - with it's stateful inspection -=20 connection initialization has some meaning as well (once established, passi= ng=20 more traffic through a connection is cheap). Depending on your application, you might find pf's TABLES which greatly=20 improve management of large IP-sets. There are also many options to fine-tu= ne=20 the number of concurrent states that a (NAT)rule can create. This helps to= =20 keep down memory consumption during DDoS-Attacks. The additional "adaptive= =20 timeouts" can also help to manage load peaks. That is comparing pf 3.5 (what is in RELENG_5) with ipfilter 3.x (also in=20 RELENG_5). ipfilter 4.x has gained some, but isn't included in FreeBSD. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3120092.GfOCXkcoAV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBoklfXyyEoT62BG0RAm44AJ97LltR9sDHGbE0MN8pkwMdt0722gCfbtiT A+s77MpaW1zInUydcy5qTok= =n0GP -----END PGP SIGNATURE----- --nextPart3120092.GfOCXkcoAV--