Ethernet, MAC Addresses & ARP

In Lesson 2 the packet got wrapped in a frame before it went out on the wire. This is that frame. Ethernet keeps it deliberately small and fixed: a handful of fields, each with one job.

The FCS — frame check sequence — is worth a moment. The sender calculates it from the frame's contents and appends it. The receiver recalculates it and compares. If the two do not match, something changed in transit, and the frame is silently discarded. Nothing asks for it to be resent at this layer; Ethernet simply drops corrupt frames and lets a higher layer notice the gap. This is the only circumstance in which a switch discards a frame outright.

A MAC address is 48 bits long, conventionally written as six pairs of hexadecimal digits — for example 00:1A:2B:3C:4D:5E. It splits cleanly in half. The first three octets are the OUI, the organizationally unique identifier, which is assigned to the manufacturer of the interface. The last three identify the specific adapter that manufacturer built. Together they are meant to be globally unique, and the address is burned into the interface rather than configured.

Two kinds of destination matter right now. A unicast MAC addresses exactly one interface, and only that interface accepts the frame. The broadcast MAC, written FF:FF:FF:FF:FF:FF — every bit set to one — is accepted by every device on the local network at once. That is the address you use when you need to reach everybody because you do not yet know who you are looking for, which is exactly the situation ARP is built for.

A sending host has a problem. It knows the destination's IP address — that is what the application gave it — but the frame it has to build needs a destination MAC address, and nothing has told it what that is. ARP, the Address Resolution Protocol, closes that gap.

1. The host checks its ARP cache, a table of the IP-to-MAC mappings it has already learned. If the address is there, it uses it and sends immediately.
2. If it is not, the host broadcasts an ARP request — destination MAC FF:FF:FF:FF:FF:FF — asking, in effect, “whoever owns this IP address, tell me your MAC.” Every device on the local network receives it.
3. Every device except the owner examines the request, sees a different IP address, and discards it. The owner answers with a unicast ARP reply, sent directly back to the asker, carrying its MAC address.
4. The host stores the mapping in its cache and builds the frame it wanted to send in the first place. Later sends to the same address skip straight to step 1 until the cache entry expires.

A switch is not told what is plugged into it. It works that out from the traffic, and it does so using the one field guaranteed to be correct: the source MAC address of every frame it receives.

When a frame arrives, the switch reads its source MAC and records that address against the port the frame came in on. That entry goes into its MAC address table. After a device has sent even a single frame, the switch knows exactly where it lives. Nothing needs to be configured for this to happen.

Then the switch looks at the destination MAC and makes one of three decisions:

• The destination is in the table — the switch forwards the frame out that one port and no others. This is the normal case, and it is why a switched network does not waste bandwidth the way a hub did.
• The destination is not in the table — this is an unknown unicast frame, and the switch floods it out every port except the one it arrived on, on the reasonable assumption that the destination is somewhere and will answer. When it does answer, the switch learns its port from that reply and stops flooding.
• The destination is the broadcast address FF:FF:FF:FF:FF:FF — the switch floods it out every port except the one it arrived on, because that is precisely what a broadcast is supposed to reach.

That is the whole of switch behaviour you need this week — enough to predict what a switch will do with any given frame, and enough for the lab. Week 3 picks it up again and adds how long entries survive, what happens when the table fills, and the commands for inspecting it.

Everything so far has been about carrying application data. ICMP — the Internet Control Message Protocol — is different: it is how devices report problems and test reachability. It is not a transport protocol and it has no port numbers; an ICMP message is carried directly inside an IP packet, which makes it a Layer 3 protocol, sitting alongside IP rather than on top of it.

Its most familiar use is ping. When you ping an address, your device sends an ICMP Echo Request to it. A device that receives one and is willing to answer sends back an ICMP Echo Reply. That is the entire exchange — a question and an answer, with nothing else attached.

One detail matters for the lab. On a local network, before the very first ping can be sent at all, the host has to resolve the destination's MAC address — so ARP runs first, and the Echo Request only goes out once the reply comes back. That is why the first ping in a sequence sometimes times out while the rest succeed: the first one was waiting for ARP. You are about to watch exactly that happen, one frame at a time.

• Frame fields: destination MAC, source MAC, EtherType, payload, FCS. A failed FCS is the one reason a frame is silently dropped.
• A MAC address is 48 bits: the OUI half identifies the vendor, the rest identifies the adapter. FF:FF:FF:FF:FF:FF is the broadcast address.
• ARP: broadcast request, unicast reply, cached result. It resolves local addresses only.
• Remote destination? The host resolves the default gateway's MAC, never the far host's.
• A switch learns from source MACs, forwards known unicast to one port, and floods unknown unicast and broadcast out every port except the one the frame arrived on.
• ping sends an ICMP Echo Request and expects an Echo Reply. A reply proves both directions work; a timeout proves much less than it seems to.