Ethernet, Frames, and Thinking in Containers: Difference between revisions

From PiRho Knowledgebase
Jump to navigationJump to search
Dex (talk | contribs)
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..."
 
Dex (talk | contribs)
No edit summary
 
Line 2: Line 2:


'''Summary:'''
'''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.
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 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.
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.


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.
Ethernet’s longevity comes from this engineering-first design philosophy.


== A Note on Models ==
== 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:
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 lives primarily in the Physical and Data Link layers. Once traffic reaches the Network layer, VLANs and media type no longer exist.
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 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.
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 intentional and is a key reason Ethernet has survived decades of change.
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 structure, a size budget, and clear boundaries.
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'''
Used for clock synchronisation. Handled entirely by hardware and not visible in packet captures.
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 actual frame.
Marks the start of the meaningful part of the frame.


'''Destination MAC'''
'''Destination MAC'''
Identifies the intended recipient. May be unicast, multicast, or broadcast.
The intended recipient. Supports unicast, multicast, and broadcast.


'''Source MAC'''
'''Source MAC'''
Identifies the sender. Switches learn MAC locations from this field.
The sender. Switches learn MAC-to-port mappings from this field.


'''802.1Q VLAN Tag (optional)'''
'''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.
Adds tagging and priority metadata. The underlying frame remains unchanged; the tag is simply inserted between Source MAC and EtherType.


'''EtherType / Length'''
'''EtherType / Length'''
Identifies the payload type (for example IPv4, IPv6, ARP).
Indicates the payload protocol (IPv4, IPv6, ARP, LLDP, etc.).


'''Payload'''
'''Payload'''
Encapsulated data from higher layers. Often an IP packet.
The encapsulated upper-layer data—commonly an IP packet.


'''Frame Check Sequence'''
'''Frame Check Sequence'''
CRC checksum for error detection. Corrupt frames are discarded silently.
A CRC32 checksum enabling error detection. Corrupt frames are silently discarded.


== Encapsulation as Containers ==
== Encapsulation as Containers ==
A practical way to understand networking is to think in terms of '''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.
 
Each layer wraps the one above it, adds a header, and passes the whole container downwards.


Nothing is rewritten.
Nothing is rewritten.
Nothing is interpreted early.
Nothing is interpreted early.
Everything is just wrapped.
Everything is simply wrapped and handed off.


=== Container Model ===
=== Container Model ===
<pre>
<pre>
┌─────────────────────────────────────────────┐
┌─────────────────────────────────────────────┐
Line 100: Line 118:
</pre>
</pre>


Each container has:
Each layer:
* A header
* adds a header
* A payload
* may add a trailer
* A maximum size
* has a maximum size
 
* treats the payload as opaque
This is why framing and packetisation feel natural once you’ve seen them physically.


== MTU: When Containers Must Fit ==
== MTU: When Containers Must Fit ==
MTU (Maximum Transmission Unit) defines the largest payload that can fit inside an Ethernet frame.
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, 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.
Historically, heterogeneous networks made MTU management a daily concern. Even today, tunnels, overlays, and VPN stacks make MTU a source of subtle breakage.


If a container does not fit:
MTU is not an abstract parameter—it is a physical limitation of a physical container.
* 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 ==
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.


== VLANs and Thicker Containers ==
However, the added overhead matters when:
VLAN tagging slightly increases the size of the Ethernet container.
* tunnelling multiple layers of encapsulation
* approaching MTU limits
* mixing devices that enforce strict maximum sizes


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.
Failure to account for “container stacking” is a common source of path MTU issues.


== Switching, Broadcast, and Behaviour ==
== Switching, Broadcast, and Behaviour ==
Switches forward frames based on MAC addresses. Broadcast traffic is flooded within a broadcast domain.
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 design feature that must be intentionally bounded.
Broadcast is not a flaw—it is a feature used for:
* ARP
* IPv6 Neighbour Discovery
* DHCP
* service discovery protocols


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.
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 has no built-in loop prevention. Protocols such as Spanning Tree exist to prevent catastrophic loops, but they introduce control-plane complexity.
Ethernet itself includes no loop prevention. A single unintended loop can saturate a network almost instantly.


Problems in the control plane often present as physical or application faults. This makes Layer 2 issues particularly difficult to diagnose.
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 ==
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.
In industrial environments, determinism and predictability matter more than raw bandwidth. Historically, systems used:
* serial links
* fieldbuses
* packet radio
* fixed-size frames


Packet radio, serial links, and early LANs make framing constraints visible again. They reward careful thinking about container size, retries, and shared media behaviour.
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 behave like simple repeaters
* Allowing broadcast domains to grow too large
* Oversized Layer 2 domains
* Assuming switches are just plugboards
* Excessive VLAN sprawl
* Overusing VLANs
* Ignoring MTU and encapsulation overhead
* Ignoring encapsulation overhead
* Redundant links without clear loop prevention
* Designing redundant links without loop prevention
* Failing to account for MTU mismatches


== Why This Still Matters ==
== Why This Still Matters ==
Modern networks hide many of these constraints, but they do not remove them.
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, 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.
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.

Related Topics