Lesson 2 — Routing Failure Isolation

Week 5Lesson 2Required42 min estimated0% progress

Routing Failure Isolation

Isolate a broken-forwarding fault with a repeatable method — confirm the route, confirm the next hop, confirm the return path — using show ip route, ping, and traceroute to name the exact hop that fails.

What you'll learn (5 objectives)~42 min: video → lesson → check → apply → lab prep

Learning objectives

Apply a layered method separating a missing route from an unreachable next hop from a missing return route
Read show ip route, ping, and traceroute together to localise where a packet stops
Explain the one-way-connectivity fingerprint of a missing return route and correct it
Recognise a recursive-lookup failure and a downstream blackhole from their symptoms
Distinguish a routing fault from a first-hop fault before changing any routes

Terms you will see

Fault isolationReturn routeOne-way connectivityBlackholeRecursive-lookup failuretraceroute

Time breakdown

Read the notes20 min
Routing Table Trainer14 min
Fault-isolation practice8 min

A method beats guessing

A packet reaching a remote host and getting an answer back must clear a chain of independent conditions. Troubleshooting is walking that chain in order and stopping at the first broken link, rather than randomly editing routes. Use the same sequence every time.

Is the destination route present on the sending router? show ip route <dest> prints the winning line or reports it is not in the table. Confirm this first, not last.
Is the next hop reachable? A route can name a next hop the router cannot actually reach. Ping it. If it is on a connected subnet, check show ip arp and that the interface is up/up.
Does traffic leave the right interface toward the right router? traceroute shows each hop that answers, and the failure is localised to just after the last responding hop.
Is there a return route? The destination's router must have a route back to the source. This is the layer beginners skip, and it causes most 'works one way' faults.
Rule out non-routing causes. An administratively down interface, an unresolved ARP entry, or an ACL can all mimic a routing fault.

Two ideas make the method work

First, each router forwards independently using only its own table — no router knows the end-to-end path. Second, every conversation needs routes in both directions, because the request and the reply are routed separately. Hold both and the one-way fault stops being mysterious.

Four fingerprints you can name on sight

Symptom to root cause

Fingerprint	Symptom	Confirm with	Root cause
Missing route	show ip route says not in table; ping fails immediately	show ip route <dest>	No static or dynamic route for the prefix
Missing return route	Ping fails though the forward route and next hop are fine — the request arrives, the reply is dropped	show ip route <source> on the far router	Far router has no route back to the source subnet
Recursive-lookup failure	Route never appears in the table at all	show ip route <dest>	Next hop is not resolvable, so IOS will not install the route
Downstream blackhole	Route present and correct, traffic silently dropped further along	traceroute	A later router has no onward route
First-hop / L1-L2	The local subnet also fails	show ip interface brief, show ip arp	Interface down, wrong VLAN, ARP unresolved

Why traceroute is the localiser

Each responding hop proves that router received the packet, had a route onward, and had a route back to you to answer the probe. The failure sits just past the last hop that answered. If hops 1 and 2 respond and hop 3 is silent, stop editing your own router and look at the table on the router that was hop 2. traceroute converts 'somewhere it breaks' into 'it breaks at this specific router'.

The classic return-route failure

Host A on 10.1.1.10 cannot ping Host B on 10.1.20.10 — every echo times out. R1 serves 10.1.1.0/24, R2 serves 10.1.20.0/24, and they share the 10.1.12.0/30 link with R1 at .1 and R2 at .2.

R1 — the forward path looks healthy

R1# show ip route
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
C        10.1.1.0/24 is directly connected, GigabitEthernet0/0
L        10.1.1.1/32 is directly connected, GigabitEthernet0/0
C        10.1.12.0/30 is directly connected, GigabitEthernet0/1
L        10.1.12.1/32 is directly connected, GigabitEthernet0/1
S        10.1.20.0/24 [1/0] via 10.1.12.2

R2 — note what is absent

R2# show ip route
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C        10.1.20.0/24 is directly connected, GigabitEthernet0/0
L        10.1.20.1/32 is directly connected, GigabitEthernet0/0
C        10.1.12.0/30 is directly connected, GigabitEthernet0/1
L        10.1.12.2/32 is directly connected, GigabitEthernet0/1

R2 has no route to 10.1.1.0/24. A's echo request reaches B fine along R1's correct forward path, but B's echo reply dies at R2, which cannot route back — so every ping times out. Note the two local routes as a sanity check: R1 owns 10.1.12.1 and R2 owns 10.1.12.2. Two routers on the same link never share a local address, and spotting a table that claims otherwise is itself a useful reflex.

Why pinging from the router can mislead you

Pinging B from R1 itself would succeed, because R1 sources the packet from 10.1.12.1 — an address R2 can route back to over its connected link. Pinging from a host on 10.1.1.0/24 fails. If you test from the router and declare the path healthy, you will miss this entire class of fault. Test from where the traffic actually originates.

Route present, traffic vanishing

Troubleshooting — installed, correct, and still dropping

Symptom: R1 shows S 10.1.30.0/24 [1/0] via 10.1.12.2 and the route is installed, but pings to 10.1.30.5 time out and traceroute reaches R2 then stops. Diagnosis: R1's route is valid and its next hop is reachable — that is why the trace reaches R2. The break is on R2, which has no route to 10.1.30.0/24 and silently drops the packet. R1's route is not wrong; it simply hands traffic to a router with nowhere to send it. Fix: install the onward route on R2, then re-run traceroute and confirm the hop count grows past it.

Contrast that with a recursive-lookup failure. There, the next hop cannot be resolved at all, so the route never installs and show ip route reports it is not in the table. Here the next hop is resolvable, so the route installs and looks perfectly healthy — the fault is one hop downstream. The difference between 'route missing' and 'route present but blackholing' is exactly what traceroute exposes, and it decides which router you go and fix.

What you should retain

Method: route present, next hop reachable, right interface and hop, return route present, then rule out Layer 1/2 and ACLs.
One-way connectivity means a missing or wrong return route on the far router.
traceroute localises the break to the router just past the last responding hop.
A recursive-lookup failure leaves the route absent; a downstream blackhole leaves it present.
Forwarding is per-hop and per-direction — every conversation needs routes both ways.
Test from where the traffic originates, not from the router, or you will source from the wrong address.

Pause and predictNot scored — nothing is recorded

Before you read on

Using the two tables above: (1) Why does A's ping to B fail even though R1's forward route is perfect? (2) Exactly what command on which router fixes it? (3) You configure two statics on R1 — route X never appears in show ip route, route Y appears but its traffic dies two hops away. Which is the recursive-lookup failure and which the blackhole?

Interactive tool

See it happen

Required~14 min

Routing Table Trainer

Practise spotting which router is missing the route for a given source or destination before attempting any fix. Naming the device first is the discipline this lesson is really teaching — most wasted troubleshooting time is spent editing the wrong router.

Open the tool

Section quiz

Check this section before moving on

Required8 questions~10 min

Reading & Troubleshooting Routes

The quiz opens on its own page so you can focus on it. It is a Week 1 milestone, tracked separately from this lesson's own completion.

Topics covered

• Every field in a route line
• Connected versus local routes
• The default route and what beats it
• One-way connectivity, blackholes, and recursive-lookup failures

Start the quiz

Study deeper

Topic guides extend this lesson — they do not replace the first-party walkthrough above.

Routing Protocols

For the wider symptom-to-check troubleshooting table this lesson condenses into five fingerprints

Open guide

Lesson orientation