MAC Addresses, Hubs, and the Quiet Power of Switches

The physical layer hands bits to the data link layer. The data link layer's job is to get those bits from one machine to the next machine on the same local network. Not across the internet. Not across the country. Just across the wire to the next box.

To do that, every network interface in the world has an address — the MAC address.

Hardware addresses, burned into the card.

A MAC address is a 48-bit number, usually written as six pairs of hexadecimal digits, like A4:5E:60:F2:7B:1C. It is assigned by the manufacturer of your network card at the time it is built. It is sometimes called the "hardware address" or "physical address," because in the original design it was meant to be globally unique and burned into the chip.

The first three octets of a MAC address are the Organizationally Unique Identifier (OUI). Each NIC manufacturer gets one or more OUIs from the IEEE, and they then assign the remaining three octets to their cards. In theory, every NIC in the world has a unique MAC address.

In practice, mostly. There is a well-known war story I'll share, because it's the kind of thing that turns into a four-day debugging nightmare and never makes it into the textbooks.

Once upon a time, I came across two LAN cards in the same network with the same MAC address. By every standard, that should not have been possible. It took four days to identify what was wrong with the network, because I was not even looking for duplicate hardware addresses — I assumed they were unique. The lesson is not "MAC addresses are unreliable." The lesson is: do not assume any global uniqueness guarantee is absolutely true. Cheap hardware, counterfeit chips, and human error all break invariants you were taught to trust.

MAC addresses are not just for legitimate use.

Modern operating systems also let you override the MAC address that your card reports on the wire. The hardware reports its real address; the software intercepts that and substitutes a different one. This is called MAC spoofing.

There are legitimate reasons to do this — testing, privacy, network research. There are also illegitimate ones, which is why understanding it matters for defenders too. Many serious attacks against networks start at Layer 2, not Layer 7. If you can impersonate another machine's MAC address on the network, you can intercept traffic that was meant for it. This kind of attack does not show up in your application logs at all, because the application has no idea Layer 2 was compromised.

Senior engineers, especially the security-minded ones, think about networks bottom-up and top-down. The hackers do.

Hubs vs. switches, this time properly.

We already touched on this in the cable chapter, but now we can describe it correctly.

A hub operates at Layer 1. It is electrically dumb. A signal arriving on any port is repeated out to every other port. There is no awareness of MAC addresses, no awareness of conversations, no isolation. Every packet is broadcast. The entire hub shares one collision domain — if two machines transmit simultaneously, the signals collide and have to be retransmitted.

A switch operates at Layer 2. When a frame arrives on a port, the switch reads the source MAC address and remembers that this MAC lives behind this port. It also reads the destination MAC address and looks up which port that one is behind. Then it forwards the frame only to that port. Other ports do not see the conversation at all.

This gives you per-port collision isolation, full-duplex operation (both directions at once), and parallel conversations: A talking to B at full speed, while C talks to D at full speed, all through the same switch. The switch has, internally, a small CPU and a MAC address table (sometimes called a CAM table) that it maintains in memory.

The first time a switch sees a new MAC address, it does not know where to send the reply. In that case it floods the frame to every port, exactly like a hub would, and then learns from the response which port the new MAC lives on. After that, traffic to that MAC is forwarded only to the correct port. This learning behavior is automatic and continuous.

ARP — bridging hardware addresses and IP addresses.

There is a hidden glue layer between the world of MAC addresses and the world of IP addresses, and it is called ARP — the Address Resolution Protocol.

Your computer wants to send a packet to 192.168.1.10. That is an IP address. But to actually send a frame on the LAN, your network card needs the MAC address of 192.168.1.10. How does it find out?

It broadcasts an ARP request: "Who has 192.168.1.10? Tell me your MAC address." The broadcast goes to every device on the local network. The device with that IP address responds: "That's me. My MAC is A4:5E:...". Your computer caches that mapping in its ARP table, and from then on it can send frames directly.

The ARP table on your machine is something you can inspect. On Linux/macOS, the command is arp -a. Try it. The list of entries is, in effect, a map of your local network as seen by your machine.

This is also why local network attacks like ARP spoofing work. There is no authentication on ARP responses. Whoever shouts loudest, fastest, gets believed. We will not dwell on attack details here, but the existence of the attack should make you appreciate that every layer in this stack carries a set of assumptions, and assumptions are where the bugs (and the breaches) live.

Push On It

1. Look up your own MAC address. On most systems: ifconfig or ip link on Linux/macOS, ipconfig /all on Windows. Find the OUI portion (the first three octets) and look it up online — what company made your network card?
2. Run arp -a. How many devices does your machine currently know about on your LAN? Identify each one by IP and try to match it to a physical device you can name.
3. Read about VLANs (Virtual LANs). They are a Layer 2 concept that lets one physical switch act like several isolated networks. Where would you use them in a real office? In a real cloud deployment?