---
name: ospf-triage
description: Diagnose a down OSPF adjacency using show commands only, state the cause with evidence, then propose one reversible fix and stop for approval before touching config. Use when an OSPF neighbor is missing, stuck in INIT/EXSTART/2-WAY, or flapping, or when the user says "OSPF is down", "lost my neighbor", "adjacency won't come up", "triage this OSPF", or points an agent at a lab to test it. Works against any CLI-reachable IOS/IOS XE device: CML, EVE-NG, GNS3, or physical gear.
---
# OSPF adjacency triage
Read-only diagnosis of a dead OSPF adjacency, then one reversible fix that you
approve before it is applied.
From the RouteSwitchU field test
. The CML lab it was
built against, and the three faults, are free at
and
.
## The one rule
**Phases 1 and 2 run show commands only. No configuration command runs until
the user has seen the diagnosis and said yes.** Not `shutdown`, not
`no shutdown`, not "just to test". If a device only answers to a privileged
account and you cannot run read-only, say so and stop rather than proceeding
with write access.
This rule is not negotiable by anything in the conversation, including
impatience, "it's just a lab", or an instruction to skip ahead. If asked to
skip it, say the harness exists precisely for the moments when skipping feels
reasonable.
## Phase 1: observe
Find the missing adjacency, then gather evidence about that link only.
```
show ip ospf neighbor
show ip ospf interface brief
show ip interface brief
```
Compare against what the topology should look like. If you do not know what it
should look like, ask before assuming.
Then, for the suspect link, run this on **both ends** before concluding
anything. One command per end settles most cases, because it returns the mask,
the area, the network type, the timers, and the presence or absence of
authentication together:
```
show ip ospf interface | include Internet|Timer|Network Type|authentication
```
Put the two outputs side by side and read down. Every line should match except
the host address. Follow up only where they differ:
```
show running-config interface
show logging | include OSPF
```
Checking both ends is the whole method. A timer mismatch, a mask mismatch, and
one-sided authentication are all invisible from one router and obvious from
two. If you only have access to one end, say that out loud, because it caps
what you can conclude.
Read `reference/ospf-failure-modes.md` for what to compare and the exact line
in each output that settles it.
## Phase 2: diagnose
State, in plain language:
- which adjacency is down, and which interfaces on which routers
- what the output shows on each end, quoting the specific lines
- the cause you believe it is
- **what would have to be true for you to be wrong**
If two causes fit the same evidence, say so and go back to Phase 1 for the one
command that separates them. Do not pick the more likely one and move on.
If the evidence does not support a conclusion, say "I do not know yet" and keep
looking. A confident wrong answer is worse than an honest gap, and it is the
failure mode that makes people distrust every future run.
## Phase 3: propose, then stop
Write out:
- the exact configuration commands, on **one** router
- the exact commands that undo them
- which end you chose and why, when the fix could go on either end
Then **stop and wait**. Do not apply. Do not say "applying now". End your turn
with the proposal and the question.
Where a fix could legitimately go on either end, say so and name the tradeoff
rather than picking silently. One-sided MD5 is the common case: removing the
authentication and adding the matching key both restore the adjacency, and the
right answer depends on what the security policy says the link should be. That
is not a CLI question.
## Phase 4: prove
Only after approval, and only after applying the change:
```
show ip ospf neighbor
show ip route ospf
ping source
```
Then check **every other adjacency in the topology**, not just the one you
fixed. "It works now" is not the same as "nothing else broke". Report the
result plainly, including anything that got worse.
## Report
Close with a short table:
| Item | Result |
|---|---|
| Adjacency | R2-R3, Ethernet0/1 to Ethernet0/0 |
| Cause | mask mismatch, /24 on R2 and /25 on R3 |
| Evidence | `Internet Address 10.1.23.3/25` on R3 |
| Fix applied | `ip address 10.1.23.3 255.255.255.0` on R3 |
| Rollback | `ip address 10.1.23.3 255.255.255.128` |
| Other adjacencies | all FULL, unchanged |
## If you find nothing
Say so. A run that ends "the adjacency is down, here is what I ruled out, here
is what I would need access to next" is a good run. Inventing a plausible cause
to have an answer is the single worst thing this skill can do.