Predict the next hop from a routing table, then prove it

Steps

1. Drag each device from the Topology onto the workspace and set its display name (click the device, Config tab, Display Name) to the name in the Devices table. Cable the ports the Links table lists: Packet Tracer's automatic connection type picks the right cable, or use a copper cross-over between two routers or between a router and a PC or server. If a router asks whether to enter the initial configuration dialog, answer no.
2. Address R1's two links:

Router> enable
Router# configure terminal
Router(config)# hostname R1
R1(config)# interface g0/0/0
R1(config-if)# ip address 192.168.1.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# interface g0/0/1
R1(config-if)# ip address 192.168.1.5 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# end

3. Address R2 and R3, including the loopbacks that stand in for remote networks. Note that R3 owns 10.20.30.40, inside the /24 that R2 owns: that is the host-route test.

Router> enable
Router# configure terminal
Router(config)# hostname R2
R2(config)# interface g0/0/0
R2(config-if)# ip address 192.168.1.2 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# interface loopback0
R2(config-if)# ip address 10.20.30.1 255.255.255.0
R2(config-if)# interface loopback1
R2(config-if)# ip address 10.5.5.5 255.255.255.255
R2(config-if)# end

Router> enable
Router# configure terminal
Router(config)# hostname R3
R3(config)# interface g0/0/0
R3(config-if)# ip address 192.168.1.6 255.255.255.252
R3(config-if)# no shutdown
R3(config-if)# interface loopback0
R3(config-if)# ip address 10.20.99.1 255.255.255.0
R3(config-if)# interface loopback1
R3(config-if)# ip address 172.31.4.4 255.255.255.255
R3(config-if)# interface loopback2
R3(config-if)# ip address 10.20.30.40 255.255.255.255
R3(config-if)# end

4. Before the real routes, see a configured route stay out of the table. Add a static route whose next hop R1 cannot reach, then look for it:

R1# configure terminal
R1(config)# ip route 10.30.0.0 255.255.0.0 10.99.99.1
R1(config)# do show ip route

There is no 10.30.0.0/16 line. Nothing in R1's table covers 10.99.99.1, so the recursive lookup fails and IOS keeps the route only in the running configuration. Remove it now, before you add a default route that would cover the next hop:

R1(config)# no ip route 10.30.0.0 255.255.0.0 10.99.99.1

5. Enter R1's routes. The 10.50.0.0/16 pair differs only in distance; the 10.70.0.0/16 pair is equal in every way:

R1(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.6
R1(config)# ip route 10.0.0.0 255.0.0.0 192.168.1.2
R1(config)# ip route 10.20.0.0 255.255.0.0 192.168.1.6
R1(config)# ip route 10.20.30.0 255.255.255.0 192.168.1.2
R1(config)# ip route 10.20.30.40 255.255.255.255 192.168.1.6
R1(config)# ip route 10.50.0.0 255.255.0.0 192.168.1.2
R1(config)# ip route 10.50.0.0 255.255.0.0 192.168.1.6 5
R1(config)# ip route 10.70.0.0 255.255.0.0 192.168.1.2
R1(config)# ip route 10.70.0.0 255.255.0.0 192.168.1.6
R1(config)# end
R1# show ip route

6. Read the table before testing anything. Find the parent heading 10.0.0.0/8 is variably subnetted, 6 subnets, 4 masks: it forwards nothing, it only groups the six routes under it. Find the Gateway of last resort is 192.168.1.6 to network 0.0.0.0 line and the S* default. Read every [1/0] as distance 1, metric 0. Notice that 10.50.0.0/16 appears once, via 192.168.1.2 only: the copy with distance 5 lost on administrative distance and is not installed. 10.70.0.0/16 has two via lines: equal distance and metric, so R1 load-shares.
7. On paper, predict the matching route and next hop for each destination: 10.20.30.1, 10.20.30.40, 10.20.30.50, 10.20.99.1, 10.5.5.5 and 172.31.4.4. List every route whose range contains the address, then take the longest. Then check each one:

R1# show ip route 10.20.30.50
R1# show ip route 10.20.30.40
R1# show ip route 10.20.99.1

The answers: 10.20.30.1 and 10.20.30.50 match the /24 via 192.168.1.2; 10.20.30.40 matches the /32 via 192.168.1.6, although the /24 also contains it; 10.20.99.1 matches the /16 via 192.168.1.6; 10.5.5.5 matches only the /8, via 192.168.1.2; 172.31.4.4 matches only the default, via 192.168.1.6. The /16 has distance 1 like the /24, but distance never decides between different prefix lengths. 8. Prove the paths with pings. Each address lives on only one neighbour, so a reply proves the packet went the way you predicted:

R1# ping 10.20.30.1
R1# ping 10.20.30.40
R1# ping 10.20.99.1
R1# ping 10.5.5.5
R1# ping 172.31.4.4

All five should succeed. The first ping to each neighbour can lose one packet while ARP resolves, so 80 percent on a first try is normal. 9. Break it: fail the link to R2 and read the table again.

R1# configure terminal
R1(config)# interface g0/0/0
R1(config-if)# shutdown
R1(config-if)# do show ip route
R1(config-if)# do ping 10.20.30.1

The connected 192.168.1.0/30 has gone, and every route via 192.168.1.2 went with it, because its next hop is no longer reachable. 10.50.0.0/16 is back, now [5/0] via 192.168.1.6: the route that lost on distance floats into the table. 10.70.0.0/16 has one via line. The ping to 10.20.30.1 fails, because that address now matches the 10.20.0.0/16 route toward R3, and R3 has no route to it. Work out on paper why 10.20.30.40 and 172.31.4.4 still answer and 10.5.5.5 does not, then ping them to check. 10. Fix it and confirm the table is back to its first shape:

R1(config-if)# no shutdown
R1(config-if)# end
R1# show ip route