From owner-freebsd-net@FreeBSD.ORG Thu Feb 15 23:30:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6674416A400 for ; Thu, 15 Feb 2007 23:30:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4208313C49D for ; Thu, 15 Feb 2007 23:30:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 4C34C1AFD17; Thu, 15 Feb 2007 18:30:24 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Thu, 15 Feb 2007 18:30:24 -0500 X-Sasl-enc: 8hliqX7+EGdN5+60MX7Cn2p2rG7iFq26EsRKWIsj/p2B 1171582223 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 3B75724599; Thu, 15 Feb 2007 18:30:22 -0500 (EST) Message-ID: <45D4ED06.40709@incunabulum.net> Date: Thu, 15 Feb 2007 23:30:14 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Yar Tikhiy References: <45D38AC9.50107@incunabulum.net> <20070215091309.GC20957@comp.chem.msu.su> In-Reply-To: <20070215091309.GC20957@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Updated 802.1p/q patch 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, 15 Feb 2007 23:30:18 -0000 Yar Tikhiy wrote: > Do you have any architectural reservations about nested VLANs in > the main network stack? Presently, a one-line patch can allow a > vlan(4) to attach to another vlan(4), but I haven't heard about the > behaviour of the resulting setup yet. > After looking around it seems there is definite scope and demand for such a feature in scenarios such as ISP Metro Ethernet setups. However, we can't rely on M_VLANTAG alone to implement it. To do it we need to be sure of the following: 1. Output path in vlan(4) changes not to call ether_output_frame() directly if nested. 2. Output path in vlan(4) detects when it's going to re-enter the parent vlan(4), and makes sure the inner 802.1q header is expanded and inserted from M_VLANTAG before passing it down the stack. 3. That the drivers and cards out there can deal with Q-in-Q. 4. That the input path only extracts and applies M_VLANTAG for the outer 802.1q header. 4. That the input path is able to reenter vlan(4) correctly on the way back up the stack; The code which produces/consumes M_VLANTAG from the 802.1q header might need to be made common. The priority field them becomes problematic. As a compromise I'd suggest the priority field in the VLAN tag is derived from the innermost 802.1q header, which will be the first M_VLANTAG which the Ethernet part of the stack sees. This gives ALTQ/RSVP/PF a chance to do its thing without complicated workarounds. BMS