From owner-freebsd-current@FreeBSD.ORG Sun Aug 3 10:31:39 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E54637B401 for ; Sun, 3 Aug 2003 10:31:39 -0700 (PDT) Received: from nova.noc.catch.no (nova.noc.catch.no [193.69.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BE9A43FBD for ; Sun, 3 Aug 2003 10:31:38 -0700 (PDT) (envelope-from lerik@nolink.net) Received: from [193.69.2.66] (callisto.noc.catch.no [193.69.2.66]) by nova.noc.catch.no (Postfix) with ESMTP id 74038FF6A; Sun, 3 Aug 2003 19:31:36 +0200 (CEST) From: Lars Erik Gullerud To: Terry Lambert In-Reply-To: <3F2C5715.D549B6CB@mindspring.com> References: <3F2C5715.D549B6CB@mindspring.com> Content-Type: text/plain Organization: Message-Id: <1059931896.47988.49.camel@callisto.noc.catch.no> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Aug 2003 19:31:36 +0200 Content-Transfer-Encoding: 7bit cc: Tom Samplonius cc: Boris Kovalenko cc: freebsd-current@freebsd.org Subject: Re: bge & vlan stranges X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2003 17:31:39 -0000 On Sun, 2003-08-03 at 02:28, Terry Lambert wrote: > > The fact of the matter is, if you use 802.1q encapsulation, the total > > frame size can be 1504. That is the standard. > > This is truly evil. Actually, after a lot of discussions over this very topic during the IEEE ratification process, the 802.1Q standard allows for both varieties. The 1522 total frame size has become the de-facto standard though, for pretty obvious reasons. If I was down at the office now, I could have looked up the relevant sections of the standard and related notes, but since I'm not, this is taken from memory. You all probably this part, but the 802.1Q header is inserted directly behind the DA/SA header fields, i.e. before the EtherType field in Ethernet_II frames (the Length field in legacy 802.3 ethernet frames). This means "legacy" implementations who doesn't understand 802.1Q and looks for Length/EtherType at a given offset in the Ethernet header will instead find "8100", the Tag Protocol Identifier in 802.1Q. These legacy implementations will therefore typically discard the packet. With this in mind, it was anticipated that devices who knew how to handle 802.1Q header fields would also be designed to handle the added 4 bytes to the total frame length. This however was the topic for a lot of the discussion, since a lot of vendors could easily adapt their software to understand the required headers, but allowing for longer frame lengths quickly ran into hardware issues. So provisions were made in the standard to allow for devices to reduce the maximum payload size to 1496 if they can not handle frames exceeding 1518 bytes total length. This is however left as an implementation detail, and it is up to the vendors and/or end-users to make sure all devices connected to a given Ethernet only use 1496 bytes data segments if using this "legacy compatibility" provision in the standard. > I would suggest, though, that L2 switches shouldn't be boundaries > for this type of encapsulation, if this is the case. Worst case, > though, an attempt at PMTU through a switch that did this anyway > should end up with whatever MTU the host has setup. > > I expect that the 802.1q encapsulation of 1500 MTU packets (yielding > 1504 MTU packets on the wire) was actually intended to operate in > switch-to-switch trunking, not sitch-to-host trunking. Indeed, the primary point of the 802.1Q standard was to allow for fully transparent trunking in the bridge-to-bridge domain, typically by inserting the 802.1Q tag at the boundary of the "VLAN domain" and stripping it when the frame leaves the 802.1Q aware domain - usually at the switches where the end-stations are connected. > Effectively, this means the machine that's doing it's own VLAN > stuff is really a trunk endpoint, not a traditional ethernet > endpoint. Yes, any machine that handles "VLAN stuff" is now effectively an extended part of the bridge domain and is no longer really an Ethernet end-station. > I have no problem with this. > > I'm just pointing out that not all cards will be able to support > the idea, and that if you depend on arbitrary cards supporting > it, you are going to get shot in the foot. Again, this is stated in the standard. If wish to use 802.1Q trunking on "legacy" devices, then it is up to you to make sure all other devices participating in this given Ethernet adheres to using 1496 bytes as the maximum payload size, as there is obviously no way for the protocol to "negotiate" this, nor to return any form of error messages to any misbehaving hosts. Actually, I'd say that you probably should not be doing 802.1Q trunking at all on a NIC not capable of exceeding a max frame size of 1518 bytes, as you are almost certain to run into problems - with the possible exception of cases like e.g. a firewall hanging off a point-to-point connection with a router and handling multiple VLANs, where you can set the correct MTU on both sides. /leg