From owner-freebsd-stable Thu Nov 4 10:34:22 1999 Delivered-To: freebsd-stable@freebsd.org Received: from tricord.system.pl (tricord.system.pl [195.205.185.10]) by hub.freebsd.org (Postfix) with ESMTP id 42E0C14DF6 for ; Thu, 4 Nov 1999 10:33:55 -0800 (PST) (envelope-from saper@system.pl) Received: from localhost (saper@localhost [127.0.0.1]) by tricord.system.pl (SYSTEM Internet) with ESMTP id TAA23511 for ; Thu, 4 Nov 1999 19:33:31 +0100 (MET) Date: Thu, 4 Nov 1999 19:33:27 +0100 (MET) From: Marcin Cieslak To: freebsd-stable@FreeBSD.ORG Subject: Re: VLAN support in -stable? In-Reply-To: <99110417075801.77033@310.priebe.alt.na> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have just come across a big problem using vlans on a FreeBSD box. The mtu on > the vlan interfaces is only 1496 bytes, the problem is that any packets > destined for the Interface larger than this are just thrown away. The solution > to this problem seems to be to allow larger ethernet packets, or to set the mtu > on all the other systems on the vlan to 1496. The second solution is not > practical for some of my networks, I will be looking at this more next week. The problem is more complex, afaik. Recently, I attended a training by a reputable hardware vendor and the guys noted few problems with IEEE 802.1p and Q standards. They require that _hardware_ should accept a longer packets, because 802.1p/Q add extra 4 bytes to the ethernet frame. Therefore, all Ethernet equipment on a network using VLAN must accept longer packets, and that's what vendors say that they are 802.1p/Q compliant. Usually, frames larger than old Ethernet maximum are thrown away and counted as "giants". The vendor reps really doubted if there is a chance to deploy those standards on a large network; they also pointed that this is a big problem to Ethernet switch vendors, since this problem is not so easy to solve in software. Even if all FreeBSD drivers would support larger packets with new MTU still 1500, the problem is the underlying hardware, not only NICs, but hubs, switches, etc. and this is a real problem in employing 802.1p/Q standards, not understanding an extra field. However, I haven't confirmed this from indepenent source, but the argumentation seems reasonable. Cisco ISL seems to encapsulate a whole packet, and has similar problem: (from http://www.cisco.com/warp/public/741/4.html): The biggest implication for systems using ISL encapsulation is that the encapsulation is a total of 30 bytes and fragmentation is not required. Therefore, if the encapsulated packet is 1518 bytes long, the ISL packet will be 1548 bytes long. Additionally, if packets other than Ethernet packets are encapsulated, the maximum length can be greatly increased. This length change must be considered when evaluating whether a MAC can support ISL packets. -- << Marcin Cieslak // saper@system.pl >> ----------------------------------------------------------------- SYSTEM Internet Provider http://www.system.pl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message