Skip to content

MAC address

Every article so far in this module has been building toward IP addresses — logical, assignable, changeable identifiers that work across the entire internet. But before a packet can travel anywhere, it has to get onto a physical wire or radio channel, and that requires a completely different kind of address: one burned into the hardware itself.

What a MAC address actually is

A MAC address (Media Access Control address) is a 48-bit identifier assigned to a network interface — a Wi-Fi card, an Ethernet port — at the Data Link layer, Layer 2 of the OSI model. It's written as six pairs of hexadecimal digits, separated by colons or hyphens:

08:00:27:4e:66:a1

Unlike an IP address, which is assigned by whoever administers a network and can change depending on which network a device joins, a MAC address is set by the hardware manufacturer at production time and, in the vast majority of cases, stays fixed to that specific network interface for its whole life. A laptop's Wi-Fi card and its Ethernet port each have their own distinct MAC address, because each is a separate physical interface.

Reading the OUI

The first three octets (24 bits) of a MAC address are the Organizationally Unique Identifier (OUI) — a block the IEEE assigns to one organization. The last three octets are assigned by that organization to identify the individual interface, and the two halves together are what make the address globally unique: the IEEE guarantees no two organizations share an OUI, and each organization is responsible for not issuing the same suffix twice within its own block.

In 08:00:27:4e:66:a1, the OUI 08:00:27 is registered to PCS Systemtechnik GmbH — the block VirtualBox uses for its virtual network adapters, which is why you'll see it constantly in VM labs. Recognizing an OUI on sight is genuinely useful: spotting a familiar one in a device list or packet capture tells you immediately whether you're looking at a physical vendor's hardware or a hypervisor's virtual NIC. Any public OUI lookup service, or the IEEE's own registry, will resolve one for you.

Two bits inside the first octet that aren't part of the OUI

Not every one of the 48 bits identifies a vendor or a device. The two lowest-order bits of the first octet carry their own meaning, independent of which organization the address belongs to:

  • The I/G bit (Individual/Group, the least significant bit of the first octet) says whether the address names one specific interface (0, unicast) or a group of interfaces (1, multicast or broadcast). It's why 01:00:5e:... addresses — used for IPv4 multicast — and ff:ff:ff:ff:ff:ff both have that bit set, while an ordinary NIC's address has it cleared.
  • The U/L bit (Universal/Local, the second-least-significant bit of the first octet) says whether the address is the one the manufacturer burned in (0, universally administered) or one that's been overridden in software (1, locally administered). This is the bit that flips when MAC randomization, covered further down, generates a new address — you can tell a randomized or manually-set MAC from a factory one just by checking whether this bit is set.

You'll see this in practice: 02:xx:xx:xx:xx:xx is a common pattern for locally administered addresses (hypervisors and randomization schemes often just set the U/L bit on an otherwise arbitrary address), while a factory OUI like 08:00:27 has both bits cleared — 08 in binary is 00001000, confirming it's both unicast and universally administered.

Where a MAC address sits inside a frame

A MAC address is only meaningful as part of the structure that carries it — an Ethernet frame. A standard Ethernet II frame looks like this, from the wire inward:

| Preamble + SFD | Dest MAC (6B) | Src MAC (6B) | EtherType (2B) | Payload (46-1500B) | FCS (4B) |
  • Preamble and Start Frame Delimiter: 8 bytes used for clock synchronization before the actual frame content starts; stripped by the NIC hardware and never shown in a capture.
  • Destination MAC: where this frame is going on the local segment — the destination host, or the default gateway, if the ultimate destination is off-network.
  • Source MAC: the sending interface's own address.
  • EtherType: a 2-byte field saying what's inside the payload — 0x0800 for IPv4, 0x86DD for IPv6, 0x0806 for ARP. This is the Layer 2 equivalent of IP's protocol field, and it's how the receiving NIC's driver knows whether to hand the payload to the IP stack or the ARP handler.
  • Payload: the IP packet (or ARP message) itself, 46 to 1500 bytes; frames shorter than 46 bytes get padded.
  • Frame Check Sequence: a 4-byte CRC the receiving NIC uses to detect a corrupted frame and silently drop it — Ethernet doesn't retransmit at this layer, it just discards and lets whatever protocol is layered on top (usually TCP) notice the loss and recover.

Run a packet capture on any Ethernet interface and this is exactly the structure you're looking at from the outside in: source and destination MAC first, then an EtherType telling the tool how to decode everything after it.

MAC vs. IP: two addresses, two jobs

It's worth being precise about why networking needs both a MAC address and an IP address, since the difference is exactly the boundary between Layer 2 and Layer 3 covered in the OSI model article:

MAC address IP address
Layer Data Link (Layer 2) Network (Layer 3)
Scope Local network only Global (routable across networks)
Assigned by Manufacturer, at production Network administrator, or DHCP
Changes when Rarely — tied to the physical interface Often — different network, different IP
Used for Delivery between two directly connected devices Routing across networks

A switch forwards Ethernet frames within a LAN using MAC addresses — it has no concept of IP addresses at all in its basic forwarding logic. A router forwards packets between networks using IP addresses. Note carefully what that means for scope: a MAC address is globally unique, but it is not globally useful. Nothing outside the local segment can route on it, because no router anywhere advertises a path to a hardware address. Every packet that leaves your laptop gets a new MAC-address pair at every single hop along its route, while its source and destination IP addresses typically stay the same from source to final destination.

This is also exactly the gap that ARP (Address Resolution Protocol) exists to fill: a host knows the IP address it wants to reach, but to actually put a frame on the wire it needs the MAC address of whichever device is next — either the destination itself, if it's on the same local network, or the default gateway, if it isn't. ARP answers precisely one question: "what MAC address belongs to this IP address, on this local network?" It does so by asking every device on the segment at once, which works only because the segment is small and bounded.

Types of MAC addresses

Beyond the standard unicast address identifying one specific interface, two other kinds show up in practice:

  • Broadcast: ff:ff:ff:ff:ff:ff is reserved to mean "every device on this local network segment." ARP requests use this address, since the sender doesn't yet know which specific device holds the IP address it's asking about.
  • Multicast: a specific bit pattern in the first octet marks an address as multicast, meaning "every device that's chosen to listen for this particular group," rather than literally everyone. Some routing protocols and streaming applications use multicast MAC addresses to reach a subset of devices efficiently.

Locally administered addresses: when a MAC isn't factory-fixed

Despite MAC addresses being described as burned into hardware, most operating systems can override the factory-assigned address in software — a practice called MAC randomization or spoofing. Modern phones and laptops do this deliberately for privacy: connecting to a new Wi-Fi network with a randomized MAC address prevents that network's owner from tracking the same device across multiple visits just by recognizing its hardware address.

This matters for troubleshooting because it's easy to misread as a fault. Seeing one physical device present two different MAC addresses on two networks — or on the same network at different times — is expected behavior on a modern operating system, not a hardware problem and not a misconfiguration. If you're building anything that identifies devices by MAC address, this is also the reason that approach no longer works reliably.

Reading a MAC address in real command output

On Linux, ip link show (or ip addr show, which includes the same information alongside IP addresses) lists interfaces and their MAC addresses:

ip link show eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:4e:66:a1 brd ff:ff:ff:ff:ff:ff

link/ether is the interface's own MAC address; brd ff:ff:ff:ff:ff:ff is the broadcast address used to reach every device on this segment. The actual MAC address will be specific to your own hardware.

To see the MAC addresses of other devices your machine has recently talked to, read the neighbour table — the cache of IP-to-MAC mappings ARP has already resolved:

ip neigh show

192.168.1.1 dev eth0 lladdr 5c:1a:6f:22:4b:e0 REACHABLE
192.168.1.42 dev eth0 lladdr 08:00:27:9c:11:07 STALE

Each line pairs an IP address with the MAC address behind it on this segment. REACHABLE means the mapping was confirmed recently; STALE means it's cached but unverified and will be re-checked before the next use. Your default gateway will almost always be in this table, because nearly all outbound traffic goes through it.

Practical scenario: two machines appear as one

In virtualized labs, cloned VMs sometimes keep the same virtual MAC address. The result is strange: one machine works for a moment, then the other works, then traffic seems to "jump" between them. The switch is not confused in a human sense; it is doing exactly what switches do. It learns that a MAC address lives behind a port, and when the same MAC appears behind another port, it updates its table.

Time  Switch learns
----  ------------------------------------------------
1     08:00:27:4e:66:a1 is on port 3
2     08:00:27:4e:66:a1 is on port 7
3     Traffic for that MAC now goes to port 7

For a sysadmin, the fix is not to change the IP address first. Check the Layer 2 identity. Each network interface on the same local network needs a unique MAC address, whether it is physical or virtual. If two hosts share one, Layer 3 addressing can look correct while frames are delivered to the wrong place — and every diagnostic that works at Layer 3, including ping, can appear to succeed intermittently while doing so.

Common mistakes

  • Trying to reach a device on a different network using its MAC address. Hardware addresses aren't routable. Once traffic needs to cross into another network only the IP address matters, and a fresh MAC-address pair gets attached for the next physical hop.
  • Treating a MAC address as a trustworthy device identity. It's globally unique as manufactured, but any operating system can change it in software, so it works as a local delivery label and not as an authentication or licensing anchor.

Practice exercises

  1. Run ip addr show (Linux) or the equivalent on your operating system and identify your own network interface's MAC address and its OUI.
  2. Look up which organization the OUI 00:1A:11 — or any OUI from your own results — is registered to, using a public OUI lookup tool or the IEEE registry linked below.
  3. Run ip neigh show and identify your default gateway's MAC address. Then explain, step by step, why a packet traveling from your laptop to a server across the internet keeps the same source and destination IP addresses the whole way, but gets a new pair of MAC addresses at every hop — and where that gateway MAC fits into the very first hop.

Exercise 3 gets you as far as one specific machine on the far side of the internet, which is where IP addressing tops out. But arriving at the right machine isn't the same as arriving at the right program on it: a single server can run a web server, a mail daemon, and a database behind one IP address, and something has to decide which of them a given packet belongs to. That's what Introduction to ports and protocols answers.

Interview questions

  • Basic: What are the two halves of a MAC address, and what does each half identify?
  • Mechanism: Walk through exactly what happens, step by step, when a host on a LAN wants to send a packet to an IP address it has never talked to before — where does ARP fit in, and what gets cached afterward?
  • Troubleshooting: Two VMs cloned from the same template can't both stay reachable at once — one works, then the other, then traffic seems to jump between them. What's the likely root cause, and which command would you run first to confirm it?
  • Trap to watch for: If asked "is a MAC address a safe way to identify a device," don't just say "yes, it's globally unique." A correct answer also mentions that software can override it, and that uniqueness at manufacture time doesn't guarantee uniqueness or stability over the device's life.

Sources