Ethernet Layer – Why Preamble is Not Considered Part of the Ethernet Header

ethernetlayer1layer2

If I search where does my data start in an Ethernet frame, I get a common answer which says TCP header( 20 bytes) + IP header ( 20 bytes) + Ethernet header( SA + DA + Type) i.e 14 bytes. So, in short the answer to that question becomes at 52-54 bytes the data starts in an Ethernet frame but shouldn't we add 8 bytes of preamble too in it ?
Also, I searched about ethernet frame size which is 1514 for ethernet frames. Why are we ignoring Preamble and CRC here ?

Best Answer

Adding to jonathanjo's answer:

Ethernet has components in both layers 1 (because it can run over different media) and 2 (because the frames are the same on the different media).

The Preamble, SoF Delimiter, and Inter-packet Gap are really in layer-1 (waking up the receiver, etc.), while the frame (including the header, payload, and FCS) is in layer-2.

The data in an ethernet frame is the payload of an ethernet frame. Your Question 1 assumes that every layer-3 protocol is IPv4, and every layer-4 protocol is TCP, which are bad assumptions. Ethernet doesn't know or care which layer-3 protocol it carries (IPv4, IPX, IPv6, AppleTalk, etc.), so the data of the frame is the payload. For example, the IPv4 packet header is 20 to 60 octets, while the IPv6 packet header is always 40 octets. Ethernet doesn't know this, it only knows that it has a payload field, not what is in that field.

The ethernet frame header is normally 14 octets, unless you have a tagged frame, then it is 18 octets. The MTU is the maximum payload size. Ethernet also has a minimum frame size of 64 octets, including the FCS, so the payload can range from 42 (with tag) or 46 (without tag) octets, up to the maximum payload size of 1500 octets. That means that ethernet frames (header and payload) are from 60 octets to 1514 (without tag) or 1518 (with tag) octets.

If by where the data starts, you mean application data, that is really going to depend on all the protocols. The UDP header is only 8 octets, and the UDP payload may be the application data, or it may be a datagram for an application-layer protocol that has its own header that may not be counted as application data. In your example of TCP, you may be running a web browser to a web server. Do you count HTTP (an application-layer-protocol) or HTML as the data (HTML is the data for HTTP)? When you refer to the data, it is relative to the protocol to which you are referring.

Regarding Path MTU Discovery

Ideally i would be relying on Path MTU discovery. But since the ethernet packets being generated are too large for any other machine to receive, there is no opportunity for IP Packet too big fragmentation messages to be returned

Based on your diagram, I agree that PMTUD cannot function between two different PCs in the same LAN segment; PCs do not generate ICMP Error messages required by PMTUD.

Jumbo frames

Some vendors (such as Cisco) have switch models which support ethernet payloads larger than 1500 bytes. Officially IEEE does not endorse this configuration, but the industry has valid needs to judiciously deviate from the original 1500 byte MTU. I have storage LAN / backup networks which leverage jumbo frame for good reason; however, I made sure that all MTUs matched inside the same vlan when I deployed jumbo frames.

Mismatched MTUs within a broadcast domain

The bottom line is that you should never have mismatched ethernet MTUs inside the same ethernet broadcast domain; if you do, it's a bug or configuration error. Regardless of bug or error, you have to solve these problems, sometimes manually.

All that discussion leads to the next question...

Why is there a spec that intentionally creates invalid ethernet frames?

I'm not sure that I agree... I don't see how the IEEE 802.3 series, or RFC 894 create invalid frames. Host implementations or host misconfigurations create invalid frames. To understand whether your implementation is following the spec, we need a lot more evidence...

This diagram is at least prima facie evidence that your MTUs are mismatched inside a broadcast domain...

+------------------+      +----------------+     +------------------+
| Realtek PCIe GBe |      | NetGear 10/100 |     | Realtek 10/100   |
|       (on-board) |      |     Switch     |     |     (on-board)   |
|                  |      +----------------+     |                  |
| Windows 7        |           ^    ^            |                  |
|                  |           |    |            |                  |
| 192.168.1.98/24  |-----------+    +------------| 192.168.1.10/24  |
| MTU = 1504 bytes |                             | MTU = 1500 bytes |
+------------------+                             +------------------+

How should an 802.3-compliant implementation respond to MTU mismatches?

What was it they [the writers of 'the spec'] expected people to do with devices that generate these too large packets?

MTU 1504 and MTU 1500 within the same broadcast domain is simply a misconfiguration; it should never be expected to work any more than mismatched IP netmasks, or mismatched IP subnets can be expected to work. Your company will have to knuckle-down and fix the root-cause of the MTU mismatches... at this time it's hard to say whether the root cause is user error, an implementation bug, or some combination of the above.

If the affected Windows machines are successfully logging into to an Active Directory Domain, one could write Windows login scripts to automatically fix MTU issues based on some well-constructed tests inside the domain login scripts (assuming the Domain Controller isn't part of the MTU issues).

If the machines are not logging into a domain, manual labor is another option.

Other possibilities to contain the damage

Use a layer3 switch^{Note 1} to build a custom vlan for anything that has broken MTUs and set the layer3 switch's ethernet MTU to match the broken machines; this relies on PMTUD to resolve MTU issues at the IP layer. Layer3 switches generate the ICMP errors required by PMTUD.

This option works best if you can re-address the broken machines with DHCP; and you can identify the broken machines by mac-address.

... why did they bump it up to 1504 bytes, and create invalid packets, in the first place?

Hard to say at this point

802.1ad vs 802.1q

How is IEEE 802.1ad (aka VLAN Tagging, QinQ) valid, when the packets are too large?

I haven't seen evidence so far that you're using QinQ; from the limited evidence I have seen so far, you're using simple 802.1q encapsulation, which should work correctly in Windows, assuming the NIC driver supports 802.1q encap.

End Notes:

^{Note 1}_{Any layer 3 switch should do... Cisco, Juniper, and Brocades all could perform this kind of function.}

Ethernet Frame Length and Babble – Understanding the Differences

1530 is including the layer-1 overhead (preamble and start frame) which you will never see without dedicated diagnostic gear, as the NIC won't present that to you. 1518 includes the FCS (CRC) which is technically part of the layer-2 information, but I've never seen a NIC pass that up the chain (read: wireshark can't show it.)

Interesting that you point to a Cisco 2900XL document. I know first hand the 2900XL crashes if you send it an "oversized" frame -- 802.1q tagged frame on a non-tagged port. (or was that the 3500XL)

If you ignore everything Cisco says, a babble is a transmitter not obeying the inter-packet gap -- sending frame after frame with little or no delay. That's a big problem for half-duplex networks.