Date: Sat, 21 Oct 2006 14:50:31 +0400 From: Anton Yuzhaninov <citrin@citrin.ru> To: "Matthew D. Fuller" <net@freebsd.org> Subject: Re[2]: Avoiding natd overhead Message-ID: <1238798379.20061021145031@citrin.ru> In-Reply-To: <20061021095808.GH75501@over-yonder.net> References: <200610210648.AAA01737@lariat.net> <20061021095808.GH75501@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. ------------C412E16C1FFDF27 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Saturday, October 21, 2006, 1:58:08 PM, Matthew D. Fuller wrote: MDF> On Sat, Oct 21, 2006 at 12:47:54AM -0600 I heard the voice of MDF> Brett Glass, and lo! it spake thus: >> >> How can I replace just the functionality of natd without moving to >> an entirely new firewall? Can I still select which packets are >> routed to the NAT engine, and when this occurs during the processing >> of the packet? MDF> Paolo Pisati's 2005 SoC work on integrating libalias into ipfw might MDF> fit here. It should move the NAT'ing into the kernel and save all the MDF> context switches and copies, and (what has me more interested) make it MDF> much easier to change port forwarding and other rules. The worst MDF> thing about natd for me isn't performance, it's that I have to blow MDF> away all the state to change anything. libalis still have big overhead comparing to ipnat: 1. libalias allocate memory for create each new entry in NAT table. libalias use linear search in linked list to find entry in table. It very slow when you have thousands simultaneous connections via nat 2. ipnat allocate all memory at startup. It better. ipnat uses hash table to fine entry in nat table - it mach faster in heavy loaded case. An next. As I can se libalias not limit maximum size of used memory. When users generate many simultaneous connections (e. g. worm or net scan), libalias may exhaust all kernel memory and so trigger panic. --=20 WBR, Anton Yuzhaninov ------------C412E16C1FFDF27--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1238798379.20061021145031>