Date: Fri, 04 Aug 2000 00:34:04 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Bob Van Valzah <Bob@WhiteBarn.Com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? Message-ID: <200008040434.AAA41523@whizzo.transsys.com> In-Reply-To: Your message of "Thu, 03 Aug 2000 22:15:21 CDT." <398A3549.902A31F5@WhiteBarn.Com> References: <398A3549.902A31F5@WhiteBarn.Com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?200008040434.AAA41523>