Date: Thu, 06 Jul 2000 17:39:16 +0100 From: Tim Priebe <tim@polytechnic.edu.na> To: Luigi Rizzo <luigi@info.iet.unipi.it> Cc: tim@iafrica.com.na, David Gilbert <dgilbert@velocet.ca>, Kevin Oberman <oberman@es.net>, "Louis A. Mamakos" <louie@TransSys.COM>, Joerg Micheel <joerg@cs.waikato.ac.nz>, freebsd-stable@FreeBSD.ORG Subject: Re: Ethernet MTUs > 1500? Message-ID: <3964B634.DE74694B@polytechnic.edu.na> References: <200007061537.RAA85384@info.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3964B634.DE74694B>