Advertise LANs over an Existing OSPF Link

Open the lab

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

4 devices · 3 links

Scenario

The WAN team has commissioned the router-to-router OSPF link. The LAN team now needs both office subnets reachable. Neighbors already show FULL, but neither remote LAN appears in the routing table. Complete the LAN routing handoff without replacing the working WAN setup.

Objectives

• Explain why FULL adjacency alone does not guarantee remote LAN reachability.
• Enable OSPF advertisement for each local /24 LAN without enabling LAN neighbor exchanges.
• Verify remote prefixes, next hops and bidirectional delivery.

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

• Process 1, router IDs 1.1.1.1 and 2.2.2.2, and transit area 0 are already configured.
• Only the transit subnet participates in OSPF. The two workstation LANs are intentionally not yet advertised.
• Both LAN interfaces must stay passive. Retain all router IDs, interface addresses, transit network statements and cabling.

Tasks

1. Verify that the routers are FULL neighbors before making changes. Compare the routing tables with the required LAN prefixes.
2. Advertise 10.10.10.0/24 from R1 and 10.20.20.0/24 from R2 in area 0. Preserve passive g0/0 on both routers.
3. Do not add static routes or advertise an unnecessarily broad address range. Document which local interfaces your network statements match.
4. Prove both O-coded remote LAN routes and both workstation directions. Explain what changed even though the neighbor relationship was already healthy.

Useful commands

show ip interface brief
show ip ospf neighbor
show ip ospf interface brief
show ip route
show running-config
copy running-config startup-config

Progressive hints

Verification

• Neighbors are FULL both before and after the change.
• Before the change neither remote LAN is learned, and workstation pings between sites fail.
• Afterward R1 learns 10.20.20.0/24 and R2 learns 10.10.10.0/24 through OSPF.
• Both workstation directions succeed and each g0/0 remains passive.

Solution / walkthrough

enable
configure terminal
router ospf 1
network 10.10.10.0 0.0.0.255 area 0
end
copy running-config startup-config

enable
configure terminal
router ospf 1
network 10.20.20.0 0.0.0.255 area 0
end
copy running-config startup-config

Previous lab

Build Your First OSPF Neighbor Relationship

Related labs

• Build Your First OSPF Neighbor Relationship
• OSPF Troubleshooting Lab
• Design and Test a Resilient OSPF Triangle

Related articles and tools

• Packet Tracer Lab - Legacy
• Concept reference
• Cisco CLI cheat sheet

Next recommended lab

OSPF Troubleshooting Lab