From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 11:38:40 2003 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 4FC2837B401; Wed, 2 Jul 2003 11:38:40 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7956A43F3F; Wed, 2 Jul 2003 11:38:39 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h62IccQv004433; Wed, 2 Jul 2003 14:38:38 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h62IccqD004432; Wed, 2 Jul 2003 14:38:38 -0400 (EDT) Date: Wed, 2 Jul 2003 14:38:38 -0400 From: Barney Wolff To: Michael Sierchio Message-ID: <20030702183838.GB4179@pit.databus.com> References: <3F0316DE.3040301@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0316DE.3040301@tenebras.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL 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: Wed, 02 Jul 2003 18:38:40 -0000 On Wed, Jul 02, 2003 at 10:31:10AM -0700, Michael Sierchio wrote: > > Currently, performance w/divert sockets and natd in ipfirewall > on a compute-bound platform (ELAN-133MHz) shows ipfw+natd throughput > to be 50% of that offered by ipfilter+ipnat. > > Is there anything that can be done to speed up either the > performance of divert and natd? Alternatively, could network > address translation be merged into ipfirewall? > > As we move from 1000BASE-TX to 10000BASE-TX, this will become > more of an issue, even on 3GHz machines. > > Comments? Suggestions? Vision? NAT is not a security feature, and should be used only where it is actually necessary to translate addresses, and as far towards the edge as possible. If you believe you need to NAT at even 1Gb, I'd look very hard at the requirements. The performance hit on crossing the kernel-userspace boundary for natd is inherent, apart from any code optimization that might be possible. But moving NAT into the kernel has great impact on kernel memory usage, which needs much more care than in user space. NATs can be DoS'd, and running out of kernel memory can be fatal. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.