|David Gilbert||Jul 3, 2000 8:22 pm|
|Joerg Micheel||Jul 3, 2000 8:38 pm|
|David Gilbert||Jul 3, 2000 8:43 pm|
|Louis A. Mamakos||Jul 3, 2000 8:52 pm|
|David Gilbert||Jul 3, 2000 9:37 pm|
|Louis A. Mamakos||Jul 3, 2000 10:08 pm|
|Tim Priebe||Jul 4, 2000 3:50 am|
|Kevin Oberman||Jul 4, 2000 4:24 pm|
|David Gilbert||Jul 4, 2000 6:46 pm|
|Tim Priebe||Jul 5, 2000 5:46 am|
|David Gilbert||Jul 5, 2000 6:20 am|
|Luigi Rizzo||Jul 5, 2000 8:16 am|
|Tim Priebe||Jul 5, 2000 9:56 am|
|Luigi Rizzo||Jul 5, 2000 11:39 pm|
|Tim Priebe||Jul 6, 2000 5:34 am|
|David Gilbert||Jul 6, 2000 5:47 am|
|Tim Priebe||Jul 6, 2000 8:04 am|
|Luigi Rizzo||Jul 6, 2000 8:28 am|
|Luigi Rizzo||Jul 6, 2000 8:37 am|
|Tim Priebe||Jul 6, 2000 9:38 am|
|Subject:||Re: Ethernet MTUs > 1500?|
|From:||Tim Priebe (ti...@polytechnic.edu.na)|
|Date:||Jul 6, 2000 9:38:54 am|
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.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message