Ethernet and MAC addressing

The previous module ended with bits arriving as a frame at a network interface. This one is about what happens next: how that frame is structured, how it gets addressed across a LAN, and how a switch decides where to forward it. Ethernet is the LAN protocol that won, and it won partly by being deliberately boring — a small, fixed frame format, a flat address space, and a forwarding model so simple that switches can implement it in cheap silicon. Understanding it well takes about an afternoon. Understanding it well enough to debug a misbehaving LAN takes a little longer; this module is a head start.

Prerequisites

• Module 1.1, Bits, signals, and the physical layer. You should be comfortable with the idea that a frame is a finite sequence of bits delimited by a preamble, encoded by a line code, and recovered by a clock-recovery loop.

Learning objectives

By the end of this module you should be able to:

1. Decode an Ethernet frame byte by byte — preamble, addresses, EtherType, payload, FCS — and explain why each field is sized the way it is.
2. Distinguish unicast, broadcast, and multicast delivery on a LAN, and predict how a switch handles each.
3. Describe what a MAC address actually identifies, why MAC-based access control is fragile, and how OUI bits work.
4. Explain why ARP exists, what it does, and what's in your Linux neighbor table after one round of ping.
5. Recognize the most common Ethernet failure modes — MAC flapping, ARP spoofing, broadcast storms — and tell them apart in a packet capture.

Why Ethernet won

Ethernet's design goal was cheap local connectivity. In 1976 Metcalfe and Boggs published the original paper as a working system at Xerox PARC; the protocol was reliable enough for production but simple enough that any vendor could build hardware for it without a license dispute. That combination — credible engineering plus a permissive standard — is what beat every alternative.

Three properties are responsible for the win:

• Fixed, simple frame format. No options, no extensibility games. A NIC ASIC can parse an Ethernet header in a single clock cycle.
• Flat address space. Every interface gets a unique 48-bit address; there's no hierarchy and no allocation politics on the LAN itself. (The hierarchy lives one layer up, in IP.)
• Stateless forwarding by switches. A switch holds a small lookup table mapping MAC addresses to ports. It doesn't run a routing protocol. It doesn't negotiate. It just forwards. Modern silicon can do this at line rate on millions of ports per second.

The trade-off Ethernet made early was scope. It was always meant for the LAN — a single broadcast domain of a few hundred to a few thousand hosts. Wide-area networking, internet routing, and inter-datacenter traffic were going to live on top of IP, and Ethernet was happy to stay in its lane. That decision is what allowed the protocol to stay simple while everything above it grew complicated.

What a MAC address actually identifies

A MAC address is 48 bits, conventionally written as six pairs of hex digits separated by colons or hyphens: f8:b1:56:c1:9d:30. It identifies a network interface, not a person, not a device, not a host. A laptop with both Ethernet and Wi-Fi has two MAC addresses, one per interface. A virtual machine with three virtual NICs has three. Bridges and bond interfaces have their own.

The first 24 bits are the Organizationally Unique Identifier (OUI), assigned by the IEEE to the vendor that built the interface. You can look up a vendor from the OUI; the IEEE publishes the registry. The remaining 24 bits are assigned by the vendor at manufacture, traditionally as a per-NIC serial. In aggregate, the 48-bit space is large enough to give every NIC ever made a unique address — about 280 trillion addresses — and assignment policy ensures no two ever collide in practice.

Two bits in the most-significant byte have special meanings:

• The U/L bit (universally vs. locally administered). If 0, the address was assigned by IEEE through an OUI. If 1, it's a locally administered address — software is making one up. Modern OSes use this for MAC randomization, virtual interfaces, and Wi-Fi privacy.
• The I/G bit (individual vs. group). If 0, the frame is unicast. If 1, it's broadcast or multicast.

This is the entire structure. There are no logical groupings beyond OUI, no routing semantics, no layered hierarchy. MAC addresses are deliberately featureless because the layer they belong to doesn't need features — it needs to forward fast.

A consequence worth being clear about: MAC addresses are not a security primitive. Every NIC driver allows the OS to override the hardware-burnt-in MAC. Linux does it with ip link set dev eth0 address xx:xx:xx:xx:xx:xx. Wi-Fi clients do it for privacy. Attackers do it to bypass MAC-based access control. Treat any system whose security depends on MAC addresses being authentic as an upgrade waiting to happen.

Ethernet frame format byte by byte

Here's a complete Ethernet II frame, the variant overwhelmingly used in modern LANs:

+----------+--------+-------------+--------------+----------+--------+--------+
| Preamble |  SFD   | Destination |    Source    |EtherType | Payload|  FCS   |
|  7 bytes | 1 byte |  MAC 6 bytes|  MAC 6 bytes |  2 bytes |46-1500 |4 bytes |
+----------+--------+-------------+--------------+----------+--------+--------+

Going through each field with its rationale:

• Preamble (7 bytes). A fixed pattern of alternating ones and zeros (10101010 ...). The receiver's clock-recovery circuit locks onto this before the actual frame arrives. The preamble does not appear in software-visible captures; the NIC strips it.
• Start Frame Delimiter (SFD, 1 byte). The pattern 10101011. The two trailing 1s break the alternating sequence and tell the receiver the next byte is the start of the frame proper.
• Destination MAC (6 bytes). The address of the interface this frame is for. May be unicast, broadcast (ff:ff:ff:ff:ff:ff), or a multicast group address.
• Source MAC (6 bytes). The address of the interface that sent it. Switches use this for forwarding-table learning; we'll come back to that.
• EtherType (2 bytes). Tells the receiver what's in the payload. The values you'll see in captures: 0x0800 is IPv4, 0x86DD is IPv6, 0x0806 is ARP, 0x8100 is a VLAN tag (with the real EtherType immediately after), 0x88CC is LLDP. Without this field, the receiver wouldn't know how to parse the bytes that follow.
• Payload (46–1500 bytes). The actual contents — typically an IP packet. The 1500-byte upper limit is the Ethernet MTU. The 46-byte lower limit was inherited from the original collision-detection requirement (Module 1.1) and persists today; if your real payload is smaller, the sender pads with zeros up to 46.
• Frame Check Sequence (FCS, 4 bytes). A CRC-32 computed over destination MAC through end of payload. The receiver recomputes the CRC and discards the frame on mismatch. Like the preamble, the FCS does not appear in software-visible captures by default — the NIC has already validated and stripped it.

Total frame size on the wire ranges from 64 bytes (the minimum, including FCS) to 1518 bytes (or 1522 with a VLAN tag). This is the constraint that almost every packet capture you'll ever see is operating inside.

A note on the alternative Ethernet 802.3 framing: instead of EtherType, the third 16-bit field is interpreted as a length. To distinguish, EtherType values are all greater than 1500, so the receiver can tell which framing is in use by inspecting the field value. In practice, almost every modern stack uses Ethernet II.

Broadcast, multicast, unicast

Ethernet defines three delivery modes by the I/G bit and the destination address pattern:

• Unicast. The destination MAC has the I/G bit clear. The frame is meant for one specific interface. Switches forward it only out the port that learned that MAC.
• Broadcast. The destination MAC is ff:ff:ff:ff:ff:ff. The frame is meant for every interface in the broadcast domain. Switches forward it out every port except the one it arrived on.
• Multicast. The destination MAC has the I/G bit set but isn't all-ones. The frame is meant for a specific group. By default, switches forward multicast like broadcast (out every port); on switches with IGMP snooping or MLD snooping enabled, multicast is forwarded only to ports that have subscribed to the group.

The reason this matters for performance is that broadcast traffic and unhandled multicast both touch every host on the segment. A LAN with 500 hosts and 100 ARP requests per second is delivering 50,000 frames per second to every NIC, every one of which has to be parsed and almost all of which are then dropped. Most are silently absorbed; a few become packet-storm pathologies. Broadcast discipline is a real operational concern at scale.

The two everyday triggers of LAN broadcast are ARP (which we'll cover next) and DHCP (whose initial DISCOVER message is necessarily broadcast because the client doesn't yet have an IP). IPv6 designed the LAN protocol family, including its equivalent of ARP, around multicast specifically to reduce the per-host noise floor.

Hubs, bridges, switches, and the death of shared collision domains

Three pieces of LAN-edge equipment, in historical order:

A hub is a multi-port repeater. Bits arriving on any port are blindly retransmitted out every other port. There's no MAC-aware logic; the hub is a 1980s answer to the question "how do we connect more than two coax taps without splitting the cable?" Hubs preserve the shared-medium fiction: every port participates in the same collision domain, and CSMA/CD still arbitrates access. Modern networks contain zero hubs except as historical curiosities.

A bridge is the next generation. A bridge forwards selectively based on MAC addresses, learning which side of itself each address lives on by watching source MACs in passing frames. A two-port bridge halves the collision domain in half, doubling LAN capacity. The original bridges were deployed as the final answer to the "why is our 10BASE5 LAN slow" problem; the answer was always "too many machines sharing the medium," and bridges fixed it by chunking the medium into separately-arbitrated halves.

A switch is a many-port bridge with hardware acceleration. A 48-port modern Ethernet switch is, conceptually, just a 48-way bridge — it learns which MAC addresses live behind which port and forwards accordingly. The hardware does the lookup at line rate. The protocol is unchanged.

The point of every hop in this evolution: shrinking the collision domain. With every bit of selectivity in the forwarding logic, fewer frames go where they don't have to, and hosts spend less time backing off from collisions on the shared cable. Modern switched Ethernet — which is what 99% of the LANs you'll touch today are — has eliminated collisions from the normal case entirely. Each switch port is a private full-duplex link to a single host; CSMA/CD is preserved in the standards but never invoked.

This is the historical answer to the question "why is the 10/100/1000 Mbps Ethernet I'm using so much faster than what my parents' generation experienced?" Switches won. Selective forwarding always wins over flooding.

How switches learn

A switch's forwarding decision uses two pieces of state:

1. The MAC address table (sometimes called the CAM table or forwarding database): a mapping from MAC address to outbound port.
2. The frame's destination MAC address: the lookup key.

The table is learned on the fly. When a frame arrives on port P with source MAC M, the switch records "MAC M is reachable through port P." The next time a frame arrives with destination MAC M, the switch sends it only out port P. The fast path of every modern Ethernet network is exactly this: source-MAC learning into a hardware-resident table, destination-MAC lookup at packet rate.

Two cases require special handling:

• Unknown-destination frame. If the switch hasn't learned a destination yet, it doesn't know which port leads there. So it floods the frame — sends it out every port except the one it arrived on. The destination, if it exists on the LAN, will eventually reply, and that reply will let the switch learn its location.
• Address aging. Entries in the MAC table expire after a configurable interval (Linux bridge defaults to 300 seconds; Cisco switches similarly). If a host stops talking, its entry will eventually drop, and the next frame to it will be flooded. This is intentional: it prevents the table from being polluted by stale entries when hosts move ports.

When a host moves (say, you unplug a laptop from one switch port and plug it into another), the first frame from the moved host carries its MAC as the source on the new port. The switch updates the table — MAC m → port new — and traffic to that MAC is delivered to the right place from the next frame onward.

The pathology to know about is MAC flapping. If a switch sees the same source MAC alternating between two ingress ports faster than it can age out the entries, the forwarding table updates back and forth on every frame. On a busy LAN this manifests as latency spikes and intermittent packet loss. The cause is almost always a layer-2 loop — two switch ports connected to each other, directly or via another switch, with no spanning-tree protocol breaking the loop. Spanning Tree Protocol (STP) and its modern descendants exist to detect and disable redundant paths automatically. We'll cover STP in a later module; for now, the rule of thumb is that any unexplained MAC flap should make you go look for a loop.

ARP — the bridge from layer 3 to layer 2

A host that wants to send an IPv4 packet has the destination's IP address, but the Ethernet header it has to construct needs a destination MAC address. There's no way to derive one from the other; they live in independent address spaces. Something has to map "this IP address" to "that MAC address." That something is ARP, the Address Resolution Protocol, defined in RFC 826 (1982 — the spec is still substantively current).

The mechanism is ruthlessly simple:

1. The sender broadcasts an ARP request: "Who has IP 10.0.0.5? Tell 10.0.0.7."
2. Every host on the segment receives the broadcast. Hosts that aren't 10.0.0.5 discard it.
3. The host that owns 10.0.0.5 replies with a unicast ARP reply: "I have 10.0.0.5; my MAC is f8:b1:56:c1:9d:30."
4. The sender caches the mapping in its neighbor table (also called the ARP cache) and transmits the actual IP packet inside an Ethernet frame addressed to that MAC.

Subsequent packets to the same destination skip ARP entirely; the cache lookup is a microsecond operation. Cache entries time out (Linux default is around 60 seconds for incomplete entries, longer for confirmed ones), at which point the next packet triggers a fresh ARP request.

ARP is link-local only. It is not a routing protocol. It does not span subnets. If you want to reach a host on a different LAN, your packet goes to your default gateway's MAC; the gateway then performs its own ARP on the destination's network. This is the layer-3 vs layer-2 split made concrete: ARP handles the within-segment, IP routing handles the across-segments.

RFC 5227 (2008) added Address Conflict Detection: when a host gets an IP, it sends a probe ARP for that address with 0.0.0.0 as the source, watches for a reply, and only commits to using the address if no one answers. This is what stops your router and your laptop from claiming 10.0.0.1 simultaneously.

The pathology to know about is ARP spoofing (a.k.a. ARP poisoning). Because ARP replies are not authenticated, any host on the segment can answer "I have 10.0.0.1" and many stacks will believe it. The attacker becomes a transparent man-in-the-middle for traffic to that IP. Defenses: dynamic ARP inspection on switches, static ARP entries for critical hosts, and — the structural fix — moving sensitive segments to mTLS or IPsec where the application doesn't trust the underlying address mapping.

For deeper LAN-meets-IP context, see Module 1.3 on IPv4 addressing and subnetting once it's published — ARP is one half of the bridge, and the IP subnet structure that drives it is the other half. IPv6 replaces ARP with NDP (RFC 4861), which uses multicast instead of broadcast and adds router solicitation and advertisement; we'll cover that in Module 1.4.

Frame size, MTU, and the practical limits of Ethernet

The Ethernet payload is 46–1500 bytes. The 1500-byte upper bound is the link MTU — the maximum size of an IP packet (or whatever's in the EtherType-named protocol slot) that fits in a single frame. Above this, the IP layer must fragment, and fragmentation is uniformly worse than not fragmenting: more headers, more state, slower forwarding, and a long history of corner-case bugs.

In practice, the entire IP fragmentation regime is being avoided across the modern internet by Path MTU Discovery: senders probe what the smallest MTU on the path is and segment their writes to fit. Module 1.5 covers PMTUD in detail. The reason MTU shows up here is simply: the link-layer constraint is 1500 bytes, and almost every higher-layer decision about packet sizing traces back to that number.

Jumbo frames are an Ethernet variant that allows payloads up to 9000 bytes. Jumbo frames are a real performance win in one specific situation: high-throughput data-center traffic between machines that have explicitly negotiated jumbo support on every link in between. They reduce per-packet overhead (fewer headers per byte transferred), and on 10 Gbps and faster links, they noticeably reduce CPU utilization on the receiving side. The catch is that every device on the path must support the same jumbo MTU; one 1500-MTU bottleneck and the path has to fragment, which is worse than having stayed standard. Jumbos are common inside well-managed data centers and almost nonexistent on the public internet.

Failure modes

A few patterns are worth recognizing on sight:

Broadcast storms. A loop in the layer-2 topology turns every broadcast frame into an exponentially-growing flood. The LAN goes from quiet to saturated in seconds, and every host's CPU is pegged processing storm traffic. The fix is spanning-tree protocol or one of its modern variants; the immediate workaround is unplugging the loop cable. If you walk into a network where every interface is at 100% utilization and no one is doing anything, this is your first hypothesis.

MAC flapping. Same source MAC alternating between switch ports. Typically a layer-2 loop that hasn't quite become a storm yet. Switch vendor logs will report it explicitly with a "MAC X moving between ports P1 and P2" message. Same fix as a storm: find and break the loop.

ARP spoofing. A malicious or buggy host answers ARP requests for an IP that isn't theirs. Symptom: traffic that should go to one host arrives at another. Detection on Linux: watch /proc/net/arp for entries that change unexpectedly, or run arpwatch. Structural defense: dynamic ARP inspection at the switch, plus mTLS or IPsec for sensitive traffic.

ARP cache poisoning by stale entries. A host that has been off-segment for hours can still appear in another host's ARP cache until the entry ages out. This produces packets sent to the wrong MAC, which a switch may then misforward or drop. ip neigh flush all is the bludgeon; reducing aging time is the dial.

Hands-on exercise

Exercise 1 — Inspect Ethernet and ARP on a live interface

Open two terminals. In Terminal 1, start a capture filtering to ARP and IPv4:

sudo tcpdump -eni en0 -c 10 'arp or ether proto 0x0800'

(Replace en0 with the active interface; on Linux this is often eth0 or enp1s0.) The -e flag tells tcpdump to print Ethernet headers, which is the whole point.

In Terminal 2, ping a host on the same subnet — your default gateway is a safe choice:

ping -c 3 $(ip route | awk '/default/ {print $3; exit}')

Look at the capture. You should see:

1. An ARP request from your host's MAC to the broadcast address ff:ff:ff:ff:ff:ff, asking who has the gateway's IP.
2. An ARP reply from the gateway's MAC, unicast back to your host's MAC, with the answer.
3. Three echo-request frames: source MAC = your host, destination MAC = gateway. EtherType 0x0800 (IPv4).
4. Three echo-reply frames in the opposite direction.

Notice the asymmetry: the ARP request is broadcast (every host on the segment heard it), but the ARP reply and the actual ping traffic are unicast (the switch forwards them only to the relevant ports because it has now learned the MACs).

Exercise 2 — Read the host neighbor table

Before the ping, run:

ip neigh show

You'll see existing neighbor entries. Most will be in STALE state — the kernel has them cached but isn't sure they're current. Run the ping, then re-run the command. The gateway entry should now be in REACHABLE state because the kernel just confirmed it.

ip neigh show

Each entry in the output is one ARP cache line: an IP, the device it's reachable through, the MAC, and the current state. The state machine has six states (INCOMPLETE, REACHABLE, STALE, DELAY, PROBE, FAILED); for everyday operation only REACHABLE and STALE matter.

To force a refresh, flush an entry:

sudo ip neigh del <ip> dev <iface>

The next packet to that destination will trigger a new ARP cycle. Useful for debugging when you suspect a stale or poisoned entry.

Common misconceptions

"A MAC address identifies a person or a whole device forever." It identifies a network interface and is trivially overridden by software. Modern Wi-Fi stacks randomize their MAC per network specifically to break this assumption.

"Switches know every destination already." They learn from observed source MACs. A frame to a destination the switch hasn't seen yet is flooded out every port. This is fine; it's how learning happens in the first place.

"ARP is a routing protocol." ARP is local-link address resolution. It maps an IP address to a MAC address on the same broadcast domain. Routing — selecting paths between domains — is a separate discipline at layer 3.

"Broadcasts are just inefficient, not dangerous." A broadcast loop becomes a storm in seconds, can knock a LAN offline entirely, and may cascade across federated layer-2 fabrics if spanning tree isn't healthy. Treat broadcast as a controlled resource, not a free one.

"CSMA/CD is how modern switched Ethernet still works." Full-duplex switched Ethernet eliminated collisions in the common case. CSMA/CD is in the standard for backward compatibility with shared-medium links that no one deploys anymore.

Further reading

1. RFC 826 — An Ethernet Address Resolution Protocol. The original ARP spec is short, readable, and substantively current.
2. RFC 894 — A Standard for the Transmission of IP Datagrams over Ethernet Networks. Two pages on how IP packets sit inside Ethernet frames. Worth reading once for the historical clarity.
3. RFC 5227 — IPv4 Address Conflict Detection. The modern probe-before-claim behavior every IPv4 stack should implement.
4. RFC 2464 — Transmission of IPv6 Packets over Ethernet Networks. Useful for comparing IPv4-era ARP semantics to IPv6's multicast-based NDP.
5. Larry Peterson and Bruce Davie, Computer Networks: A Systems Approach, book.systemsapproach.org. The link-layer chapters are the cleanest systems-level explanation of switching, framing, and the bridge from LAN mechanics to higher layers.

The next module in the track moves up one layer to IP itself: addressing, subnetting, and the routing logic that lets a packet leave the LAN.