ospf-analysis

name	ospf-analysis
description	OSPF protocol analysis with adjacency diagnosis, area design validation, LSA interpretation, and SPF convergence assessment. Multi-vendor coverage for Cisco IOS-XE, Juniper JunOS, and Arista EOS with protocol-first diagnostic reasoning.
license	Apache-2.0
metadata	{"safety":"read-only","author":"network-security-skills-suite","version":"1.0.0","openclaw":"{\"emoji\":\"🔍\",\"safetyTier\":\"read-only\",\"requires\":{\"bins\":[\"ssh\"],\"env\":[]},\"tags\":[\"ospf\",\"routing\",\"protocol\"],\"mcpDependencies\":[],\"egressEndpoints\":[]}"}

OSPF Protocol Analysis

Protocol-reasoning-driven analysis skill for OSPF adjacency formation, area design, LSDB integrity, and SPF convergence. Unlike device health checks that compare counters against thresholds, OSPF analysis requires interpreting the neighbor FSM, walking the LSA flooding scope, and validating area topology across the control plane.

Commands are labeled [Cisco], [JunOS], or [EOS] where syntax diverges. Unlabeled statements apply to all three vendors.

When to Use

• OSPF neighbor adjacency not forming or stuck in a non-Full state
• Unexpected route changes or missing routes in the OSPF domain
• Area design review — backbone connectivity, stub/NSSA configuration audit
• SPF algorithm running too frequently (unstable link, flapping interface)
• Post-change verification of OSPF configuration (new interfaces, area changes, redistribution updates)
• LSDB growing unexpectedly or LSA age anomalies indicating flooding issues
• Convergence too slow after planned maintenance or unplanned link failure

Prerequisites

• SSH or console access to the router (read-only privilege sufficient)
• OSPF process running on the device with at least one active interface
• Knowledge of expected area topology: which routers are ABRs/ASBRs, which interfaces belong to which areas, expected neighbor relationships
• Awareness of configured authentication type per area (none, simple, MD5)
• Router IDs known or deterministic (explicit configuration preferred over auto-selection from loopback/interface addresses)

Procedure

Follow this diagnostic flow sequentially. Each step builds on data from prior steps, moving from broad inventory to targeted diagnosis.

Step 1: OSPF Instance and Interface Inventory

Verify OSPF is running and confirm which interfaces participate in each area.

[Cisco]

show ip ospf interface brief

[JunOS]

show ospf interface

[EOS]

show ip ospf interface brief

Record each interface: area assignment, network type (broadcast, point-to-point, NBMA), state (DR, BDR, DROther, Point-to-Point), cost, and hello/dead timers. Compare against expected design — every interface that should participate must appear. An interface missing from output means OSPF is not enabled on it (missing network statement or ip ospf configuration). Verify area assignments match the design — a misassigned area creates a separate adjacency domain.

Step 2: Neighbor State Assessment

List all OSPF neighbors and interpret their FSM state.

[Cisco]

show ip ospf neighbor

[JunOS]

show ospf neighbor

[EOS]

show ip ospf neighbor

Compare the neighbor list against expected topology. Every directly connected OSPF router should appear. For each neighbor not in Full state, the FSM state reveals the failure domain:

• Down → No hellos received from this neighbor. Causes: interface down, OSPF not enabled on remote interface, ACL blocking multicast 224.0.0.5/6.
• Attempt → (NBMA only) Unicast hello sent, no reply. The neighbor is configured but not responding.
• Init → Hellos received but this router's RID is not in the neighbor's hello. Causes: one-way communication — area ID mismatch, authentication mismatch, hello/dead timer mismatch, or MTU preventing return hellos.
• 2-Way → Bidirectional communication confirmed. On broadcast/NBMA networks, non-DR/BDR routers remain in 2-Way with each other — this is normal. Only DR/BDR pairs proceed to Full.
• ExStart → DR/BDR election complete, attempting to establish master/slave for database exchange. Stuck here = MTU mismatch (most common cause) or DBD packet issues.
• Exchange → Database Description (DBD) packets being exchanged. Stuck here = LSDB too large to synchronize or DBD retransmission failures.
• Loading → LSR/LSU exchange in progress, retrieving missing LSAs. Stuck here = unstable LSA flooding or peer withdrawing LSAs during sync.

Reference: references/state-machine.md for full FSM detail.

Step 3: Area Design Validation

Verify OSPF area topology matches the intended design.

[Cisco]

show ip ospf | include Area|router

[JunOS]

show ospf overview

[EOS]

show ip ospf | include Area|router

Validate these design invariants:

• Backbone connectivity: Area 0 must be contiguous. If an ABR has area 0 interfaces that cannot reach other area 0 routers, a virtual link is required. Verify virtual links are up if configured.
• ABR identification: Any router with interfaces in multiple areas is an ABR. Confirm ABR count matches design — unexpected ABRs indicate area misconfiguration.
• ASBR identification: Routers performing redistribution into OSPF. Verify only intended routers are ASBRs — unplanned redistribution causes routing instability.
• Stub/NSSA consistency: All routers in a stub or NSSA area must agree on the area type. A mismatch prevents adjacency formation. NSSA areas generate Type 7 LSAs that ABRs translate to Type 5 — verify translation is occurring.

Step 4: LSDB Analysis

Examine the Link-State Database for integrity and anomalies.

[Cisco]

show ip ospf database database-summary

[JunOS]

show ospf database summary

[EOS]

show ip ospf database database-summary

Check LSA types and counts per area:

• Type 1 (Router): One per router per area. Count should match router count.
• Type 2 (Network): One per broadcast/NBMA segment with a DR. Count should match multi-access segment count.
• Type 3 (Summary): Generated by ABRs. High count in stub areas indicates summarization not configured.
• Type 4 (ASBR Summary): Generated by ABRs to advertise ASBR reachability.
• Type 5 (External): Generated by ASBRs. Should not appear in stub areas. Unexpected Type 5 LSAs indicate redistribution issues.
• Type 7 (NSSA External): NSSA equivalent of Type 5. Translated to Type 5 by the ABR at the NSSA boundary.

Check LSA age: maximum age is 3600 seconds, LSAs are refreshed at 1800 seconds. LSAs with age near 3600 that are not being refreshed indicate an originating router has lost reachability. LSAs with age stuck at 3600 (MaxAge) are being flushed from the LSDB — excessive MaxAge LSAs indicate instability.

Step 5: SPF Convergence Assessment

Evaluate SPF calculation frequency and convergence behavior.

[Cisco]

show ip ospf | include SPF

[JunOS]

show ospf statistics

[EOS]

show ip ospf | include SPF

Check SPF run count and last execution time. Frequent SPF runs (more than once per minute sustained) indicate network instability — a flapping link or interface causing repeated LSA updates. Identify the trigger by checking the LSDB for recently updated LSAs (low age values).

Review SPF throttle timers: initial delay, secondary delay, and maximum hold time. Aggressive timers (low initial delay) provide faster convergence but increase CPU load during instability. Conservative timers protect the CPU but delay convergence.

After a planned change, measure time from the change event to the last SPF run. Compare against the convergence target for the deployment type.

Threshold Tables

Operational parameter norms for OSPF — protocol-level expectations by network type and deployment scale.

Hello and Dead Interval Defaults:

Network Type	Hello Interval	Dead Interval	Notes
Broadcast	10s	40s	Default for Ethernet
Point-to-Point	10s	40s	Default for serial/P2P
NBMA	30s	120s	Requires neighbor statements
Point-to-Multipoint	30s	120s	No DR election

All routers on a segment must agree on hello and dead intervals — mismatch prevents adjacency.

LSA Norms:

Parameter	Normal	Warning	Critical
LSA age	0–1800s	1800–3500s	3600s (MaxAge)
LSA refresh	Every 1800s	Missed refresh	Persistent MaxAge
Type 1 count per area	= router count	>2x routers	Indicates duplicate RID
Type 5 count (enterprise)	10–500	>1000	>5000
Type 5 in stub area	0	Any (design violation)	—

SPF Norms:

Parameter	Normal	Warning	Critical
SPF runs (per hour)	1–5	6–20	>20
SPF initial delay	50–200ms	<50ms (too aggressive)	>5000ms (too slow)
SPF max hold	5000–10000ms	<2000ms	>50000ms
Convergence (single link)	<1s	1–5s	>10s

Decision Trees

Adjacency Not Forming

Neighbor not reaching Full state
├── State: Down
│   ├── Interface up? → Check Layer 1/2 status
│   ├── OSPF enabled on interface? → Check network statement or ip ospf config
│   ├── Correct area? → Compare area ID both sides
│   └── Multicast reachable? → Check ACLs for 224.0.0.5/224.0.0.6
│
├── State: Init (one-way)
│   ├── Hello timer mismatch? → Compare hello/dead intervals both sides
│   ├── Area ID mismatch? → Must match exactly on shared segment
│   ├── Authentication mismatch? → Verify type and key both sides
│   ├── Subnet mismatch? → Interfaces must be on same subnet
│   └── MTU blocking return hellos? → Check interface MTU both sides
│
├── State: 2-Way (expected on broadcast for DROther↔DROther)
│   ├── Both routers DROther? → Normal — Full only with DR/BDR
│   ├── DR/BDR election stuck? → Check priority values, verify DR is up
│   └── Unexpected? → Force DR election: clear ospf process (disruptive)
│
├── State: ExStart (most actionable stuck state)
│   ├── MTU mismatch? → Compare MTU both sides (most common cause)
│   │   ├── Cisco: ip mtu vs ip ospf mtu-ignore
│   │   ├── JunOS: interface MTU settings
│   │   └── Fix: match MTU or enable mtu-ignore (workaround)
│   └── DBD packet issues? → Check for packet drops, interface errors
│
├── State: Exchange
│   ├── LSDB too large? → Reduce area scope, add summarization
│   ├── DBD retransmissions? → Check interface reliability, CRC errors
│   └── CPU overloaded? → Check process CPU during exchange
│
└── State: Loading
    ├── LSAs being withdrawn during sync? → Check for flapping neighbor
    ├── Incomplete LSR responses? → Verify peer stability
    └── Timeout? → Increase retransmit interval if link is slow

Missing or Unexpected Routes

Route not in routing table (or unexpected route present)
├── Missing route?
│   ├── LSA in LSDB? → show ip ospf database [type] [id]
│   │   ├── LSA present → SPF did not install
│   │   │   ├── Better route via another protocol? → Check admin distance
│   │   │   ├── Filtered by distribute-list? → Check outbound filters
│   │   │   └── Next-hop unreachable? → Verify forwarding address
│   │   └── LSA absent → Not being advertised
│   │       ├── In stub area? → Type 5 filtered by design — use NSSA or default
│   │       ├── ABR not summarizing? → Check area range / summary config
│   │       ├── Redistribution missing? → Verify ASBR redistribute config
│   │       └── Originator down? → Check originating router's OSPF status
│   └── Check area boundaries → ABR filtering or summarization may exclude
│
└── Unexpected route?
    ├── Unexpected Type 5 LSA? → Identify ASBR → check redistribution scope
    ├── Unexpected Type 7 → Type 5 translation? → Check NSSA ABR behavior
    ├── Route from wrong area? → Verify area assignments on originator
    └── Duplicate router ID? → Two routers with same RID cause LSA conflicts

Report Template

OSPF ANALYSIS REPORT
=====================
Device: [hostname]
Vendor: [Cisco | JunOS | EOS]
OSPF Process ID: [process-id]
Router ID: [router-id]
Check Time: [timestamp]
Performed By: [operator/agent]

ADJACENCY STATUS:
- Total neighbors expected: [n]
- Full: [n] | Non-Full: [n]
- Neighbors requiring attention: [list with FSM states]

AREA TOPOLOGY:
- Areas configured: [list with types — backbone, stub, NSSA, standard]
- ABR count: [n] | ASBR count: [n]
- Backbone contiguous: [yes/no]

FINDINGS:
1. [Severity] [Category] — [Description]
   Neighbor/Area: [identifier]
   Observed: [state or metric]
   Expected: [normal state or value]
   Root Cause: [diagnosis from decision tree]
   Action: [recommended remediation]

LSDB SUMMARY:
- LSA counts by type: [Type 1: n, Type 2: n, ...]
- MaxAge LSAs: [count — 0 is healthy]
- LSA age anomalies: [any near-expiry LSAs]

SPF STATUS:
- Last SPF run: [timestamp]
- SPF runs in last hour: [count]
- Convergence assessment: [healthy/warning/critical]

RECOMMENDATIONS:
- [Prioritized action list]

NEXT CHECK: [CRITICAL: 1hr, WARNING: 8hr, HEALTHY: 24hr]

Troubleshooting

MTU Mismatch (ExStart Stuck)

The most common OSPF adjacency failure. Neighbors reach ExStart but cannot proceed because DBD packets exceed the smaller MTU and are dropped. Fix by matching MTU on both sides. Workaround: ip ospf mtu-ignore (Cisco/EOS) skips the check but may cause fragmentation issues. On JunOS, set matching MTU values at the interface level.

Duplicate Router IDs

Two routers with the same Router ID cause LSA conflicts — each router's Type 1 LSA overwrites the other's in the LSDB. Symptoms: routes flapping, intermittent reachability. Fix: assign unique router IDs explicitly. Detect by checking for Type 1 LSAs with the same Link State ID but different advertising routers.

Area 0 Discontinuity

If area 0 is split, inter-area routing breaks — ABRs cannot flood Type 3 LSAs across the gap. Fix: restore physical backbone connectivity or configure virtual links through a transit area. Virtual links are temporary solutions — long-term design should maintain contiguous backbone.

Excessive Redistribution

Redistributing too many external routes into OSPF floods the LSDB with Type 5 LSAs, increasing SPF computation time and memory usage. Use route-maps with prefix-lists to limit redistribution scope. Consider stub or NSSA areas to shield non-edge routers from external LSAs.

Type 7 to Type 5 Translation

In NSSA areas, the ABR with the highest Router ID translates Type 7 LSAs to Type 5 for flooding into area 0. If translation fails, external routes from the NSSA are invisible to the rest of the OSPF domain. Verify the translator ABR is healthy and the forwarding address in the Type 7 LSA is reachable.