Ethernet

Reading time: 8 minute Word count: 1506

Network Ethernet LAN MAC

When a host already knows the destination IP, and maybe even the next hop, the packet does not leave the NIC as an IP packet first. What lands on the wire is an Ethernet frame. Problems like “same subnet but no connectivity”, “ARP never gets an answer”, or “DHCP broadcast went out but nobody replied” are not mainly Layer 3 problems. They usually fail earlier, at the Layer 2 hop.

Ethernet handles frame delivery on the local link. It looks like boring infrastructure that “just works”, but many of the most common engineering problems sit exactly here: broadcast domain boundaries, how switches learn MAC addresses, why same-subnet traffic can still fail, and why ARP and DHCP naturally depend on its behavior model.

Ethernet is not just “sending frames”. It is the local-link mechanism that uses MAC addresses, frame boundaries, and switching to turn higher-layer IP neighbor relationships into a real reachability path between devices

Why It Exists

Cross-network addressing is IP’s job. But inside one local network, the host first has to solve something closer and simpler:

Which local device should this frame go to
Which device should receive it
How should the switching device move it to the right port

In other words, before IP begins routing across subnets, the local link needs its own delivery model. Ethernet solves exactly that problem: on a shared or switched LAN, it lets devices deliver frames to the right place by Layer 2 address.

The Background It Came From

Ethernet was designed for local-network interconnection, not for Internet-scale cross-subnet forwarding. It serves:

Communication between devices in the same broadcast domain
Local forwarding between hosts and switches
The most basic encapsulation for upper-layer protocol access

That choice shapes the whole design:

It prioritizes local frame delivery
It does not take responsibility for cross-subnet routing
It relies on local broadcast and learning to do discovery by default
It uses MAC addresses, not IP addresses, to describe the receiver on this link

So Ethernet is naturally a layer of local reality, not global addressing.

Grasp the Main Model First

To understand Ethernet, remember these four objects first:

Frame: the unit actually sent by the link layer
MAC address: the local delivery identifier on the link
Switch: the Layer 2 device that learns and forwards by MAC
Broadcast domain: the range over which broadcast frames can spread

You can compress the logic like this:

Host sends a frame
  -> frame carries source MAC / destination MAC
  -> switch decides which port to forward to based on the MAC table
  -> if the destination is unknown, it floods or broadcasts

If you do not understand that step first, many ARP, DHCP, and “same subnet but no connectivity” symptoms will be misread as Layer 3 problems.

The Most Common Main Path

Start with one host sending a frame to another host in the same subnet:

sequenceDiagram participant A as Host A participant SW as Switch participant B as Host B A->>SW: Ethernet Frame
src=A_MAC, dst=B_MAC Note over SW: Look up MAC table SW->>B: Forward to B's port

If the switch does not yet know where B_MAC lives, it floods first:

sequenceDiagram participant A as Host A participant SW as Switch participant B as Host B participant C as Host C A->>SW: Ethernet Frame
dst=B_MAC Note over SW: MAC table miss SW->>B: Flood SW->>C: Flood Note over B: Receive and process Note over C: Receive and drop

In both cases, the switch’s most important action is not understanding business traffic. It is learning and forwarding:

Learn from the source MAC which port this address is on
Forward directly for known destinations
Flood first for unknown destinations

Why MAC and IP Must Not Be Mixed Up

MAC and IP are both easy to think of as “device addresses”. That quickly creates confusion because they serve different layers:

IP solves cross-network addressing
MAC solves local-link delivery

When a host sends a packet to a remote server:

The destination IP inside the IP packet may be the remote public server
The destination MAC inside the Ethernet frame may only be the local default gateway

That is not a conflict between two address layers. They are describing different receiver scopes from the start.

Why Switches Can Forward Without Configuring Every Host

The most important switch behavior is not that it “knows the topology”. It learns from source MAC addresses.

When a frame enters a port, the switch records:

This source MAC was seen on this port

The next time it sees a frame for that MAC, it can forward selectively. That makes the model very valuable:

No need to pre-register every host by hand
When a host moves ports, the table entry can update gradually
Local forwarding can self-learn from traffic

But there are tradeoffs too:

Unknown destinations must be flooded at first
Table entries expire, and then flooding may happen again
Loops, spoofing, or abnormal broadcast traffic can amplify problems

So Ethernet’s “simplicity” is really built on switches continuously maintaining soft state.

Why Broadcast Domains Matter

Broadcast frames do not cross the whole network forever. They only spread inside the local broadcast domain. That directly affects whether many protocols work:

ARP broadcast only works within the local broadcast domain
DHCP Discover also spreads only within the local broadcast domain by default
Without a relay, broadcast does not reach other subnets

That is why “the server is online, but broadcast cannot reach it” is often not a server problem at all. The more likely causes are:

The broadcast domain boundary is broken
VLAN division is wrong
Relay or switching configuration does not match expectations

So a broadcast domain is not an abstract concept. It is the real boundary where many protocols live or die.

Why DHCP and ARP Naturally Depend on Ethernet

What they depend on is not the Ethernet brand name. They depend on two basic Layer 2 behaviors:

Broadcast can reach the local link
Hosts can send and receive frames by MAC address

ARP depends on Ethernet because it has to ask “who owns this IP?” inside the local link. DHCP discovery depends on Ethernet because when the client knows almost nothing yet, the most realistic way is to shout in the local broadcast domain first.

So if Ethernet broadcast, learning, or forwarding is broken, ARP and DHCP often fail before TCP or HTTP do.

Why VLAN Rewrites the Meaning of “Local”

People often instinctively treat “plugged into the same switch” as “in the same LAN”, but VLANs break that intuition immediately.

Under VLAN semantics:

Different switch ports on the same physical switch may not belong to the same broadcast domain
MAC learning and broadcast flooding are constrained by VLAN boundaries
ARP, DHCP, and neighbor discovery are all redefined by the VLAN scope

So physical proximity does not mean the same thing as being in the same Layer 2 local network.

What to Look at in Packet Captures

Do not start by staring at EtherType. A more useful order is below.

First check where the frame is trying to go

Confirm:

Who the source MAC is
Who the destination MAC is
Whether the frame is unicast, broadcast, or multicast

Get this right first, and then you know whether the frame was only supposed to reach one device or was meant to spread across the broadcast domain.

Then check whether the switching path matches expectations

Common symptoms include:

Unknown unicast flooding
Repeated broadcast traffic
MAC table flapping
The same MAC appearing on different ports repeatedly

These usually point directly to:

A Layer 2 loop
Wrong cabling
MAC spoofing
Virtualization migration
An unstable switch table entry

Finally check whether the problem was misclassified as a higher-layer issue

Many “IP is broken”, “ARP keeps failing”, or “DHCP has no response” incidents actually start earlier:

The frame never reached the correct port
The broadcast never reached the expected scope
The switching path was already wrong at Layer 2

Once Ethernet is not standing correctly, ARP, IP, TCP, and HTTP will all look broken together.

What Engineering Should Actually Think About Ethernet Today

Do not think of Ethernet as a transparent base that automatically works once the cable is plugged in. It determines the real reachability path on the local link
Do not mix MAC addresses with IP addresses. They describe different receiver scopes
Do not ignore switch learning and flooding. They directly decide whether local forwarding is stable
Do not underestimate broadcast domain boundaries. Many ARP, DHCP, and neighbor-discovery problems die there
Do not default every LAN problem to Layer 3. If the local link is wrong first, everything above it will also be wrong