OSPF area troubleshooting — LSDB inconsistencies, area mismatch, stuck states, NSSA issues

OSPF area failures are not the same as OSPF interface failures. An interface failure is local to a single adjacency; an area failure crosses the ABR boundary and can affect every router in the area. The diagnostic sequence is different: an interface failure starts with show ip ospf neighbor; an area failure starts with show ip ospf database and show ip ospf border-routers.

This lesson covers the four most common area-level failures:

1. LSDB inconsistencies across an area boundary.
2. Area-id and area-type mismatches.
3. Neighbours stuck in Init / Exstart because of area configuration differences.
4. NSSA Type 7 translation issues (P-bit, forward address, ABR refusal).

Each failure mode has a specific diagnostic and a specific remediation.

Diagnostic command set

The area-troubleshooting command set:

show ip ospf
show ip ospf database
show ip ospf database self-originate
show ip ospf database router
show ip ospf database network
show ip ospf database summary
show ip ospf database external
show ip ospf database nssa-external
show ip ospf border-routers
show ip ospf neighbor
show ip ospf virtual-links
show ip ospf interface
show ip ospf statistics
show ip route ospf
debug ospf lsa
debug ospf nssa
debug ospf adj
vtysh -c 'show ip ospf'

The debug ospf commands are the deep diagnostic. They print every LSA flooding decision, every NSSA translation decision, and every adjacency state change to the log. The cost is high log volume; the operator enables them sparingly.

Failure mode 1 — LSDB inconsistencies across an area boundary

A router inside Area X has a Type 1 LSA that says “I have an interface to 10.1.0.0/24”. The downstream Area Y is supposed to see a Type 3 Summary for 10.1.0.0/24, not the Type 1. The ABR’s job is to filter the Type 1 and inject the Type 3.

An LSDB inconsistency happens when:

• The Type 1 leaks across the boundary (the ABR did not filter it).
• The Type 3 does not appear (the ABR did not inject it).
• The Type 3 carries the wrong prefix or mask (the ABR summarised incorrectly).
• The Type 3 carries the wrong metric (the ABR’s cost is wrong).

The diagnostic is show ip ospf database on both sides of the boundary, compared:

# On the source router (inside Area 10)
show ip ospf database router self-originate

# On the destination router (inside Area 0)
show ip ospf database summary

# The destination should see the prefix as a Type 3, not a Type 1

sequenceDiagram
  participant R as Router inside Area 10
  participant ABR as ABR
  participant D as Router inside Area 0
  R-->>ABR: Type 1 Router LSA<br/>advertises 10.1.0.0/24
  Note over ABR: Should inject Type 3 Summary 10.1.0.0/24
  ABR-->>D: Type 3 Summary 10.1.0.0/24
  D->>D: show ip ospf database summary<br/>10.1.0.0/24 visible
  Note over ABR,D: Inconsistency:<br/>Type 1 leaks or Type 3 missing

The remediation depends on the cause:

• Type 1 leaks: the ABR’s filtering is broken. Verify the configuration. A common cause is a range declaration that summarises too narrowly.
• Type 3 missing: the ABR’s summarisation is broken. Verify the range declaration or the absence of one (no range means no summary).
• Type 3 wrong prefix / mask: the ABR’s range declaration has the wrong prefix / mask. Correct the configuration.
• Type 3 wrong metric: the ABR’s range ... cost N declaration has the wrong cost. Correct the configuration.

Failure mode 2 — Area-id and area-type mismatches

A router’s interface is configured in Area 10, but the neighbour’s interface is configured in Area 20. The adjacency fails because the two routers do not agree on which area they share.

The diagnostic is show ip ospf neighbor verbose:

show ip ospf neighbor <neighbour-id> detail

The output includes the area-id mismatch:

Neighbor 192.0.2.1, interface address 10.0.0.2, Area 0
  In the area 10
  Area mismatch!

The remediation is to correct the configuration on one side so the two routers agree on the area-id.

For area-type mismatches, the same diagnostic:

Neighbor 192.0.2.1, interface address 10.0.0.2, Area 0
  In the area 0
  Area-type mismatch!

The remediation is to correct the area-type declaration on one side so the two routers agree on the type (standard, stub, NSSA).

A common production scenario:

• A new router joins the area. The operator forgets to add area-type stub to the new router’s configuration. The new router forms adjacencies with non-stub routers (it does not check the E-bit on the Hello packets it sends), but the existing stub routers refuse to form adjacencies with it (the E-bit check fails on their side).
• The new router sees the existing routers in Full. The existing routers see the new router in Init.
• The operator runs show ip ospf neighbor verbose on the new router and sees the area-type mismatch flag.

The remediation is to add area-type stub to the new router’s configuration and commit. The adjacencies re-form.

Failure mode 3 — Neighbours stuck in Init or Exstart

The Init state means the router has received a Hello from the neighbour but has not been included in the neighbour’s Hello. The neighbour’s Hello does not list this router’s router-id.

The Exstart state means the router and the neighbour are negotiating the master / slave relationship for the database exchange. The state is normal during initial adjacency formation. A neighbour stuck in Exstart for more than a few seconds indicates a problem.

The Init / Exstart failures with area-level causes:

• Area-id mismatch. The two routers are in different areas. The Hello packets are accepted (they share the same OSPF multicast group) but the area-id check fails. The adjacency stays in Init.
• Area-type mismatch (stub / standard). The two routers have different area-type declarations. The E-bit check fails on the Hello packets. The adjacency stays in Init.
• MTU mismatch. The two routers have different MTU values on the interface. The DBD (Database Description) packets do not fit and the adjacency stays in Exstart. The MTU mismatch is not strictly an area failure but it surfaces in the same diagnostic.
• Stub area is transit for a virtual link. The virtual link configuration is rejected by FRR (the transit area must be standard), but if the configuration is forced, the virtual link’s Hello packets are dropped.

The diagnostic sequence:

# 1. Confirm the neighbour is in Init / Exstart
show ip ospf neighbor
# Output: state = Init / Exstart

# 2. Read the verbose output for the cause
show ip ospf neighbor <neighbour-id> detail
# Output: area mismatch, area-type mismatch, MTU mismatch, etc.

# 3. Compare the configuration on both sides
# On router A:
show configuration commands | grep "area "
# On router B (via SSH / console):
# show configuration commands | grep "area "

# 4. Look for the area-type mismatch specifically
show ip ospf interface <interface-name>
# Output: area-type flag

The remediation depends on the cause. The most common production fix is to align the configuration on both sides of the adjacency.

Failure mode 4 — NSSA Type 7 translation issues

NSSA Type 7 translation can fail in three ways:

1. P-bit clear. The ASBR-NSSA redistributes a prefix with the P-bit clear. The ABR does not translate the Type 7 to a Type 5. The prefix stays inside the NSSA only. The downstream domain does not see the route.

2. Forward address unreachable. The Type 7’s forward address is an address that the receiving router cannot reach. The route is present in the LSDB but does not install in the RIB (recursive routing failure).

3. ABR refuses translation. The ABR has a no-redistribute range that matches the prefix. The ABR suppresses the Type 5 generation.

The diagnostic for P-bit:

show ip ospf database nssa-external self-originate verbose
# Output: P-bit clear flag

The diagnostic for forward address:

show ip ospf database nssa-external <prefix> verbose
# Output: Forward address field

show ip route <forward-address>
# Output: route to the forward address (or recursive routing failure)

The diagnostic for ABR refusal:

show configuration commands | match "not-advertise"
# Output: the suppressed ranges

flowchart TB
  subgraph "NSSA area 30"
    ASBR[ASBR-NSSA]
    ABR[ABR-NSSA]
  end
  subgraph "Backbone area 0"
    B[Core]
  end
  ASBR -- "Type 7 10.99.0.0/16 P-bit clear" --> ABR
  ABR -. "P-bit clear: do not translate" .-> ABR
  ASBR -- "Type 7 10.100.0.0/16 forward unreachable" --> ABR
  ABR -- "Type 5 10.100.0.0/16 generated" --> B
  ASBR -- "Type 7 10.101.0.0/16 P-bit set" --> ABR
  ABR -. "range matches: do not translate" .-> ABR

The remediation:

• P-bit clear: ensure the ASBR’s redistribution uses the default P-bit behaviour (set). Do not explicitly clear the P-bit unless the operator wants the prefix to stay inside the NSSA only.
• Forward address unreachable: use a forward address the receiving router can reach (typically the ASBR’s interface in the NSSA). If the forward address is in a different area, ensure that area has a route back to the ASBR.
• ABR refusal: remove the no-redistribute range or align the range to not match the prefix.

The diagnostic playbook

A generic diagnostic sequence for an OSPF area-level failure:

1. Confirm the scope of the failure. Is it one adjacency, one area, or the whole domain? show ip ospf neighbor shows the adjacency state; show ip ospf shows the area state.
2. Compare the LSDB across the area boundary. Run show ip ospf database on both sides and look for the missing or extra LSA types.
3. Check the area-id and area-type. Run show ip ospf interface on each interface and look for the area-id and area-type flags.
4. Check the configuration. Run show configuration commands | match "area " and look for the declarations. Compare with the neighbour’s configuration.
5. Enable OSPF debug for the specific subsystem. Use debug ospf lsa, debug ospf nssa, or debug ospf adj to see the protocol-level decisions.
6. Apply the remediation. Make the configuration change and verify with the diagnostic command set.

Rollback

The rollback for an area-level change is the same as any OSPF change:

# Capture the running configuration before the change
show configuration commands | save /tmp/ospf-area-troubleshoot-$(date +%s).txt

# Compare
compare

# Commit with a short confirm window
commit-confirm 5

# Rollback if needed
rollback 1
commit

The commit-confirm window is essential for area-level changes because the change is adjacency-wide. If the change breaks the adjacencies, the rollback must fire automatically.

Production discipline

Cross-course references

• The OSPF troubleshooting part (XXII) covers the adjacency-level failures: neighbour stuck (vyos-xxii-01-neighbour-stuck), MTU mismatch (vyos-xxii-02-mtu-mismatch), area mismatch (vyos-xxii-03-area-mismatch), and duplicate router-id (vyos-xxii-05-duplicate-router-id).
• The OSPF fundamentals part covers the LSA types (vyos-xviii-03-lsa-types) and the area concept (vyos-xviii-04-areas).
• The previous lessons cover the area types (vyos-xx-01-area-types), the stub / NSSA mechanism (vyos-xx-02-stub-nssa), summarisation (vyos-xx-03-summarisation), virtual links (vyos-xx-04-virtual-links), and design patterns (vyos-xx-05-multi-area-design).
• The Linux course’s V-Linux-NetConfig covers the kernel-level primitives the operator uses when the area failure manifests as a forwarding failure.

Quiz