Day 5 — Supplement A: From Switching to Routing

How a Packet Actually Leaves Your Network

Foundation Networking Course | Civilian Track Companion to Day 5 — Network Layer & IP Addressing Document Version: v1.2

Document Map

This supplement is organized into four Stages, each containing one or more Parts:

• Stage I — Layer 2 Foundations (Switching)

  • Part 1 — Local Networks

  • Part 2 — DNS Need

  • Part 3 — On-Link Check

  • Part 4 — ARP

• Stage II — The PC's Decision Process (Bridge)

  • Part 5 — DNS Resolution

  • Part 6 — Sending to the Gateway

• Stage III — The Router Takes Over (Routing)

  • Part 7 — Router Forwarding

• Stage IV — Edge Cases

  • Part 8 — Proxy ARP

• Appendix A — Network Design Variations

Part numbering continues in Supplement B (Part 9 onward).

Purpose of This Supplement

The main Day 5 lecture covers IP addressing, subnetting, and routing as separate topics. This supplement exists to connect them — to walk through, in one continuous story, why a router has to exist at all, and how a device actually decides, packet by packet, whether to use the switch or the router.

We'll use one real, relatable example — typing google.com into a browser — and follow it the entire way, step by step.

Stage I — Layer 2 Foundations (Switching)

The world of MAC addresses and the local segment, where Day 4's switching material lives. This stage establishes the floor that everything else builds on.

Part 1 — Local Networks

Life Inside the Local Network (Layer 2 Only)

Start with the simplest possible case: two devices on the same switch, in the same network.

A switch's entire job is communication between Layer 2 devices. Because every device connected to it is in the same network, the switch doesn't need to think about routing, gateways, or which network anything belongs to. It only needs two pieces of information for every frame: the source MAC address and the destination MAC address. As long as both devices are on the same switch (the same Layer 2 segment), the switch can get a frame from one to the other without ever looking at an IP address.

Switches move frames using MAC addresses, and only MAC addresses.

But this immediately raises a problem. A device wants to send something — and it knows the destination's IP address (that's how humans and applications refer to things). The switch can only deliver based on MAC address. Something has to translate between the two. That something is ARP — but before we get to ARP, we need to look at the very first problem a device hits, before it even has an IP address to work with.

Part 2 — DNS Need

The Real Starting Point: You Don't Even Have an IP Address Yet

When you type google.com into your browser and press Enter, your PC needs an IP address to actually send the request to Google — that's just how IP networking works, everything has to be addressed by IP.

But the problem starts right here: your PC doesn't know the IP address of google.com. It only has a name.

So it needs a translator — something that can take "google.com" and hand back an actual IP address. We call this translator DNS.

This single fact is the reason the rest of this document has two layers to it: your PC first has to reach a DNS server (using whatever IP that DNS server has), and only afterward does it have a real IP address for google.com to reach. Both of those — reaching the DNS server, and then reaching google.com — go through the exact same decision-making process, which we'll cover next.

Part 3 — On-Link Check

The One Decision Every Outgoing Packet Goes Through: On-Link Determination

Before your PC sends anything — the DNS query, or later the actual request to google.com — it has to answer one question first:

"Is this destination on my own local network, or not?"

This check has a name: on-link determination (also called same-subnet determination). It is the single most important decision in this entire story, because everything downstream — whether ARP is even attempted, and who it's aimed at — depends on the answer.

The Calculation Behind On-Link Determination

Every device knows two things about itself:

1. Its own IP address — e.g. 192.168.10.10

2. Its subnet mask — e.g. 255.255.255.0 (the same as /24)

The subnet mask tells the device which bits identify the network and which bits identify the host. To perform on-link determination, the device applies its subnet mask to both its own IP address and the destination IP address, using a bitwise AND, and compares the two results:

• Wherever the mask bit is 1, the original IP bit is kept.

• Wherever the mask bit is 0, the result is forced to 0.

If the two results match, the destination is on-link (local). If they don't match, the destination is off-link (remote). This is the same operation used elsewhere in Day 5 to calculate network and broadcast addresses during subnetting.

Worked Example

Device: 192.168.10.10 /24

Checking 192.168.10.50 (a local DNS server, for example):

My IP:          192.168.10.10   →  11000000.10101000.00001010.00001010

Mask (/24):     255.255.255.0   →  11111111.11111111.11111111.00000000

                                    -----------------------------------

My network:     192.168.10.0    →  11000000.10101000.00001010.00000000



Destination:    192.168.10.50   →  11000000.10101000.00001010.00110010

Mask (/24):     255.255.255.0   →  11111111.11111111.11111111.00000000

                                    -----------------------------------

Dest. network:  192.168.10.0    →  11000000.10101000.00001010.00000000



My network (192.168.10.0) == Dest. network (192.168.10.0)  →  SAME  →  ON-LINK (local)

Checking 8.8.8.8 (a public DNS server, for example):

My IP:          192.168.10.10   →  11000000.10101000.00001010.00001010

Mask (/24):     255.255.255.0   →  11111111.11111111.11111111.00000000

                                    -----------------------------------

My network:     192.168.10.0    →  11000000.10101000.00001010.00000000



Destination:    8.8.8.8         →  00001000.00001000.00001000.00001000

Mask (/24):     255.255.255.0   →  11111111.11111111.11111111.00000000

                                    -----------------------------------

Dest. network:  8.8.8.0         →  00001000.00001000.00001000.00000000



My network (192.168.10.0) != Dest. network (8.8.8.0)  →  DIFFERENT  →  OFF-LINK (remote)

This is purely local math, done instantly, before a single bit is sent anywhere. This is the decision that everything else in this document depends on.

Part 4 — ARP

Turning an IP Address Into a MAC Address

ARP (Address Resolution Protocol) sits between Layer 3 and Layer 2 — its only job is to translate an IP address into a MAC address.

• Layer 3 (IP) gives ARP an input: "I need to reach this IP address."

• Layer 2 (MAC) is what ARP produces as output: "Here is the MAC address behind that IP."

Every device keeps an ARP table (also called an ARP cache) that memorizes IP-to-MAC mappings it has already learned, so it doesn't have to ask again every time. (This is different from a switch's MAC address table, which tracks which port each MAC address lives behind — two separate tables, two separate purposes.)

How ARP Asks the Question — Broadcast

When a device doesn't yet know the MAC address behind an IP, it sends the question to everyone on the local segment, using a broadcast, addressed to FF:FF:FF:FF:FF:FF:

"Who has 192.168.10.50? Tell 192.168.10.10."

The switch floods this broadcast out every port except the one it came in on. Every device on the segment sees the question. Only the one device that owns that IP recognizes itself and replies — a normal unicast, straight back to the asker, carrying its MAC address.

Why Broadcast Is the Reason ARP Can't Cross Networks

This is the detail the rest of the story depends on: a router will never forward a broadcast onto another network. That is a hard stop. So ARP, by its very nature, can only ever get an answer from inside its own local segment.

This is exactly why on-link determination (Part 3) has to happen before ARP is ever attempted. Your PC already knows, from the math, whether broadcasting an ARP request for a given IP could possibly get an answer. It never wastes an ARP request on something it already knows is unreachable by broadcast — which is why the on-link check exists as the first step, not an afterthought.

Stage II — The PC's Decision Process (Bridge)

The PC has now learned everything Layer 2 can offer. From here on, it has to start making routing decisions — even though it isn't a router. This stage is the transition from "is it local?" to "which way should I send it?"

Part 5 — DNS Resolution

Reaching the DNS Server: Two Scenarios

Now let's connect Parts 2–4 using the real google.com example. Where your DNS server's IP address comes from determines which path your PC takes — and this depends on how your PC's IP configuration was set up.

Scenario 1 — Dynamic IP (DHCP), local DNS server

If your PC's IP address was assigned dynamically (DHCP), it almost always also receives a DNS server address automatically — and that DNS server is usually inside your own local network (often your router itself).

1. PC runs on-link determination on the DNS server's IP → result: on-link.

2. Because it's on-link, the PC ARPs directly for the DNS server's MAC address.

3. The DNS server replies with its MAC.

4. The PC sends the DNS query straight to it — the frame never leaves the local network.

5. The DNS server replies with google.com's real IP address (e.g. 142.250.190.78).

Scenario 2 — Static IP, public DNS (e.g. 8.8.8.8)

If the PC's IP configuration was set manually, and the DNS server given is a public address like 8.8.8.8, the path changes:

1. PC runs on-link determination on 8.8.8.8 → result: off-link.

2. Because it's off-link, ARP for 8.8.8.8 directly is never even attempted — the PC already knows that broadcast would go nowhere.

3. Instead, the PC sends the DNS query toward its default gateway, which forwards it onward toward 8.8.8.8.

4. Eventually the query reaches 8.8.8.8, which replies with google.com's real IP address.

(How exactly the PC knows to send it to the gateway — and how it gets the gateway's MAC address — is what Part 6 explains in detail.)

Part 6 — Sending to the Gateway

Now You Have google.com's IP — How Does the PC Know to Send It to the Gateway?

The PC now has the real IP for google.com: 142.250.190.78. It runs on-link determination one more time, and the result comes back off-link (essentially always the case for a public internet address — your local network is a tiny private bubble, Google's servers are nowhere near it numerically).

OK — so what does the PC do now?

The Simple Answer First — And Why It's Almost Enough

You might reasonably think: "That's easy. The PC already knows the gateway's IP from its IP configuration. On-link said 'not local.' So just send the frame to the gateway. Done."

And honestly — in a simple home network, you'd be right. That logic works:

1. On-link determination: not local.

2. Look up the configured gateway address: 192.168.10.1.

3. ARP for the gateway's MAC, build the frame, send it.

If that's all you ever needed, there'd be no story here. A single "gateway IP" setting plus the on-link check would be enough, and we could stop now.

But here's the problem: that simple logic only works when there's exactly one non-local direction to go. The moment your network has more than one possible "remote" destination — needing different next hops — it falls apart.

Why "Just Send to the Gateway" Isn't Enough in Real Networks

Imagine your office network. You're on 192.168.10.0/24, but there's more than one router on your segment:

• 192.168.10.1 — the normal gateway, used for internet access

• 192.168.10.254 — a different router that connects to the research network 10.50.0.0/16

Now you try to reach 10.50.1.5. On-link determination says: not local. Fine. But which gateway does the PC send the frame to?

With just a single stored gateway IP, the PC has no way to choose. It would send everything to 192.168.10.1 — including the traffic for 10.50.0.0/16, which 192.168.10.1 knows nothing about. The traffic would be dropped.

What the PC actually needs is a way to say:

• For 10.50.x.x destinations → use 192.168.10.254

• For everything else not local → use 192.168.10.1

That's two rules, with different next hops, and the PC has to pick the right one based on the destination. A single stored gateway address can't do this. A list of rules can. That list is called a routing table.

Your PC Has Its Own Routing Table — the Host Routing Table

Every device with a TCP/IP stack — your laptop included — has its own small routing table, called the host routing table. Routers have big ones with thousands of entries; your PC's has just a handful. But the lookup process is exactly the same.

The host routing table is built automatically as soon as your PC gets its IP configuration. For our simple home example, it would contain entries like these:

Destination       Mask              Next Hop           Interface

192.168.10.0      255.255.255.0     0.0.0.0 (direct)   eth0     ← your own local network

0.0.0.0           0.0.0.0           192.168.10.1       eth0     ← the default route

• The local network entry (192.168.10.0/24) says: "for anything on my own subnet, send it out my interface directly — no gateway needed." Built automatically from your IP and subnet mask.

• The default route (0.0.0.0/0) says: "for anything not matched by anything else, send it to 192.168.10.1."

And in the more complex office example, the table would have a third entry sitting between them:

Destination       Mask              Next Hop           Interface

192.168.10.0      255.255.255.0     0.0.0.0 (direct)   eth0     ← local network

10.50.0.0         255.255.0.0       192.168.10.254     eth0     ← specific route to research net

0.0.0.0           0.0.0.0           192.168.10.1       eth0     ← default route (catch-all)

Now the PC has a way to handle multiple non-local destinations correctly. The lookup walks through the entries from most specific to least specific, and uses the first one that matches. (This is the same longest prefix match rule from the main lecture — your PC uses it just like a router does.)

You can actually see your own routing table on your machine — try route print on Windows, or ip route on Linux/macOS. You'll see your own host routing table sitting right there.

So What Is the Default Route, Really?

Here's the honest answer to "why do I need a default route if I already have the gateway address":

In a simple home network, the default route really is just "the routing-table form of the gateway address." You're not wrong to notice that. It looks duplicative because, for that simple case, it is — both say the same thing: "anything remote, send to 192.168.10.1."

But the default route exists as a mechanism, not just for the simple case. It's the catch-all entry at the bottom of a routing table that may have other, more specific entries above it. In a home network with only two entries (local + default), it looks redundant. In a network with five or ten entries, the default route is what catches everything the more specific entries didn't.

So the relationship between "default gateway" and "default route" is:

• The default gateway (192.168.10.1) is the address you (or DHCP) configure.

• The default route (0.0.0.0/0) is the routing-table entry that points to it.

• The routing table is the mechanism that lets you have other, more specific entries alongside the default one.

The gateway address by itself is just a number in a config file. The default route is what installs that number into the routing table as the catch-all. And the routing table is what allows other routes (research network, VPN, static routes) to coexist with that catch-all and be checked first.

How the PC Uses the Host Routing Table for google.com

So when the PC asks itself "where do I send 142.250.190.78?", it doesn't have magic intuition — it walks through its host routing table from most specific to least specific:

• Does 142.250.190.78 match 192.168.10.0/24 (local network)? → No.

• Does it match any other specific entry? → No.

• Does it match 0.0.0.0/0 (default route)? → Yes — and that entry says: "send it to 192.168.10.1."

That's the answer. The PC now knows: send this frame toward 192.168.10.1.

In a simple home network like ours, this lookup is effectively the same as "is it local? if not, use the gateway." But the mechanism scales: tomorrow when you connect to a VPN, the VPN client just adds another entry to the table, and the same lookup process now correctly routes corporate traffic through the VPN while everything else still uses the default route.

Two Paths to Get the Gateway's MAC: Cache or Fresh ARP

The PC knows the gateway's IP address, but the switch can only deliver by MAC. So now we hit ARP again — with two possible paths:

Path 1 — The gateway's MAC is already in the ARP cache

Remember Part 4 — every device keeps an ARP table (ARP cache) of recently-learned IP-to-MAC mappings. If the PC has talked to the gateway before — for the earlier DNS query, or any other recent traffic — it already remembers the gateway's MAC. No ARP request needed. The PC just pulls the MAC out of the cache, builds the frame, and sends it. This is the most common case in practice, because once you're online and exchanging traffic, you're talking to the gateway constantly, so its MAC is almost always cached.

Path 2 — The gateway's MAC is not in the cache (or the entry expired)

Then the PC does the same ARP process from Part 4, but aimed at the gateway:

"Who has 192.168.10.1? Tell 192.168.10.10."

Broadcast goes out, switch floods it, the router on 192.168.10.1 recognizes itself and replies with its MAC. The PC stores that mapping in its ARP cache for next time.

Wait — Does a Router Interface Even Have a MAC Address?

A reasonable question at this point: the PC is asking for the router's MAC address — but the router's interface is just a port on the side of a router, not an Ethernet card like the one in a PC. Does it actually have a MAC address?

Yes — every router interface has its own MAC address, burned into it at the factory, exactly like an Ethernet card on a PC.

A router interface isn't really "just a port" in the way a switch port is. It's a full Layer 2 + Layer 3 interface — it has electronics, a chip, and a unique MAC address. This has to be true: the router needs to participate in Ethernet on that network, and Ethernet only works with MAC addresses. Frames are addressed source MAC to destination MAC. If the router interface didn't have a MAC, nobody could send it a frame, and it couldn't send frames either. So every Ethernet-capable interface on a router gets its own MAC, just like every Ethernet card on a PC does.

A typical Cisco router with multiple interfaces will have a different MAC address for each interface — Gi0/0 has one MAC, Gi0/1 has another. They're separate physical chips, separate electronics, separate MAC addresses, even though they all live in the same router chassis.

You can confirm this on a real router with the command:

show interface GigabitEthernet0/0

You'll see a line like:

Hardware is iGbE, address is 0050.7966.6800 (bia 0050.7966.6800)

That 0050.7966.6800 is the router interface's MAC address — same format as any other MAC, fully usable in Ethernet frames.

How Does the Switch Know Which Port the Router Is On?

OK — the router has a MAC. But the PC doesn't send the frame directly to the router. It sends the frame to the switch, and the switch has to figure out which port the router is connected to. How does the switch know?

The switch learns the router's MAC the same way it learns every other device's MAC — by observing traffic.

Remember from Day 4 — switches build their MAC address table by watching the source MAC of every frame coming in. Whenever a frame arrives, the switch looks at the source MAC and records: "this MAC address lives on this port." It does this automatically for every device that ever sends a frame, including the router:

MAC Address              Port

0050.7966.6800           Gi0/3      ← router's MAC, learned automatically

aabb.cc11.2233           Fa0/1      ← your PC's MAC

ccdd.ee44.5566           Fa0/2      ← another PC

So when did the switch learn where the router lives? It happened during the ARP exchange itself. Walking through it step by step:

1. Your PC sends an ARP broadcast asking "Who has 192.168.10.1?" — this is a broadcast, so the switch floods it everywhere.

2. The frame's source MAC is the PC's MAC — the switch sees that frame coming in on the PC's port and records: "PC's MAC = port Fa0/1."

3. The router receives the broadcast (the switch flooded it to every port, including the router's port), recognizes its own IP, and sends a unicast ARP reply back to the PC. That reply's source MAC is the router's MAC.

4. The switch sees this reply frame coming in on whichever port the router is connected to (Gi0/3 in the example) — and records: "router's MAC = port Gi0/3."

That's the moment the switch learns where the router lives. From now on, the switch has the router's MAC in its table, and any frame addressed to that MAC will be forwarded out the correct port — not flooded.

So the chain from PC to router actually involves two MAC-table lookups happening invisibly, in two completely different tables:

1. The PC's ARP table tells the PC: "router IP 192.168.10.1 = router MAC 0050.7966.6800."

2. The switch's MAC address table tells the switch: "MAC 0050.7966.6800 = port Gi0/3."

Both tables get built automatically by observing normal traffic. Neither one requires any configuration. And once both are populated, frames flow from PC to router with zero broadcasts and no extra overhead — just pure Layer 2 forwarding based on MAC addresses.

The Frame the PC Finally Sends

Either way, the PC now has everything it needs to build the actual frame:

Ethernet Frame:

  Destination MAC : Router's MAC          ← just to get the frame to the router

  Source MAC      : PC's own MAC



  IP Packet (inside the frame):

    Destination IP : 142.250.190.78       ← unchanged — this is still where it's ultimately going

    Source IP      : 192.168.10.10

    [HTTP/HTTPS request: GET / ...]

The frame is addressed (at Layer 2) to the router — that's just "who do I physically hand this to next." But the packet inside (Layer 3) is still asking for Google's real address. Nothing about the actual destination changes. Only the next-hop MAC address changes.

The switch sees the router's MAC as the destination and forwards the frame to whichever port the router is on. The router receives it, strips off the Ethernet layer, looks at the IP packet inside, sees 142.250.190.78, and now the router has to make its own routing decision.

Stage III — The Router Takes Over (Routing)

Up to here, all the work has happened on the PC. Now the packet has physically arrived at the router, and the router has to take its own turn at making the same kinds of decisions. This is the routing world.

Part 7 — Router Forwarding

The Router Takes Over: What Happens When the Frame Arrives

OK — the frame just arrived at the router's Gi0/1 port. Now let's slow down and trace exactly what happens, one step at a time, the same level of detail we used for the PC's side.

Step 1 — First, a Reminder: What's Actually Inside That Frame?

Before we explain what the router does, let's remember what arrived at its door.

When the PC built the frame back in Part 6, it didn't just send "raw data." It wrapped that data in layers — each layer adding its own header with specific information. This wrapping process is called encapsulation, and every frame leaving the PC contains roughly three pieces of information stacked together:

• Ethernet header (Layer 2) — source MAC and destination MAC. Job: get this frame from one device to the next-hop device on the local segment.

• IP header (Layer 3) — source IP and destination IP. Job: identify where this is ultimately going, end-to-end, across every network it crosses.

• Payload — the actual data (the HTTPS request to Google).

Each layer has a different job. The Ethernet header is only useful for one hop — it gets the frame from your PC to the router, and that's it. The IP header keeps going the whole journey, unchanged. The payload is the actual content that nobody along the way touches.

So the frame the router receives looks like this:

[ Ethernet header | IP header | Payload ]

   ↑                ↑           ↑

   MAC addresses    IP addresses  HTTPS request

   (for THIS hop)   (end-to-end)  (untouched)

Step 2 — The Router Strips Off the Ethernet Header (De-encapsulation)

Here's the key insight: once the frame arrives at the router's port, the MAC addresses have done their job and are no longer useful.

Why? Because the router isn't on a local network anymore — it's about to forward this to a different network entirely. MAC addresses only mean something within one Layer 2 segment. They don't help the router decide which direction to send the packet next. What the router needs is the IP information, because IP addresses are what work across networks.

So the router does something called de-encapsulation — it unwraps the outer Ethernet layer and throws it away. The MAC addresses are discarded. What's left is just the IP header and the payload.

And here's a small but important detail: once you remove the Ethernet wrapper, we don't call this a "frame" anymore. It's a packet.

This is the proper terminology — Layer 2 PDU = frame, Layer 3 PDU = packet. The router stops thinking in terms of frames the moment it strips off the Ethernet layer; from this point on, it's working with the packet inside.

Before (frame arrives):              After (router strips Ethernet):

[ Ethernet | IP | Payload ]      →   [ IP | Payload ]

                                     (now called a "packet")

Step 3 — The Router Reads the Destination IP Address

The router now looks inside the IP header and reads the destination IP address:

Destination IP : 142.250.190.78

Source IP      : 192.168.10.10

This is the only question the router cares about: where does this packet need to go?

Step 4 — The Router Runs On-Link Determination — Same Calculation the PC Did

Here's the part that connects beautifully to everything we already covered. The router does the exact same bitwise AND calculation that the PC did way back in Part 3. The only difference is that the router checks against its own interfaces and subnet masks, not the PC's.

The router asks itself: "Is 142.250.190.78 on a network that's directly connected to one of my own interfaces?"

To answer that, we need to introduce something new: the concept of a directly connected network, and how it ends up in the router's routing table.

Step 5 — Where Does the Router's Routing Table Come From in the First Place?

The router's routing table doesn't start empty. The moment you configure an IP address on a router's interface and that interface becomes fully active — both the physical layer (cable detected, signal alive) and the line protocol (the Layer 2 protocol reports up) — the router automatically adds an entry to its routing table for that interface's network. This is called a directly connected network.

In Cisco terminology, the interface needs to be in the "up/up" state — the first "up" is physical (something is detected on the wire), the second "up" is the line protocol (the Layer 2 protocol agrees the link is working). If you configure the IP but no cable is connected, or the other end is off, the interface stays "up/down" and no C entry appears. This is worth knowing because it means: missing a route in the table sometimes just means the interface isn't actually up — not that anything was misconfigured at Layer 3.

So if you configured Gi0/1 with IP 192.168.10.1/24 and brought it up, the router automatically knows: "the network 192.168.10.0/24 is reachable directly through my Gi0/1 interface — no other router needed, I'm sitting on it myself." That entry shows up in the routing table marked with the letter C (for "connected"):

Codes: C - connected, L - local, S - static, ...



C    192.168.10.0/24 is directly connected, GigabitEthernet0/1

C    10.0.0.0/30     is directly connected, GigabitEthernet0/0

These C entries appear automatically — you don't configure them. They're a free byproduct of configuring the interfaces themselves.

How to Actually See This on a Router

A few short notes — not commands to memorize, just so you know how an admin would verify what we just described:

• show ip route — displays the routing table itself, including the C entries.

• show ip interface brief — one-line-per-interface summary showing each interface's IP, status (up/down), and line protocol (up/down). If you ever wonder why a C entry isn't appearing, this is the first place to look.

• show cdp neighbors — on Cisco devices, CDP (Cisco Discovery Protocol) automatically detects directly connected Cisco devices and shows you who's on the other end of each cable. Very useful for verifying that two routers are actually cabled to each other the way you think they are.

One more detail worth knowing: this whole story assumes the connection between the router and the next device is Ethernet (the most common case today). If it's a serial point-to-point link (HDLC, PPP — older WAN-style connections), there are no MAC addresses at all on that link. The next-hop concept still exists, but ARP doesn't apply because a serial link only has two ends, so there's no ambiguity about who the "next hop" is. For the rest of this part, we'll keep assuming Ethernet, since that's what almost every modern link looks like.

Step 6 — What "Directly Connected" Actually Means

This phrase has a specific technical meaning, and it's worth pausing on because participants will hear it constantly in real Cisco environments.

"Directly connected" means: this network is reachable through one of my own interfaces, with no other router in between. The router is physically (or logically) attached to it — devices on this network can talk to the router without going through any third party.

A router's very first job is to know about its directly connected networks. These are the networks the router itself sits on, and they form the foundation of every other routing decision. Why? Because at every routing decision later, the question becomes: "Is the destination on one of my directly connected networks, or do I need to send it to another router?"

• If the destination IS on a directly connected network → the router can deliver it itself. It just needs to ARP for the destination's MAC on that local interface and send the frame. (This is what happens at the very last hop, when the packet finally arrives at a router connected to Google's network.)

• If the destination IS NOT on a directly connected network → the router has to send the packet to another router that's closer. To figure out which one, the router needs more information than just its own connected networks.

Step 7 — A More Realistic Scenario: Three Configured Networks, One Connected Device, and a Destination That Matches None of Them

Let's stop using the toy example and look at a more realistic router setup. Imagine a router that has been configured with three of its own networks — three interfaces, each connected to a different segment — plus one extra device hanging off one of those segments. Specifically:

• Gi0/1 → the LAN network 192.168.10.0/24 (PCs, the printer, etc.)

• Gi0/2 → the server network 192.168.20.0/24 (internal servers)

• Gi0/3 → the management network 192.168.30.0/24 (admin workstations)

• A directly connected device on the WAN side via Gi0/0 → the ISP modem at 10.0.0.1, on the link 10.0.0.0/30

So the routing table on this router automatically contains four C entries — one for each interface that was configured and brought up:

Codes: C - connected, L - local, S - static, ...



C    192.168.10.0/24 is directly connected, GigabitEthernet0/1

C    192.168.20.0/24 is directly connected, GigabitEthernet0/2

C    192.168.30.0/24 is directly connected, GigabitEthernet0/3

C    10.0.0.0/30     is directly connected, GigabitEthernet0/0

Now our packet arrives, destined for 142.250.190.78 (google.com). The router walks through its routing table, doing the same on-link calculation on each entry:

• Is 142.250.190.78 on 192.168.10.0/24? → No.

• Is 142.250.190.78 on 192.168.20.0/24? → No.

• Is 142.250.190.78 on 192.168.30.0/24? → No.

• Is 142.250.190.78 on 10.0.0.0/30? → No.

None of the router's directly connected networks contain Google's IP address. And that makes sense — Google's servers obviously aren't on the office LAN, the server segment, the management segment, or the tiny WAN link.

So what does the router do?

A Detail We Glossed Over: The L Entries

Before we answer that, there's one detail in real Cisco routing tables that the table above quietly leaves out. Every C entry actually has a companion L (local host) entry alongside it. The L entry is a /32 route for the router's own IP on that interface.

Why does it exist? When the router needs to recognize traffic destined to itself — someone pinging the router, or someone trying to SSH into it for management — the router needs to know "this address is me, hand the packet to my own CPU instead of trying to forward it somewhere." The L entry is the mechanism that makes this work. The /32 mask means "exactly this single address, no other."

So the actual routing table — the one you'd see if you ran show ip route on a real Cisco device — looks like this:

Codes: C - connected, L - local, S - static, ...



C    192.168.10.0/24 is directly connected, GigabitEthernet0/1

L    192.168.10.1/32 is directly connected, GigabitEthernet0/1

C    192.168.20.0/24 is directly connected, GigabitEthernet0/2

L    192.168.20.1/32 is directly connected, GigabitEthernet0/2

C    192.168.30.0/24 is directly connected, GigabitEthernet0/3

L    192.168.30.1/32 is directly connected, GigabitEthernet0/3

C    10.0.0.0/30     is directly connected, GigabitEthernet0/0

L    10.0.0.2/32     is directly connected, GigabitEthernet0/0

Just like every C entry, every L entry appears automatically when the interface comes up — no configuration required. Day 5 Supplement C Part 5 covers the L route in more depth (it's where the routing-table mechanics get the full treatment); for now, just know that they're always there, paired with every C, and they represent the router recognizing its own interface IPs.

For the rest of this part, we'll keep showing the table with both C and L entries so you see what a real one looks like.

Step 8 — The Router Does Exactly What the PC Did: It Falls Back to Its Default Route

This is the moment everything ties together. The router is now in exactly the same situation the PC was in back in Part 6. It has a destination IP that doesn't match any of the networks currently in its routing table — none of the C entries (its directly connected networks) matched. The router needs a fallback: a default rule it can use whenever no specific match is found. The idea is simple — "if I don't specifically know where this destination is, send it to someone who might." That "someone" is the upstream router, and the rule that points to it is called the default route.

That default route is 0.0.0.0/0 — pointing to the upstream neighbor (in this case, the ISP's router at 10.0.0.1). Same mechanism, same logic as the PC. The routing table now looks like this, with the default route added:

Codes: C - connected, L - local, S - static, ... S* - default static



C    192.168.10.0/24  is directly connected, GigabitEthernet0/1

L    192.168.10.1/32  is directly connected, GigabitEthernet0/1

C    192.168.20.0/24  is directly connected, GigabitEthernet0/2

L    192.168.20.1/32  is directly connected, GigabitEthernet0/2

C    192.168.30.0/24  is directly connected, GigabitEthernet0/3

L    192.168.30.1/32  is directly connected, GigabitEthernet0/3

C    10.0.0.0/30      is directly connected, GigabitEthernet0/0

L    10.0.0.2/32      is directly connected, GigabitEthernet0/0

S*   0.0.0.0/0        [1/0] via 10.0.0.1

The S* marks the default route as a static route configured by an administrator. The asterisk (*) flags it as the "gateway of last resort" — the route used when nothing else matches. The router walks down the list, finds no specific match, hits the default route, and uses it.

Where Does the Router's Default Route Come From?

Normally, a router doesn't have a default gateway configured the way a PC does. But in small networks, the administrator can add one manually as a static route — that's what produces the S* entry we just saw. In big networks, routers learn the default route automatically from a dynamic routing protocol (covered in Day 6). Same role either way — "gateway of last resort" — the code letter just tells you where the entry came from (S* for static, other codes for dynamic protocols).

Why This Works

The PC sends its remote traffic to its default gateway because nothing in its host routing table matches. The router, in turn, sends its unknown traffic to its default gateway (the ISP) because nothing in its routing table matches either. Same idea, just one level higher up the chain. And the ISP's router does the same thing again — checks its routing table, and either knows the specific path or falls back to its default route, sending the packet further upstream.

The simple version of why this makes the internet work:

A router only really knows its direct connections. For anything else, it trusts its gateway and sends the traffic there. That gateway does the same with its gateway, and so on — until the packet reaches a router that has the destination directly connected.

That's the model worth holding in your head. It's true at the edge of the internet (your home, your office, small ISPs) — exactly the kind of networks this supplement is mostly about. Deeper inside the internet, the picture changes: core routers don't rely on a default route at all. They have huge routing tables with specific paths to every public network on Earth, learned through BGP (Border Gateway Protocol, covered in Day 5 Supplement B Part 12 and again in Day 6). But that's an exception that builds on top of the basic model, not a replacement for it.

Step 9 — Now the Router Knows the Next Hop — But It Needs a MAC Address

The router has decided: "send this packet out Gi0/0 toward 10.0.0.1." But it can't actually send the bare packet onto the wire yet.

Wait — Why Does a Layer 3 Device Need a MAC Address?

A reasonable question at this point: "the router is a Layer 3 device, and it already knows the next hop's IP — why does it need to bother with MAC addresses at all?"

Here's the honest answer. Operating at Layer 3 means the router makes its forwarding decision at Layer 3 — using the destination IP, looking at the routing table, picking the next hop and exit interface. That's the decision. But moving the packet onto the physical wire still happens at Layer 2, because that's how Ethernet works — frames travel on the wire, and every frame has a destination MAC in its header. Without a destination MAC, the frame can't even be built.

And knowing the IP of the next hop doesn't help build that frame. The Ethernet header doesn't have a field for IP addresses — only MAC addresses. The router has its own MAC (per interface, used as the source MAC), but the destination MAC belongs to a different device — the next-hop router — and the only way to get it is to ask. That's where ARP comes in, just like it did for the PC.

So the order is:

1. Routing table lookup (Layer 3) → decides "send to 10.0.0.1 out Gi0/0"

2. ARP (Layer 2 resolution) → gets the MAC address behind 10.0.0.1

3. Frame encapsulation (Layer 2) → builds the Ethernet frame with the right MACs

4. Physical transmission → bits go on the wire

Layer 3 decided where to send. Layer 2 actually delivers it. Both are needed for every packet on every Ethernet hop.

(One exception worth knowing: on serial point-to-point links — HDLC or PPP, older WAN-style connections — there are no MAC addresses, so this whole ARP step disappears. The router just sends the packet onto the serial line, which has only two ends, so there's no ambiguity about who receives it. We mentioned this in Step 5 too.)

How the Router Gets the MAC

Same two paths as before:

• If 10.0.0.1's MAC is already in the router's ARP cache → use it directly. No ARP needed.

• If not → the router sends an ARP request out Gi0/0: "Who has 10.0.0.1? Tell 10.0.0.2." (The router uses its own WAN-side IP as the source — 10.0.0.2.) The ISP's router replies with its MAC. The router caches it for next time.

This is the same ARP protocol the PC used in Part 4 — same packet format, same broadcast mechanism, same caching behavior. Only difference is who's asking and which IPs/MACs are involved. ARP doesn't know or care whether the device running it is a PC, a router, a printer, or anything else — it just answers the question "what MAC is behind this IP on my local segment?" That's true for the PC asking about its gateway in Part 4, and it's true for the router asking about its next hop here in Step 9.

Step 10 — The Router Builds a Brand-New Ethernet Frame (Re-encapsulation)

Now the router wraps the packet in a fresh Ethernet header — this is called re-encapsulation. The new frame looks like this:

NEW Ethernet Frame (going out Gi0/0 toward the ISP):

  Destination MAC : ISP router's MAC          ← brand new — for this hop

  Source MAC      : This router's Gi0/0 MAC   ← also new — different interface!



  IP Packet (unchanged):

    Destination IP : 142.250.190.78           ← still unchanged

    Source IP      : 192.168.10.10            ← still unchanged

    [HTTPS request: GET / ...]

Both MAC addresses changed — source and destination. The IP packet inside is carried forward completely untouched.

This is the core idea worth repeating to participants one more time:

MAC addresses are rewritten at every hop. The IP addresses inside the packet are never touched until the packet reaches its final destination. The Ethernet frame is disposable per-hop; the IP packet survives the whole journey.

Step 11 — One More Thing: The TTL Gets Decremented

Quick but important detail: every IP packet has a TTL (Time To Live) field in its header. Each router that forwards the packet decreases the TTL by 1. This exists to prevent a packet from looping forever if something's misconfigured — if TTL hits 0, the packet gets dropped instead of circulating endlessly.

(This will matter again later in the course when you cover traceroute, which works by deliberately exploiting this exact mechanism — sending packets with very low TTL values and seeing which router drops them.)

Step 12 — The Router Sends the New Frame Out

The frame goes out onto the WAN link toward the ISP's router. And now — this exact same process, Steps 1 through 12, repeats at the ISP's router, and at every router after that, all the way until the packet finally reaches a router that has 142.250.190.78 on one of its directly connected networks. That last router does one final ARP (for Google's actual server this time, not another router), builds one final frame, and delivers it straight to the destination server.

The Clean Summary

"A router does the same kind of thinking the PC did, just on a bigger scale. It strips off the Ethernet frame the moment the packet arrives — because MAC addresses are only useful for one hop and we're about to leave this network. Then it looks at the IP address (which works across networks), does the same on-link calculation the PC did, and asks: 'is this destination on one of my directly connected networks?' If yes, deliver locally. If no, look up where to send it next in the routing table — and if nothing specific matches, fall back to the default route, exactly like the PC did."

"Every router automatically knows about its own directly connected networks — the moment you configure an interface with an IP address, that network is in the routing table for free, marked C. Everything else the router learns about — static routes, default routes, OSPF routes — gets added on top of that foundation. And the default route is what lets a router handle traffic for destinations it has no specific knowledge of: 'I don't know where this exactly goes, send it upstream to someone who might.' That single mechanism, chained across thousands of routers, is what makes the global internet work."

What Is the Router's Gateway?

Now we come to the question that closes the loop: just like the PC has a default gateway, what is the router's gateway?

The answer follows the symmetry of everything we've already covered. Just like the PC has its own "next hop" for unknown destinations, the router has its own "next hop" for unknown destinations — and that's exactly what the default route on the router points to.

In our scenario:

• PC's default gateway = 192.168.10.1 (the router itself)

• Router's default gateway = 10.0.0.1 (the ISP's router, sitting on the other end of the WAN link)

That 10.0.0.1 is the router's gateway. It's the next hop in the router's default route entry:

S*   0.0.0.0/0   [1/0] via 10.0.0.1

Read that line out loud: "for any destination (0.0.0.0/0), go via 10.0.0.1." That's the router's equivalent of "send everything I don't know about to my gateway."

So the gateway concept doesn't only apply to PCs. Every device in the chain — your PC, your office router, the ISP's router, the next ISP up — each one has its own "upstream gateway" that it sends unknown traffic to.

The Mental Model: Gateways Chain Together All the Way Up

This is the picture worth drawing for participants:

Your PC

   │  default gateway = 192.168.10.1 (your router)

   ▼

Your router

   │  default gateway = 10.0.0.1 (the ISP's router)

   ▼

ISP's router

   │  default gateway = some bigger ISP's router

   ▼

Bigger ISP's router

   │  default gateway = some Tier-1 backbone router

   ▼

...and so on, until somebody on the path actually knows

   the specific route to Google's network (no default needed anymore).

Each device only needs to know two things:

1. Its directly connected networks (the C entries — what it can reach on its own)

2. Its own gateway (the next hop for everything it doesn't directly know)

That's it. No single device on the internet knows the path to every other device. They each just know "my neighbors and one upstream direction." Stack all of those tiny pieces of knowledge together, and they form the full path — without any one router needing the complete map.

A Terminology Note Worth Being Precise About

• "Default gateway" is what we usually call this on end devices (PCs, phones, servers) — it's the term you see in IP configuration screens.

• "Default route" or "gateway of last resort" is what we usually call the same concept on routers — it's the term you see in show ip route output.

But they're the same idea, just at different levels of the hierarchy. A PC's "default gateway" is the IP that becomes the next hop in its default route. A router's "default route" points to its default gateway — which is another router upstream.

Some people even use the phrase "upstream router" when talking about a router's gateway — emphasizing the direction (upward, toward the bigger network) rather than the role.

The Big Idea Worth Landing for Participants

"'Gateway' isn't a special property of PCs. It's a universal idea: 'the next hop for stuff I don't specifically know how to reach.' Every device that connects to a bigger network has one. Your PC's gateway is your router. Your router's gateway is the ISP. The ISP's gateway is a bigger ISP. The internet works because every device just needs to know its directly connected neighbors and one upstream direction — and the chain of upstream gateways takes care of the rest."

This is also why the default route on every router in the chain is so powerful — it's what allows the internet to scale to billions of devices without anybody needing to know everybody else. Each router only has to know a tiny piece of the puzzle.

Stage IV — Edge Cases

The main story is done. This stage covers the one important edge case that participants will encounter in real networks — what happens when the on-link math itself gives the wrong answer.

Part 8 — Proxy ARP

The Edge Case: When On-Link Determination Gets the Wrong Answer

Everything above assumes the subnet mask is configured correctly, so on-link determination gives the right answer. But what happens if it doesn't?

Imagine a device is misconfigured with a subnet mask that's too large — for example, a /16 mask when the real local network is only a /24. With that mask, the device's own on-link math will say "on-link" for IP addresses that are actually on a different physical network, separated by a router.

In that case, the device does exactly what Part 3/4 describe for an on-link destination: it ARPs directly for the real destination — even though that destination is genuinely remote. Normally, this ARP broadcast would go out, the router wouldn't forward it, and the device would get silence — a failed lookup, with no way to reach the destination.

Proxy ARP exists to rescue exactly this situation. A router configured for Proxy ARP listens for these "doomed" ARP requests on its local interface. When it sees one for an IP it knows is reachable (just not locally), it replies on behalf of the real destination — but with its own MAC address, instead of staying silent. The misconfigured device never knows the difference: it gets an ARP reply, assumes that MAC belongs to the real destination, and sends its traffic there. The router then forwards the traffic onward, using its routing table, exactly as it would for any other gateway traffic.

A few things worth being precise about:

• Proxy ARP is a fallback for a misconfiguration, not the normal mechanism. In a correctly configured network (correct subnet masks everywhere), on-link determination always gives the right answer, and Proxy ARP never needs to fire.

• It's enabled by default on Cisco routers. It exists historically to help devices that have no concept of a default gateway at all, or devices with an incorrectly large subnet mask, still reach other networks — without anyone having to fix the misconfiguration.

• It can also hide problems. Because Proxy ARP quietly "fixes" broken subnet masks, it can mask a misconfiguration that should really be corrected instead of patched over. For this reason, some network designs deliberately disable it.

Key Takeaway for Participants

"Before a device ever sends a single ARP request, it already knows — through on-link determination — whether the destination is local or remote. ARP never blindly fires and hopes for the best; it's always aimed at whichever IP the device actually needs a MAC address for next: the real destination if local, or the gateway if not. And the way it 'knows' to use the gateway in the simple case isn't magic — it's the default route in the host routing table, pointing to the gateway's IP. In a home network, this looks redundant — and it kind of is. But the routing table is the same mechanism a router uses, and the moment your network has more than one possible remote direction, it's what lets you handle them correctly. The only time ARP gets sent toward a genuinely remote destination is when on-link determination itself was wrong — a misconfigured subnet mask — and that's specifically what Proxy ARP exists to paper over."

This is the idea that makes the rest of Day 5 — routing tables, longest prefix match, static vs. dynamic routing — make sense as a solution to a problem, rather than a list of facts to memorize. The problem is: Layer 2 and ARP physically cannot cross network boundaries. Everything about routers and routing exists to solve exactly that problem.

Appendix A — Network Design Variations: Where Does the Routing Actually Happen?

Everything in this document has assumed a specific physical layout: PCs connect to switches, switches connect to a router, the router connects to the wider world. That's the "textbook" design — and it works — but it's not the only design you'll encounter in real networks. Participants who go on to work in enterprise or data center environments will see a different layout that initially looks like it skips the router entirely.

This appendix explains both designs side by side, so it's clear that the principles in the main document apply to both — only the physical hardware changes.

Design 1 — Traditional: PCs → Switches → Router → Backbone

This is the design described throughout the main document, and it's what most home networks and small offices use:

PCs ──┐

PCs ──┼──► Access Switch ──┐

PCs ──┘                    │

                           ├──► Router ──► Backbone / ISP

PCs ──┐                    │

PCs ──┼──► Access Switch ──┘

PCs ──┘

How routing works in this design:

• The switches are pure Layer 2. They forward frames using MAC addresses, exactly like Part 1 (Local Networks) of this document.

• The router is the one and only device doing Layer 3 work. It holds the default gateway for the PCs, it has the routing table, it does the on-link determination on its own interfaces, and it does the encapsulation/de-encapsulation cycle we covered in Part 7.

• The router's own gateway is the next hop upstream — the backbone, the ISP, whatever sits above it.

This is what your home network looks like. It's also what most small offices look like. Everything in the main document maps exactly onto this design.

Design 2 — Distributed: PCs → Switches → Two Big Switches → Backbone

Now the alternative design — what looks at first glance like "there's no router, the switches do everything":

PCs ──┐

PCs ──┼──► Access Switch ──┐

PCs ──┘                    │

                           ├──► Big Switch ──┐

                           │                  │

PCs ──┐                    │                  ├──► Backbone

PCs ──┼──► Access Switch ──┤                  │

PCs ──┘                    │                  │

                           └──► Big Switch ──┘

Here's the key thing that confuses everyone the first time they see this design: those "big switches" aren't really just switches. They're called Layer 3 switches (or multilayer switches), and the right way to think about them is:

A Layer 3 switch is a switch and a router in the same box. It does Layer 2 switching for traffic within a VLAN (just like a normal switch), and Layer 3 routing for traffic between VLANs (just like a router). One physical device, two functions.

So this design doesn't skip the router — it integrates the router into the switch chassis. The routing logic from Part 7 still happens; it's just happening inside a different kind of device.

Why Design 2 Exists

Two main reasons:

1. Performance and scale. A traditional router is a separate device with a separate connection — every packet routed between two VLANs has to physically travel from the switch to the router and back. In big enterprise or data center networks, that becomes a bottleneck. Layer 3 switches do the same work in the same chassis, in hardware (purpose-built ASICs), at line rate — much faster.

2. Redundancy. Two big switches in the middle means if one fails, the other keeps working. They're typically configured as a redundant pair (using protocols like HSRP, VRRP, or modern stacking technologies like vPC or VSS) so that everything below them stays connected even if one of them dies. A single router is a single point of failure; two Layer 3 switches working together aren't.

How Routing Works in Design 2

Conceptually, exactly the same as Design 1. Everything we covered in Parts 1–7 still applies — just played out across different physical hardware:

• The PC still has its own host routing table with a default route.

• The PC's default gateway is still an IP address — but that IP lives on the Layer 3 switch (specifically, on a thing called an SVI — Switched Virtual Interface, which is the L3 switch's equivalent of a router interface).

• The Layer 3 switch still does on-link determination, still has a routing table with C entries for directly connected VLANs/networks, still has a default route pointing upstream.

• The Layer 3 switch still strips off the Ethernet frame, looks at the IP packet, and re-encapsulates it for the next hop — exactly like a router does in Part 7.

The user, the PC, the OSI model — none of them know or care that it's a Layer 3 switch instead of a router. The bytes flowing through it are processed in the same way.

Where the Boundary Between Switching and Routing Lives

What actually changes between the two designs is where the boundary between Layer 2 switching and Layer 3 routing happens.

In Design 1, the boundary is physical: switches are at the edge, the router is its own box, and the boundary is the cable between them.

In Design 2, the boundary is logical, inside the same device. When a frame arrives at the Layer 3 switch:

• If the destination MAC is for a device on the same VLAN → the L3 switch acts as a switch, forwards by MAC, no Layer 3 work happens.

• If the destination MAC is the L3 switch's own MAC (meaning "I'm sending this here so you can route it") → the L3 switch acts as a router: strips the Ethernet header, looks at the IP packet, makes a routing decision, re-encapsulates, and sends out a different VLAN or up to the backbone.

That second case is literally just Part 7 of this document happening inside a switch chassis instead of a router chassis.

"The Backbone Does the Routing" — What That Actually Means

When people say "the backbone does the routing," they usually mean one of two things:

Meaning A — The backbone handles routing between sites or buildings. That's normal. Your office's Layer 3 switches do internal routing (between VLANs at your site); the backbone's routers do routing between your site and other sites. Each layer does its part. This is how big enterprises actually work.

Meaning B — No routing happens locally at all; the backbone is the gateway for everything. This is theoretically possible but rarely how things are actually built, because it means every single packet between two VLANs at the same site has to go out to the backbone and back in — wasteful. So in practice, even when "the backbone does the routing," local routing still happens at the local Layer 3 switches for local traffic.

The more accurate framing is:

Layer 3 switches at the site do local routing (between VLANs); the backbone (or a router upstream) does routing to the wider world. Different routing happens at different layers, but routing is always happening somewhere.

The Big Idea Worth Landing

The "where the routing happens" question is a deployment choice, not a routing principle. The on-link determination, the routing table, the directly connected entries, the default route, the encapsulation/de-encapsulation cycle — all of that is exactly the same. What changes is whether that work is done by a dedicated router box, by a Layer 3 switch with routing built in, or by a chain of devices each doing a piece. The concepts don't move; only the hardware doing the work moves.

A Layer 3 switch is not "the backbone doing routing instead of a router." It's a device that is a router, just packaged inside the same chassis as a switch. The routing logic from Part 7 still applies to it exactly. The only thing that changes is the physical layout of where the work happens.

Document History

Version	Date	Changes
v1.0	Previous	Initial published version (originally labeled "Part 1 of 2"). Covers the full PC-side decision process, the router receiving and forwarding the packet up through the moment it sends the new frame toward its own gateway, the Proxy ARP edge case, and Appendix A on network design variations.
v1.1	Previous	Renamed and restructured for navigation only — no content changes. Renamed from "Day 5 Supplement Part 1 of 2" to "Day 5 — Supplement A: From Switching to Routing" under the new convention (Day + Supplement letter + Stage + Part). Added Stage I–IV groupings above the existing Parts so the document's arc is visible from the table of contents. Each Part now has a short reference label plus the original long teaching title as a subtitle. Cross-references updated to the new format (e.g., "5A Part 3" = Day 5, Supplement A, Part 3). Part numbering continues in Supplement B (Part 9 onward).
v1.2	Current	Content fixes and clarifications in Part 7 (Router Forwarding). Eight changes, all in response to careful read-through feedback: (1) Added missing L (local host) entries to the routing-table examples, with a new short subsection between Step 7 and Step 8 introducing them before they appear in the table. (2) Precision fix in Step 5 — clarified that the C entry appears only when the interface is fully "up/up" (both physical layer and line protocol up), with a brief explanation of what that means and how to troubleshoot a missing route. (3) Added a verification subsection in Step 5 covering show ip route, show ip interface brief, and show cdp neighbors, plus a note that serial point-to-point links don't use MAC/ARP. (4) Expanded the "fallback" explanation in Step 8 — pulled the definition out as its own concept and linked the everyday word "fallback" to the technical term "default route." (5) Added a brief subsection in Step 8 explaining that small networks add a default route manually as a static route, while big networks learn it from a dynamic protocol. (6) Rewrote the "This pattern is what makes the internet work" sentence in concrete beginner-friendly language, with a release-valve sentence noting that core internet routers actually know specific paths via BGP. (7) Added a "Why Does a Layer 3 Device Need a MAC Address?" subsection in Step 9 explaining that Layer 3 decides where to send but Layer 2 still does the actual delivery, and that IP doesn't help build an Ethernet frame because the header has no IP field. Includes the serial-link exception. (8) Added a brief note in Step 9 that the router's ARP is the same protocol the PC used in Part 4 — same packet format, same broadcast mechanism, same caching — only the IPs and MACs differ.

End of Supplement A. Supplement B continues from the moment the router has built its new frame and is about to send it out to its own gateway — tracing the packet's path through the ISP, the backbone, and onward to the destination.