Ethernet, Frames, and Thinking in Containers: Difference between revisions
Created page with "= 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 loca..." |
No edit summary |
||
| Line 2: | Line 2: | ||
'''Summary:''' | '''Summary:''' | ||
Ethernet is the | 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 == | == Context == | ||
Ethernet was | 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 == | == A Note on Models == | ||
For clarity, this article uses the familiar five-layer TCP/IP model: | |||
* Physical – signals exist | * Physical – signals exist | ||
* Data Link – frames exist | * Data Link – frames exist | ||
| Line 18: | Line 27: | ||
* Application – meaning exists | * Application – meaning exists | ||
Ethernet | 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 == | == What Ethernet Actually Does == | ||
Ethernet | 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. | |||
This simplicity is | 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 == | == The Ethernet Frame == | ||
An Ethernet frame is a container. It has a fixed | 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 === | === Ethernet Frame Structure === | ||
<pre> | <pre> | ||
┌──────────────────────────────────────────────────────────────┐ | ┌──────────────────────────────────────────────────────────────┐ | ||
| Line 44: | Line 66: | ||
│ Payload (46–1500 bytes) │ | │ Payload (46–1500 bytes) │ | ||
├──────────────────────────────────────────────────────────────┤ | ├──────────────────────────────────────────────────────────────┤ | ||
│ Frame Check Sequence – FCS (4 bytes) | │ Frame Check Sequence – FCS (4 bytes) │ | ||
└──────────────────────────────────────────────────────────────┘ | └──────────────────────────────────────────────────────────────┘ | ||
</pre> | </pre> | ||
=== Field Breakdown === | === Field Breakdown === | ||
'''Preamble''' | '''Preamble''' | ||
Seven bytes used for clock synchronisation. Consumed/stripped by hardware; not present in captures. | |||
'''Start Frame Delimiter (SFD)''' | '''Start Frame Delimiter (SFD)''' | ||
Marks the start of the | Marks the start of the meaningful part of the frame. | ||
'''Destination MAC''' | '''Destination MAC''' | ||
The intended recipient. Supports unicast, multicast, and broadcast. | |||
'''Source MAC''' | '''Source MAC''' | ||
The sender. Switches learn MAC-to-port mappings from this field. | |||
'''802.1Q VLAN Tag (optional)''' | '''802.1Q VLAN Tag (optional)''' | ||
Adds | Adds tagging and priority metadata. The underlying frame remains unchanged; the tag is simply inserted between Source MAC and EtherType. | ||
'''EtherType / Length''' | '''EtherType / Length''' | ||
Indicates the payload protocol (IPv4, IPv6, ARP, LLDP, etc.). | |||
'''Payload''' | '''Payload''' | ||
The encapsulated upper-layer data—commonly an IP packet. | |||
'''Frame Check Sequence''' | '''Frame Check Sequence''' | ||
A CRC32 checksum enabling error detection. Corrupt frames are silently discarded. | |||
== Encapsulation as Containers == | == Encapsulation as Containers == | ||
A | 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 rewritten. | ||
Nothing is interpreted early. | Nothing is interpreted early. | ||
Everything is | Everything is simply wrapped and handed off. | ||
=== Container Model === | === Container Model === | ||
<pre> | <pre> | ||
┌─────────────────────────────────────────────┐ | ┌─────────────────────────────────────────────┐ | ||
| Line 100: | Line 118: | ||
</pre> | </pre> | ||
Each | Each layer: | ||
* | * adds a header | ||
* | * may add a trailer | ||
* | * has a maximum size | ||
* treats the payload as opaque | |||
== MTU: When Containers Must Fit == | == MTU: When Containers Must Fit == | ||
MTU (Maximum Transmission Unit) defines the largest payload | 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, | 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 == | == 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 | Broadcast is not a flaw—it is a feature used for: | ||
* ARP | |||
* IPv6 Neighbour Discovery | |||
* DHCP | |||
* service discovery protocols | |||
Unmanaged switches | 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 == | == Control Plane Reality == | ||
Ethernet | 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 == | == 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 == | == Common Pitfalls == | ||
* Treating VLANs as security boundaries | * Treating VLANs as security boundaries | ||
* Assuming switches | * Allowing broadcast domains to grow too large | ||
* Assuming switches are just plugboards | |||
* | * Overusing VLANs | ||
* Ignoring | * Ignoring encapsulation overhead | ||
* | * Designing redundant links without loop prevention | ||
* Failing to account for MTU mismatches | |||
== Why This Still Matters == | == Why This Still Matters == | ||
Modern networks | 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. | ||
VPNs | |||
Networks fail when we forget that every packet is | Networks fail when we forget that every packet is simply a box that has to fit. | ||
== Related Topics == | == Related Topics == | ||
Latest revision as of 14:04, 13 March 2026
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.