Understanding LAN from a Front-End Developer's Perspective: MAC Addresses, Ethernet Frames, and Switches

As front-end developers, you interact with networks every day — sending HTTP requests, receiving JSON responses, maintaining WebSocket connections. But have you ever wondered: when your browser communicates with a remote server, how does data actually take its first step? Or when your laptop transfers a file to your phone on the same Wi-Fi, what path does the information follow to arrive at the right place?

This chapter focuses on the most fundamental layer of network communication — the local area network. We won't discuss the wider internet just yet, nor dissect a complete browser request cycle. Instead, we start with a smaller question: inside the same room, how does one device send data to another? The answer introduces three core characters: MAC addresses, Ethernet frames, and switches. Understanding them gives you the first piece of the computer networking puzzle.

Picture a typical home scenario: your phone, laptop, tablet, and smart TV are all connected to the same Wi-Fi. At this point, these devices have already formed a local area network, or LAN. Office desk networks, school computer labs, and an entire floor of a company building are also LANs.

The definition of a LAN is straightforward: a network that connects multiple devices within a limited physical area, enabling them to communicate with each other. It solves a fundamental problem — within this local scope, how do devices locate one another and reliably deliver data?

Once data needs to travel beyond this local boundary (say, accessing an external server), the communication mechanisms become far more complex. But even then, any packet leaving your machine must first traverse the local LAN. The LAN is the first hop for every network request.

Inside a LAN, suppose computer A wants to send the data hello to phone B. The first challenge is: how do you address the other party?

Descriptions like "that black phone" or "the tablet I usually use" make sense to humans but are useless to machines. Network devices need a machine-readable, fixed physical identifier. At the LAN layer, this identifier is called a MAC address (Media Access Control address).

A MAC address is the physical identity of a network interface card within a LAN. Every device capable of networking has a network interface: a laptop's wireless card, a wired Ethernet port, a phone's Wi-Fi module, a router's interface, a server's network adapter... Each network interface is assigned a globally unique MAC address at the factory.

It typically consists of 6 bytes (48 bits), expressed in hexadecimal, like this:

A4:5E:60:C1:2B:9F
38:F9:D3:7A:11:20
CC:2D:E0:12:88:AB

With a MAC address, computer A can specify the destination precisely: "Please deliver this data to the device with address 38:F9:D3:7A:11:20." This is far more precise than "deliver to that phone," and machines can execute it perfectly.

An important nuance: a MAC address identifies a network interface, not the abstract "entire device." A laptop might simultaneously have a wireless card, a wired Ethernet port, a Bluetooth module, and even virtual network interfaces created when running Docker. Each network interface has its own independent MAC address. So, more rigorously: a single device can have multiple MAC addresses. For now, just remember: one network interface corresponds to one MAC address, which serves as a "communication ID" within the LAN.

With a MAC address in hand, computer A might think it can simply toss hello into the LAN. But the network is not a point-to-point dedicated line — it's a shared medium where all devices can "hear" the signal. The tablet, TV, and router in the room can all perceive it. If you sent a bare hello, a cascade of problems would arise:

• Who should receive it? Without a destination label, every device would be confused.
• Who sent it? The receiver wouldn't know where the data came from and couldn't reply.
• Is the data intact? Signals can be corrupted during transmission, and the receiver has no way to verify integrity.
• Which upper-layer protocol? Which processing module should handle the data — HTTP? Something else?

This is why a LAN never transmits raw data directly. It must encapsulate the data into a standardized packet. In Ethernet, the most prevalent LAN technology, this packet is called an Ethernet frame.

A simplified Ethernet frame can be imagined as an envelope with these fields:

┌─────────────────────┐
│  Destination MAC     │  ← Recipient: who is this frame for?
├─────────────────────┤
│  Source MAC          │  ← Sender: who sent this frame?
├─────────────────────┤
│  Type / Length       │  ← Content type: what protocol is inside? (e.g., IPv4, ARP)
├─────────────────────┤
│  Payload             │  ← Letter body: the actual data being transmitted
├─────────────────────┤
│  Frame Check Sequence│  ← Tamper seal: was the data corrupted in transit?
└─────────────────────┘

• Destination MAC tells every device on the LAN who this frame belongs to. Only the device with an exact match will accept and process it. Other devices, even if they sense the signal, will discard the frame due to the address mismatch.
• Source MAC lets the receiver know who sent it, enabling a reply. Meanwhile, the switch (discussed in the next section) uses it to learn device locations.
• Type field marks the upper-layer protocol. For example, 0x0800 means IPv4 data is inside; 0x0806 means ARP. This way the receiver can hand off the payload to the correct upper-layer protocol.
• Payload carries the actual information to be transmitted — it might be a TCP handshake packet, a fragment of an HTTP request, or a video stream.
• Frame Check Sequence (FCS) is a checksum. The receiver recalculates and compares it; if they don't match, the frame is considered corrupted and discarded. Ethernet itself does not handle retransmission — reliable delivery is left to upper layers (such as TCP).

So what circulates within a LAN is never raw data, but fully encapsulated Ethernet frames. This is a crucial point: every communication must be packaged into a frame.

Now, imagine we use a switch to connect three computers into a wired LAN:

Computer A ──┐
Computer B ──┼── Switch
Computer C ──┘

The switch's core responsibility is: to connect multiple devices within a LAN and, based on the destination MAC address, forward frames from one port to the correct output port. When A sends a frame destined for C, the switch inspects the destination MAC and then delivers the frame only to the port where C is connected, rather than blindly broadcasting to all devices. This is precision forwarding, which dramatically improves LAN efficiency.

One key point: the switch doesn't care whether you're visiting example.com or api.github.com, nor whether the payload is JSON or HTML. It only looks at the destination MAC and source MAC in the Layer 2 frame header and makes decisions accordingly. This layered philosophy mirrors front-end development: the underlying HTTP library doesn't care about the page's UI. Each layer has its own clear boundary.

A switch obviously can't locate devices by guessing. It internally maintains a MAC address table (also called a forwarding table), which records which physical port each MAC address corresponds to. This table isn't manually configured by an administrator — the switch builds it dynamically through self-learning.

Assume the table is initially empty:

1. Computer A (MAC: AA:AA:AA:AA:AA:AA, connected to port 1) sends a frame to computer C (MAC: CC:CC:CC:CC:CC:CC, connected to port 3). The frame enters the switch through port 1.
2. The switch first looks at the frame's source MAC AA…AA and immediately records: "address AA…AA is on port 1." The table now has its first entry.
3. It then looks at the destination MAC CC…CC, but there is no entry for CC…CC yet. The switch doesn't know where C is, so it resorts to flooding: it copies and forwards this frame to every port except the receiving port 1 (i.e., ports 2 and 3). This ensures C will definitely receive it, even though B will temporarily receive an irrelevant frame as well.
4. Computer C receives the frame, sees that the destination MAC matches its own, processes it, and prepares a reply. Computer B sees the mismatch and simply discards it.
5. C's reply frame to A enters the switch through port 3. The switch again checks the source MAC and learns: "address CC…CC is on port 3."
6. At this point, the switch knows the locations of both A and C. From now on, any frame destined for CC…CC will be directly and precisely forwarded to port 3, never bothering B again.

This learning process happens continuously, and the switch eventually builds knowledge of all active devices, allowing the vast majority of traffic to be forwarded point-to-point with high efficiency. Only unknown or broadcast frames trigger flooding.

When the switch doesn't know where the destination is, flooding is the only reasonable approach: it's essentially saying "I don't know this address — everyone, please pay attention. The real recipient, please respond." Once the target replies, its location is recorded, and flooding is never needed again for that address. Flooding incurs a one-time bandwidth cost in exchange for fully automatic discovery capability. In a properly designed LAN, this is perfectly manageable. The real trouble comes from broadcast storms, which are usually caused by network loops and are beyond the scope of this article.

Many people have just one networking box at home, commonly called a "router." But in reality, consumer-grade all-in-one devices go far beyond routing alone. They typically integrate the following logical roles into a single box:

• Switch: connects LAN ports, handling Layer 2 frame forwarding within the local network.
• Wireless Access Point (AP): emits Wi-Fi signals, allowing wireless devices to join the same LAN.
• Router: connects the LAN to the internet, performing IP-layer forwarding and Network Address Translation (NAT).
• DHCP server: automatically assigns IP addresses to LAN devices.
• Basic firewall: provides inbound/outbound security filtering.

When your phone and laptop connect to the same Wi-Fi, they are actually joining the same built-in switch via the wireless AP, forming a hybrid "wireless + wired" LAN. Therefore, within the LAN — whether connected via Ethernet cable or Wi-Fi — all the principles we've discussed (MAC addresses, Ethernet frames, switch learning and forwarding) apply exactly the same way. This distinction is crucial when troubleshooting common issues like "I can ping within the LAN but can't access the internet."

By now, we have a solid grasp of the complete LAN communication chain: identify devices with MAC addresses, encapsulate data in Ethernet frames, and let the switch perform precision forwarding based on its self-learned MAC address table. These three elements form the foundation of Layer 2 networking.

But in real-world development, you typically know the destination IP address (such as 192.168.1.100 or 10.0.0.5), not its MAC address. When a front-end app calls an API, you provide a domain name or IP — never a MAC address. So:

If you only know the IP address, how do you obtain the corresponding MAC address?

This is exactly the problem that another core LAN protocol — ARP (Address Resolution Protocol) — solves. In the next article, we'll see how ARP cleverly uses broadcast requests and unicast replies to map an IP address to a MAC address, and why, when accessing the internet, we always query the gateway's MAC address rather than the remote server's. This will naturally connect the two major scenarios of "LAN communication" and "cross-network communication."

• A LAN is a network interconnecting devices within a small area. It is the first hop for data leaving your machine.
• A MAC address is the physical identity of a network interface. Delivery within a LAN is entirely based on it.
• An Ethernet frame encapsulates destination MAC, source MAC, type, data, and checksum into a standardized transmission unit.
• A switch forwards frames precisely to the correct port based on the destination MAC and a self-learned MAC address table. Unknown destinations trigger flooding to guarantee reachability.
• A home "router" typically integrates a switch, wireless AP, router, DHCP server, and more — its LAN portion is essentially a switch.
• MAC addresses answer the question "who within the same LAN?" while IP addresses answer "which network is the destination in?" The two serve distinct roles, bridged by ARP.