Manual

OSPF neighbours stay in Init or Exstart

The neighbour state tells you where to look: Init is the hello, Exstart is the MTU.

You switched OSPF on between two routers, the neighbour appears in the list and stays there. It never reaches Full, so no routes are exchanged and your network does not know the other side. Sometimes it sits in Init, sometimes in Exstart or Exchange, sometimes it flips between them.

What it is not: this is not a routing problem. Nothing has been exchanged yet, so there is nothing to say about routes. It is not a matter of patience either: a healthy adjacency is Full within seconds. If it stops somewhere, it stays there. The state says exactly how far it got.

Down, or no neighbour at all
No hellos arrive. Interface, area, authentication or firewall.
Init
You hear it, it does not hear you. The traffic is one-way.
Exstart or Exchange
They are talking, but the database packets do not get through. Nearly always the MTU.

The quick checks, in order

  1. What is the state exactly? /routing ospf neighbor print. A good answer: state: Full. Note the state on both sides, because they can differ and that difference is information.
  2. Is the interface taking part? /routing ospf interface print. A good answer: the interface is listed with the right area and not as passive. A passive interface sends nothing.
  3. Do the hellos arrive? /tool sniffer quick interface=tunnel ip-protocol=ospf, or /log print where topics~"ospf". A good answer: packets in both directions. Seeing them in one direction only is your Init.
  4. Does the firewall allow it? /ip firewall filter print stats and look at the input chain. A good answer: a rule that accepts traffic from the neighbour's interface, and a final drop whose counter does not climb while OSPF is trying. OSPF is IP protocol 89 and goes to 224.0.0.5.
  5. Is the MTU the same? /interface print on both sides, and compare the MTU of the interface OSPF runs on. A good answer: exactly the same number. This is the check that fixes Exstart.
  6. Does a large packet get through? /ping neighbour size=1400 do-not-fragment. A good answer: replies. If small pings work and large ones do not, the narrowing is somewhere along the way.

The usual causes, most common first

Exstart: the MTU differs

While building the database, both sides send their interface MTU along. If those differ, the other end refuses and it sticks in Exstart or Exchange. Over a tunnel this is the standard mistake, because every tunnel type has its own overhead: GRE leaves 1476, IPIP 1480, EoIP 1458 and WireGuard defaults to 1420. The fix is the same number on both sides, not the highest number you can find.

Init: the traffic goes only one way

Your router sees the neighbour's hellos and names it, but its own hellos do not arrive on the other side, or the other way round. That is nearly always a firewall: the input chain on one of the two routers does not accept traffic from that interface. On a tunnel this happens when the tunnel interface is not in the LAN list, because the default rules accept input from LAN and drop the rest.

Area, timers or authentication differ

OSPF only forms a relationship between neighbours that agree on the basics: the same area ID, the same hello and dead interval, and the same MD5 key on both sides or none at all. One side with authentication and one without does not give the error you expect; nothing happens.

The router ID is missing or duplicated

Without a loopback or a filled-in router ID, RouterOS picks one itself, and that can change when an interface goes away. Two routers with the same ID give adjacencies that keep starting over.

What the configurator does about it

  • OSPF lives in the Routing section, off by default. You fill in one or more Areas, with backbone on 0.0.0.0 first, and below that Interface templates with an area, an interface or a network, a cost, a passive tick and an MD5 tick per row.
  • The Loopback/router-id address field creates a bridge lo without spanning tree, with a /32 on it, and that address becomes the router ID when you leave the Router-ID field empty. Fill it in: it is the cheapest way to stay ahead of router-ID trouble.
  • Tick MD5 authentication on a template and that key goes onto every template with authentication, with auth-id=1. The other side has to use the same key and the same id.
  • A template that names an interface and is not passive gets type=broadcast. For an ordinary LAN interface that is right. On a link with two ends a DR election is pointless; if a neighbour over a tunnel sits in 2-Way, set type=ptp on both sides.
  • Be clear about the biggest blind spot: the tool does not check the MTU of a tunnel. In the multi-device view it compares the MTU at the two ends of a drawn cable, and the bridge MTU of devices cabled together, but a tunnel falls outside that. The checks on tunnels are about public addresses, keys, roles and clashing address ranges, not about MTU. With OSPF over a tunnel that is exactly the number you want to know, and you have to compare it yourself on both sides.
  • There are two separate MTU warnings nearby: one about WireGuard over PPPoE and one about VXLAN, which needs 1550 bytes along the path. Those are about throughput, not about OSPF, but they point at the same number.
  • The tool also does not check whether both sides use the same area and the same timers. It only knows one side of the link, unless you put both routers in the same site.

Where the cause lies outside your router

  • The path between the two. With a tunnel over the internet, the smallest MTU along the way decides what gets through. Large packets vanishing silently look like an MTU mismatch.

Read on: OSPF, MTU and OSPF between sites.

Want to try it right away? Open the configurator