Imagine you're the network engineer for a bank, and suddenly a branch office can't reach the core. Users are screaming, but the router logs show nothing obvious. The culprit? An OSPF area mismatch — a silent killer that prevents neighbor adjacency without any obvious error flags. On the CCNA 200-301 exam (objective 3.4: Troubleshoot OSPF), area mismatch is one of the most common configuration errors tested. This chapter will teach you exactly how to detect, diagnose, and fix it, saving your network — and your exam score.
Jump to a section
Think of OSPF routers as employees in a large corporate campus with multiple buildings (areas). Each building has its own security badge that grants access only to that building. The badge has a color code: Area 0 badges are gold, Area 1 badges are silver, Area 2 are bronze, etc. For two employees to have a private conversation (form an adjacency), they must show each other their badges. If one employee flashes a gold badge and the other flashes a silver badge, they realize they belong to different buildings and cannot talk — they simply walk away. No alarm sounds, no report is filed; they just don't communicate. This is exactly what happens in OSPF: when two routers exchange Hello packets, they include their configured area ID. The receiving router checks the area ID in the Hello against its own interface's OSPF area. If they don't match, the Hello is silently ignored — the neighbor never even reaches the INIT state. The routers remain strangers, even though they are physically connected. In a real campus, if two employees from different buildings tried to talk, they might use a phone or email, but in OSPF, there is no alternative path for exchanging routing information across area boundaries — that's the job of an Area Border Router (ABR), which has one foot in each area. Without an ABR, mismatched areas mean zero connectivity, just like two employees with incompatible badges.
What is an OSPF Area Mismatch?
An OSPF area mismatch occurs when two routers connected by a link are configured to belong to different OSPF areas on that link. OSPF uses a two-level hierarchy: the backbone area (Area 0) and non-backbone areas (Area 1, 2, etc.). All areas must connect to Area 0 via an ABR. When two routers attempt to form an adjacency, they exchange Hello packets that contain the Area ID. If the Area IDs do not match, the receiving router drops the Hello and the neighbor relationship never forms. This is a fundamental requirement: OSPF neighbors must be in the same area on the same link.
How It Works: The Hello Protocol and Area ID Check
OSPF routers send Hello packets every HelloInterval (default 10 seconds on broadcast and point-to-point links, 30 seconds on NBMA). The Hello packet contains:
Router ID
Area ID
Authentication data (if configured)
Network mask
HelloInterval and DeadInterval
Router priority
Designated Router (DR) and Backup DR (BDR)
Neighbor list
When Router A receives a Hello from Router B on an interface, it first checks the Area ID field. If the Area ID in the Hello does not match the Area ID configured on the receiving interface, the Hello is discarded. No further processing occurs. Router A does not add Router B to its neighbor table, no state transitions happen, and no error message is logged by default. This silent discard is what makes area mismatch particularly insidious — it looks like a dead link, but the physical layer is fine.
OSPF Neighbor States and Where Mismatch Stops
Normal OSPF neighbor progression: Down -> Attempt (if on NBMA) -> Init -> 2-Way -> ExStart -> Exchange -> Loading -> Full.
With an area mismatch, the process stops before Init. The router never sees the neighbor as a candidate. In show ip ospf neighbor, the neighbor does not appear at all. This is different from other issues like a mismatched subnet mask, which might allow the neighbor to reach Init or 2-Way before stalling.
Verification with IOS CLI
To detect an area mismatch, use the following commands:
Step 1: Check OSPF neighbors
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address InterfaceIf the output is empty or missing the expected neighbor, area mismatch is a suspect.
Step 2: Verify OSPF interface configuration
R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Internet Address 10.0.0.1/24, Area 0.0.0.0
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 1.1.1.1, Interface address 10.0.0.1
Backup Designated router (ID) 2.2.2.2, Interface address 10.0.0.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:02
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 2.2.2.2 (Backup Designated Router)
Suppress hello for 0 neighbor(s)Look for the line Area 0.0.0.0 (or whatever area). On the neighboring router, the area must match.
Step 3: Check the running configuration
R1# show running-config | section router ospf
router ospf 1
network 10.0.0.0 0.0.0.255 area 0On R2, you might see:
router ospf 1
network 10.0.0.0 0.0.0.255 area 1This mismatch causes the problem.
Step 4: Debug OSPF events (use with caution)
R1# debug ip ospf hello
OSPF hello debugging is on
R1#
*Mar 1 00:01:23.456: OSPF: Send hello to 224.0.0.5 via GigabitEthernet0/0 area 0.0.0.0
*Mar 1 00:01:23.456: OSPF: Hello from 2.2.2.2 with mismatched area 0.0.0.1The debug output explicitly says "mismatched area." This is the definitive proof.
How It Interacts with Other Protocols
Area mismatch is purely an OSPF issue. It does not affect Layer 2 (Ethernet, PPP) or Layer 3 (IP connectivity). The routers can still ping each other because the interfaces are up and IP is configured. This is why connectivity tests (ping) succeed, but routing does not work — a classic symptom that points to a routing protocol problem.
Summary
Area mismatch prevents OSPF neighbor formation because the Hello packet's Area ID does not match the receiving interface's area. The neighbor never appears in show ip ospf neighbor. Debug shows the mismatch explicitly. The fix is to change the network statement or interface-specific area configuration so both sides agree on the same area.
Verify physical connectivity
Before diving into OSPF, confirm that Layer 1 and Layer 2 are operational. Use `show ip interface brief` to verify the interface status is up/up. Then ping the neighbor's IP address. If ping fails, the problem is not OSPF-specific. For area mismatch, ping will succeed because the interfaces are up and IP routing is working for directly connected networks. This step eliminates lower-layer issues. Example: `R1# ping 10.0.0.2` should succeed. If it does, move to step 2.
Check OSPF neighbor table
Run `show ip ospf neighbor` on both routers. If the neighbor is missing entirely (not even in INIT state), it suggests the Hello packets are being dropped. A neighbor in INIT or 2-WAY indicates a different problem (e.g., mismatched subnet, authentication). With area mismatch, the neighbor list will be empty for that interface. Document what you see. Example output: `R1# show ip ospf neighbor` returns nothing for the expected neighbor.
Examine OSPF interface configuration
Use `show ip ospf interface [interface]` on both routers. Look for the line that says "Area X.X.X.X". Compare the area IDs. They must match. Also note the network type, timers, and DR/BDR status. This command shows the actual area the interface belongs to, which may differ from what you think you configured. Example: On R1 you see "Area 0.0.0.0", on R2 you see "Area 0.0.0.1". Mismatch confirmed.
Review OSPF configuration under router ospf
Run `show running-config | section router ospf` on both routers. Look at the network statements. Each network statement associates a range of IP addresses with an area. The interface's IP must fall within one of these network statements. If the network statements are correct, but the interface still shows a different area, check for interface-specific `ip ospf area` commands under the interface configuration. Example: `R1(config-router)# network 10.0.0.0 0.0.0.255 area 0` vs `R2(config-router)# network 10.0.0.0 0.0.0.255 area 1`.
Enable OSPF debugging (if needed)
If the configuration seems correct but the neighbor still doesn't form, enable `debug ip ospf hello` on one router. This will show every Hello sent and received. Look for lines like "Hello from [neighbor] with mismatched area [area]". This is the definitive proof. Example: `R1# debug ip ospf hello` then wait for a Hello interval. Output: `OSPF: Hello from 2.2.2.2 with mismatched area 0.0.0.1`. Disable debugging with `undebug all` immediately after capturing the evidence.
Correct the area mismatch
On the router with the wrong area, change the network statement or interface-specific area. Use `network [ip] [wildcard] area [correct-area]` under router ospf, or `ip ospf [process-id] area [correct-area]` under the interface. Then verify with `show ip ospf interface` that the area is now correct. The neighbor should form within two Hello intervals (20 seconds on broadcast). Example: `R2(config)# router ospf 1` then `R2(config-router)# network 10.0.0.0 0.0.0.255 area 0`. Then `R2# clear ip ospf process` to force a restart (optional).
In a typical enterprise network, OSPF areas are used to segment a large routing domain into smaller, more manageable pieces. For example, a retail chain might have a headquarters (Area 0) and hundreds of branch offices, each in its own area (e.g., Area 100, Area 200). Each branch router connects to the HQ via a WAN link. The branch router is configured as an ABR, with one interface in the branch area and the WAN interface in Area 0. A common real-world mistake: during a router replacement or configuration template copy, the network engineer accidentally uses the wrong area number on the WAN interface. The branch router's WAN interface ends up in Area 100 instead of Area 0. The result: the branch cannot reach HQ, but ping works. The help desk might blame the WAN provider, but the issue is a simple area mismatch.
Another scenario: merging two companies. Company A uses OSPF with Area 0 and Area 1. Company B uses OSPF with Area 0 and Area 2. They connect their Area 0 routers via a leased line. If one side mistakenly configures the link as Area 1, the adjacency fails. The engineer must verify area IDs on both sides. At scale, with dozens of routers, area mismatch can be introduced by a typo in an automation script. For example, a Python script that deploys OSPF configuration might have a variable area_id set incorrectly for a specific interface. The symptom is identical: ping works, but no OSPF neighbor.
Performance considerations: OSPF itself is efficient, but the absence of a neighbor means no route exchange. Traffic from the branch to HQ will be dropped because the branch router has no route to HQ networks (except via default if configured). The fix is simple: correct the area ID. However, if the mismatch is on a link that is part of a larger area, it can cause routing blackholes. For example, if a backbone link is misconfigured as a non-backbone area, OSPF will not form adjacency, and the backbone may become partitioned. This is why Cisco recommends using ip ospf area under the interface rather than network statements for critical links — it's more explicit and easier to audit.
When misconfigured, the impact is immediate: no routes are exchanged. The network engineer must use show ip ospf neighbor and show ip ospf interface to isolate the issue. In production, you would never enable debug on a busy router; instead, you'd compare configurations side by side. Area mismatch is one of the easiest OSPF problems to fix once identified, but it is also one of the easiest to overlook because ping works.
The CCNA 200-301 exam objective 3.4 specifically includes troubleshooting OSPF neighbor adjacency issues. Area mismatch is a classic exam topic because it is a simple misconfiguration with a clear symptom: no neighbor. The exam expects you to interpret show ip ospf neighbor output and recognize that an empty neighbor table for a connected link indicates a Hello packet rejection. You must know the exact commands to verify the area on an interface (show ip ospf interface) and to see the OSPF configuration (show running-config | section router ospf).
Common wrong answers candidates choose: 1. "The routers are not in the same subnet." This is a distractor because mismatched subnet mask also prevents adjacency, but in that case, the neighbor might reach INIT state. With area mismatch, the neighbor never appears. Candidates see no neighbor and think subnet mismatch first. 2. "The Dead Timer expired." Dead timer expiration occurs when Hello packets are not received, but with area mismatch, Hellos are received and discarded. The Dead Timer never starts because the neighbor is not recognized. 3. "Authentication is misconfigured." Authentication mismatch also prevents adjacency, but the debug output would show "authentication mismatch" rather than "mismatched area." Candidates often jump to authentication because it's a common exam topic. 4. "The router ID is duplicated." Duplicate router IDs cause issues in the ExStart/Exchange phase, not at the Hello stage. The neighbor would appear in the neighbor table with a state like EXSTART/EXCHANGE.
Specific values: Hello interval default 10 seconds, Dead interval 40 seconds on broadcast links. Area ID is a 32-bit number, often written in dotted decimal (e.g., 0.0.0.0 for Area 0). The network statement uses a wildcard mask, not a subnet mask. The wildcard for a /24 is 0.0.0.255.
Decision rule for scenario questions: If the question states that ping works between two routers but OSPF shows no neighbor, suspect area mismatch or passive interface. Use show ip ospf interface to check the area. If the areas match, check if the interface is passive with show ip protocols. Area mismatch is the more likely answer if the scenario mentions different area numbers.
The exam may present a show ip ospf neighbor output with no neighbors, and a show ip ospf interface output showing Area 0 on one side and Area 1 on the other. The correct answer is to change the area on one side to match. Sometimes the exam uses a simulated CLI where you must enter the correct command. Know that network 10.0.0.0 0.0.0.255 area 0 is how you set the area under router ospf.
Area mismatch prevents OSPF neighbor formation; the neighbor never appears in show ip ospf neighbor.
Ping works between routers with area mismatch because Layer 3 connectivity is intact.
Use show ip ospf interface to verify the area configured on an interface.
Debug ip ospf hello shows 'mismatched area' message for received Hellos with wrong area.
Correct area mismatch by changing the network statement or using ip ospf area under the interface.
Default Hello interval is 10 seconds (broadcast/point-to-point), Dead interval is 40 seconds.
Area ID is a 32-bit number; area 0 is written as 0.0.0.0 in show commands.
These come up on the exam all the time. Here's how to tell them apart.
Area Mismatch
Neighbor never appears in show ip ospf neighbor
Ping works between routers
Hello packet is discarded due to area ID check
Debug shows 'mismatched area'
Fix: change area on one side
Subnet Mask Mismatch
Neighbor may appear in INIT state
Ping works if IP addresses are in same subnet (unlikely with mask mismatch)
Hello is accepted but subnet mask field is compared
Debug shows 'mismatched subnet mask'
Fix: adjust subnet mask on interface
Mistake
Area mismatch causes an OSPF neighbor to show in INIT state.
Correct
Area mismatch causes the Hello to be silently discarded; the neighbor never appears in any state, not even INIT.
Candidates think the router at least acknowledges the Hello, but OSPF drops it before updating the neighbor table.
Mistake
If the router IDs are the same, area mismatch can still form an adjacency.
Correct
Duplicate router IDs cause problems during database exchange, but area mismatch prevents adjacency entirely regardless of router IDs.
Candidates confuse the order of checks: area is checked before router ID uniqueness.
Mistake
The network statement's wildcard mask must match the subnet mask for the interface.
Correct
The wildcard mask in the network statement can be any value that includes the interface IP; it doesn't have to match the subnet mask.
Candidates think OSPF requires exact subnet matching, but the network statement is just a matching condition.
Mistake
Area mismatch only affects adjacency if the routers are in different OSPF process IDs.
Correct
Area mismatch is independent of process ID; routers can have different process IDs and still become neighbors if areas match.
Candidates confuse process ID (local significance) with area ID (must match).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, area mismatch prevents adjacency, so no routes are exchanged. Without routes, traffic is dropped (unless a default route exists). A routing loop requires two or more routers to have incorrect routing information, but with area mismatch, there is no routing information exchanged at all on that link. The symptom is a blackhole, not a loop.
It affects only the specific link (interface) where the mismatch occurs. The router can still have OSPF neighbors on other interfaces that are correctly configured. For example, a router can be in Area 0 on one interface and Area 1 on another (as an ABR), but if the neighbor on the Area 0 interface is configured for Area 1, that specific adjacency fails.
Use consistent configuration templates and automation. Always verify with 'show ip ospf interface' after configuration. Use interface-specific 'ip ospf area' commands rather than network statements for critical links, as they are more explicit. Implement change management and peer review for OSPF configuration changes. Use monitoring tools that alert when OSPF neighbors are missing.
Area mismatch prevents adjacency because the area ID in the Hello must match. Process ID mismatch does NOT prevent adjacency; two routers can have different OSPF process IDs and still become neighbors. The process ID is locally significant. On the CCNA exam, be careful not to confuse these two.
Indirectly. If the wildcard mask does not include the interface IP, the network statement will not activate OSPF on that interface. The interface would then not be in any OSPF area, which is different from being in a wrong area. The symptom would be that OSPF is not running on the interface at all ('show ip ospf interface' would not show the interface). This is a different problem.
In OSPF, the Hello packet contains the Area ID and the subnet mask. The receiving router first checks the Area ID. If it matches, it then checks the subnet mask. If the area mismatches, the Hello is discarded immediately, so no neighbor entry is created. If the area matches but the subnet mask mismatches, the router creates a neighbor entry in INIT state because it received a valid Hello (area matches) but then detects the mask issue. This is a key exam distinction.
No. The area number on a link must be identical on both ends. Each interface belongs to exactly one area. If you want two routers to be in the same area, you must configure the same area ID on the connecting interfaces. There is no way to have different area IDs on the same link and still form an adjacency.
You've just covered Troubleshoot: OSPF Area Mismatch — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?