Skip to content

Router

Every device on your LAN can already reach every other device on your LAN without any help — that's what a switch is for, forwarding Ethernet frames by MAC address within one local segment. The problem starts the moment you want to reach something outside that segment: a server on the other side of the planet, reachable only by IP address, with no MAC address you could possibly know in advance. A router is the device that solves exactly that problem, and it's worth being precise about what "solving it" actually means, because the mechanism is simpler than the reputation the word "router" carries.

One job, repeated at every hop

A router's job is this: receive a packet, look at its destination IP address, and decide which interface to send it out of next. That's the whole job. It doesn't need to know the full path to the destination — only the next step. Every router along a path makes that same narrow decision independently, and the full route from source to destination emerges from thousands of these small, local choices rather than from any single device planning the whole journey in advance. How Does the Internet Actually Work? put it plainly: no single router knows the full path — it only knows the next hop.

This is the boundary that separates a router from a switch, and it's worth stating precisely because the two devices are so often confused: a switch forwards within a network, using MAC addresses at Layer 2; a router forwards between networks, using IP addresses at Layer 3, the Network layer of the OSI model.

The routing table

Every router keeps a routing table — a list of network prefixes and, for each one, which interface (and often which next-hop IP address) to send matching traffic out of. On Linux, you can read a host's own routing table with:

ip route show

default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.42
10.8.0.0/24 via 192.168.1.1 dev eth0 metric 100

Read this top to bottom, most specific match wins: a packet destined for 192.168.1.55 matches the second line directly — it's on the same local segment, so it goes straight out eth0 with no router involved at all. A packet destined for 10.8.0.5 matches the third line, a more specific route than the catch-all default, and gets sent to 192.168.1.1 as the next hop. Everything else — anything that doesn't match a more specific entry — falls through to the default route, which is exactly the default gateway concept MAC address introduced earlier in this course: the one device your host hands off to whenever it doesn't already know a more direct path.

A router applies this same logic to every packet it forwards, using its own, typically much larger, routing table — one entry per network it knows how to reach, not per individual host. That's what keeps routing tables a manageable size even at internet scale: a router doesn't need a row for every one of the billions of IP addresses in existence, only for the address blocks it has a path toward.

How a router actually decides where a packet goes

Concretely, for every packet a router receives, it does roughly this:

  1. Extract the destination IP address from the packet header.
  2. Search the routing table for the most specific matching prefix (the longest matching subnet mask — this is called longest prefix match).
  3. Decrement the packet's TTL by one, and drop it if TTL has reached zero — the exact mechanism traceroute relies on to map a path one hop at a time.
  4. Rewrite the frame's Layer 2 addressing for the next hop (source MAC becomes the router's own outgoing interface, destination MAC becomes the next hop's), and forward it out the interface the matched route points to.

Notice what does not change through this whole process: the packet's source and destination IP addresses. Those stay fixed from the original sender all the way to the final destination. Only the Layer 2 framing gets rewritten at every hop — the same distinction the MAC address article drew between an address that's globally unique but only locally useful, and one that's globally routable.

How routers learn their routes

Small networks — a home, a single office — get by with static routes: an administrator types them in by hand, and they don't change until someone edits them again. This doesn't scale to a network of any real size, because a human can't keep up with links failing, new networks appearing, and paths needing to shift in real time.

Larger networks use dynamic routing protocols instead, where routers exchange information about what they can reach and automatically recalculate routes when the topology changes. How Does the Internet Actually Work? already named the protocol that does this between whole organizations — BGP — where each autonomous system announces the address blocks it can reach. The protocols routers use to learn routes within a single organization's network work differently and are a deeper topic than fits here; this course comes back to routing at internet scale in a later module.

NAT: a router's other common job

On almost every home and small-office network, the router does a second job beyond forwarding: it also performs NAT, translating the private addresses on your LAN into the single public address your ISP assigned you, and back again for return traffic. Routing and NAT are conceptually separate — a router can forward packets between networks without ever touching an address, and NAT can technically run on a device that isn't routing between anything else — but consumer routers do both, which is part of why "router" ends up meaning "the box that connects my home to the internet" in everyday use, even though routing and address translation are two distinct functions bundled into one device.

Practical scenario: one subnet, two default gateways

A office network has two routers on the same 192.168.10.0/24 segment: the primary internet router at 192.168.10.1, and a site-to-site VPN router at 192.168.10.2 that provides a path to a partner company's network. A new workstation gets a static IP configuration during setup, and whoever configured it copies the gateway address from an old device on the VPN router's segment instead of the internet router's.

The symptom is confusing at first: the workstation can reach every other machine on the local 192.168.10.0/24 subnet without any problem — that traffic never touches a router at all, since it stays within one Layer 2 segment. But every request to the outside internet times out. The VPN router has a route back to the partner network and nothing else; anything addressed outside both its own local subnet and the partner's network gets silently dropped, because it has no default route of its own pointing anywhere further.

The fix isn't a firewall rule or a DNS setting — it's checking ip route show default on the workstation and confirming the default gateway actually points at the device that has a path to the rest of the internet, not just at a router that happens to be reachable. Two routers sharing a subnet doesn't cause a conflict by itself; a host pointed at the wrong one for its actual traffic does.

Practice exercises

  1. Run ip route show (Linux) or route print (Windows) on your own machine, and identify the default gateway. Then run ip neigh show and confirm the gateway's IP address resolves to a real MAC address on your local segment.
  2. Using the routing table shown earlier in this article, work out which line matches traffic to 10.8.0.200 and which matches traffic to 172.16.0.1, and explain why longest-prefix match makes the second one fall through to the default route.
  3. Explain, in your own words, why a router forwarding a packet changes the packet's source and destination MAC addresses at every hop but never changes its source and destination IP addresses — and what would break if it did.

A router decides where a packet should go next. It has no concept of blocking traffic based on policy, inspecting what's inside a packet, or deciding that some traffic simply shouldn't be allowed through at all — that's an entirely different job, handled by a firewall.

Sources