The Mixed Estate

Switch vs router

2026-10-17T00:00:00Z

Last time, DHCP (Dynamic Host Configuration Protocol) handed a device an address and, tucked in alongside it, a default gateway. We swept straight past it to talk about options. Time to go back and ask the obvious question: what does that gateway actually do with your traffic the moment it leaves your device?

Almost everything else in networking quietly assumes you already know. This is the article that stops waving its hands about it.

Switch vs router

The quickest way to keep these straight is to think about where each one makes its decisions.

A switch moves traffic within a single network. Every device it's dealing with is on the same subnet, and it forwards frames using MAC (Media Access Control) addresses at Layer 2.

A router moves traffic between different networks: other subnets, other sites, or out to the internet. It makes its decisions using Internet Protocol (IP) addresses at Layer 3.

That's genuinely the whole distinction. If two devices are on the same subnet, a switch alone gets them talking and a router isn't part of the conversation. The moment a device wants something on a different subnet, which includes anything outside its own virtual LAN (VLAN), it has no choice but to hand the packet to a router and let that router work out the next step.

The default gateway, properly explained

This is what Option 3 from the DHCP article was quietly setting up. The default gateway is simply the router a device should use for anything that clearly isn't on its own local subnet.

Before sending anything, the device compares the destination address against its own address and subnet mask. If the destination is local, it sends the traffic directly. If it isn't, it hands the packet to the gateway and lets that deal with the rest of the journey.

Leave out the gateway, or get it wrong, and a device can talk happily to everything on its own subnet while being unable to reach anything else. That's the classic "the network's fine but nothing works" ticket, and it sends people looking in all the wrong places first.

What's inside a routing table

A router's whole job runs off one structure: the routing table. Every entry is essentially a rule saying that traffic for this network should go out of this interface, towards this next hop.

You can see one on your own machine. On Linux or a Mac, ip route or netstat -rn will show it. On Windows, use route print. A tiny one looks like this:

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50

Each entry has:

A destination network, the range the rule applies to.
An interface to send matching traffic out of.
Usually a next hop, the next router along the path, if the destination isn't directly attached.
Often a metric, a cost value used to prefer the cheaper or faster path when more than one route could do the job.

Every table also has a default route, usually written as 0.0.0.0/0. It's the catch-all: if nothing more specific matches, send it here. On a home or office router, that entry is what points towards your internet service provider (ISP), and it's how a router says "I've no specific rule for this, so it's probably headed for the wider internet."

How a router picks a route

This is the part that catches people out the first time. A routing table can contain several entries that all match the same destination: a broad one and a much more specific one. So which wins?

The rule is longest prefix match. The router always prefers the most specific matching route, meaning the one with the longest prefix, over a broader one, whatever the metric says.

Say a table contains these two routes:

10.0.0.0/16 via router A
10.0.5.0/24 via router B

A packet for 10.0.5.20 matches both. The /24 is more specific, so it goes via router B, every time. Metric only comes into play as a tiebreaker when two entries are equally specific.

It's how a router can hold a broad default route pointing at the internet plus a handful of specific routes for internal networks, and never mix the two up.

Static vs dynamic routing

There are two ways entries get into that table.

Static routes are configured by hand. They're reliable and predictable, but they don't adapt: if a link goes down, a static route has no idea it should route around the problem.

Dynamic routing uses a routing protocol, with OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol) being the big names. Routers talk to each other, share what they know about the network, and update their tables automatically when something changes, such as a link failing. Those protocols are dense enough to deserve their own articles, so this is only a signpost.

Most home and small-office setups need little more than a single default route, because there's only one sensible way out to the internet. Larger networks with more than one possible path lean on dynamic routing precisely because they need to adapt without a human noticing and fixing it.

Summary

Switches move traffic within a network, and routers move it between networks. Every router relies on a routing table full of "send this destination out this way" entries, and it always prefers the most specific match available. Static routes are hand-configured and simple. Dynamic routing adapts automatically, at the cost of real complexity.

With that in place, we can go back to addressing, because IPv6 (Internet Protocol version 6) doesn't hand out addresses the way DHCP does. Next up: SLAAC vs DHCPv6.

DHCP and its options: more than just an IP address

2026-10-13T00:00:00Z

Every device on a network starts out the same way: it has no address, no idea who else is there, and no way to ask anyone directly. So it shouts… DHCP is the protocol that answers.

It's easy to take for granted, but most of what makes a network feel like it "just works" (the printer that appears on its own, the laptop that behaves on a new Wi-Fi network) comes down to DHCP doing its job quietly in the background. It's also one of the first places to look when something stops working.

Why DHCP exists

Before DHCP, addressing was manual. Every device got a static IP, recorded somewhere: a spreadsheet if you were lucky, a sticky note if you weren't. That falls apart quickly at any kind of scale.

DHCP (Dynamic Host Configuration Protocol) solves one problem: getting a device everything it needs to talk on the network, automatically, without anyone touching it.

The important phrase there is everything it needs. An IP address is only part of it. A device also needs a subnet mask, a default gateway and DNS servers, and sometimes a boot server or a time source. Those extras are delivered as options, which are covered below.

DORA: how a device gets its address

The exchange is four packets, and it has a name worth remembering: DORA.

Discover. The device has no IP yet, so it can't address anything directly. It broadcasts to 255.255.255.255, effectively asking whether any DHCP server is out there.
Offer. A DHCP server replies with a candidate lease: an IP address, a lease time and its own identity.
Request. This is the step that catches people out. The client doesn't simply accept the offer. It broadcasts again, naming the specific offer and server it wants. If there's more than one DHCP server on the segment, that broadcast tells the others their offers weren't chosen.
Acknowledge. The chosen server confirms the lease and hands over the full set of options.

Four packets take a device from nothing to fully configured.

It also explains something you'll see in the wild: APIPA. If a device ends up with a 169.254.x.x address, DORA failed somewhere. No Offer came back, so the device gave itself a fallback address that can only talk to other APIPA devices on the same segment. It isn't broken, just a client giving up gracefully.

Scopes, leases and reservations

A scope is the pool of addresses a DHCP server is allowed to hand out, along with the rules attached to it: the subnet, any exclusions and the lease duration.

Lease time

Lease time is a setting most people leave on the default and forget about. That's usually fine, until it isn't.

Short leases mean devices renew often. That suits environments where addresses churn, such as guest Wi-Fi or a large kiosk fleet where devices come and go.
Long leases mean less renewal traffic, but changes take longer to reach devices. If you change the DNS servers or the gateway, clients won't pick that up until they next renew, which could be days.

A long lease can also be perfectly sensible. If DHCP is running on a modest router and your network rarely changes, there's no reason to make it work harder than it needs to.

Reservations

A reservation sits between static and dynamic addressing. The device still uses DHCP, but its MAC address is pinned so it always receives the same IP. It's the sensible way to give a printer or server a predictable address without configuring it by hand on the device itself.

One real-world note: end users tend to think of a reservation as a static address. It's worth knowing the difference, because the configuration lives on the DHCP server, not the device.

Options: where the real configuration lives

The IP address is almost the least interesting thing DHCP provides. The options carry the configuration that makes that address useful, and each one has a number.

A few come up constantly when managing a real estate:

Option	Name	What it does
3	Router	The default gateway. Without it, a device knows its own subnet but can't reach anything beyond it.
6	DNS servers	Get this wrong across a large estate and you'll spend a day chasing "the internet's down" tickets that turn out to be DNS in disguise.
15	Domain name	Feeds suffix search lists, which is why a device can resolve "fileserver" without the full FQDN being typed. Using FQDNs everywhere is still the better habit.
66 / 67	TFTP server and boot filename	Essential for PXE boot, imaging and zero-touch provisioning. The device is told not just an address, but where to go to boot an operating system.

Vendor-specific options

Option 43 is the classic vendor-specific option. Wireless controllers use it so that an access point can find its controller automatically on first boot, with no manual configuration. It's the difference between unboxing 200 access points and having them configure themselves, and touching every one by hand.

Options are also where platform differences show up in a mixed estate. Not every operating system honours every option in the same way, so it's worth checking before assuming a setting will work everywhere.

There's a further catch: different vendors sometimes use the same option number for entirely different things. If DHCP isn't running on a proper server, it can be very hard to specify an option on a per-vendor, per-device basis.

Where DHCP breaks

Three failure patterns turn up again and again.

Scope exhaustion

The pool runs dry, usually because the lease time is too long for the number of devices passing through the subnet. New devices get nothing.

Take a pub running residential kit for customer Wi-Fi on a busy day. Two hundred customers, nearly all on a phone, and half of them with a watch as well, is 300 addresses. But the router's default setup is 192.168.1.0/24, a Class C network with the mask 255.255.255.0, which only has room for 254 usable addresses. The customers who arrived last can't get online.

Rogue DHCP servers

Someone plugs in a cheap router with DHCP enabled by default, and now part of the segment is getting offers from two servers. This is exactly what DHCP snooping on managed switches is for: it lets you specify that only certain ports are allowed to answer DHCP requests.

The usual explanation is that they were only trying to get five devices online from the one ethernet port they'd been given.

Option drift

Someone updates the DNS servers on one scope and forgets the other four. A chunk of the estate then quietly resolves against a decommissioned server until every lease naturally expires.

Summary

DORA hands out the lease. Scopes define the pool and the rules around it. Options are the payload that makes the address worth having. Get the options wrong, and the address barely matters.

Understanding DHCP also raises an obvious question: once a device has its default gateway, what does that gateway actually do with its traffic? That's covered in the next article, on what a router really does.

The Mixed Estate

Switch vs router

Switch vs router

The default gateway, properly explained

What's inside a routing table

How a router picks a route

Static vs dynamic routing

Summary

Further reading

DHCP and its options: more than just an IP address

Why DHCP exists

DORA: how a device gets its address

Scopes, leases and reservations

Lease time

Reservations

Options: where the real configuration lives

Vendor-specific options

Where DHCP breaks

Scope exhaustion

Rogue DHCP servers

Option drift

Summary

Further reading