From owner-freebsd-net Thu Feb 3 10:54:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from euitt.upm.es (haddock.euitt.upm.es [138.100.52.102]) by builder.freebsd.org (Postfix) with ESMTP id 918EA3FFE for ; Thu, 3 Feb 2000 10:54:22 -0800 (PST) Received: from localhost (pjlobo@localhost) by euitt.upm.es (8.9.3/8.9.3) with ESMTP id TAA06969; Thu, 3 Feb 2000 19:48:31 +0100 (MET) Date: Thu, 3 Feb 2000 19:48:31 +0100 (MET) From: "Pedro J. Lobo" To: "Matthew N. Dodd" Cc: freebsd-net@FreeBSD.ORG Subject: Re: 802.1Q VLANs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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