Lessons (6, study in order)

Lesson 1 · Where Layer 2 can't reach

Beginner · about 8 min

Goal: Pick up the dead end left by the "Network Layer 2" module, and see exactly what problem layer 3 solves.

First, recall that dead end

In the last scenario of the Network Layer 2 module, two hosts sit on the same switch — physically one hop apart, but their IPs are on different subnets — and they simply can't reach each other.

The conclusion there was:
"A switch only looks at MAC addresses; it has no idea what a "subnet" even is.
Crossing subnets requires a layer-3 device, and the way a host finds one is through its default gateway."

★ This lesson picks up right from that sentence.

★★ Three fundamental differences between layer 3 and layer 2

| | Layer 2 (switch) | Layer 3 (router) |
|---|---|---|
| How addresses are compared | MAC exact match | IP prefix containment |
| How the table is built | self-learned (learns source MAC from incoming frames) | manually configured or computed by a protocol |
| TTL? | No → a loop is a disaster | Yes → a packet dies on its own |

★★ The first row matters most: "prefix containment" is the entire source of layer 3's scalability.
One route, 10.1.0.0/16, covers over 60,000 addresses;
one entry in a MAC table can only correspond to one device.

★ We'll save the third row for Lesson 6 — that's where you'll see TTL come to the rescue.

★ IP is end-to-end, MAC is hop-by-hop

This is the key to understanding forwarding, and also the easiest thing to get confused about:

For a packet PC1 sends to PC2, along the way:
· The destination IP stays PC2's IP the entire time, never changing
· While the L2 frame header's destination MAC changes at every hop — first the gateway's MAC, then the next router's MAC...

★ So every router that receives the packet has to ask itself again: "given this destination IP, who should I hand it to?" — and that question is exactly a routing table lookup.

Hands-on: watch a packet cross a subnet

Go to the Connectivity Test page and ping PC1 → PC2.

★ Watch the hop-by-hop path: the packet leaves PC1, passes through R1 and R2, and arrives at PC2.
★★ Notice the TTL decreasing at every hop — layer 2 has no such field at all.

Key takeaways

• ★ Layer 2 can't handle crossing subnets: a switch has no idea what a "subnet" is
• ★★ Layer 3 matches addresses using prefix containment — this is the entire source of its scalability
• ★ IP is end-to-end (unchanged), MAC is hop-by-hop (changes every hop)
• Layer 3 has TTL, layer 2 doesn't

Lesson 2 · The routing table: connected routes are free

Beginner · about 8 min

Goal: Understand what every column in a routing table means, plus "I haven't configured anything, so why is there a route?"

A routing table answers exactly one question

"The destination IP is this — which direction should I send it?"

So the columns of the table are exactly these:

| Column | Meaning |
|---|---|
| Destination network/mask | used for matching (★ prefix containment, not exact match) |
| Next hop | who to hand it to (★ must be the interface IP of a directly connected neighbor) |
| Outgoing interface | which port to send out of (★ found by recursively looking up the next hop, not manually configured) |
| Preference | which one wins when several match (connected 0 < static 60) |

★★ "I haven't configured anything, so why is there something in the routing table?"

Because a connected route is a byproduct of an interface's IP — once an interface has an IP configured and is up, the route for that subnet appears automatically, with no configuration needed.

It means: "this subnet hangs directly off one of my interfaces, I can reach it directly."

★ Its preference is 0, the highest in the whole table — because there's no more reliable source of information than "a subnet I'm directly connected to."

★★ And that leads to a very useful corollary in reverse:
if an interface's IP is on the wrong subnet, the connected route is wrong too, and every static route afterward inherits that error — because a static route's next hop relies on the connected route to judge "is it reachable".

Hands-on: watch a connected route appear on its own

The current scenario is ② Configure from scratch — interface IPs are all set, but not a single static route exists yet.

Go to the Routing Table page and look at R1:
★ It already has 2 connected routes (one for each interface's subnet), and zero static routes.
★★ So right now R1 only knows the two subnets it's directly connected to; for PC2's subnet it has no idea which way to go at all.

Key takeaways

• What a routing table answers: the destination IP is this, which direction do I send it
• ★★ Connected routes need no configuration — an interface with an IP that's up automatically has one
• ★ The outgoing interface is found by recursively looking up the next hop, not manually configured
• Preference: connected 0 < static 60, lower wins

Lesson 3 · ★★ Longest prefix match: the one and only route-selection rule

Beginner · about 10 min

Goal: Compress the entire route lookup process into three sentences.

Three sentences, done

① Find every route that matches this destination IP
② The one with the longest mask wins
③ If masks are equally long → compare preference (lower wins)

That's it. There is no rule four.

★★ Why "longest"

Because the longer the mask, the smaller the range a route describes, and the more specific its information is.

· 10.1.1.0/24 is saying "I know exactly how to reach these 254 addresses"
· 10.1.0.0/16 is saying "10.1.x.x roughly goes this way"
· 0.0.0.0/0 is only saying "send everything else here"

★ Specific information should of course win over vague information — that's the entire logic.

★★ Which immediately gives us a corollary: a default route is always the last resort.
Its mask length is 0, the shortest possible prefix, so it can never win as long as any other route matches.

★ The default route is the most cost-effective route there is

ip route-static 0.0.0.0 0.0.0.0 <next-hop> — "send everything else to here."

★ In real networks, an access-layer device usually only needs:
a handful of local subnets (connected, free) + one default route pointing upstream.
It doesn't need to know every subnet on the entire internet.

★★ And real networks also use longest prefix match to build "exception routes":
most traffic takes the default exit, while a specific subnet gets steered separately with a longer prefix (for example, routing one subnet's traffic onto a dedicated line).

Hands-on: three overlapping routes — see who wins

The current scenario is ④ Longest prefix match: R1 has three routes pointing in different directions —
0.0.0.0/0 → R2, 10.1.0.0/16 → R3, 10.1.1.0/24 → R3.

Go to the Connectivity Test page and ping PC1 → PC3 (10.1.1.10).

★★ Look at "all candidate routes" at R1's hop — the UI lists all three and marks which one wins and why.

Key takeaways

• ★★ ① Pull out every route that matches ② the longest mask wins ③ if tied, compare preference
• Why longer wins: the longer the mask, the more specific it is, and specific beats vague
• ★ A default route (/0) is always the last resort
• ★ Real networks use a longer prefix to build "exception routes" that steer individual subnets separately

Lesson 4 · ★★ Manually configuring a static route

Beginner · about 10 min

Goal: Learn how to configure one, and avoid the most common syntax mistake.

What the command looks like

Huawei:  ip route-static 10.0.2.0 255.255.255.0 10.0.12.2
Huawei:  ip route-static 10.0.2.0 24 10.0.12.2        ← the mask can also be written as a length
Cisco:   ip route 10.0.2.0 255.255.255.0 10.0.12.2

Three parameters: destination network, mask, next hop.

★ Note that the outgoing interface doesn't need to be written — the device looks up the connected route for the next hop and works out which port to send from automatically. This step is called "route recursion".

★★ The most common syntax mistake: the next hop isn't a directly connected address

The next hop must be "the interface IP of a directly connected neighbor." Three common mistakes:

· ❌ Using the destination host's IP as the next hop (... 10.0.2.0 24 10.0.2.10)
· ❌ Using a remote router's IP that's one hop further away as the next hop (one extra hop means it's no longer directly connected)
· ❌ An interface IP configured on the wrong subnet, so what looks directly connected actually isn't

★ The result is that this route gets configured but does nothing — it's visible in the config, but never makes it into the forwarding table.
This "configured but not working" state is one of the most confusing situations during troubleshooting.

★★ How to check: run display ip interface brief first to see your own interface subnets, and confirm the next hop actually falls within one of them.

★ Another common slip: writing the destination as a host address instead of a network

ip route-static 10.0.2.10 24 ... — this is wrong.

The destination must be written as the network number (host bits all zero): under /24, the subnet that 10.0.2.10 belongs to is 10.0.2.0.

★ This lab will directly reject this kind of input and tell you "did you mean 10.0.2.0?"

Hands-on: configure it from scratch

The current scenario is ② Configure from scratch — not a single static route exists.

Go to the Configure Static Routes page and try it yourself:
① First configure a route on R1 to PC2's subnet (10.0.2.0/24)
② Go to the Connectivity Test page and ping once — ★ you'll find it's still not working
③ Think about why, then move on to Lesson 5

★ You can also deliberately write a wrong next hop and see how the error message explains it.

Key takeaways

• ip route-static <destination> <mask> <next-hop> — three parameters
• ★ The outgoing interface doesn't need to be written — the device works it out by recursively looking up the next hop
• ★★ The next hop must be the interface IP of a directly connected neighbor
• ★ The destination must be written as the network number, not the address of some host inside that subnet

Lesson 5 · ★★★ Only the outbound path was configured: the most classic mistake

Troubleshooting · about 12 min

Goal: Understand "routes are one-directional", and why this mistake is especially hard to self-diagnose.

Symptom: the outbound path works, but the ping still fails

In the last step of the previous lesson, you configured a route to PC2 on R1, then pinged — and it still didn't work.

★★★ And the most confusing part is: the outbound path really did work.
The packet truly did leave PC1, pass through R1 and R2, and arrive at PC2. Smooth sailing the whole way.

The problem is on the return path: PC2 needs to send back an ICMP reply, but R2 has no idea how to get back to PC1's subnet — its routing table only has its two connected routes, with no route to 10.0.1.0/24.

★★★ Root cause: routes are one-directional

This is something extremely easy to overlook, but once it clicks you'll never forget it:

A single static route only describes "how to get to a given subnet."
It never automatically produces the route in the opposite direction.

And ping, TCP, HTTP — any communication with a request and a reply — needs both directions to work.

★★ So the correct habit when configuring static routes is: configure them in pairs.
The moment you finish one route, ask yourself: "is there a route back?"

★★ Why this mistake is especially hard to self-diagnose

Because staring at your own device's configuration, everything really does look correct — and it genuinely is correct.

· R1's routing table: ✅ has a route to 10.0.2.0/24, with the right next hop
· R1's interfaces: ✅ all up, all IPs correct
· Ping from R1 to R2: ✅ works

The actual problem is on a different device, and its administrator might not even be you.

★★★ The most useful troubleshooting command in the real world — run it on the remote device:

display ip routing-table | include 10.0.1.0

(replace 10.0.1.0 with the subnet the source host is on)
No output means that's exactly where the problem is.

Hands-on: see the asymmetry with your own eyes

The current scenario is exactly ③ Only the outbound path configured. Go to the Connectivity Test page and ping PC1 → PC2.

★ The UI lists the outbound and return paths separately:
· Outbound: ✅ works, passes through 2 routers
· Return: ❌ breaks at R2 — no matching route

★★ Then go to the Configure Static Routes page, add a return route on R2, and ping again.

Key takeaways

• ★★★ Routes are one-directional — configuring one only solves one direction
• ping / TCP / any communication needs both directions to work
• ★★ What makes the symptom so confusing: the outbound path really did work, and your own config really is correct
• ★ To diagnose: run display ip routing-table | include <source subnet> on the remote device
• ★ Habit: configure static routes in pairs

Lesson 6 · The ceiling of static routing, and how TTL saves you

Advanced · about 12 min

Goal: See the two fundamental limitations of static routing, and why layer 3 doesn't need STP.

★ Limitation one: no automatic recovery (black holes)

A static route is dead — it has no idea what's happening in the network.

If a link goes down, that route (if it only specifies a next-hop IP) still stays in the routing table on many devices,
so packets keep getting fed endlessly into a dead end — this is called a black hole.

★ A mitigation for small networks: floating static routes — configure two routes to the same destination with different preferences (say, primary 60, backup 100); when the primary route's outgoing interface goes down, the backup automatically takes over.

⚠️ But this is only a mitigation: it only handles a directly connected link going down, and it's still blind to failures further away.

★★ Limitation two: it doesn't scale (route count grows quadratically)

Go count in the ⑥ Three routers in series scenario: 3 routers, 4 subnets, requiring 6 static routes to configure.

★ And the router in the middle, R2, must know about both sides at once — every time you add a subnet, every other router might need one more route.

For N subnets to be fully interconnected, the worst case requires N×(N−1) routes.
10 subnets means 90 routes; changing the topology once means touching multiple devices, and missing just one route breaks one direction.

★★ This is the entire reason dynamic routing protocols exist: let devices exchange information and compute routes themselves, and recompute automatically when the topology changes.

★★★ And here's a pleasant surprise: TTL saves you

Go to the ⑤ Routing loop scenario and ping PC1 → PC2.

R2's route is misconfigured and points back at R1 → the packet bounces back and forth between the two forever.

★★ But look at the consequence: TTL decreases by 1 at every hop, starting from 255, and after 255 hops the packet drops itself.
The service doesn't work (the config really is wrong), but the network stays alive — bandwidth isn't saturated, and you can still log into the devices to fix the configuration.

★★★ Now think back to the "Network Layer 2" and "STP" modules: an Ethernet frame header has no TTL, so a frame caught in an L2 loop keeps circulating forever, with copies doubling exponentially →
a broadcast storm → the whole network goes down, and you can't even log in to rescue it.

That single field is the whole reason layer 2 needs STP, and layer 3 doesn't.

★ Where to go next

Static routing's place is clear: for small networks, a stable topology, and a single exit point, it's the least effort — no CPU overhead, no protocol traffic, fully predictable.

Once you scale up, it's time to switch to a dynamic routing protocol:
· OSPF — link-state, runs Dijkstra to compute shortest paths (this project has that module)
· IS-IS — similar, more common in carrier networks (also has a module)
· RIP — the prototype distance-vector protocol, mainly useful for understanding "why counting to infinity happens"

★★ And the key difference between them and static routing comes down to one sentence: static routes wait for a human to change them; dynamic routes recompute themselves.

Key takeaways

• ★ Limitation one: no automatic recovery → black holes (mitigation: floating static routes)
• ★★ Limitation two: doesn't scale — N subnets can need up to N×(N−1) routes in the worst case
• ★★★ TTL means an L3 loop is just "unreachable", while an L2 loop takes down the whole network
• ★ Static routing suits small networks with a stable topology; switch to OSPF / IS-IS once you scale up