Open the lab

[ YOUR LAB FILE ]

Download the starting topology, then work through the lesson in SwitchLab.

Download SwitchLab Lab (.swlab)

  1. Save the .swlab file without renaming its extension.
  2. Open SwitchLab. Import and export controls currently require a desktop-width window. On a smaller screen, Tools → Fit brings the topology into view.
  3. Select Import Sandbox (folder icon), choose the downloaded file, and confirm the device and cable counts below.
  4. 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 enable only when the prompt ends in >.
  5. 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

  • Read interface status, routing tables, and IOS running configuration.
  • Understand OSPF process IDs, router IDs, area 0, and passive interfaces.
  • Complete the static routing lab or demonstrate equivalent routing knowledge.

Follow the CCNA study path · Browse all SwitchLab labs

Topology

OSPF Troubleshooting Lab: actual SwitchLab starting topology
Starting topology captured in SwitchLab. Select the image to view it at full size.

4 devices · 3 links

Scenario

After a maintenance change, HQ can still reach its gateway and the branch router’s transit address, but HQ and branch PCs cannot reach each other. OSPF process 1 in area 0 should exchange both LAN routes. Find the configuration fault without replacing OSPF with static routes.

Objectives

  • Separate physical/IP connectivity from OSPF adjacency.
  • Use configuration and operational evidence to isolate one fault.
  • Restore FULL adjacency and remote routes while preserving passive LAN interfaces.
  • Verify bidirectional delivery and reproduce the original fault by reimporting the starter file.

CCNA blueprint

200-301 v1.1 objectives — this lab covers the following specific skills, not every subtopic in the domain.

  • 3.4.a — Troubleshoot single-area OSPFv2 neighbor adjacency.
  • 3.4.d — Identify peers by router ID.
  • 3.1.a — Distinguish OSPF-learned routes from connected routes.

Starting information

  • Use the addressing and cable tables below. Both local gateways and the 10.0.12.0/30 transit are operational.
  • Both routers use OSPF process 1, area 0. R1 uses router ID 1.1.1.1; R2 uses 2.2.2.2.
  • The LANs must remain advertised in OSPF, with g0/0 passive on both routers. There is one configuration fault; host addressing and cabling are correct.
HostIPv4 addressMaskGateway
PC110.10.10.10255.255.255.010.10.10.1
PC210.20.20.20255.255.255.010.20.20.1
RouterInterfaceIPv4 addressMask
R1g0/010.10.10.1255.255.255.0
R1g0/110.0.12.1255.255.255.252
R2g0/010.20.20.1255.255.255.0
R2g0/110.0.12.2255.255.255.252
Device / portDevice / port
PC1 / eth0R1 / g0/0
R1 / g0/1R2 / g0/1
PC2 / eth0R2 / g0/0

Tasks

  1. From both PCs, test the local gateway and the remote PC. On R1, ping 10.0.12.2. Record which paths work.
  2. On both routers, inspect interfaces, OSPF neighbors, routing tables, and running configuration. Compare intended routing participation with Hello suppression.
  3. Make the smallest correction that restores OSPF adjacency. Preserve both LAN network statements and passive LAN interfaces. Do not add static routes.
  4. Verify FULL neighbors and OSPF routes on both routers. Retest both PCs and save R1’s configuration.
  5. Reimport the original downloaded file to restart. Confirm the remote ping fails and the neighbor is absent again.

Useful commands

show ip interface brief
show interfaces g0/1
show ip ospf neighbor
show ip route
terminal length 0
show running-config
ping 10.0.12.2
copy running-config startup-config

Progressive hints

Hint 1

A successful transit ping proves IP reachability, not OSPF adjacency. Start with the neighbor table.

Hint 2

Compare OSPF network statements and passive-interface settings. A passive LAN can still be advertised, but a passive transit cannot exchange Hellos with its peer.

Hint 3

Under R1’s router ospf 1 configuration, examine g0/1. Keep g0/0 passive; only the router-to-router link needs Hello exchange.

Verification

  • Initially both gateways and the transit ping work, but show ip ospf neighbor has no peer and remote PC pings fail.
  • After repair, R1 sees router ID 2.2.2.2 in FULL state; R2 sees 1.1.1.1 in FULL state.
  • R1 learns O 10.20.20.0/24 through 10.0.12.2, and R2 learns O 10.10.10.0/24 through 10.0.12.1.
  • PC1 → 10.20.20.20 and PC2 → 10.10.10.10 succeed. Both routers retain passive-interface g0/0 and their LAN network statements.
  • Reimporting the starter restores the absent neighbor and failed remote ping. The simulator converges deterministically; this lab does not test wall-clock OSPF timers.

Solution / walkthrough

Show Solution

Use enable only from a > prompt; if already at #, begin with configure terminal.

R1

R1’s passive transit suppresses the Hello exchange. Remove only that setting. Passive g0/0 remains appropriate for a LAN with no OSPF peer; its network statement keeps the LAN advertised.

enable
configure terminal
router ospf 1
no passive-interface g0/1
end
copy running-config startup-config

Run every verification check above after the changes. A saved configuration alone does not prove packet delivery.

Previous lab

Advertise LANs over an Existing OSPF Link

Related labs

Related articles and tools

Next recommended lab

Route through a Three-Router OSPF Core