Date: Fri, 4 Aug 2000 09:42:10 -0400 (EDT) From: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca> To: Bob@WhiteBarn.Com, louie@TransSys.COM Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? Message-ID: <200008041342.JAA05141@cholla.INRS-Telecom.UQuebec.CA>
next in thread | raw e-mail | index | archive | help
> >Louie, Thanks for your comments and for framing the question more >clearly. > >Let's assume we do want to do 1500-byte frames on the virtual interfaces >and go on to an ugly aspect of implementing it. > >Longer frames seem to require that the physical interface "know" that >1504-byte frames should be allowed when the VLAN or 802.1p driver is >above it but prohibited otherwise. Conversely, the VLAN driver should >"ask" before assuming that the physical interface can handle the larger >frames so that it can fail the open in those cases where the driver can't >handle them? > >Is there any existing mechanism for "negotiation" of MTU between the >physical layer and virtual layer? If not, should there be? I suppose we >could crank the MTU of all physical interfaces up to whatever they can >really handle instead of artificially limiting them to 1500 bytes, but >that sounds icky. > >In short, it seem kind of gross to have to hack the source code of the >physical driver when you intend to use it with a virtual driver above it. >Is it worth making an elegant solution to this or should we just let the >few who need longer frames continue futzing the source of the physical >drivers? > Well the actual solution isn't very elegant, is it? But there doesn't seem to be a simple way to fix this. A _new_ MTU will require the existing drivers to be modified anyways, but as things go more and more NICs should support 802.1Q tagging. In my opinion VLANs are most useful (and were designed, I believe) for bridging segments (that includes trunking), thus 802.1Q tagging should be done by the bridge module. If you follow IEEE (a document that goes by the name P802.3ac/D3.1, "Frame Extensions for VLAN Tagging on 802.3 Networks) it is the Ethernet frame that gets bigger, not the IP packet that gets smaller. (my 2c :). Tarik. > Thanks, > > Bob > >"Louis A. Mamakos" wrote: > >> You've got the wrong alternatives considered. >> >> The two to choose between are: >> >> 1. The IPv4 MTU for packets on an Ethernet are always 1500 bytes. To >> this, the ethernet driver adds various link-layer headers (source >> and destination MAC addresses, Ethernet Type/802.3 length) as well as >> trailers (Ethernet CRC). >> >> For some ethernet links which use VLAN trunking, there are additional >> fields in the link layer headers which are added to support VLANs and >> 802.1p priority. Ethernet interfaces which choose to participate in >> explicit VLAN tagging need to be able to add and remove this header, >> which may result in maximal length frames a few byte longer than >> previously. >> >> 2. The IPv4 MTU for packets is decreased because the hardware you >> have can't accomodate the addition of VLAN tagging when you want to >> use explicit tagging of frames, and the IP payload is "large." >> >> I would argue that if your Ethernet hardware can't send and receive >> frames with the "normal" sized payload AND the addition of VLAN tags, >> then you have no business using it on explicitly tagged VLAN ethernet >> segments. E.g., alternative 1 is correct. >> >> It's important to distinguish between the payload length that the >> link layer (e.g., ethernet) offers to transport for the higher level >> protocol (IPv4 in this discussion) with the constraints that the >> physical layer protocol has. Ethernet MTUs have never been 1500 >> bytes; that's the IP MTU of IP packets carried inside of Ethernet >> frames. The length of the Ethernet frame was sacred until someone >> wanted to do VLAN tagging (which has to be consented to by the >> parties) and they allowed the packets to grow larger to accomodate >> this. >> >> This makes sense when you consider that the primary application of >> explicit VLAN tags is on a VLAN trunk between Ethernet switches. The >> end system using the ethernet switches should not have to care (or >> even be aware) that the link between a couple of switches is just >> a plain ethernet, or a VLAN trunk carrying multiple distinct >> broadcast domains, one per VLAN. >> >> louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008041342.JAA05141>