Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 07 Aug 2000 17:32:14 -0500
From:      Bob Van Valzah <Bob@WhiteBarn.Com>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: VLAN MTU? 1500? 1504? Why?
Message-ID:  <398F38ED.776E84E2@WhiteBarn.Com>
References:  <398A3549.902A31F5@WhiteBarn.Com> <200008040434.AAA41523@whizzo.transsys.com> <398AB99C.9D5938B9@WhiteBarn.Com> <200008041446.KAA27928@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Ok, it looks to me like some code is needed that doesn't exist. I'd be glad to
help make it happen if I had a sample. Can anybody help get me started?

Here's the state of the world as I understand it based on comments here and my own
experimentation. Please set me straight if I'm off base.

1) A 1500-byte IPv4 MTU on an Ethernet VLAN is desirable. Things sometimes things
break over VLAN interfaces that only support 1496-byte IPv4 MTUs.

2) 4.1-RELEASE contains a working vlan pseudo device driver, but only the ti
driver is capable of running a 1500-byte IPv4 MTUs with it "as shipped."

3) A patch is available (http://www.euitt.upm.es/~pjlobo/fxp-mtu-patch-4.x) for
the fxp driver of 4.0-RELEASE that allows a 1500-byte IPv4 MTU. However, this
patch doesn't "negotiate" with the physical device--it just assumes that all
physical devices can handle the larger link-layer headers.

4) It is possible (see below) for such negotiation to take place. I haven't been
able to find an example of it yet.

If somebody could provide me with a sample of this negotiation, I'd be happy to
port it to the fxp and all the other capable cards I have around here.

    Bob

Garrett Wollman wrote:

> <<On Fri, 04 Aug 2000 07:39:56 -0500, Bob Van Valzah <Bob@WhiteBarn.Com> said:
>
> > Is there any existing mechanism for "negotiation" of MTU between the
> > physical layer and virtual layer?
>
> Yes.  In FreeBSD's implementation, the network interface driver
> indicates its ability to handle 802.1p-enacapsulated frames (as used
> in 802.1Q) by advertising a header length of 18 rather than the
> standard (no encapsulation) 14 octets.  (The current implementation
> does not, however, have a mechanism for rejecting 1518-byte
> *unencapsulated* packets, as should officially be done.  I don't think
> this is a serious problem.)
>
> -GAWollman
>
> --
> Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
> wollman@lcs.mit.edu  | O Siem / The fires of freedom
> Opinions not those of| Dance in the burning flame
> MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick



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?398F38ED.776E84E2>