Date: Thu, 15 Feb 2007 23:30:14 +0000 From: Bruce M Simpson <bms@incunabulum.net> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Updated 802.1p/q patch Message-ID: <45D4ED06.40709@incunabulum.net> In-Reply-To: <20070215091309.GC20957@comp.chem.msu.su> References: <45D38AC9.50107@incunabulum.net> <20070215091309.GC20957@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45D4ED06.40709>