From owner-freebsd-net@FreeBSD.ORG Mon Feb 14 04:47:31 2005 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 07E6316A4CE for ; Mon, 14 Feb 2005 04:47:31 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B517243D49 for ; Mon, 14 Feb 2005 04:47:30 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id ECEA9F5C6; Sun, 13 Feb 2005 23:47:29 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 628246389; Sun, 13 Feb 2005 23:47:25 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16912.11613.216501.589279@canoe.dclg.ca> Date: Sun, 13 Feb 2005 23:47:25 -0500 To: Max Laier In-Reply-To: <200502140157.36085.max@love2party.net> References: <16911.51264.86063.604597@canoe.dclg.ca> <200502140157.36085.max@love2party.net> X-Mailer: VM 7.17 under 21.4 (patch 16) "Corporate Culture" XEmacs Lucid cc: freebsd-net@freebsd.org cc: David Gilbert Subject: Re: altq for vlans? 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, 14 Feb 2005 04:47:31 -0000 >>>>> "Max" == Max Laier writes: Max> On Sunday 13 February 2005 22:36, David Gilbert wrote: >> Has anyone considered patching the vlan driver to support altq? I >> gather that since tun works, so should vlan. Max> This should be a FAQ. Anyway, here is the story: Max> While you can do ALTQ queueing on vlan interfaces the usefulness Max> of this is very little. If the physical interface supports ALTQ Max> it is *always* better to do the queueing there. If the physical Max> interface does not support ALTQ it must be patched. [...] Max> If that does not help you, please try to explain what exactly you Max> try to achieve and why it is not possible with this method. Max> Thanks. Well... the issue is several fold. Firstly, the router in question is talking in trunk mode to a switch which in turn hands out ports to end user boxes. So the "real" interface could be queue limited, but in general, it can be assumed that the GigE interface is faster than the sum of the traffic coming into it. Now... you seem to be saying that if the queue is attached to (in this case) em0, and vlan10 goes through em0, that traffic will be subject to the queue ... even though it's been tagged ... and from the perspective of em0 is no longer IP traffic. This is certainly not obvious, if it is the case. But from a vlan-as-virtual-circuit-replacement standpoint, it makes sense to note a vlan as a queue entity. Anyways, the _real_ problem is that traditionally, I'd used firewall rules for accounting as well as security. To that end, labels are very cool. However, they have one rather large defect: If you're dealing with keep state rules, there seems to be no obvious way to account for incoming vs. outgoing traffic. The label only reports total traffic for the state matching the rule... which is both in and out. So... I was only messing with queues right now in hopes that the queue would give better reporting. Maybe not. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================