pjhtech Tools
MikroTik · RouterOS v7

MikroTik OSPF Commands: Neighbours, Interfaces and LSAs

Quick answer #

Use /routing/ospf/neighbor/print detail to inspect adjacency state, then compare operational interfaces with their interface templates. Finally inspect the requested route. OSPF reaching Full and a destination becoming reachable are separate milestones; routing policy and the return path still matter.

Scope: RouterOS v7 on RouterBOARD, CCR, CRS running RouterOS, or CHR where the relevant feature exists. Not SwOS. Output fields depend on release and hardware. Uses RouterOS v7 OSPF interface-template configuration and operational interface menus; scope is OSPFv2/v3 inspection, with an IPv4 route example.

Commands #

Filter the LSA and route examples to the actual item being investigated on a large network. The example route is documentation address space.

Commands
RouterOS v7 · RouterOS v7 terminal; absolute menu paths

Read-only
/routing/ospf/instance/print detail
Read-only
/routing/ospf/area/print detail
Read-only
/routing/ospf/interface-template/print detail
Read-only
/routing/ospf/interface/print detail
Read-only
/routing/ospf/neighbor/print detail
Read-only
/routing/ospf/lsa/print
Read-only

Replace these example values: 203.0.113.0/24.

/ip/route/print detail where dst-address=203.0.113.0/24
Read-only
/log/print where topics~"ospf"
Output may contain sensitive operational data.

Read the result #

The template describes which interfaces should participate and with which parameters. The operational interface view describes the resulting OSPF interfaces. Comparing these catches the common investigative mistake of staring only at a template that does not match the interface you thought it matched.

Read neighbour state in the context of the network type. Full indicates completed adjacency. Two routers on a broadcast segment need not all become fully adjacent to each other; a stable 2-way relationship can be normal between non-DR/BDR routers. An Init state instead indicates that the expected bidirectional Hello relationship is not yet established.

For a neighbour repeatedly stalling during database exchange, compare both ends' configuration and packet evidence. Check area, addressing, authentication, timers and network type before treating the state name as a diagnosis. Keep the two endpoints' outputs close in time so that a transient view on one side is not compared with a recovered view on the other.

Investigate from adjacency to destination #

Write down the expected neighbour address and router ID. Confirm the interface and area first, then inspect state and stability. Once adjacency is accounted for, look for the destination's topology information and installed route. If the route exists, inspect the next hop and verify the return route from the destination side.

A successful router-originated test may use another source address from the client's traffic. Choose a test that represents the affected subnet and document the source. This keeps a management-path success from obscuring a missing user-network advertisement.

Pitfalls #

Avoid disabling and enabling the entire OSPF instance to see whether the problem disappears. That affects other adjacencies and removes valuable timing evidence. Avoid changing multiple neighbouring templates simultaneously unless the change is planned and its scope is clear.

Do not assume a configured interface speed automatically establishes the cost policy you intended. Read the actual OSPF interface cost and compare both directions. Keep the final incident conclusion specific: failed adjacency, missing advertisement, route selection, or forwarding after route installation.

Sources

Documentation reviewed: 8 October 2026