Open the lab
[ YOUR LAB FILE ]
Download the starting topology, then work through the lesson in SwitchLab.
- Save the .swlab file without renaming its extension.
- Open SwitchLab. Import and export controls currently require a desktop-width window. On a smaller screen, Tools → Fit brings the topology into view.
- Select Import Sandbox (folder icon), choose the downloaded file, and confirm the device and cable counts below.
- Select a device, then choose Open device on desktop or its name in the bottom bar on smaller screens. Select CLI for switches/routers or Desktop → Terminal for PCs. Enter
enableonly when the prompt ends in >. - Follow this page beside the simulator. Use a free account to export your work. Reimport the original download to restart; export any work you want to keep first.
Prerequisites
- Configure router interfaces and read a routing table.
- Understand /24 LANs, a /30 transit subnet, and next-hop addresses.
Topology
4 devices · 3 links
Scenario
A route was edited during branch maintenance. Both workstations still reach their local gateways, but traffic between HQ and the branch fails. The addressing plan is approved and the branch default route is unchanged. Find the forwarding decision that disagrees with the connected transit subnet.
Objectives
- Separate local access health from remote routing failure.
- Compare the configured next hop with the peer interface address and connected subnet.
- Replace only the incorrect HQ static route and prove bidirectional delivery.
CCNA blueprint
200-301 v1.1 objectives — this lab covers the following specific skills, not every subtopic in the domain.
- 3.1.a — Read the static route code.
- 3.1.d — Identify the next hop.
- 3.3.a — Configure and verify an IPv4 default route.
- 3.3.b — Configure and verify an IPv4 network route; IPv6 is outside this lab.
Starting information
- R1 serves HQ; R2 serves the branch. The /30 transit link connects their g0/1 interfaces.
- PC and router addresses in the tables are authoritative and must remain unchanged.
- Static routes are already configured. A single next-hop error is present on R1; R2 has the intended default return route.
| Host | IPv4 address | Mask | Gateway |
|---|---|---|---|
| PC1 | 10.10.10.10 | 255.255.255.0 | 10.10.10.1 |
| PC2 | 10.20.20.20 | 255.255.255.0 | 10.20.20.1 |
| Router | Interface | IPv4 address | Mask |
|---|---|---|---|
| R1 | g0/0 | 10.10.10.1 | 255.255.255.0 |
| R1 | g0/1 | 10.0.12.1 | 255.255.255.252 |
| R2 | g0/0 | 10.20.20.1 | 255.255.255.0 |
| R2 | g0/1 | 10.0.12.2 | 255.255.255.252 |
| Device / port | Device / port |
|---|---|
| PC1 / eth0 | R1 / g0/0 |
| R1 / g0/1 | R2 / g0/1 |
| PC2 / eth0 | R2 / g0/0 |
Tasks
- Predict which tests distinguish a local LAN fault from a remote-route fault. Test each local gateway before attempting the remote workstation.
- Inspect R1 and R2 interface addresses and routing tables. Compare R1’s configured branch route in
show running-configwith the actual R2 transit address. An unusable configured route may be absent from the installed routing table. - Remove the incorrect route and configure a specific route to the branch LAN through the connected peer. Retain R2’s default route and all interface settings.
- Verify both end-to-end directions. Explain why testing only a gateway or only reading the configuration would miss the original problem. Export your completed sandbox if you want to retain it.
Useful commands
show ip interface brief
show ip route
show running-config
ping 10.0.12.2
ip route <network> <mask> <next-hop>
copy running-config startup-configProgressive hints
Hint 1
Both local gateways work. Follow the packet toward the remote LAN and identify where the next forwarding decision is needed.
Hint 2
A static next hop must be reachable. Compare its address with the /30 subnet on g0/1, not with the destination LAN.
Hint 3
Use no ip route with the incorrect configured values before adding the route through R2’s g0/1 address. Do not solve the outage by broadening the transit mask.
Verification
- Each PC still reaches its local gateway.
- R1 shows S 10.20.20.0/24 via 10.0.12.2.
- R2 shows a static default 0.0.0.0/0 via 10.0.12.1 and identifies its gateway of last resort.
- PC1 → 10.20.20.20 and PC2 → 10.10.10.10 both succeed.
Solution / walkthrough
Show Solution
Use enable only from a > prompt; if already at #, begin with configure terminal.
R1
10.0.12.6 lies outside the directly connected 10.0.12.0/30 link. R2 uses 10.0.12.2. Remove the stale route so the configuration also matches the intended design; R2 already has the return path.
enable
configure terminal
no ip route 10.20.20.0 255.255.255.0 10.0.12.6
ip route 10.20.20.0 255.255.255.0 10.0.12.2
end
copy running-config startup-configRun every verification check above after the changes. A saved configuration alone does not prove packet delivery.