Ethernet Frames, Links & Auto-Negotiation

Ethernet is not one cable, connector, line code, or speed. It is a family whose common MAC service carries recognizable frames across PHYs selected for copper, fiber, backplanes, access networks, vehicles, and other environments. Keeping the frame, link mode, and physical signalling separate prevents most Ethernet reasoning errors.

A link can report carrier while losing frames, a packet capture can omit the preamble and FCS, and two interfaces can be electrically compatible yet disagree about duplex or pause behavior. Diagnosis therefore needs evidence from both partners and from the right observation boundary.

The three boundaries #

IEEE 802.3 deliberately supports many speed-specific media-independent interfaces and PHYs under a common MAC specification. A fault at one boundary does not identify the others: link up proves enough physical-layer agreement to establish a link, not correct VLAN membership, usable MTU, error-free delivery, or application reachability.

What is in an Ethernet frame? #

For a conventional untagged frame:

The result is 64–1518 octets from destination address through FCS for the conventional untagged format. A single IEEE 802.1Q tag contributes four more octets inside the frame, before the original Length/Type field. The seven-octet preamble, one-octet start-frame delimiter, and minimum interpacket gap are transmission overhead but are not delivered as MAC client data.

The distinction matters when calculating utilization. Carrying a full 1500-octet IP packet in an untagged Ethernet frame consumes:

$$8\ \text{preamble/SFD} + 14\ \text{MAC header} + 1500\ \text{payload} + 4\ \text{FCS} + 12\ \text{interpacket gap} = 1538\ \text{octet-times}.$$

At 1 Gb/s this is $1538 \times 8 / 10^9 = 12.304\ \mu\text{s}$ before considering higher-layer acknowledgements, queueing, or other traffic. A 1500-byte interface MTU normally describes the maximum network-layer packet carried as Ethernet payload; it is not the complete on-medium footprint.

Length, EtherType, and demultiplexing #

The two-octet field after the source address has two interpretations:

• values at most 1500 state the MAC client-data length, with another sublayer identifying the upper protocol;
• values at least 1536 are EtherTypes that directly identify the carried protocol or encapsulation;
• the interval 1501–1535 is intentionally not used to choose either interpretation.

Ethernet II is the common direct-EtherType form. IPv4 uses 0x0800; an 802.1Q customer VLAN tag is introduced by tag protocol identifier 0x8100. The maintained registry is the authority for assignments; recognizing a familiar hexadecimal value is not evidence that the payload itself is valid.

Padding belongs to the Ethernet frame, not to the upper packet. For example, an IPv4 receiver uses the IPv4 Total Length field to distinguish its datagram from any Ethernet pad. This is why a decoder must respect length fields at each layer rather than treating every captured trailing byte as application data.

MAC addresses are scoped identifiers #

An ordinary Ethernet MAC address is 48 bits. The low-order bit of the first transmitted octet distinguishes an individual address from a group address; the next bit distinguishes universally administered from locally administered address space. ff:ff:ff:ff:ff:ff is the all-stations broadcast address within a broadcast domain.

A MAC address is not an end-to-end Internet identity. Routers terminate one link-layer frame and create another for the next link, so source and destination MAC addresses change across routed hops while network-layer addresses can remain. Virtual machines, containers, bonds, bridges, and locally administered addresses also break the assumption that one burned-in address permanently identifies one physical box.

FCS detects corruption; it does not repair it #

The transmitting MAC computes a CRC over the protected frame fields and sends the result as the FCS. A receiver recomputes it and discards a frame that fails validation. There is no Ethernet acknowledgement or retransmission in the ordinary MAC service; recovery, if required, belongs to a higher layer or another link-specific mechanism.

Many NICs validate and remove the FCS before the host capture path. Consequently:

• a normal host capture often contains neither preamble nor FCS;
• a bad frame may increment a NIC or switch counter but never reach Wireshark;
• an apparent higher-layer checksum problem on locally transmitted traffic may instead reflect checksum offload, not an Ethernet FCS failure.

Treat the capture file and interface counters as different observation planes, not competing versions of the same evidence.

Half duplex, full duplex, and collisions #

In half-duplex shared-medium Ethernet, a station senses the medium, transmits when idle, detects a collision while transmitting, and retries after a randomized backoff. Propagation delay makes collisions possible even when both stations sense before sending. Slot time and network-diameter constraints ensure that a valid collision is detected before a transmission is mistaken for success.

Full-duplex Ethernet uses a point-to-point link with simultaneous transmit and receive paths. There is no shared contention domain, so CSMA/CD, collision windows, and backoff do not govern data transfer. Queues can still overflow and frames can still be corrupted or discarded; “no collisions” does not mean “no congestion or loss.”

Hubs, coax segments, and repeater-diameter calculations are now primarily diagnostic history. They explain legacy captures and counters, but a normal switched link should operate full duplex.

What auto-negotiation actually resolves #

Auto-negotiation lets link partners advertise supported modes and apply a defined priority to select a mutually supported technology. Depending on the PHY, advertised abilities can include rate, duplex, pause behavior, and other mode-specific capabilities. The result is a pairwise agreement; reading only one end is incomplete evidence.

A frequent failure pattern is asymmetric configuration:

1. one side is forced to a speed and duplex instead of advertising normally;
2. the other side detects enough signalling to establish a link but cannot learn the forced duplex setting;
3. the auto side falls back according to its detection rules while the forced side remains full duplex;
4. traffic passes at low load, then degrades asymmetrically under concurrent transmission.

On the half-duplex side, collisions or late collisions can rise. On the full-duplex side, corrupted receive frames and FCS-related counters can rise because it interprets the partner's collision behavior as data corruption. The decisive test is not “both links are green”; it is agreement on the resolved mode plus stable counters under bidirectional load.

For ordinary twisted-pair Ethernet, the safe operational default is auto-negotiation at both ends unless the applicable PHY or device documentation requires another mode. Forcing both ends can create a deliberate fixed mode; forcing only one end creates ambiguity.

Pause is link flow control, not congestion control #

Full-duplex Ethernet can negotiate link-level pause behavior. A receiver may ask its directly attached peer to stop transmitting for a bounded interval. This can prevent a local receive queue from overflowing, but it does not identify which application or transport caused the pressure.

Pause can therefore move congestion upstream and couple otherwise unrelated flows. It is not a replacement for queue design, transport congestion control, or admission policy. Diagnose it by correlating pause-frame and queue-drop counters at both ends; a link with few drops but sustained pause may still be the point where congestion propagates.

A link diagnosis sequence #

Start at the physical boundary and move upward only when the evidence agrees:

1. Identity and topology: confirm the exact local interface, remote port, transceiver/cable path, and any intermediate patching.
2. Administrative and carrier state: distinguish disabled, no carrier, and operationally up.
3. Resolved mode at both ends: compare speed, duplex, auto-negotiation, lane/PHY mode, and pause resolution.
4. Monotonic counters: sample twice across a controlled interval. Look for carrier transitions, symbol/alignment errors, FCS errors, late collisions, pause frames, and ingress/egress discards.
5. Frame semantics: confirm expected source/destination addresses, EtherType, VLAN treatment, and payload size at the correct observation point.
6. Bidirectional test: exercise both directions. A unidirectional light path, pair fault, or duplex mismatch can pass a one-way probe.
7. Change one component: swap or reconfigure only one cable, optic, port, or advertised mode, then repeat the same observation.

Counters need a denominator and a time window. Ten FCS errors in ten frames is catastrophic; ten in $10^{12}$ frames may be an intermittent physical issue but cannot be interpreted without rate and timing. Clearing counters can simplify a test only when doing so is authorized and the previous evidence has been preserved.

Common reasoning traps #

• “The Ethernet frame is everything visible on the wire.” Preamble, SFD, and the interpacket gap consume time but are not normally delivered in a host packet capture.
• “A bad FCS should appear in tcpdump.” Commodity receive hardware usually drops it before the host capture boundary.
• “Link up proves the cable is good.” Marginal signalling, a one-direction fault, or mismatched mode can establish carrier and still lose traffic.
• “No collisions means the link is healthy.” Full-duplex links should have no collisions, but can have FCS errors, queue drops, pause storms, or incorrect VLAN/MTU configuration.
• “A faster PHY changes Ethernet addressing.” PHY selection changes signalling and reach; the MAC frame and forwarding semantics remain the relevant link-layer contract.
• “Jumbo frames are automatically negotiated.” A larger configured MTU is a network design choice that must be supported consistently along the path; ordinary link auto-negotiation does not prove end-to-end jumbo-frame compatibility.