
Default Gateways and How Hosts Route
Default Gateways and How Hosts Route
Where you are: Module 4, lesson 6 of 8. You can split addresses into network and host parts (lesson 2), you know MAC and IP addresses do different delivery jobs (lesson 3), and you can design subnets (lessons 4–5). This lesson answers the question those skills have been circling: when your computer has a packet to send, how does it decide where the packet goes first? The answer lives in a table inside your own machine — and you will read that table today, then deliberately break it in a simulator to watch the exact failure it causes.
What you'll learn
- Explain the default gateway's role using the classic neighborhood-entrance picture
- Walk the local-or-remote decision your computer makes for every single packet
- Read a real host routing table (
route printon Windows,ip routeon Linux) line by line - Explain the 0.0.0.0/0 "anywhere else" line and why the most specific route always wins
- Recognize the symptom signature of a wrong gateway — and fix it
This lesson builds on Chapter 6 of Dr. Tahseen Al-Doori's Network Essentials, which introduces the default gateway with an analogy that has helped a generation of students, and then does something unusual for an introductory text: it sends you straight to the route print command to see the machinery for yourself. We will do both — the analogy first, then the command, then a safe break-and-fix experiment.
The neighborhood entrance
A classic analogy from Dr. Al-Doori's course asks you to picture where you live as a gated neighborhood with exactly one entrance. Visiting a friend three doors down needs no gate: you walk straight to their door, inside the walls. But visiting anyone in another neighborhood always begins the same way — through your one entrance — no matter which neighborhood you are heading to. You do not need to know the whole city's street map. You need to know two things: who is inside your walls, and where the entrance is.
Your computer lives by the same two facts. Devices on its own subnet are the neighbors: it delivers to them directly. Everything else in the world — a server across the ocean, a PC one subnet away — is reached the same first step: hand the packet to the default gateway, the router that is your subnet's entrance. "Default" is precise here: it is where traffic goes by default, when no more specific instruction applies.
The gateway is physical and logical at once. Physically, it is a port on a router connected to your subnet. Logically, it is that port's IP address — the address entered into every host's settings (usually by DHCP, which is why you have probably never typed it). Every host on the subnet shares the same gateway, just as every resident shares the one entrance. And note what a missing or wrong gateway does not break: the neighborhood itself. Local delivery continues perfectly. Only the way out is gone — a symptom signature worth memorizing, because you will meet it in this lesson's lab and then for the rest of your career.
The decision behind every packet
How does your computer know a destination is "outside the walls"? It performs a comparison you already know how to do by hand — from the subnetting lessons — for every packet it sends:
- Take the destination IP address.
- Apply my own subnet mask to it, extracting the destination's network number as seen from my configuration.
- Compare with my own network number.
- Same network → local delivery. Address the frame directly to the destination's MAC address (found via ARP, from lesson 3) and send.
- Different network → remote delivery. Address the frame to the gateway's MAC address — while the packet inside still carries the far destination's IP address — and send. The router takes it from there, hop by hop.
Step 5 is Module 2's two-address system earning its keep: the frame's MAC address gets the packet one hop, to the router; the packet's IP address names the true destination, end to end. The gateway must therefore be an address on your own subnet — the book poses this as a thought question, and the analogy answers it: an entrance you cannot walk to is not your entrance. Layer 2 can only deliver frames to on-link neighbors, and the gateway is reached by exactly such a frame.
Hosts route too: reading the table
We tend to say "routers route," but every host carries a small routing table and consults it for each outgoing packet — the decision above is really a table lookup. Let's read one. The output below is from a Windows machine at 192.168.10.57/24 (authored for this lesson, trimmed to the rows that matter — yours will differ in details):
C:\> route print
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.10.1 192.168.10.57 35
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
192.168.10.0 255.255.255.0 On-link 192.168.10.57 291
192.168.10.57 255.255.255.255 On-link 192.168.10.57 291
192.168.10.255 255.255.255.255 On-link 192.168.10.57 291
224.0.0.0 240.0.0.0 On-link 192.168.10.57 291
255.255.255.255 255.255.255.255 On-link 192.168.10.57 291
===========================================================================
Read it as a set of rules: for destinations matching this network and mask, deliver this way.
- The first line is the star. Destination 0.0.0.0 with mask 0.0.0.0 — a network of "no bits checked" — matches every address in existence. In prefix notation it is 0.0.0.0/0, the default route. Its Gateway column holds 192.168.10.1: the entrance. In words: "to go anywhere not covered below, hand the packet to 192.168.10.1." The book has you find exactly this line, and its reading stands unchanged today.
- 192.168.10.0 / 255.255.255.0 — On-link. My own subnet. "On-link" means no gateway needed — these are the neighbors; deliver directly. This row is born from your IP address and mask the moment the interface configures.
- 127.0.0.0 / 255.0.0.0 — the loopback range from lesson 2: traffic to yourself, never leaving the machine.
- 192.168.10.57 and 192.168.10.255 — my exact address (traffic to myself) and my subnet's broadcast, each a /32 single-address rule.
- 224.0.0.0 / 240.0.0.0 — the multicast range, delivered on-link.
- Metric — a cost score for breaking ties when several interfaces could serve; lower wins. On a laptop with Ethernet and Wi-Fi both up, metrics decide which carries the default route.
The same table on Linux is two lines that say the same thing (ip route):
$ ip route
default via 192.168.10.1 dev wlan0 proto dhcp metric 600
192.168.10.0/24 dev wlan0 proto kernel scope link src 192.168.10.57 metric 600
default is 0.0.0.0/0 — Linux just says the word. via 192.168.10.1 names the gateway; the second line is the on-link subnet rule (scope link), learned from the kernel when the interface came up; proto dhcp admits who filled in the gateway.
One selection rule completes the picture: when several rows match a destination, the most specific match wins — the row with the longest mask. The default route, with the shortest possible mask, matches everything and therefore wins only when nothing else matches at all. It is the table's rule of last resort, which is precisely what "default" means.
Two worked lookups against the table above:
- Destination 192.168.10.20: matches 0.0.0.0/0 and 192.168.10.0/24. The /24 is more specific → On-link → ARP for 192.168.10.20's own MAC, deliver directly. The gateway never sees this packet.
- Destination 142.250.80.46: matches only 0.0.0.0/0 → via 192.168.10.1 → ARP for the gateway's MAC, frame to the router, packet onward to the world.
That is the whole secret of host routing: one specific rule for home, one catch-all for everywhere else.
When the gateway is wrong
Now invert the knowledge. A host with a wrong or missing gateway shows a precise, recognizable illness:
- Local works. Ping neighbors, reach the office printer, browse a NAS on the same subnet — all fine, because on-link delivery never consults the gateway.
- Remote fails. Every destination beyond the subnet times out — web, mail, everything — because the way out points at a door that is not there.
Seen from the helpdesk chair: "I can print but I have no Internet" is a gateway story until proven otherwise. Two commands tell you in a minute: ipconfig (does the Default Gateway field hold a plausible on-subnet address?) and ping <gateway> (does the entrance answer?). Because DHCP normally supplies the gateway, the wrong-gateway disease is most common on hand-configured machines — servers, printers, lab gear — exactly the devices people configure once and forget.
Activity: Find the "anywhere" line on your own computer
Instructions. On your real machine — this is read-only, nothing to break:
- Windows: open Command Prompt, run
route print(ornetstat -r, which shows the same table — the book teaches both spellings). Linux: runip route. - Find your default route: the 0.0.0.0 / 0.0.0.0 line (Windows) or the
default vialine (Linux). Note the gateway address it names. - Run
ipconfig(Windows) orip addr(Linux) and confirm the same gateway/subnet story: your address, your mask, and the gateway inside your subnet. - Find your on-link subnet row and check it against your mask.
- Ping the gateway address and confirm it answers.
Deliverable. Three lines in your notes: your address and mask, your gateway, and the default-route line copied out with a one-sentence translation into plain words.
Self-check. Your gateway address falls inside your own subnet (apply your mask to both and compare network numbers — lesson 2 skills). If you are at home, the gateway is almost certainly your home router, and the same box will star in the next lesson.
Lab: Break and Fix the Gateway (Packet Tracer)
Deliberately causing this failure on your real network would knock you offline mid-lesson. So we break it where breaking is free: Cisco Packet Tracer, the network simulator you installed for Module 3's labs.
Objective. Build two subnets joined by a router, prove end-to-end connectivity, then sabotage one PC's gateway and observe — and explain — exactly which traffic dies and which survives. Then fix it.
Setup. Packet Tracer, new blank file. Drag in: two PCs (PC-A, PC-B), one 2960 switch, one router (any two-port model such as a 4331), and a third PC (PC-C). Cable with straight-through copper: PC-A and PC-B to the switch, the switch to the router's first Gigabit port, PC-C directly to the router's second Gigabit port.
The plan (from this module's style — two small subnets):
| Device | Address | Mask | Gateway |
|---|---|---|---|
| Router port 1 | 192.168.10.1 | 255.255.255.0 | — |
| Router port 2 | 192.168.20.1 | 255.255.255.0 | — |
| PC-A | 192.168.10.11 | 255.255.255.0 | 192.168.10.1 |
| PC-B | 192.168.10.12 | 255.255.255.0 | 192.168.10.1 |
| PC-C | 192.168.20.11 | 255.255.255.0 | 192.168.20.1 |
Steps.
- Configure the router: click it → Config tab → select the first Gigabit interface → set IP address and mask per the table → tick On (Port Status). Repeat for the second interface. Link lights turn green.
- Configure each PC: click it → Desktop tab → IP Configuration → Static → enter address, mask and gateway per the table.
- Baseline, local: PC-A → Desktop → Command Prompt →
ping 192.168.10.12. Expect replies (first attempt may drop one while ARP resolves — normal, and now you know why). - Baseline, remote: from PC-A,
ping 192.168.20.11. Replies prove routing works: PC-A handed the packet to 192.168.10.1, the router forwarded it into the other subnet, and the reply retraced the path. - Break it. On PC-A, change the gateway to 192.168.10.99 — a valid-looking address on the right subnet where no device exists. Leave everything else untouched.
- Local test again:
ping 192.168.10.12— still perfect. The neighborhood does not care about the entrance. - Remote test again:
ping 192.168.20.11— Request timed out, every attempt. PC-A dutifully tries to hand the packet to .99, ARPs for a ghost, and gets silence. - Optional but excellent: switch to Simulation mode (bottom-right), repeat step 7, and watch the ARP frames for 192.168.10.99 leave PC-A and die unanswered — the failure made visible at layer 2.
- Fix it. Restore PC-A's gateway to 192.168.10.1. Re-run step 7: replies return immediately.
Expected result. With the bad gateway: local ping succeeds, remote ping fails 100%. After the fix: both succeed.
Verify. You can state, before running each ping, whether it will use the gateway — and be right all four times (steps 3, 4, 6, 7).
Questions.
- Why did breaking the gateway leave the PC-A ↔ PC-B ping untouched?
- In step 7, does PC-A's packet ever reach the router? Where exactly does delivery die?
- Would
ping 192.168.10.99from PC-A fail the same way as step 7, or differently? (Think: is .99 local or remote from PC-A's view?) - PC-B's gateway is still correct. Can PC-B reach PC-C while PC-A cannot? What does that tell a troubleshooter about where gateway problems live?
(Answers: 1 — local delivery is on-link; the gateway is consulted only for other networks. 2 — no; it dies on PC-A's own subnet, at the ARP step: no device answers for .99, so no frame can even be addressed. 3 — differently in mechanism, same in outcome: .99 is local, so PC-A ARPs for it directly rather than for a gateway — and still gets silence; timeout either way, but no routing was ever involved. 4 — yes, PC-B is unaffected: the gateway setting is per-host, so a wrong gateway breaks exactly one machine — which is why "only one user lost the Internet" points at that user's configuration, not at the router.)
If it goes wrong.
- Red link lights at the router. The interface is administratively off — revisit step 1 and tick On for both ports.
- Step 4 fails from every PC. Check the router's second interface address (192.168.20.1) and PC-C's gateway; a router port configured but off, or PC-C gatewayless, are the usual suspects.
- Step 3 fails. A cabling slip (PC to router instead of switch) or a typo in PC-B's address; hover each device to inspect its addressing at a glance.
- You used a copy of the file with the break still in place. Symptoms follow the config, not your intentions — re-check PC-A's gateway field first.
Reset/cleanup. Save as m4-gateway-lab — Module 5 extends a two-subnet build like this one. Nothing on your real network was touched.
Check yourself
- A host at 192.168.10.57/24 has no gateway configured at all. List two destinations it can still reach and two it cannot.
- Translate this routing-table line into one plain-English sentence: destination 0.0.0.0, mask 0.0.0.0, gateway 192.168.10.1.
- A hand-configured server at 192.168.10.80/24 was given gateway 192.168.11.1. Its admin reports: colleagues on the subnet reach it fine, but it cannot download updates. Explain both symptoms with the delivery decision.
- A destination of 192.168.10.200 matches both the on-link 192.168.10.0/24 row and the 0.0.0.0/0 row. Which rule fires, and under what principle?
- Two PCs on the same subnet have different gateway settings — one right, one wrong. Will file sharing between the two PCs work? Will their Internet access differ?
- Why must the default gateway's address belong to the host's own subnet? Answer with the two-address system from Module 2.
Answers
- Reachable: anything on-link — e.g., a neighbor like 192.168.10.12, the subnet broadcast, and itself (loopback 127.0.0.1). Unreachable: anything beyond the subnet — e.g., 8.8.8.8, any website, a host on 192.168.20.0/24. No entrance, no outside.
- "For any destination not matched by a more specific rule — that is, anywhere outside my own network — hand the packet to the router at 192.168.10.1."
- Inbound-local works because neighbors deliver to the server on-link, no gateway involved. Outbound-remote fails because the server's exit rule points at 192.168.11.1 — an address outside its own subnet, which it can never reach at layer 2 (it would need a gateway to reach its gateway). Fix: set the gateway to an address inside 192.168.10.0/24 — here, 192.168.10.1.
- The on-link /24 row — the most specific match (longest mask) always wins; the default route is only the match of last resort.
- File sharing between them works: same subnet, direct on-link delivery, gateways never consulted. Internet access differs: the PC with the correct gateway gets out; the other times out on every remote destination — gateway settings are strictly per-host.
- The gateway is reached by a frame addressed to its MAC — and frames only deliver on-link (MAC = one hop; IP = end to end). An off-subnet gateway address could never be framed to directly, so the "way out" would itself require a way out.
Key terms
- Default gateway — the router address on your subnet where all traffic for other networks is sent; the neighborhood's one entrance.
- Host routing table — the per-machine rule list mapping destination networks to delivery methods; consulted for every outgoing packet.
- Default route (0.0.0.0/0) — the catch-all rule matching every destination; "anywhere else, use the gateway."
- On-link — a routing-table delivery method meaning "no gateway — deliver directly to the destination's MAC."
- Longest-prefix match — when several rules match, the one with the most mask bits (most specific) wins.
- Metric — a tie-breaking cost when multiple interfaces offer routes; lower is preferred.
route print/netstat -r— Windows commands displaying the host routing table (two names, same table).ip route— the Linux command displaying the host routing table.- Local vs remote decision — masking the destination with your own mask and comparing network numbers; the fork every packet takes.
Summary
- The default gateway is your subnet's single entrance: local destinations are reached directly, everything else goes to the gateway first — a classic picture from the book that remains exactly right.
- For every packet, the host masks the destination with its own mask and compares network numbers: same → on-link delivery via ARP; different → frame to the gateway's MAC, destination IP unchanged inside.
- Hosts route too:
route print(Windows) andip route(Linux) show the rule table; the 0.0.0.0/0 line is the gateway rule, and "default" means match of last resort. - Most specific match wins — the on-link subnet row always beats the default route for local traffic.
- The gateway must be on the host's own subnet, because it is reached by a one-hop frame.
- Wrong-gateway signature: local delivery intact, all remote destinations dead, exactly one machine affected — you produced, observed and fixed it in the simulator.
- DHCP normally sets the gateway; hand-configured devices are where gateway mistakes hide.
Next lesson
Your gateway does more than forward packets — on a home network, that same box quietly rewrites them. Next: private address ranges, why your house and your neighbor's can both be 192.168.1.0/24 without conflict, and NAT — the address-translation trick that lets a whole household share one public address.
Sources and further study
- Al-Doori, T., Network Essentials, Chapter 6 — the default gateway, the neighborhood-entrance teaching, and the original
route printwalk-through this lesson modernizes. - Microsoft Learn, "ipconfig" — https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig — reference for reading your address, mask and gateway on Windows.
- RFC 4632, "Classless Inter-domain Routing (CIDR)" — https://www.rfc-editor.org/rfc/rfc4632 — the prefix notation behind 0.0.0.0/0 and longest-prefix matching.
- Download: OSI and TCP/IP Model Reference (keep it at hand while tracing the frame-to-gateway, packet-to-destination split).
