From owner-freebsd-net@FreeBSD.ORG Thu Mar 9 14:53:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3808C16A420 for ; Thu, 9 Mar 2006 14:53:12 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id A998C43D49 for ; Thu, 9 Mar 2006 14:53:10 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k29Er9G8028237 for ; Thu, 9 Mar 2006 15:53:09 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id D49533F17; Thu, 9 Mar 2006 15:53:03 +0100 (CET) Date: Thu, 9 Mar 2006 15:53:03 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20060309145303.GB19877@zen.inc> References: <20060307180222.GA1308@zen.inc> <440FA8DC.3010006@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <440FA8DC.3010006@errno.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FAST_IPSEC and tunnelled packets processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2006 14:53:12 -0000 On Wed, Mar 08, 2006 at 08:02:36PM -0800, Sam Leffler wrote: [.....] > If I recall the IPIP handling is different from KAME because there is > support for IPIP encapsulation independent of the IPsec protocols while > KAME only handles IPIP as part of the ESP tunnel configuration. As to > overhead, in practice, at least back in 4.x where this work was > originally done, the netisr dispatch was effectively shortcircuited > because the dispatch was done from the netisr thread so the net cost was > a enqueue+dequeue of the packet. I'm not sure about extraneous trips > through ip_input or not stripping headers; this stuff used to work right > but I've not looked at the code in years. There IS some code to remove the IPIP header, but it doesn't work. I just reported pr kern/94273 with a patch which solves it. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com