Ethernet, Frames, and Thinking in Containers
Ethernet, Frames, and Thinking in Containers
Summary: Ethernet is the foundational link technology of modern networking. It was designed as a practical engineering solution long before formal network-layer models existed. Understanding Ethernet frames and encapsulation as physical containers makes concepts such as MTU, VLANs, and packetisation intuitive rather than abstract.
Context
Ethernet was developed at Xerox PARC in the early 1970s to solve a local problem: connecting many machines to shared resources efficiently. It existed and worked well before formal networking models such as OSI or TCP/IP were defined.
The models came later to describe existing behaviour, not to govern Ethernet’s original design. This historical ordering explains many of Ethernet’s enduring characteristics and quirks.
A Note on Models
This article uses a simplified five-layer TCP/IP model because it aligns well with how Ethernet is actually deployed and troubleshot:
- Physical – signals exist
- Data Link – frames exist
- Network – packets exist
- Transport – conversations exist
- Application – meaning exists
Ethernet lives primarily in the Physical and Data Link layers. Once traffic reaches the Network layer, VLANs and media type no longer exist.
What Ethernet Actually Does
Ethernet moves frames across a local medium. It does not guarantee delivery. It does not provide end-to-end reliability. It delivers best-effort frames and leaves recovery to higher layers.
This simplicity is intentional and is a key reason Ethernet has survived decades of change.
The Ethernet Frame
An Ethernet frame is a container. It has a fixed structure, a size budget, and clear 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 Used for clock synchronisation. Handled entirely by hardware and not visible in packet captures.
Start Frame Delimiter (SFD) Marks the start of the actual frame.
Destination MAC Identifies the intended recipient. May be unicast, multicast, or broadcast.
Source MAC Identifies the sender. Switches learn MAC locations from this field.
802.1Q VLAN Tag (optional) Adds context to the frame. The original Ethernet frame remains intact; the tag simply identifies the broadcast domain and priority.
EtherType / Length Identifies the payload type (for example IPv4, IPv6, ARP).
Payload Encapsulated data from higher layers. Often an IP packet.
Frame Check Sequence CRC checksum for error detection. Corrupt frames are discarded silently.
Encapsulation as Containers
A practical way to understand networking is to think in terms of containers.
Each layer wraps the one above it, adds a header, and passes the whole container downwards.
Nothing is rewritten. Nothing is interpreted early. Everything is just wrapped.
Container Model
┌─────────────────────────────────────────────┐ │ Ethernet Frame │ │ ┌─────────────────────────────────────────┐ │ │ │ IP Packet │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ │ │ TCP / UDP Segment │ │ │ │ │ │ ┌─────────────────────────────────┐ │ │ │ │ │ │ │ Application Data │ │ │ │ │ │ │ └─────────────────────────────────┘ │ │ │ │ │ └─────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────┘ │ └─────────────────────────────────────────────┘
Each container has:
- A header
- A payload
- A maximum size
This is why framing and packetisation feel natural once you’ve seen them physically.
MTU: When Containers Must Fit
MTU (Maximum Transmission Unit) defines the largest payload that can fit inside an Ethernet frame.
Historically, engineers often had to calculate MTU values explicitly to ensure frames would traverse every hop without fragmentation. Heterogeneous links, tunnelling, and unreliable Path MTU Discovery meant that oversized packets could fail silently.
If a container does not fit:
- It may fragment
- It may be dropped
- Or it may fail intermittently
This is not abstract theory. It is physical constraint.
VLANs and Thicker Containers
VLAN tagging slightly increases the size of the Ethernet container.
A VLAN-tagged frame is still Ethernet. It is simply a thicker box. This matters when MTU margins are tight or when multiple layers of encapsulation are present.
Switching, Broadcast, and Behaviour
Switches forward frames based on MAC addresses. Broadcast traffic is flooded within a broadcast domain.
Broadcast is not a flaw. It is a design feature that must be intentionally bounded.
Unmanaged switches typically forward frames without interpreting VLAN tags. This behaviour is correct, but it can undermine architectural assumptions if intent is not enforced elsewhere.
Control Plane Reality
Ethernet has no built-in loop prevention. Protocols such as Spanning Tree exist to prevent catastrophic loops, but they introduce control-plane complexity.
Problems in the control plane often present as physical or application faults. This makes Layer 2 issues particularly difficult to diagnose.
Industrial and Constrained Networks
Switched Ethernet is excellent for enterprise environments. Some industrial and constrained systems historically favoured direct links or specialised protocols to achieve determinism and predictable timing.
Packet radio, serial links, and early LANs make framing constraints visible again. They reward careful thinking about container size, retries, and shared media behaviour.
Common Pitfalls
- Treating VLANs as security boundaries
- Assuming switches behave like simple repeaters
- Oversized Layer 2 domains
- Excessive VLAN sprawl
- Ignoring MTU and encapsulation overhead
- Redundant links without clear loop prevention
Why This Still Matters
Modern networks hide many of these constraints, but they do not remove them.
VPNs, tunnels, overlays, wireless, and packet radio all bring framing limits back into focus. Engineers who understand frames as containers recognise these issues early.
Networks fail when we forget that every packet is just a box that has to fit.
