Area mismatch — hello area field, type 1 mismatch, summary vs external in stub

OSPF area mismatch is a higher-level failure than MTU mismatch or duplicate router-id: it is a topology failure, not a protocol failure. The two routers’ Hellos have different area-ids (or different area-types), and the adjacency fails because the routers do not agree on which area they share.

This lesson covers the protocol-level details: the Hello packet’s area-id field, the E-bit and N-bit Options flags that encode area-type, the diagnostic output for area mismatches, and the production playbook for migrating areas.

The Hello packet and the area-id field

OSPF Hello packets carry the area-id in the OSPF header:

OSPF Hello packet:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |     Type      |         Packet length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Router ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Area ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Checksum             |          AuType               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Authentication ... (variable)                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The receiving router compares the Area ID in the incoming Hello to the area-id configured on its interface. If they disagree, the Hello is silently discarded and the adjacency fails.

sequenceDiagram
  participant R1 as R1 (Area 0)
  participant R2 as R2 (Area 1)
  R1->>R2: Hello<br/>Area ID = 0
  Note over R2: Area ID 0 != Area ID 1<br/>Hello discarded
  R2->>R1: Hello<br/>Area ID = 1
  Note over R1: Area ID 1 != Area ID 0<br/>Hello discarded
  Note over R1,R2: Adjacency fails<br/>Init state

The diagnostic:

show ip ospf neighbor
# (empty)

show ip ospf neighbor detail
# (empty - no neighbour formed)

# On R1
show ip ospf interface eth0
# Interface eth0
#   Area 0

# On R2
show ip ospf interface eth0
# Interface eth0
#   Area 1

The fix is to align the area-id on both sides:

# On R2
delete protocols ospf area 1 interface eth0
set protocols ospf area 0 interface eth0
commit
save

The E-bit and N-bit Options flags

OSPF Hello packets carry an Options field with several flags. For area-type matching, the two relevant flags are:

• E-bit (External). Set when the router is in a standard area (can carry Type 5 AS-External LSAs).
• N-bit (NSSA). Set when the router is in an NSSA area (can carry Type 7 NSSA-External LSAs).

The flags’ meaning for adjacency formation:

The receiving router checks the Options field on the incoming Hello. If the flags do not match the area-type of the receiving router’s interface, the Hello is discarded.

sequenceDiagram
  participant R1 as R1 (Standard area)
  participant R2 as R2 (Stub area)
  R1->>R2: Hello<br/>E-bit = 1, N-bit = 0
  Note over R2: R2 is in stub area<br/>Expects E-bit = 0<br/>Mismatch<br/>Hello discarded
  R2->>R1: Hello<br/>E-bit = 0, N-bit = 0
  Note over R1: R1 is in standard area<br/>Expects E-bit = 1<br/>Mismatch<br/>Hello discarded
  Note over R1,R2: Adjacency fails

The diagnostic:

show ip ospf neighbor detail
# Neighbor 10.255.0.2, interface address 10.0.0.2
#   Area mismatch!

# Or:
debug ospf packet hello
# log shows: "Hello packet area-id mismatch"
# or: "Hello packet E-bit mismatch"

The fix is to align the area-type on both sides:

# Make both standard
set protocols ospf area 0 network 10.0.0.0/24
# (no stub or nssa declaration)

# Or make both stub
set protocols ospf area 1 stub
set protocols ospf area 1 network 10.0.0.0/24
commit
save

Area-type mismatch details

The four area types and their OSPF behaviour:

Standard area

• Accepts Type 1, Type 2, Type 3, Type 4, Type 5 LSAs.
• E-bit is set on outgoing Hellos.
• Allows external routes via Type 5 AS-External LSAs.
• Allows inter-area routes via Type 3 Summary LSAs.

Stub area

• Accepts Type 1, Type 2, Type 3, Type 4 LSAs (no Type 5).
• E-bit is clear on outgoing Hellos.
• Default route is injected by ABR as Type 3 Summary 0.0.0.0/0.
• External routes are not allowed; the ABR does not propagate Type 5 LSAs into the area.

Totally stub (stub no-summary)

• Accepts Type 1, Type 2, Type 3 (only default route) LSAs.
• E-bit is clear.
• Default route is injected; no other inter-area or external routes are allowed.

NSSA

• Accepts Type 1, Type 2, Type 3, Type 4, Type 7 LSAs.
• N-bit is set on outgoing Hellos; E-bit is clear.
• ASBR can redistribute external routes as Type 7.
• ABR translates Type 7 to Type 5 for propagation to other areas.

Totally NSSA (NSSA no-summary)

• Accepts Type 1, Type 2, Type 3 (only default), Type 7 LSAs.
• N-bit set; E-bit clear.
• Default route is injected; no other inter-area routes are allowed; Type 7 to Type 5 translation still happens at ABR.

Summary vs external routes in stub areas

A common production confusion: a router in a stub area expects to see external routes (Type 5 LSAs). It will not. The ABR filters Type 5 LSAs from entering the stub area; the ABR injects a default route (Type 3 Summary 0.0.0.0/0) instead.

The diagnostic:

# On a router in a stub area
show ip ospf database
# Type 1 Router-LSAs: visible
# Type 2 Network-LSAs: visible
# Type 3 Summary-LSAs: visible (including default)
# Type 4 ASBR-Summary-LSAs: not visible
# Type 5 AS-External-LSAs: NOT visible
# Type 7 NSSA-External-LSAs: not visible (NSSA only)

The behaviour is by design: stub areas are not supposed to carry external routes. If the operator needs external routes in a stub area, the operator should use NSSA instead.

NSSA Type 7 to Type 5 translation

In an NSSA, an ASBR redistributes external routes as Type 7 NSSA-External LSAs. The ABR’s job is to translate Type 7 to Type 5 for propagation to the rest of the OSPF domain.

The translation fails when:

• P-bit clear. The Type 7 has the P-bit (propagate) clear; the ABR does not translate.
• Forward address unreachable. The Type 7’s forward address is unreachable from the receiving router.
• ABR refusal. The ABR has a no-redistribute range that matches the prefix.

The diagnostic:

show ip ospf database nssa-external self-originate verbose
# Type 7 LSAs originated by this router, with P-bit

show ip ospf database external
# Type 5 LSAs in the LSDB
# If empty but Type 7 LSAs are present, translation is failing

Production scenarios

Scenario 1 — New router in an existing area

A new router joins an existing area. The operator forgets to configure the area-type declaration. The new router’s Hellos have E-bit set; the existing stub-area routers’ Hellos have E-bit clear; the adjacency fails.

The fix is to add the area-type declaration to the new router:

set protocols ospf area 1 stub
set protocols ospf area 1 network 10.0.0.0/24
commit
save

Scenario 2 — Migrating from stub to NSSA

An operator converts a stub area to NSSA so the area can redistribute external routes. The conversion is not atomic; during the transition, some routers are stub and some are NSSA. The adjacency fails for the routers with mismatched area-type.

The fix is to make the change area-wide in a maintenance window:

# On every router in the area
set protocols ospf area 1 nssa
delete protocols ospf area 1 stub
commit
save

flowchart LR
  subgraph "Before"
    A1["R-A stub<br/>E-bit clear"]
    A2["R-B stub<br/>E-bit clear"]
    A3["R-C nssa<br/>E-bit clear, N-bit set"]
  end
  subgraph "After (consistent NSSA)"
    B1["R-A nssa<br/>E-bit clear, N-bit set"]
    B2["R-B nssa<br/>E-bit clear, N-bit set"]
    B3["R-C nssa<br/>E-bit clear, N-bit set"]
  end
  A1 -. "Inconsistent: A-B see each other, A-C mismatch" .-> A3
  A1 -- "consistent: Full adjacency" --> A2
  B1 -- "consistent: Full adjacency" --> B2
  B2 -- "consistent: Full adjacency" --> B3

Scenario 3 — Area-id typo

An operator configures area 0.0.0.10 instead of area 0.0.0.1 on a new router. The Hellos have area-id 10; the existing routers have area-id 1. The adjacency fails.

The diagnostic is show ip ospf interface showing the area-id. The fix is correcting the configuration.

Production failure modes

• Area-id mismatch. Two routers have different area-ids on the same link. The fix is to align the area-id.
• Area-type mismatch (E-bit). One router is standard, the other is stub. The fix is to align the area-type.
• Area-type mismatch (N-bit). One router is stub, the other is NSSA. The fix is to align the area-type.
• Stub area with Type 5 LSAs. The operator expects Type 5 LSAs in a stub area. They will not appear. The fix is to use NSSA instead of stub.
• NSSA without ASBR. The operator configures NSSA but forgets the ASBR. The NSSA does not have any Type 7 LSAs to translate. The fix is to add the redistribution.

Diagnostic playbook

The diagnostic sequence for an area-mismatch failure:

1. Confirm the adjacency is not forming. show ip ospf neighbor is empty.
2. Check the area-id on both sides. show ip ospf interface on each router. Disagreement is the area-id mismatch.
3. Check the E-bit and N-bit. debug ospf packet hello shows the incoming Hello’s Options field. Compare to the expected area-type’s Options.
4. Check the area-type declaration. show configuration commands | match "area .* stub\\|nssa". Compare with the neighbour’s configuration.
5. Apply the fix. Align area-id or area-type on both sides.
6. Validate. show ip ospf neighbor shows Full.

Rollback

The rollback for an area-related change:

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

# Compare
compare

# Commit with a short confirm window
commit-confirm 5

# Rollback if needed
rollback 1
commit

For an area migration:

# Revert to the previous area-type
delete protocols ospf area 1 nssa
set protocols ospf area 1 stub
commit
save

Production discipline

Cross-course references

The OSPF areas lessons vyos-xviii-04-areas (area concept), vyos-xx-01-area-types (area types), vyos-xx-02-stub-nssa (stub and NSSA), vyos-xx-04-virtual-links (virtual links), and vyos-xx-05-multi-area-design (multi-area design) cover the area primitives this lesson assumes. The OSPF configuration lessons vyos-xix-03-ospf-area-config (area configuration) and vyos-xix-05-ospf-authentication (authentication) cover related configuration. The OSPF troubleshooting lessons vyos-xxii-01-neighbour-stuck (neighbour-stuck states) and vyos-xxii-06-missing-route (missing route) cover related failure modes.

Quiz