First, my apologizes if my vocabulary is imprecise/incorrect... But I am a server guy, not a network expert.
I have a question regarding VLAN tagged ethernet frame. What's is the minimal size of such ethernet frame? 64 bytes or 68 bytes? (not counting the preamble/SFD that had nothing to the present discussion).
From my understanding, both can happen:
1) Some implementation reduce the data payload to 42 minimun in order to insert the 4 bytes needed for the VLAN tagging; leading to eventually tagged frame of min. 64 bytes.
2) Other implementations will increase the ethernet frame of 4 bytes for the tag, leading to a frame of min. 68 bytes.
The problem I am facing is that the switch strip the 4 bytes VLAN tag before passing the packet to the server. If a 64 bytes frame is sent to that switch (case 1), then a 60 bytes frame is passed to the server after stripping. The server's ethernet driver shall drop this packet, because the sanity check "Ethernet frame is at least 64 bytes long" isn't fulfilled. Causing many headaches like ssh connections does not work etc. Of course, if the switch receives a 68 bytes frame, then everything is fine.
What does the standard say about this? Is there a standard specifying a min. size for the ethernet frame of 68 bytes?
The minimum size for any Ethernet frame is 64 bytes (512 bits). I don't see that the VLAN tag changes that minimum size.
In minimum size frames, I would expect that most of the time, the Ethernet payload consists of a lot of pad bytes. Not real data content at all. So I don't think it matters very much whether some Ethernet driver wants to add more pad bytes than necessary. I don't know whether this is common practice or not. It seems wasteful to me, to pad more than necessary.
This should never happen. It is the responsibility of the switch to create the correct frame format (i.e. VLAN tagged or not VLAN tagged, depending on the config of that port), and to ensure that any frame transmitted from any of its ports is no less than 64 bytes long.
I was just wondering why the 64 byte minimum is still there for full-duplex ethernet. The physical reason for it is gone. Gigabit doesn't do frame extension for full duplex. I don't remember seeing this discussed before, though.
I discuss it in Chapter 7 of "The Switch Book" (section 7.3.6). Here is the relevant excerpt:
7.3.6. Ethernet Minimum Frame Size Constraint
Commercially-available Ethernet existed in its half duplex only incarnation for over 15 years before the networking environment could support (and the standards recognized and legitimized) the use of full duplex mode. Because of this history, there is a huge installed product base (and knowledge base) surrounding half duplex Ethernet. In order to allow a peaceful coexistence between the half and full duplex modes, we chose to retain a certain amount of baggage from half duplex Ethernet in the full duplex version.
While there is no need for a minimum frame length in full duplex mode, retaining this restriction allows device drivers and higher-layer software to treat both flavors of Ethernet (full and half duplex) identically.
Also, consider what would happen in a switched environment where some of the switch ports were operating in half-duplex mode (with the minimum frame length constraint) and others were operating in full duplex mode (with no minimum length constraint). If a short frame were received from a full duplex port that needed to be forwarded to a half-duplex port, the frame would have to be either discarded or padded. Any padding would require a change to the FCS, reducing the robustness of error detection. In addition, if a short multicast frame were being forwarded to a combination of full duplex and half duplex ports, the same frame would take different forms, and require different transmission times. This unnecessarily complicates switch design. Thus, maintaining the minimum frame length restriction in full duplex mode allows for seamless bridging between half duplex and full duplex Ethernets.
Rich Seifert wrote: (big snip regarding minimum frame length on full duplex ethernet)
This is pretty close to the previous post where VLAN tagged 64 byte frames need to be padded and a new CRC computed when the tag is removed. I suppose you can expect more processing power from VLAN switches, though.
I think, though, that you can compute the new CRC based on the old one such that error detection robustness is retained.