Every vendor exposes the same underlying state, because the protocol is standardised and the database is identical on every router in an area. What differs is the command hierarchy, and in a few places what the output silently omits.
The six commands worth memorising
| Question | Cisco IOS | Juniper | Alcatel, Nokia SR OS | Huawei VRP |
|---|---|---|---|---|
| Process summary | show ip ospf | show ospf overview | show router ospf status | display ospf brief |
| Neighbours | show ip ospf neighbor | show ospf neighbor | show router ospf neighbor | display ospf peer |
| Database | show ip ospf database | show ospf database | show router ospf database | display ospf lsdb |
| Interfaces | show ip ospf interface | show ospf interface | show router ospf interface | display ospf interface |
| Routes from OSPF | show ip route ospf | show route protocol ospf | show router ospf routes | display ip routing-table protocol ospf |
| Statistics | show ospf statistics | show ospf statistics | show router ospf statistics | display ospf statistics |
Huawei uses peer rather than neighbour throughout, which is the single most common reason a command is typed correctly and rejected. It is also worth noting that Huawei separates the summary from the detail, so the brief form and the full form of several of these differ more than the equivalent elsewhere.
Reading the process summary first
The summary is the command to run before any other, because it reports the router identifier, the areas the device belongs to, the area types, and the reference bandwidth in use.
Three of the four most common faults are visible there without looking anywhere else. A router identifier that is not what was intended, an area type that disagrees with the neighbour, and a reference bandwidth that differs across the domain all appear in that one output.
The interface view is the one that resolves adjacency faults
The neighbour command reports the state, which tells you something is wrong. The interface command reports why, because it carries the hello and dead intervals, the area, the network type, the cost, the authentication setting, and the MTU.
Comparing that output on both ends of a link resolves nearly every adjacency that will not form, and it is faster than reasoning about the state machine. An adjacency stuck at ExStart is an MTU disagreement visible on that screen, and a mismatch in the intervals or the area is visible in the same place.
Database output needs scoping
The unscoped database command returns every advertisement the router holds, which on a large network is thousands of lines and is rarely what anyone wanted.
All four platforms accept a type and an identifier to narrow it, and the useful pattern is to ask for a specific advertisement rather than to page through the whole database. Asking for the router advertisement of a particular device shows exactly which links it is claiming, which is how a topology that does not match reality gets identified.
Where the output can mislead
A neighbour listed as two way on a broadcast segment is correct rather than broken, because only the designated and backup designated routers form full adjacencies. Reading that as a fault is a common misdiagnosis and produces a lot of wasted effort.
Cost of one on every interface is not an error either, it is the default reference bandwidth of one hundred megabits per second applying to links that all exceed it. The command output is accurate and the routing decision is being made without any speed differentiation at all.
Note: if a command works on one platform and is rejected on another, check the noun before the syntax. Neighbour against peer, database against lsdb, and overview against brief account for most of the difference, and the hierarchy is usually the smaller part of the problem.