From owner-freebsd-stable Thu Jul 6 9:39: 3 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mail.polytechnic.edu.na (mail.polytechnic.edu.na [196.31.225.2]) by hub.freebsd.org (Postfix) with ESMTP id 0618837C45B for ; Thu, 6 Jul 2000 09:38:50 -0700 (PDT) (envelope-from tim@polytechnic.edu.na) Received: from ns1.horizon.na ([196.31.225.199] helo=polytechnic.edu.na) by mail.polytechnic.edu.na with esmtp (Exim 3.02 #2) id 13AGYG-0002kK-00; Thu, 06 Jul 2000 16:39:08 -0200 Message-ID: <3964B634.DE74694B@polytechnic.edu.na> Date: Thu, 06 Jul 2000 17:39:16 +0100 From: Tim Priebe Reply-To: tim@iafrica.com.na X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: tim@iafrica.com.na, David Gilbert , Kevin Oberman , "Louis A. Mamakos" , Joerg Micheel , freebsd-stable@FreeBSD.ORG Subject: Re: Ethernet MTUs > 1500? References: <200007061537.RAA85384@info.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > > > An Ethernet frame with vlan tagging does _not_ have an extra header etc, > > however you see it, it's the original bits plus some extra bits! > > > When a tagged packet must be sent out ports that are not tagged for that > > vlan, the reverse process occures. The tagged header is removed, and > > replaced with a new one. Obviously new CRC values are generated each > > i am not sure about this one: my understandinbg reading the > spec (18months ago) was that tagged packets only go out on trunk > interfaces (unmodified) or on interfaces tagged for that VLAN (this > time they are untagged). Sorry I was not clear, the tagged header is replaced with an untagged one. > > If the switch does some thing strange, like using different vlan tag > > values for the same vlan on different interfaces, then it would have to > > change the tag value, and recalculate the CRC. This is too complex a > > Why are you so worried by the CRC, which is compuited on the fly > by the interface as bits are sent on the wire ? I almost said nothing about the CRC, but since the confusion seemed to be around encapsulation, which normally takes an entire packet or frame, and encapsulates it in a new packet or frame, that is typically - new header - original packet or frame - new CRC -, therefor I mentioned it. > > > I do know how my FreeBSD-based > > > vlan bridge behaves -- it does multiple encaps, but then if a > > > packet becomes too large it is silently dropped by the interface. > > > > If it encapsulates the the original frame including the original headers > > in a new ethernet frame, then it is doing it wrong, and can not be > > expected to interoperate with a bridge that does it right. Your frames > > sorry i used the wrong terminology -- i said "encapsulate/decapsulate" but > meant "tag/untag" -- and it did interoperate with a real VLAN bridge (802.1Q) I did not mean to be argumentative, only that it be clear that we are only talking about 4 extra bytes, and that it would be in conformance to the standards, which someone seemed to disagree with on a previous such thrread on a FreeBSD list. It is important to me that this works properly, but my employer will insist that we move to Linux, if I have to patch the system after every upgrade. Tim. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message