Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Feb 2000 19:48:31 +0100 (MET)
From:      "Pedro J. Lobo" <pjlobo@euitt.upm.es>
To:        "Matthew N. Dodd" <winter@jurai.net>
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: 802.1Q VLANs
Message-ID:  <Pine.OSF.4.21.0002031919510.5862-100000@haddock.euitt.upm.es>
In-Reply-To: <Pine.BSF.4.21.0002031236160.479-100000@sasami.jurai.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Feb 2000, Matthew N. Dodd wrote:

>On Thu, 3 Feb 2000, Pedro J. Lobo wrote:
>
>> The 802.1Q standard does allow frames with those 4 extra bytes, and
>> the machines that "speak" 802.1Q must be able to recognize those long
>> frames as valid.
>
>Humm...  Ideally the VLAN driver should be able to set the MTU for its
>parent and deal with being able to set the MTU > 1500.

No, the MTU doesn't need to be changed. In fact, changing it would
probably mean trouble.

The maximum ethernet frame size is 1518 bytes. Substract 6 + 6 + 2 + 4
(destination address, source address, frame type and frame crc) and you
get 1500 bytes, which is the maximum payload that a frame can carry. That
is the MTU.

802.1Q adds 4 bytes to the maximum frame size, but the payload
length doesn't change. So, the MTU is still 1500 bytes. From the IP stack
point of view, a 802.1Q interface is exactly the same as a traditional
ethernet one. And everything works flawlessly: the interfaces that doesn't
speak 802.1Q will discard some frames as oversized, but that doesn't
matter because they wouldn't know how to process them anyway.

If you lower the MTU to 1496 bytes you will have to accept 1500-byte IP
packets anyway, because other machines can (legally) send them to
you. Accepting a packet that's bigger than the interface's MTU is at least
strange. And, if the machine is a router (which in fact was my goal when I
made the patch) you would have to fragment and re-assemble a lot of
packets, which is very inefficient.

>This prevents us from making VLAN specific hacks to the other drivers
>and relegates the problem to one of supporting 'large frames'.

You *can't* avoid making modifications to the drivers. The driver must
accept ethernet frames up to 1522 bytes *if and only if* they are 802.1Q
frames, and it *can't* drop them or it will break the standards.

>> You are completely right on this. Not all cards will be able to
>> support 802.1Q. The Etherexpress Pro/100 (fxp driver) certainly is. I
>> don't know about other cards, but I suspect that many of them will
>> offer you the posibility of send and receive extra-large frames.
>
>Well, I see no reason to restrict people to cards that don't support large
>frames; if they really need to use VLANs they can adjust the MTU down.  In

Well, I do see a reason: to keep the standards compliance. A network card
is cheap: I buy the fxp's for less than $50. I think it isn't a big price
for being compatible with the rest of the world. And I would be fairly
surprised if recent network controllers from other vendors (3Com, DEC,
etc, etc) didn't have the ability to support long frames, though I can't
assure it.

Of course if you *really* need it you can lower the MTU and work with
frames 4 bytes shorter, but I think that the VLAN code should fully 
support the standards when the NIC allows it.

Cheers,

	Pedro.

-- 
-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 91 336 78 19
Centro de Cálculo                       Fax:    +34 91 331 92 29
E.U.I.T. Telecomunicación               e-mail: pjlobo@euitt.upm.es
Universidad Politécnica de Madrid
Ctra. de Valencia, Km. 7                E-28031 Madrid - España / Spain



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?Pine.OSF.4.21.0002031919510.5862-100000>