Understanding Network Fundamentals: MAC, ARP, Broadcast Domains and Packet Flow

How Data Really Moves in a Network: MAC Addresses, ARP, Broadcast Domains and the Logic Behind It

When you start building or managing a network, everything looks simple at first: there is a cable, a switch, an IP address – if it works, it works. But in practice, problems rarely come from “simple” places. One day the printer shows as “connected” but nothing prints, another day the VPN is up but the intranet does not open, and sometimes everything seems to be “working” but the network is slow and applications lag.

Most of these problems actually lie in the very fundamentals of networking: how devices find each other, how data moves inside the network, which addresses are used to communicate, and where this communication unnecessarily multiplies.

In this article, I want to strengthen the basics. Because in my view, a person who truly “knows networking” is not the one who can recite the most expensive switch models, but the one who knows where to start when a packet is lost. Solid fundamentals move you from the helpdesk reflex of “turn it off and on again” to analytical thinking: “Is this a physical layer issue, or is it breaking at Layer 2 or Layer 3?”

What is a network, really?

A network, in its simplest form, is a communication system that allows devices to exchange data. It has two parts:

Physical part: Cables, Wi-Fi, outlets, patch panels, NICs, ports, signals.
Logical part: Addressing, frames, packets, routing, resolution (ARP/DNS), broadcast, etc.

Most problems are reported as “the internet is down”, but the root cause is usually in the logical part. If the physical layer were completely broken, nothing would work at all. In reality, some things work and some do not. This grey zone is explained by Layer 2 and Layer 3 logic.

OSI vs. TCP/IP: Not memorization, but a map

The OSI model is often taught by rote learning. I see it more as a map that tells you where to look when something breaks.

  • Layer 1 (Physical): Cables, signal, port LEDs, CRC errors, link up/down
  • Layer 2 (Data Link): MAC addresses, switching, frames, VLANs, STP, ARP
  • Layer 3 (Network): IP addressing, subnets, routing, ICMP, TTL, NAT
  • Upper layers: TCP/UDP, applications, DNS/HTTP, etc.

The TCP/IP model groups these more practically. In daily work, both are simply troubleshooting languages. When you say “ping doesn’t work”, you are already testing Layer 3.

PDU: Data changes its form inside the network

Data is not the same at every layer. It is wrapped differently:

  • Layer 2: Frame
  • Layer 3: Packet (IP packet)
  • Layer 4: Segment (TCP) / Datagram (UDP)

This matters in practice. When you open Wireshark, what you see must be interpreted according to the layer. For example, MAC flapping on a switch is a Layer 2 issue that disrupts frames, but the user experiences it as “slow network” on the IP level.

MAC address: Identity before IP

Switches do not care about IP addresses; they work with MAC addresses. A MAC address is the hardware identifier of a network interface. A switch learns:

  1. It looks at the source MAC of incoming frames and stores it with the port.
  2. It checks the destination MAC:
    • Known → unicast to the correct port
    • Unknown → flood to all ports in the VLAN (except the incoming one)

Flooding increases when the switch does not know where a MAC is, and too much flooding degrades performance. MAC tables also age out. This explains problems like “it worked for a few minutes and then stopped” in misconfigured networks with loops or wrong VLANs.

Broadcast domain: Invisible in small networks, painful in large ones

A broadcast domain is the area where broadcast frames are propagated. ARP requests, discovery protocols, and many Windows services use broadcast. Switches forward them to all ports in the same VLAN.

As the network grows, broadcast traffic grows. Every device must process it. At some point, this “noise” affects performance. VLANs are therefore not only for organizational separation but also for limiting broadcast domains.

Collision domain (for completeness)

In the old hub days, all ports shared one collision domain. With switches, each port is its own collision domain and runs full duplex, so collisions are practically eliminated. This explains why switches replaced hubs.

ARP: “I know the IP, but I need the MAC”

Inside the same subnet, IP communication still needs MAC addresses. ARP resolves IP to MAC.

Example:

  • PC1: 192.168.1.10
  • PC2: 192.168.1.20
  • Subnet: 192.168.1.0/24

PC1 sends an ARP Request (broadcast): “Who has 192.168.1.20?”
PC2 replies with its MAC (unicast).
PC1 stores it in the ARP cache and starts normal communication.

Why the ARP cache matters

ARP tables reveal many real problems:

  • IP conflicts
  • Wrong gateway
  • Duplicate IP addresses
  • DHCP misconfiguration
  • A packet going to the wrong physical device

Commands like arp -a (Windows) or ip neigh (Linux) are fundamental tools.

When ARP becomes “stubborn”

If you move an IP address from one device to another (e.g., old server to new VM), some hosts may still have the old MAC in their ARP cache. Until it expires, traffic is sent to the wrong place. Then you see: “IP is correct, but nothing works.” Clearing ARP caches or forcing MAC relearning fixes this.

“The network works, but it’s slow”: Broadcast and flooding

In enterprise networks:

  • Missing or wrong STP → loops → broadcast storms
  • Wrong trunk/VLAN setup → MAC table instability → flooding
  • Oversized broadcast domains → unnecessary processing load

Understanding Layer 2 behavior is therefore essential before designing networks.

What do you gain from this foundation?

  • You start troubleshooting at Layer 2/3, not only DNS.
  • You understand what Wireshark actually shows.
  • You know why VLANs exist beyond “department separation”.
  • You can detect IP conflicts and gateway issues via ARP.
  • You think in traffic flow, not in random commands.

Bridge to the next topic

With this Layer 2 foundation, the natural next steps are:

  • VLAN segmentation
  • Trunking and tagging
  • STP and loop prevention
  • Then proper subnetting and routing

In networking, the hardest part is not memorizing commands, but visualizing how traffic flows. If you can picture that in your head, you are no longer just fixing tickets – you are understanding infrastructure.