Date: Fri, 04 Aug 2000 07:39:56 -0500 From: Bob Van Valzah <Bob@WhiteBarn.Com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? Message-ID: <398AB99C.9D5938B9@WhiteBarn.Com> References: <398A3549.902A31F5@WhiteBarn.Com> <200008040434.AAA41523@whizzo.transsys.com>
next in thread | previous 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?
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?398AB99C.9D5938B9>