Date: Thu, 06 Jul 2000 13:34:42 +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: <39647CE2.C1D11DD5@polytechnic.edu.na> References: <200007060640.IAA82096@info.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > > > > just curious, what do we do when we have multiple encapsulation ? > > > (i.e. is this allowed ?) > .. > > I am not sure what you mean. If you mean "VLAN encapsulation", then it > > is a misunderstanding. The standard Ethernet frame is not encapsulated. > > ok think of the following: I have a st machine which goes through > a VLAN bridge out to a trunk interface, which in turn goes into > a VLAN bridge which does trunkinking again ... basically you might > end up with frames being encapsulated multiple times (and decapsulated > on the reverse path). Now i wonder if this is allowed by the vlan spec An Ethernet frame with vlan tagging does _not_ have an extra header etc, that encapsulates the the original frame. When a Frame that was not tagged is tagged by a bridge, the original header is removed, the information from the original header is used to create a new header, with the vlan tag. The new header and the data from the original frame are used to create a new frame. 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 time the header is replaced. If the the frame has a vlan tag, and is to be sent out an interface that it needs to be tagged on, then it does not need any modification, as stated it is already has the vlan tag. 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 solution, when the standard specifies that you can have 4095 vlans (if my memory serves me correctly). > and also how does a vlan bridge behaves when it sees a vlan-tagged > frame on a non-trunk port. This probably depends on the switch. The 3Com 1100 and 3300 can be set to learn what vlans can be sent out a port based on the vlans it sees coming in through that port. > 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 will be able to pass through a standard bridge, but it will not be able to restore the original frame that your system has encapsulated. Everything I say above presuposes we are talking about 802.1Q, and not some vendor specific vlan implementation. 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?39647CE2.C1D11DD5>