Lesson 4 of 5

Troubleshooting: Area and Network Mismatch

Lab Objectives

  • Understand and fix OSPF area mismatches and incorrect network/wildcard statements.
  • Practice verifying OSPF adjacency and route advertisement after correcting area and network configuration.
  • Learn why correct area IDs and wildcard masks matter in a production network and how to use OSPF show commands to diagnose problems.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Correct Area IDs on Router Interconnects

Ensure every router-to-router link (R1–R2, R1–R3, R1–R4) is advertised into OSPF Area 0. Do not change IP addresses — only correct OSPF network statements so the three /24 inter-router subnets are in area 0.

Task 2: Fix Wildcard Mask and Advertise VLAN Subnets on R2

R2 must advertise the 10.10.40.0/24 link to S1 and the two VLAN networks (192.168.1.0/24 and 192.168.2.0/24) into OSPF Area 0. Make sure the wildcard mask is correct so these networks appear as /24s and not host routes.

Task 3: Verify and Reset OSPF to Apply Changes

After fixing OSPF configurations, reset the OSPF process where required so the neighbors form (if they do not form automatically). Verify neighbors reach FULL state and that OSPF-learned routes appear in the routing table.

Think About It: Why does putting a link into the wrong OSPF area prevent other routers from learning about networks beyond that link? (Hint: consider OSPF LSA flooding and area boundaries.)


Lab Solution

Note: The base topology (use this exactly) — exact IPs shown on router interfaces:

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 | Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 | / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

IP Scheme reminder:

  • 10.10.10.0/24 — R1-R2 link
  • 10.10.20.0/24 — R1-R3 link
  • 10.10.30.0/24 — R1-R4 link
  • 10.10.40.0/24 — R2-S1 link
  • 192.168.1.0/24 — VLAN 10 (Sales)
  • 192.168.2.0/24 — VLAN 20 (Engineering)
  • 192.168.3.0/24 — VLAN 30 (Management)
  • 203.0.113.0/24 — Public/Internet simulation

Task 1 Solution: Correct Area IDs on Router Interconnects

What we are doing: Put the three router-to-router Ethernet subnets into OSPF Area 0 so OSPF LSAs can flood across the backbone and neighbors form between R1–R2, R1–R3, and R1–R4.

R1# configure terminal
R1(config)# router ospf 1
R1(config-router)# network 10.10.10.0 0.0.0.255 area 0
R1(config-router)# network 10.10.20.0 0.0.0.255 area 0
R1(config-router)# network 10.10.30.0 0.0.0.255 area 0
R1(config-router)# end

What just happened:

  • router ospf 1 — enters OSPF process 1. This process will manage OSPF LSAs and neighbor formation.
  • network 10.10.x.0 0.0.0.255 area 0 — instructs the router to include any interface with an IP in that /24 into OSPF process 1 and to advertise it into Area 0. The wildcard mask 0.0.0.255 matches the whole /24 network.
  • This makes R1 originate LSAs for the three inter-router networks into the backbone area.

Verify:

R1# show ip ospf interface
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.10.10.1/24, Area 0
  Type BROADCAST, Cost: 1
GigabitEthernet0/1 is up, line protocol is up
  Internet Address 10.10.20.1/24, Area 0
  Type BROADCAST, Cost: 1
GigabitEthernet0/2 is up, line protocol is up
  Internet Address 10.10.30.1/24, Area 0
  Type BROADCAST, Cost: 1

Why this matters: OSPF uses the area ID to control LSA flooding and database synchronization. If an interface is in the wrong area, LSAs from neighbors on that interface will be placed into a different database and will not merge with Area 0, preventing reachability across the backbone.


Task 2 Solution: Fix Wildcard Mask and Advertise VLAN Subnets on R2

What we are doing: Ensure R2 advertises 10.10.10.0/24 and 10.10.40.0/24 and the two VLAN subnets (192.168.1.0/24, 192.168.2.0/24) into Area 0 using the correct wildcard masks so they are learned by other routers as /24 networks.

R2# configure terminal
R2(config)# router ospf 1
R2(config-router)# network 10.10.10.0 0.0.0.255 area 0
R2(config-router)# network 10.10.40.0 0.0.0.255 area 0
R2(config-router)# network 192.168.1.0 0.0.0.255 area 0
R2(config-router)# network 192.168.2.0 0.0.0.255 area 0
R2(config-router)# end
R2# clear ip ospf process

What just happened:

  • The network ... area 0 lines include the R2 interfaces (router-to-R1 link, link to S1, and VLAN subnets) in OSPF Area 0.
  • Using wildcard 0.0.0.255 ensures the entire /24 is matched. A common mistake is using 0.0.0.0 (host wildcard) which causes OSPF to advertise only a single host route instead of the full subnet.
  • clear ip ospf process restarts OSPF to force immediate reconvergence and new neighbor relationships; in a production environment use with caution due to temporary topology disruption.

Verify:

R2# show ip ospf neighbor
Neighbor ID     Pri State           Dead Time Address         Interface
10.10.10.1       1  FULL/DR         00:00:33  10.10.10.1    GigabitEthernet0/0
R1# show ip route ospf
O 10.10.40.0/24 [110/2] via 10.10.10.2, GigabitEthernet0/0
O 192.168.1.0/24 [110/2] via 10.10.10.2, GigabitEthernet0/0
O 192.168.2.0/24 [110/2] via 10.10.10.2, GigabitEthernet0/0

Real-world context: In production, VLAN subnets behind an access router must be advertised correctly so other parts of the network (e.g., data center or Internet edge) can reach hosts. A wrong wildcard mask may result in host routes or missing subnets and create outages for entire groups of users.


Task 3 Solution: Verify and Reset OSPF to Apply Changes

What we are doing: Confirm neighbors are FULL on all three R1 links to R2/R3/R4. If not FULL, identify the mismatch (area ID or wildcard) and fix it, then reset OSPF if necessary.

R1# show ip ospf neighbor
Neighbor ID     Pri State           Dead Time Address         Interface
10.10.10.2       1  FULL/DR         00:00:34  10.10.10.2    GigabitEthernet0/0
10.10.20.2       1  FULL            00:00:32  10.10.20.2    GigabitEthernet0/1
10.10.30.2       1  FULL            00:00:31  10.10.30.2    GigabitEthernet0/2

What just happened:

  • show ip ospf neighbor lists neighbors known via OSPF on that router. FULL indicates adjacency is fully formed and LSDB exchange completed.
  • FULL/DR indicates that neighbor is the Designated Router for that multi-access segment — normal on broadcast networks.

Verify route propagation:

R4# show ip route
Codes: O - OSPF, C - connected, S - static
C 10.10.30.0/24 is directly connected, GigabitEthernet0/0
O 10.10.10.0/24 [110/2] via 10.10.30.1, GigabitEthernet0/0
O 192.168.1.0/24 [110/3] via 10.10.30.1, GigabitEthernet0/0
O 192.168.2.0/24 [110/3] via 10.10.30.1, GigabitEthernet0/0

Tip: If you fix a misconfigured network statement and neighbors do not re-form, clear ip ospf process forces a restart of the OSPF process to pick up the new network statements immediately. In busy networks plan for a maintenance window before issuing this.


Troubleshooting Scenario

Scenario: Wrong Area for R4 Link

Symptom: PC1 (on 192.168.1.0/24) cannot ping PC5 (behind R4). show ip ospf neighbor on R1 shows neighbors only for R2 and R3; R4 neighbor is missing.

Your task: Find and fix the issue.

Hint: Check the OSPF network statements on R4 for the 10.10.30.0/24 interface — likely the area is wrong.

Solution:

  • On R4, inspect OSPF config:
R4# show running-config | section router ospf
router ospf 1
 network 10.10.30.0 0.0.0.255 area 1
  • Change area to 0 and restart OSPF:
R4# configure terminal
R4(config)# router ospf 1
R4(config-router)# no network 10.10.30.0 0.0.0.255 area 1
R4(config-router)# network 10.10.30.0 0.0.0.255 area 0
R4(config-router)# end
R4# clear ip ospf process
  • Verify neighbor on R1:
R1# show ip ospf neighbor
Neighbor ID     Pri State           Dead Time Address         Interface
10.10.30.2       1  FULL            00:00:28  10.10.30.2    GigabitEthernet0/2

Explanation: R4 was advertising its link into Area 1, isolating its LSAs from Area 0. After moving it to Area 0, LSA flooding reached R1 and R2, restoring end-to-end connectivity. In production, area mismatches are a common cause of partial outages.


Verification Checklist

  • All inter-router links (10.10.10.0, 10.10.20.0, 10.10.30.0) appear in OSPF Area 0 on their respective routers.
  • show ip ospf neighbor on R1 shows R2, R3, and R4 in FULL state.
  • OSPF-learned routes (192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24) appear in routing tables of other routers as O routes.

Common Mistakes

SymptomCauseFix
Only a host route for a subnet appears in OSPF (e.g., 10.10.40.1/32)Wildcard mask used is 0.0.0.0 (host) instead of 0.0.0.255Change network statement to use 0.0.0.255 wildcard for /24, then clear ip ospf process
Neighbor not forming on a linkNetwork statement on one side is in the wrong area IDCorrect the area ID on the router with the wrong network command and restart OSPF if needed
Subnet not visible beyond one routerInterface not included in OSPF (no matching network statement)Add the proper network command for that subnet into OSPF area 0

Challenge Task

Reconfigure the topology so that R2 advertises the Sales (192.168.1.0/24) and Engineering (192.168.2.0/24) subnets into OSPF Area 1 while the backbone (10.10.10/20/30) remains in Area 0. Ensure connectivity between VLANs across the Autonomous System while respecting OSPF area boundaries. (Hint: Think about how LSAs from Area 1 are summarized or passed by Area Border Routers — you will need to create Area 1 on R2 only and ensure R1 acts as the ABR.)

Final thought: OSPF area and network statement mistakes are analogous to mailing a package to the wrong zip code — it may never reach its destination. Accurate addressing (area IDs, network statements, wildcard masks) ensures LSAs and routes are delivered to the correct OSPF databases so traffic flows end-to-end.