Think of a network as a building full of rooms, doors, and hallways. You move information the same way you would move letters and packages between apartments.
License: CC BY-NC-ND 4.0
Preface: Why We Need Analogies
I wrote this for the version of me who could type ping and traceroute but still had no picture of what the packet was doing.
That gap matters. Subnet masks, ARP tables, and routing entries are not hard because they are abstract. They are hard because they are abstract and invisible. If nobody gives you a picture, you end up memorizing syntax without building intuition.
I use analogy here because packets are invisible until you have seen enough failures to picture the trip in your head. When you are in a terminal at 3 AM and the output starts to smear together, that picture is often what keeps you from guessing.
When the analogy stops being accurate, I will say so directly. A good analogy should make your next diagnostic step clearer, not make you confidently wrong.
Prologue: The Day the Map Failed Me
My first real lesson in networking came during an outage in 2014.
A customer’s database cluster dropped off the network. The engineer next to me said something about an ASA firewall, ARP entries, and a gateway that had gone missing. I knew the terms. I did not know what story they were telling.
I ran the obvious commands:
$ ping 10.50.2.1
From 10.50.2.23 icmp_seq=1 Destination Host Unreachable
$ traceroute 10.50.2.100
...
* * *
That output looked dramatic, but it did not tell me enough. A timeout did not prove the remote host was dead. “Host unreachable” did not prove the firewall was broken. It only told me that somewhere between my machine and the destination, the path was failing.
The real issue turned out to be an IP conflict on an old switch stack. ARP entries were wrong. Traffic was being sent to the wrong place. The problem was ordinary. What I lacked was not vocabulary. I lacked a map.
That is the map we are building here.
Part One: Buildings as Networks
Chapter 1: The Room, the Door, and the Placard
Start with a building.
Your local network is the building. A device on that network is a room in the building. Your laptop is a room. Your phone is a room. A printer is a room, whether you like that printer or not.
Every room needs a door. In networking terms, that door is an interface. An Ethernet port is a door. A Wi-Fi radio is a door. A server can have several doors because it may connect to several networks at once.
Each door has two labels:
- A door label stamped into the hardware. This is the MAC address, such as
AA:BB:CC:11:22:33. - A room placard assigned by the building’s current floor plan. This is the IP address, such as
192.168.1.101.
The difference matters.
The MAC address is used for local delivery on the same floor. It is usually tied to the interface, though modern systems can spoof, virtualize, or randomize it.
The IP address describes where the device currently sits in the network’s logical layout. If you carry the same laptop to a coffee shop, the hardware door is still your hardware door, but the room placard changes because you are now in a different building.
When two devices are on the same local network, they do not need a city map. They need local labels and a local path.
Where the analogy bends
A device is not literally a room with one fixed door. It may have multiple interfaces, virtual interfaces, tunnels, or VPN adapters. The analogy still holds if you treat each interface as a separate door attached to the same room.
What matters is this:
- MAC address answers: “Which local door?”
- IP address answers: “Which logical location?”
Chapter 2: The Hallways Between Rooms
Now look at the path between doors.
The physical or wireless medium that carries traffic is the hallway. Different hallways behave differently.
Copper
In many offices and homes, the hallway is copper Ethernet.
Think of it as a direct tube from your door to a shared mailroom on your floor. It is point to point. Your device is not shouting into a crowd. It is sending bits over a dedicated link to the switch.
Copper is practical and common, but it has limits. On standard twisted-pair Ethernet, runs longer than about 100 meters usually need different design choices because the signal degrades.
Fiber
If you need distance, higher bandwidth, or cleaner signaling, you use fiber.
Fiber carries light instead of electrical signaling. That makes it useful for longer links, uplinks between closets, data center interconnects, and long-haul transport. It is fast and reliable when installed correctly, but it usually costs more and needs more careful handling.
Wi-Fi
Wi-Fi is still a hallway, but it is a shared one.
Instead of a private tube, you are using radio in a shared space. That changes the failure modes. Distance matters. Walls matter. Interference matters. Congestion matters. When Wi-Fi feels unstable, the problem is often not “the internet” in general. It is the local shared medium.
Measuring the hallway
Two terms show up constantly here:
- Bandwidth is the capacity of the link. How much data can move per second.
- Latency is the travel time. How long one unit of data takes to cross the path.
You can have high bandwidth and still have noticeable latency. A fast long-distance link can move a lot of data once the flow is established while still taking time for the first response to arrive.
Where the analogy bends
Hallways in a building feel passive. Real links are electrical, optical, or radio systems with error handling, negotiation, duplex settings, and physical constraints. The hallway picture is useful for direction and capacity, but not for the full physics.
Chapter 3: Floors as Subnets
A building with one enormous floor would be noisy and difficult to manage. Networks solve that problem by dividing space into subnets.
In this analogy, a subnet is a floor.
Devices on the same floor can usually deliver traffic directly to each other. Devices on different floors need help from the building’s vertical path: the default gateway.
Why divide the building at all?
- To keep local broadcast traffic contained.
- To organize systems by role or trust level.
- To make routing and policy easier to reason about.
If every device lived on one giant flat network, broadcasts would spread everywhere. ARP requests, service discovery traffic, and other local noise would reach far more devices than necessary. A small amount of that traffic is normal. At larger scale it becomes a design problem.
The subnet mask is the floor plan.
If your address is 192.168.10.101/24, the /24 tells your machine that addresses beginning with 192.168.10 are on the same floor. If the destination is outside that range, the device knows it needs the gateway.
That is the first routing decision most hosts make:
- Same floor: deliver locally.
- Different floor: send toward the elevator lobby.
Where the analogy bends
A subnet is a logical boundary, not an architectural one carved into concrete. In practice, subnets interact with VLANs, route tables, firewalls, and provider-specific behavior. The “floor” picture is useful because it gives you the right first question: “Is this destination local or not?”
Chapter 4: Sliding the Envelope
Now walk through a local delivery.
You are in room 10-101. You want to send a file to room 10-115. In IP terms, suppose your device is 192.168.10.101 and the destination is 192.168.10.115.
Your machine checks the floor plan first. The destination is on the same subnet, so this is local delivery.
But local IP knowledge is not enough. To put a frame on the wire, your machine still needs the destination MAC address. So it asks the floor:
Who has
192.168.10.115?
That question is ARP.
The request is broadcast on the local segment. Every device on the floor can hear it. The device that owns 192.168.10.115 replies with its MAC address. Your machine caches that result so it does not have to ask again for every packet.
Now the frame can be sent.
The switch on your floor acts like a mailroom that learns where doors are connected. As frames arrive, the switch records which source MAC addresses are reachable through which physical ports. Later, when it sees a destination MAC it already knows, it forwards the frame only out the correct port.
That selective forwarding is why modern switched networks are quieter and more efficient than old shared-media Ethernet.
A failure case worth remembering
If the switch does not know the destination MAC yet, it does not magically know where to send the frame. It floods the frame within that local broadcast domain except on the port it arrived on. That is one place where the clean mailroom picture starts to blur: unknown destinations briefly look more like “ask the whole floor.”
Leaving the floor
Now change the destination. Suppose you want to reach 192.168.20.115.
Your machine compares that address to its subnet mask and sees that the destination is not local. It does not ARP for the remote host’s MAC. It ARPs for the MAC address of the default gateway, because the next local hop is the elevator lobby.
So the local frame looks roughly like this:
- Destination MAC: gateway’s local interface
- Source MAC: your interface
- IP destination: the remote host on another subnet
That detail is easy to miss and worth keeping in your head: the Ethernet frame is addressed to the next local hop, while the IP packet is addressed to the final destination.
From there, the router takes over.
Where the analogy bends
Switches usually forward based on Layer 2 headers, not by opening and interpreting the whole message the way a human clerk would. The analogy is still useful because it teaches the troubleshooting sequence:
- Is the destination local or remote?
- If local, do I know the destination MAC?
- If remote, do I know the gateway MAC?
- Has the switch learned where that MAC lives?
If you can answer those four questions, local network behavior stops feeling mysterious.