bge & vlan stranges

[Lars Erik Gullerud]

On Sun, 2003-08-03 at 02:28, Terry Lambert wrote:

> >   The fact of the matter is, if you use 802.1q encapsulation, the total
> > frame size can be 1504.  That is the standard.
> 
> This is truly evil.

Actually, after a lot of discussions over this very topic during the
IEEE ratification process, the 802.1Q standard allows for both
varieties. The 1522 total frame size has become the de-facto standard
though, for pretty obvious reasons. If I was down at the office now, I
could have looked up the relevant sections of the standard and related
notes, but since I'm not, this is taken from memory.

You all probably this part, but the 802.1Q header is inserted directly
behind the DA/SA header fields, i.e. before the EtherType field in
Ethernet_II frames (the Length field in legacy 802.3 ethernet frames).
This means "legacy" implementations who doesn't understand 802.1Q and
looks for Length/EtherType at a given offset in the Ethernet header will
instead find "8100", the Tag Protocol Identifier in 802.1Q. These legacy
implementations will therefore typically discard the packet.

With this in mind, it was anticipated that devices who knew how to
handle 802.1Q header fields would also be designed to handle the added 4
bytes to the total frame length. This however was the topic for a lot of
the discussion, since a lot of vendors could easily adapt their software
to understand the required headers, but allowing for longer frame
lengths quickly ran into hardware issues.

So provisions were made in the standard to allow for devices to reduce
the maximum payload size to 1496 if they can not handle frames exceeding
1518 bytes total length. This is however left as an implementation
detail, and it is up to the vendors and/or end-users to make sure all
devices connected to a given Ethernet only use 1496 bytes data segments
if using this "legacy compatibility" provision in the standard.

> I would suggest, though, that L2 switches shouldn't be boundaries
> for this type of encapsulation, if this is the case.  Worst case,
> though, an attempt at PMTU through a switch that did this anyway
> should end up with whatever MTU the host has setup.
> 
> I expect that the 802.1q encapsulation of 1500 MTU packets (yielding
> 1504 MTU packets on the wire) was actually intended to operate in
> switch-to-switch trunking, not sitch-to-host trunking.

Indeed, the primary point of the 802.1Q standard was to allow for fully
transparent trunking in the bridge-to-bridge domain, typically by
inserting the 802.1Q tag at the boundary of the "VLAN domain" and
stripping it when the frame leaves the 802.1Q aware domain - usually at
the switches where the end-stations are connected.

> Effectively, this means the machine that's doing it's own VLAN
> stuff is really a trunk endpoint, not a traditional ethernet
> endpoint.

Yes, any machine that handles "VLAN stuff" is now effectively an
extended part of the bridge domain and is no longer really an Ethernet
end-station.

> I have no problem with this.
> 
> I'm just pointing out that not all cards will be able to support
> the idea, and that if you depend on arbitrary cards supporting
> it, you are going to get shot in the foot.

Again, this is stated in the standard. If wish to use 802.1Q trunking on
"legacy" devices, then it is up to you to make sure all other devices
participating in this given Ethernet adheres to using 1496 bytes as the
maximum payload size, as there is obviously no way for the protocol to
"negotiate" this, nor to return any form of error messages to any
misbehaving hosts.

Actually, I'd say that you probably should not be doing 802.1Q trunking
at all on a NIC not capable of exceeding a max frame size of 1518 bytes,
as you are almost certain to run into problems - with the possible
exception of cases like e.g. a firewall hanging off a point-to-point
connection with a router and handling multiple VLANs, where you can set
the correct MTU on both sides.

/leg