From owner-freebsd-net Tue May 1 22:38:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.csl.sony.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 4183037B422 for ; Tue, 1 May 2001 22:38:50 -0700 (PDT) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57] (may be forged)) by inetfw.csl.sony.co.jp (8.11.2+3.4W/3.7Ws3/inetfw/2001041615/smtpfeed 1.08) with ESMTP id f425cc516025; Wed, 2 May 2001 14:38:38 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id OAA96705; Wed, 2 May 2001 14:38:38 +0900 (JST) To: gunther@aurora.regenstrief.org Cc: snap-users@kame.net, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp Subject: Re: [altq 806] The future of ALTQ, IPsec & IPFILTER playing together ... In-Reply-To: <3AEEEE79.8F7CC7B0@aurora.regenstrief.org> References: <3AEEEE79.8F7CC7B0@aurora.regenstrief.org> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010502143838P.kjc@csl.sony.co.jp> Date: Wed, 02 May 2001 14:38:38 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 35 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gunther Schadow wrote: > However, I understand that ALTQ works in the data link layer at > the interface to the NIC. IPsec, however, works above that layer, > even before the IPFILTER rules (on outgoing packets.) So, we have > the following "pipe" > > IPSEC -----> IPFILTER -------> ALTQ > > the problem is that ALTQ will only see IPSEC ESP packets. So, > all the properties of the payload packets that allow me to > define the ALTQ classes are now encapsulated in ESP and thus > invisible to the ALTQ classifier. In general, we don't recommend to use tunnels since it introduces too much complexity and, as itojun said, there's no single solution for all possible combinations. For your requirements, it seems simpler to apply TOS marking beforehand. The TOS field of the IP header is available to the ALTQ classifier even with ESP both in the transport mode and the tunnel mode. (this is what diffserv is all about.) You can mark the TOS (or IPv6 traffic class) field either by - an application using setsockopt(2) or - a diffserv traffic conditioner on the ingress interface (you will need another box for this) Regarding classifier implementations, Jason Thorpe and his colleagues at Zembu are working on a generic programable classifer based on the BPF language. I'd like to merge it into ALTQ when it becomes available. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message