FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.

This article explains how to resolve the OSPF neighbor issue where your OSPF is stuck in INIT stated.


FortiGate v6.2

FortiGate v6.4

FortiGate v7.0


OSPF uses multicast IP to send HELLO to its neighbor(s).

Sometimes, the multicast packets can get dropped between the source and destination, when this happens, the other side will not receive the HELLO packets, and as such will not be able to get pass the INIT state.

Just for clarity sake, these are the states OSPF routers pass through to form neighbors:


Down State

Attempt State

INIT State

2-Way State

Exstart State

Exchange State

Loading State

Full State (OSPF became fully operational)


Until the neighbors are in FULL State, your network won’t function.


So, neighbor routers get stuck in INIT state when an OSPF router failed to receive its neighbor HELLO packets. These can be caused due to a couple of reasons.

Below are some common causes and suggested solutions.

  1. There’s a Firewall in-between the OSPF neighbors that drops OSPF multicast packets.
  • If you have admin access to the Firewall, you can permit from OSPF routers.
  • If you don’t have control over the network, you can opt for using UNICAST OSPF.
  1. One side of the OSPF neighbors uses authentication while the other did not.
  • Configure authentication on both side or remove it from the side that have it configured.
  1. HELLOs are dropped at Layer 2.
  • Troubleshoot the switched network, especially if this has been working before. Then, check for what changed. It could also be as a result of broken hardware.
  1. The switched network in-between no longer has Multicast capability.
  • Enabling some features can make the switch to loss Multicast capability – detail of this is out of this article scope.
  1. MTU mismatch between the neighbors
  • Check the MTU and if different, you can set OSPF neighbors to ignore MTU. Or, adjust the MTU to same size.


Commands that can help you troubleshoot OSPF stuck in INIT state.

Note: Take this from both neighbors.

#get router info ospf interface

  • Look for the MTU, are the same on both routers? If not make them same or ignore MTU.
  • Look for Tx and Rx HELLO packets, do you notice HELLOs are being dropped.  If yes fix the drops.
  • Did you see authentication been set on one side? Set the other or remove the one set.


# get router info ospf interface

portX is up, line protocol is up

  Internet Address 192.168.X.Y/30, Area, MTU 1500

  Process ID 0, VRF 0, Router ID 192.168.X.Y, Network Type POINTOPOINT, Cost: 1

  Transmit Delay is 1 sec, State Point-To-Point

  Timer intervals configured, Hello 10.000, Dead 40, Wait 40, Retransmit 5

    Hello due in 00:00:08

  Neighbor Count is 0, Adjacent neighbor count is 0

  Crypt Sequence Number is 7900942

  Hello received 14467 sent 75124, DD received 780 sent 906    <<<<<< HELLOs are being dropped.

  LS-Req received 78 sent 261, LS-Upd received 27423 sent 376

  LS-Ack received 298 sent 24409, Discarded 0

  Cryptographic authentication enabled          <<<< Authentication configured

  Sending SA: Key 1


#diag sniffer packet any 'host' 4

  • Is OSPF multicast sent & receive? Or it’s just being sent only. If it’s 1-way and not 2-ways, OSPF will stuck in INIT.  You should fix the drop or use unicast OSPF (set your network type to non-broadcast and specify your neighbor manually).

Sample of 1-way HELLOs:

Line 26: 2.523359 portX out 192.168.X.Y -> ip-proto-89 60
Line 27: 12.493354 portX out 192.168.X.Y -> ip-proto-89 60
Line 28: 22.013359 portX out 192.168.X.Y -> ip-proto-89 60
Line 29: 32.462481 portX out 192.168.X.Y -> ip-proto-89 60
Line 30: 42.251139 portX out 192.168.X.Y -> ip-proto-89 60
Line 31: 51.970889 portX out 192.168.X.Y -> ip-proto-89 60
Line 32: 62.049800 portX out 192.168.X.Y -> ip-proto-89 60
Line 33: 72.219987 portX out 192.168.X.Y -> ip-proto-89 60