OSPF Neighbor Stuck in INIT State: FortiGate Troubleshooting

2026年8月27日 LOG admin

OSPF neighbors pass through Down → Attempt → INIT → 2-Way → ExStart → Exchange → Loading → Full on the way to a working adjacency — and the state where troubleshooting most often stalls is INIT. A neighbor stuck in INIT means your router is receiving HELLO packets from the peer, but the peer is not receiving yours. This article explains the INIT state, the handful of causes behind it, and the FortiGate commands that pinpoint which one you are dealing with.

What INIT Means

OSPF uses multicast 224.0.0.5 (AllSPFRouters) to send HELLOs. If the multicast packets are dropped between source and destination, the peer never sees your HELLO and stays in INIT — a one-way relationship. Common causes: MTU mismatch, HELLO drops, authentication configured on only one side, or a firewall blocking protocol 89.

Stated precisely: a router shows INIT when it has received a valid HELLO from the neighbor, but its own Router ID is not present in the neighbor list carried inside that HELLO. Receiving a HELLO is enough to create a neighbor data structure and move the state out of Down, but OSPF refuses to advance past INIT until two-way communication is confirmed. The neighbor is heard, but it has not heard us — or it heard us and rejected the packet before processing the neighbor list.

Where INIT Sits in the Neighbor State Machine

Knowing the exact stuck state narrows the fault domain before you touch a single command:

Down / Attempt — no HELLO received at all: cabling, VLAN, interface down, OSPF not enabled on one side, or a passive interface on the far end.
INIT — HELLOs arrive but are not accepted or not answered in the other direction. Almost always a drop, an authentication mismatch, a timer mismatch or a network-type mismatch.
2-Way — bidirectional communication is confirmed but the pair never becomes adjacent: typically a broadcast/NBMA segment where both routers are DR-other, or an area/passive mismatch.
ExStart / Exchange — HELLOs are fine, the Database Description exchange fails: MTU mismatch (the classic), duplicate Router ID, or a one-way path that only drops large packets.
Loading — LSAs are requested but never delivered: MTU, filtering of LSU/LSR, or a flapping link resetting the exchange.

If you see INIT, stop looking at the routing layer. The routing protocol has not started; something below it is asymmetrically dropping multicast.

Cause 1: One-Way Multicast Delivery

This is the single most common root cause. HELLOs leave one router and never reach the other, so the receiving router never gets an answer and both ends disagree about the state of the relationship. Typical culprits:

A FortiGate policy, an ACL, or an upstream firewall that blocks IP protocol 89 (OSPF) or the multicast group 224.0.0.5 in one direction only.
A Layer 3 switch without PIM on the transit VLAN, so 224.0.0.5 is not forwarded between the router interfaces.
IGMP snooping enabled on an intermediate switch with no multicast querier, causing the group to be pruned and multicast frames to be flooded inconsistently.
A wireless bridge or a pair of media converters that treat multicast as broadcast and drop it under load.
Asymmetric routing: HELLOs go out of one interface and the return path exists over a different link where multicast is not permitted.
Policy-based IPsec VPN where multicast traffic is not matched by the phase 2 selectors, so HELLOs are never encapsulated.

Confirm it with a sniffer on both ends (below) rather than by assumption: seeing HELLOs at one side and not the other converts a guess into a fact.

Cause 2: Authentication Mismatch

OSPF checks authentication before it processes anything useful in the packet. If a router receives a HELLO with the wrong authentication type, the wrong key ID or the wrong key material, it silently discards the packet — no ICMP, no syslog by default. The sender never learns why and the receiver stays in INIT because the peer's HELLOs, while they arrive on the wire, are never accepted.

Typical mistakes: MD5 configured on one side only, a text (plain) password on one side and MD5 on the other, a key-chain key ID mismatch (MD5 only matches when the key ID and the secret both match), or one side still carrying the old password after a rotation. Note that an authentication mismatch produces the opposite symptom depending on which router you are looking at, which is exactly why two views are needed before changing anything.

Cause 3: HELLO and Dead Interval Mismatch

HELLO and dead intervals are carried in the HELLO packet and must match exactly on broadcast and point-to-point links. When they differ, the receiver drops the HELLO as invalid, the peer sees nothing coming back, and the adjacency stalls at INIT (or flaps between INIT and Down when the dead timer expires). The FortiOS defaults are 10 seconds for HELLO and 40 seconds for dead; any manually tuned value must be identical on both peers.

Cause 4: Network Type Mismatch

Two routers on the same segment that disagree about the network type can reach INIT and go no further. A router configured for non-broadcast or point-to-multipoint waits for unicast HELLOs and ignores multicast; a router configured for broadcast or point-to-point sends to 224.0.0.5. Each hears nothing that it is willing to answer, so both directions look one-way. On FortiGate, check the OSPF interface's network type against the peer's configuration before assuming a physical fault.

Cause 5: MTU Mismatch — What It Really Breaks

An MTU mismatch is famous for the wrong reason. Because the Database Description packets are large, an MTU mismatch usually surfaces as a neighbor stuck in ExStart or Exchange, not INIT — the routers get two-way communication working, then fail the DBD exchange. In tunnel and overlay scenarios the effect can be different: an asymmetric MTU (for example 1500 on one side of a GRE or IPsec interface and 1400 on the other) can swallow the larger HELLO packets while smaller keepalives from other protocols pass, which does look like INIT from the outside. Check both MTU values on both devices and their transit path, or set mtu-ignore on the OSPF interface to remove the variable from the equation.

Cause 6: Duplicate Router ID and Area Mismatch

Two routers advertising the same Router ID break the DBD exchange and tend to sit in ExStart, but they also generate confusing counter behaviour and sometimes drop the first HELLO exchange before the pair stabilises. An area mismatch is a different failure: the routers receive each other's HELLOs, but because the area IDs in the packet do not match their local interface, the HELLO is discarded as invalid — again producing one-way counters and an INIT-looking symptom from one side. Verify the area ID on the interface configuration, not just on the process.

Diagnostic Commands on FortiGate

get router info ospf interface
get router info ospf neighbor

On the OSPF interface output, check the counters:

Internet Address 192.168.X.Y/30, Area 0.0.0.0, MTU 1500
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello received 14467 sent 75124, DD received 780 sent 906   <-- HELLOs are being dropped
** Cryptographic authentication enabled **                    <-- auth mismatch possible

Compare MTU on both routers (make them equal or ignore MTU), verify HELLO counters on both sides, and confirm authentication is configured identically on both peers.

Drill down per interface and per neighbor when you need the raw protocol view:

diagnose ip router ospf interface port1
diagnose ip router ospf neighbor
get router info ospf status
get router info ospf database brief

The per-interface diagnostic prints the HELLO timer values, the authentication type and key ID actually in use, and the neighbor list with the Router IDs that were seen. If the neighbor list on one side is empty while the other side lists its peer, the asymmetry is confirmed at protocol level and you can stop checking physical links.

Reading the HELLO Counters

The Hello received and Hello sent counters are the fastest triage signal in the whole toolkit:

Sent is climbing on both sides, received is zero on one side — packets are being dropped or blocked in one direction on the wire.
Sent and received both climb, yet the neighbor stays in INIT — the packets arrive but are rejected: authentication, area, timer or network-type mismatch.
Received climbs but the neighbor ages out and returns — a genuine dead-interval expiry, usually a flapping link or a heavily congested path.

Sniffer Verification

Confirm whether HELLOs are actually leaving and arriving:

diagnose sniffer packet any "ip proto 89" 4 0 a
diagnose sniffer packet any "host 224.0.0.5" 4

If you see only outbound HELLOs (1-way), fix the drop or switch to unicast OSPF — set the network type to non-broadcast and specify the neighbor manually.

Use the verbose level 4 output with the absolute timestamp (a) so you can line up captures taken on both routers in the same clock window. The direction that shows nothing is the one to investigate: capture again one hop closer to the source until the HELLOs disappear, and you have found the filtering device. Remember that a FortiGate will not show its own locally generated multicast in the sniffer unless you filter on any, and that ARP or hardware-level drops never appear in a software capture at all.

Fixing the One-Way Path

Work from the outside in: remove the drop first, then make the protocol robust against the environment.

Fix the filtering. Allow IP protocol 89 between the two peer addresses in both directions, and make sure 224.0.0.5 and 224.0.0.6 are permitted on the transit segment.
Align authentication. Use the same type, key ID and secret on both sides, and re-enter the key on both routers rather than editing one copy.
Align timers and area IDs. Identical hello/dead intervals and identical area IDs on the interfaces.
Make MTU consistent — or neutralise it:

config router ospf
    config ospf-interface
        edit "port1"
            set interface "port1"
            set network-type point-to-point
            set mtu-ignore enable
        next
    end
end

On a point-to-point link this is usually the correct answer: no DR/BDR election, no MAC-layer multicast dependency, and the MTU check is disabled. On a broadcast segment where multicast genuinely cannot be trusted, fall back to unicast HELLOs:

config router ospf
    config ospf-interface
        edit "port1"
            set interface "port1"
            set network-type non-broadcast
        next
    end
    config neighbor
        edit "10.0.0.2"
            set ip 10.0.0.2
        next
    end
end

If the mismatch is on the physical MTU rather than the OSPF behaviour, override it explicitly instead of masking it:

config system interface
    edit "port1"
        set mtu-override enable
        set mtu 1500
    next
end

Post-Fix Verification

get router info ospf neighbor
get router info routing-table ospf
execute ping-options source 10.0.0.1
execute ping 10.0.0.2

A healthy adjacency shows Full/ - or Full/DR with a dead timer counting down and re-arming before it reaches zero. Then confirm the routes actually installed with get router info routing-table ospf — an adjacency can be Full while the LSDB filters or summarises away every prefix. Finally, watch the counters for a minute: if Hello received stops climbing while the session stays up, the drop is intermittent and will come back at the worst possible moment.