Dex at 11:14, 14 March 2026

2026-03-14T11:14:18Z

← Older revision		Revision as of 11:14, 14 March 2026
Line 1:		Line 1:
	~~= 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 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.

Dex at 14:04, 13 March 2026

2026-03-13T14:04:30Z

Show changes

Dex: 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..."

2026-03-13T10:45:40Z

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..."

New page

= 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 ===

<pre>
┌──────────────────────────────────────────────────────────────┐
│ 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) │
└──────────────────────────────────────────────────────────────┘
</pre>

=== 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 ===

<pre>
┌─────────────────────────────────────────────┐
│ Ethernet Frame │
│ ┌─────────────────────────────────────────┐ │
│ │ IP Packet │ │
│ │ ┌─────────────────────────────────────┐ │ │
│ │ │ TCP / UDP Segment │ │ │
│ │ │ ┌─────────────────────────────────┐ │ │ │
│ │ │ │ Application Data │ │ │ │
│ │ │ └─────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
</pre>

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.

== Related Topics ==
* [[Ethernet (IEEE 802.3)]]
* [[IEEE 802 Family]]
* [[VLANs and IEEE 802.1Q]]
* [[Spanning Tree Protocol]]
* [[MTU and MSS]]
* [[Packet Radio Fundamentals]]

Ethernet, Frames, and Thinking in Containers - Revision history

Dex at 11:14, 14 March 2026

Dex at 14:04, 13 March 2026