Switching and VLANs

The last lesson ended with a laptop on 10.20.4.0/24 handing anything outside its subnet to a default gateway and trusting a chain of routers to get it the rest of the way. That covers the packet's journey once it leaves the local network. It says nothing about how the laptop's frame gets to the gateway in the first place, or how two machines plugged into the same switch fifteen feet apart find each other. That handoff, entirely local, entirely inside one network, is switching, and it runs on a different address than the one routing cares about.

A switch forwards frames by MAC address, not IP address

Every network interface, on a laptop, a phone, a server, a printer, ships from the factory with a MAC address burned into its hardware: a 48-bit number written as six pairs of hex digits, something like 3c:22:fb:9a:11:04. It is assigned once, at manufacture, and under normal operation it does not change no matter what network the device joins or what IP address gets handed to it by DHCP. An IP address describes where a device sits in a network's addressing scheme, and that scheme can be reassigned in an instant. A MAC address describes the physical interface itself, and it stays fixed to that hardware.

A switch connects devices within a single local network, and its forwarding decisions never look at an IP address at all. It reads the destination MAC address on each incoming frame, a frame being the Ethernet-level container that carries an IP packet across one physical link, and decides which port to send it out. This is Layer 2 work, one layer below the routing covered last lesson, and it is worth sitting with why the split exists. IP addressing is a logical scheme, assigned by an administrator or a DHCP server, meant to represent where something is in a hierarchy of networks. MAC addressing exists to answer a narrower, more mechanical question: on this one physical segment, which specific piece of hardware is this frame meant for. A switch only ever needs to answer that narrower question, so it only ever needs the narrower address.

This is also why the earlier lesson's description of a router as boundary-crossing and a switch as staying inside one network holds up under closer inspection. Every device plugged into a switch, directly or through other switches chained together, shares the same IP subnet. A frame moving between them never needs a router, never needs a default gateway, and never needs anything beyond a MAC address to find its target.

A switch learns by watching source addresses go by

A switch is not preloaded with a map of which device sits on which port. It builds that map itself, and it builds it entirely by observation. Every time a frame arrives on any port, the switch looks at the frame's source MAC address, the address of the device that sent it, and records an entry: this MAC address lives on this port. That record goes into a structure called the MAC address table, sometimes called a CAM table on the hardware itself, and it is the single piece of state that makes efficient forwarding possible.

Before a switch has learned where a given destination MAC lives, it has only one option: flood the frame out every port except the one it arrived on, and let whichever device recognizes itself as the intended recipient keep it while everything else ignores it. That is expensive on a busy network, since it means every unknown destination briefly behaves like a shout into every room in the building. Once the switch has seen a reply, or any frame at all originating from that MAC address, the entry lands in the table and every future frame addressed to it goes straight to the one port that needs it. The flooding was a one-time cost paid while the switch was still ignorant of where things lived.

Picture four devices on a small switch: a workstation on port 1, a network printer on port 2, a file server on port 3, and an uplink to another switch on port 4. The first few frames each device sends populate the table, and after that, traffic between the workstation and the printer never touches ports 3 or 4 at all. That containment is the entire value proposition of a switch over a hub, the older device it replaced, which simply repeated every incoming signal out every other port regardless of who needed it. A switch's whole design is built around not doing that.

MAC Address        Port    Age (sec)
3c:22:fb:9a:11:04    1       12
a4:5e:60:c1:88:2f    2       47
00:1a:2b:3c:4d:5e     3        3
88:66:5a:12:0d:99     4        1

That age column matters. Entries do not sit in the table forever; a switch times them out, typically after a few minutes of silence from that address, because a device might get unplugged from one port and moved to another, or a network card might get swapped out. If the entry never expired, a moved device would become unreachable until something forced a fresh entry, so the table quietly refreshes itself as long as traffic keeps flowing.

Restating the split: one network versus between networks

It helps to put the switch and router side by side one more time, now that both have a full explanation behind them. A switch works within a single network, using MAC addresses, at Layer 2, and its job is getting a frame from one port to another as directly as possible. A router works between networks, using IP addresses, at Layer 3, and its job is deciding which network a packet needs to reach next and which interface gets it started in that direction. A switch never consults a routing table and never makes a longest-prefix-match decision, because every device attached to it is already, by definition, reachable without one. A router never learns MAC addresses the way a switch does, at least not for anything beyond its own directly connected interfaces, because its entire concern is addresses outside the local segment.

This division shows up physically in most real deployments. An office might have a dozen switches spread across floors, all of them feeding into one or two routers that connect that office's network to everything else. Frames move freely and quickly between any two devices on any of those switches, since they all belong to the same local network, chained together by uplinks exactly like the port 4 example above. The moment traffic needs to leave that local network entirely, for the internet or for a separate department's subnet, it has to pass through a router, and only then does IP-level, Layer 3 decision-making enter the picture at all.

The broadcast domain: what a shout actually reaches

Some frames are not addressed to any single MAC address. A broadcast frame carries the special destination ff:ff:ff:ff:ff:ff, and a switch's rule for that address is simple and absolute: send it out every port, no exceptions, no table lookup needed because the destination is, by design, everyone. DHCP requests work this way, since a device that has no IP address yet has no way to send anything except a broadcast, hoping a DHCP server somewhere on the segment answers. ARP requests, the mechanism a device uses to find the MAC address behind a known IP address, work the same way.

The set of devices a broadcast actually reaches is called a broadcast domain, and on a plain switch, with no further configuration, that domain is the entire switch and everything chained to it through other switches. A broadcast sent by a device on port 1 of one switch reaches every device on that switch, crosses the uplink to a second switch, and reaches every device there too, all the way out to wherever the chain of switches ends. A router, notably, does not forward broadcasts between the networks on its different interfaces. That is one of the clean, structural reasons the boundary between "one network" and "different networks" matters: a broadcast domain stops exactly where routing begins.

A large flat network, meaning one big broadcast domain with nothing splitting it, has a real cost that grows with size. Every broadcast, every DHCP request, every ARP lookup from any device reaches every other device on that entire domain, and as the device count climbs into the hundreds or thousands, that background chatter starts consuming real bandwidth and real processing time on every single node, whether or not that node cares about the message. There is also a security dimension worth naming plainly: any device sitting on a shared broadcast domain can see certain kinds of local traffic meant for its neighbors, and a compromised device on a flat network has an easier time reaching everything else on that same segment. Neither problem is solved by adding faster switches. It is solved by making the broadcast domain smaller.

VLANs carve one switch into several isolated networks

A VLAN, virtual LAN, is the feature that lets a single physical switch behave as though it were several separate switches, each with its own broadcast domain, without running a separate cable or buying separate hardware for each one. An administrator assigns each port on a switch to a VLAN, identified by a number, and from that point on the switch treats devices in different VLANs as though they were not connected at all, even though the same physical box and the same physical cabling carry both. A broadcast sent by a device in VLAN 10 reaches every other port assigned to VLAN 10 and stops there. It never reaches a port assigned to VLAN 20, even one sitting right next to it on the same switch.

A guest network and an internal server network sharing one switch is the example that makes this concrete. A small business might put its front-desk visitor Wi-Fi access point on VLAN 20 and its internal file server and accounting workstations on VLAN 10. Both sets of devices plug into the same physical switch, sometimes the same rack unit, and the hardware cost stays the same as running one flat network. But a guest device on VLAN 20 has no path to anything on VLAN 10 without going through a router configured to allow it, and by default nothing is configured to allow it. Segmentation like this limits how far an attacker who compromises one device can actually reach. A compromised guest laptop sitting on VLAN 20 cannot simply scan the local network and discover the accounting server, because as far as that switch's forwarding logic is concerned, VLAN 10 might as well be on a different building's wiring.

A port connected to a single end device, a workstation, a printer, an access point serving one VLAN, is called an access port. It belongs to exactly one VLAN, and every frame arriving on it is treated as belonging to that VLAN with no tagging needed, since there is only ever one VLAN in question on that link. Between switches, though, a single cable often needs to carry traffic for many VLANs at once, since two switches might each have devices on VLAN 10, VLAN 20, and VLAN 30, and running a separate physical cable per VLAN between every pair of switches does not scale. That link is called a trunk port, and it solves the problem with tagging, standardized under 802.1Q: every frame crossing a trunk gets a small tag inserted into its header naming which VLAN it belongs to, so the switch on the receiving end knows exactly which VLAN to deliver it into once it arrives. The tag exists only on the trunk link itself. It gets added the moment a frame leaves an access port headed toward a trunk, and stripped back off the moment it leaves the trunk headed into an access port on the far side, so an ordinary end device never sees a VLAN tag at all.

Switching and VLANs handle everything that happens before a packet ever needs a router: getting a frame to the right device by MAC address, and, with VLANs, deciding which devices even count as being on the same network in the first place. What neither one explains is how an entire building full of devices, each with a private address like 192.168.10.40, manages to reach the public internet through what looks from the outside like a single address. That translation, and the reason private address ranges exist at all, is the next lesson: NAT and private networks.