Date: Tue, 26 Dec 2006 11:27:44 -0800 From: Julian Elischer <julian@elischer.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: Max Laier <max@love2party.net>, Andre Oppermann <andre@freebsd.org>, freebsd-net@freebsd.org Subject: Re: [was] addition to ipfw (read vlans from bridge).. Message-ID: <459177B0.2030006@elischer.org> In-Reply-To: <20061226061610.GD81280@comp.chem.msu.su> References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> <200612160446.02644.max@love2party.net> <4584CE0C.3020307@elischer.org> <458C426A.9060604@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <20061226061610.GD81280@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Yar Tikhiy wrote: >> >> If what you are suggesting is that we pass into ipfw an 'offset' >> into the packet as well as the packet, then yes I like that idea, >> but I didn't see Andre suggest it. > > Do you consider only ideas by Andre? ;-) By Andre's opinion I > meant this: > > Please have the ipfw code examine the vlan tag in the mbuf instead of > fiddling with the mbuf contents. At the moment I plan the ipfw code to be unaware of vlan headers. the plan is: Add an argument to ipfw which is the offset in the packet where the IP header may be found. Change the L2 users of ipfw to leave the packet alone, but calculate the correct offset to pass to ipfw. IPFW will make no assumptions as to what packet contents come before the offset. Bridge and L2 callers of ipfw will set the offset to non-0 values where the IP callers will set it to 0. The non IP callers may make some MAC information available to the ipfw code my some separate method, as it does at the moment. How this is done will depend if we want to support Q-n-Q, and if so, how much.. > > -- > Andre > > If we want ipfw to know of L2, then examining the VLAN tag in it > is OK. If not really, then ipfw (or any pfil filter) can get just > the offset of IP. What vlan tag? what if it's from an interface with no VLAN capacity.. What we need to do is make a convention so that vlan tags are always created at the lowest layer, even if HW vlan tagging is not supported, so that all packets look as if they have come from HW capable packets, and add code so that all non WH capable interfaces interpret Van tags at the lowest level, that way vlan packets always look the same. [...] > > Pardon, but you seem to mistake me for Max Laier. :-) OTOH this is > a good chance for me to ask you a similar question: Did you recieve > my mail on m_copym() usage in the kernel? I can resend it to you > if you didn't. ;-) Honestly, I'd appreciate much if you dropped a > line on the topic. > sure.. My reader may have misfiled it under spam.. send it again.. >>> There is also work in progress to introduce nested VLANs AKA Q-n-Q. >>> They seem to present a challenge to the scheme you are implementing. >> not a permanent problem.. it could be modified to handle it. >> but I'll take it into account in the next version if >> you think it is a required feature.. what is the maximum >> nesting level? > > Infinity. Why to introduce such a hard limit? Because an infinite limit complicates things? > Well, 802.1ad allows > just two tags: the customer (C) tag and the service (S) tag, but > each gets its own ethertype. C-TAG's is 81-00 while S-TAG's is > 88-a8. I don't think we support the different ethertypes yet, so > Q-n-Q is just the nesting of type 81-00 tags. (802.1ad appears a > funny reading: it's essentially a patch against the 802.1q text!) > Cisco and Juniper boxes seem to have a limit of two tags as well. > While they may have a reason to (all those ASICs, you know,) we > don't have it. Allowing for only two tags will tempt us into > duplicating code instead of developing fair algos and interfaces. > yes but algorythmically doing something we may never be required to do may lead to unneeded code slowdown. I guess we can look at it and decide.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?459177B0.2030006>