Ethernet, Frames, and Thinking in Containers
Ethernet, Frames, and Thinking in Containers
Summary: Ethernet is the fundamental link technology underpinning modern networks. Born as a pragmatic engineering solution rather than a theoretical model, it carries data in strictly defined containers known as frames. Understanding Ethernet in physical, tangible terms—wires, limits, sizes, boundaries—makes concepts such as MTU, VLANs, broadcast behaviour, and encapsulation feel natural and intuitive rather than abstract.
Ethernet is simple, and that simplicity is its strength.
Context
Ethernet was created at Xerox PARC in the early 1970s to solve a practical problem: how to allow a cluster of machines to communicate over a shared medium with minimal coordination and maximal reliability. Importantly, Ethernet existed before the OSI model, before the TCP/IP suite was fully formed, and long before today’s rich networking abstractions.
The standards and models arrived later to describe existing behaviour—not to dictate Ethernet's design.
This reversal of history explains several of Ethernet’s enduring characteristics:
- Its design prioritises robustness and simplicity over strict layering.
- It assumes unreliable media and embraces best-effort delivery.
- It defines strict frame boundaries, because early LANs were noisy and needed them.
- It is intentionally agnostic about anything beyond the local wire.
Ethernet’s longevity comes from this engineering-first design philosophy.
A Note on Models
For clarity, this article uses the familiar five-layer TCP/IP model:
- Physical – signals exist
- Data Link – frames exist
- Network – packets exist
- Transport – conversations exist
- Application – meaning exists
Ethernet occupies only the first two layers. Once a frame delivers its payload to the Network layer, the link characteristics (VLANs, copper vs fibre, duplex settings, etc.) cease to matter entirely.
Everything above Layer 2 is indifferent to how the bits travelled.
What Ethernet Actually Does
Ethernet transports frames between directly connected devices. That is all. It does not:
- guarantee delivery
- acknowledge receipt
- retransmit lost frames
- perform routing
- ensure order
- manage congestion
These guarantees belong to higher layers.
Ethernet is intentionally minimalist. It sends bounded containers across a medium and trusts upper protocols to recover from loss or corruption. This simplicity is precisely why Ethernet has survived unchanged for over 40 years.
The Ethernet Frame
An Ethernet frame is a physical container. It has:
- a strict structure
- fixed-size header fields
- a defined minimum and maximum length
- explicit start and end boundaries
Ethernet Frame Structure
┌──────────────────────────────────────────────────────────────┐ │ Preamble (7) | SFD (1) │ ├──────────────────────────────────────────────────────────────┤ │ Destination MAC (6 bytes) │ ├──────────────────────────────────────────────────────────────┤ │ Source MAC (6 bytes) │ ├──────────────────────────────────────────────────────────────┤ │ 802.1Q VLAN Tag (4 bytes, optional) │ ├──────────────────────────────────────────────────────────────┤ │ EtherType / Length (2 bytes) │ ├──────────────────────────────────────────────────────────────┤ │ Payload (46–1500 bytes) │ ├──────────────────────────────────────────────────────────────┤ │ Frame Check Sequence – FCS (4 bytes) │ └──────────────────────────────────────────────────────────────┘
Field Breakdown
Preamble Seven bytes used for clock synchronisation. Consumed/stripped by hardware; not present in captures.
Start Frame Delimiter (SFD) Marks the start of the meaningful part of the frame.
Destination MAC The intended recipient. Supports unicast, multicast, and broadcast.
Source MAC The sender. Switches learn MAC-to-port mappings from this field.
802.1Q VLAN Tag (optional) Adds tagging and priority metadata. The underlying frame remains unchanged; the tag is simply inserted between Source MAC and EtherType.
EtherType / Length Indicates the payload protocol (IPv4, IPv6, ARP, LLDP, etc.).
Payload The encapsulated upper-layer data—commonly an IP packet.
Frame Check Sequence A CRC32 checksum enabling error detection. Corrupt frames are silently discarded.
Encapsulation as Containers
A powerful way to understand networking is to think of every layer as a container within a container. Ethernet does not interpret its payload; it merely wraps it and forwards it. Likewise, IP wraps transport segments, and transport wraps application data.
Nothing is rewritten. Nothing is interpreted early. Everything is simply wrapped and handed off.
Container Model
┌─────────────────────────────────────────────┐ │ Ethernet Frame │ │ ┌─────────────────────────────────────────┐ │ │ │ IP Packet │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ │ │ TCP / UDP Segment │ │ │ │ │ │ ┌─────────────────────────────────┐ │ │ │ │ │ │ │ Application Data │ │ │ │ │ │ │ └─────────────────────────────────┘ │ │ │ │ │ └─────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────┘ │ └─────────────────────────────────────────────┘
Each layer:
- adds a header
- may add a trailer
- has a maximum size
- treats the payload as opaque
MTU: When Containers Must Fit
The MTU (Maximum Transmission Unit) defines the largest payload an Ethernet frame may carry. Exceed it, and something must give:
- fragmentation
- silent drops
- intermittent failures
- path-dependent behaviour
Historically, heterogeneous networks made MTU management a daily concern. Even today, tunnels, overlays, and VPN stacks make MTU a source of subtle breakage.
MTU is not an abstract parameter—it is a physical limitation of a physical container.
VLANs and Thicker Containers
A VLAN tag increases the frame size by 4 bytes. A tagged frame is simply a slightly thicker container. It is still Ethernet. It still obeys the same behaviours and limitations.
However, the added overhead matters when:
- tunnelling multiple layers of encapsulation
- approaching MTU limits
- mixing devices that enforce strict maximum sizes
Failure to account for “container stacking” is a common source of path MTU issues.
Switching, Broadcast, and Behaviour
Ethernet switches forward frames based on MAC learning. Broadcast and unknown-destination traffic is flooded within the broadcast domain.
Broadcast is not a flaw—it is a feature used for:
- ARP
- IPv6 Neighbour Discovery
- DHCP
- service discovery protocols
But broadcast domains must be intentionally bounded. Unmanaged switches will happily forward every frame, including VLAN-tagged traffic, without enforcing any form of segmentation or intent.
Control Plane Reality
Ethernet itself includes no loop prevention. A single unintended loop can saturate a network almost instantly.
Control-plane protocols that compensate for this include:
- STP / RSTP
- MST
- LACP
- Vendor-specific loop guard features
Layer 2 problems often manifest as:
- intermittent slowness
- high CPU usage
- flapping links
- application timeouts
Industrial and Constrained Networks
In industrial environments, determinism and predictability matter more than raw bandwidth. Historically, systems used:
- serial links
- fieldbuses
- packet radio
- fixed-size frames
These environments make the physical constraints of framing impossible to ignore.
Common Pitfalls
- Treating VLANs as security boundaries
- Allowing broadcast domains to grow too large
- Assuming switches are just plugboards
- Overusing VLANs
- Ignoring encapsulation overhead
- Designing redundant links without loop prevention
- Failing to account for MTU mismatches
Why This Still Matters
Modern networks abstract away many physical details—but they do not eliminate them. Overlays, VPNs, wireless links, packet radio, and virtualised infrastructure all reintroduce the same constraints.
Networks fail when we forget that every packet is simply a box that has to fit.
