Topology:  10.10.10.1 -> Router id: 1.1.1.1. 10.10.10.2 -> Router id: 2.2.2.2. Note: The OSPF router ID should be unique. If the same ID was configured, a duplicate router ID error will appear, and OSPF neighborship will not come up. Init to 2-way state:
In the 'Init' state, the firewall has sent the OSPF 'hello' packet but has not received the 'hello' packet from the neighbor firewall. Whenever a router/firewall sees its router ID in a neighbor hello packet, it confirms bidirectional communication and transitions the neighbor state to two-way.
 In the snippet above, when the neighboring firewall/router receives the OSPF hello from 10.10.10.1, it enters the init state. It will stay in the init state until it receives the following type of hello packet from 10.10.10.1:
 In the above snippet, an active neighbor router-id is added and sent over a multicast address. Once its neighbor 2.2.2.2 receives this hello packet, it will change the state from 'init' to a 2-way state. To add the active neighbor in the 'hello' packet, the following parameters are checked:
Note: The log below shows what a stuck in Init state debug would look like.
Notice that the log only contains '(1-WayReceived)', there is no '(2-WayReceived).
2-way to ExStart/Exhange/ Loading state:
The 2-way state means a bi-directional communication has been established between the routers. At this point, the routers perform DR and BDR elections. Note: DR and BDR election happens for each segment.   Once the primary/secondary relationship is established: The router with the highest router ID becomes the primary, and the next highest is selected as the secondary device. The DBD (Database Descriptor) packets are exchanged in the exchange state. The DBD packets are link-state advertisements and describe the entire Link state database content. A router attempts to form a full adjacency with a neighbor if one of the two routers is the DR or BDR. OSPF routers become fully adjacent to routers with which they have completed the database synchronization process. This is the process by which OSPF routers exchange link-state information to populate their databases with the same information. Again, this database synchronization process is only executed between two routers if one of the routers is the DR or BDR. MTU needs to be matched; otherwise, the neighborship is stuck in the Exstart state.
Note: Sometimes, MTU does match on both sides, but the neighborship remains stuck in the Exstart state because DBD/LSU packets are expiring and are unable to reach the other side. This could be caused by an L2 switch or L2-WAN device (MPLS,) which is placed between OSPF routers and does not forward packets at this MTU. FortiGate can only send and receive 5 Database Descriptors (DD) packets at a given point of time in a queue for all interfaces trying to form a neighborship. If multiple OSPF interfaces are negotiating at the same time, it will take some time to form the neighborship between routers. Note: If OSPF interfaces are stuck in ExStart/Exchange state for some reason and the OSPF process queue is 5/5, then other OSPF interfaces will not be able to form neighbor-ship to 'Full' as well.  Some user commands: diagnose sniffer packet any “proto 89” 6 0 l
diagnose sniffer packet any “host 224.0.0.5” 6 0 l
get router info ospf neighbor
get router info ospf interface
get router info ospf database brief
get router info ospf database self-originate
get router info ospf database router lsa
In case of configuration with more OSPF peers, to filter the sniffer for specific peers, commands below can be used : diagnose sniffer packet any "(host 10.10.10.1 and proto 89) or (proto 89 and host 10.10.10.2)" 6 0 l This sniffer will capture all the traffic from 10.10.10.1 and protocol number 89 or traffic from 10.10.10.2 and protocol number 89. For OSPF always the source is unicast address, and the destination is multicast. The OSPF debug can show error messages as well if the adjacency is not forming. diagnose debug disable
diagnose debug reset
diagnose ip router ospf all enable / disable
diagnose ip router ospf level info
diagnose debug console timestamp enable
diagnose debug enable
execute router clear ospf process
execute router clear ospf process <- Restart the OSPF process.
The sample debug output below shows that the OSPF Hello received on the 'ospftest' interface did not contain the correct OSPF area ID.
OSPF: RECV[Hello]: From 10.90.32.1 via ospftest:10.90.32.2: Invalid Area ID 0.0.0.0
OSPF: IFSM[ospftest:10.90.32.2]: Hello timer expire
OSPF: SEND[Hello]: To 224.0.0.5 via ospftest:10.90.32.2, length 44
OSPF: -----------------------------------------------------
OSPF: Header
OSPF: Version 2
OSPF: Type 1 (Hello)
OSPF: Packet Len 44
OSPF: Router ID 10.90.32.2
OSPF: Area ID 0.0.0.1
OSPF: Checksum 0xd142
OSPF: AuType 0
OSPF: Hello
OSPF: NetworkMask 255.255.255.255
OSPF: HelloInterval 10
OSPF: Options 0x2 (*|-|-|-|-|-|E|-)
OSPF: RtrPriority 1
OSPF: RtrDeadInterval 40
OSPF: DRouter 0.0.0.0
OSPF: BDRouter 0.0.0.0
OSPF: # Neighbors 0
OSPF: -----------------------------------------------------
Disable real-time debug: diagnose ip router ospf all disable
diagnose debug disable
Note: Instead of using 'diagnose ip router ospf all enable', it is possible to enable or disable specific packet debugging with the commands below: diagnose ip router ospf packet
usage: diagnose ip router ospf packet [dd|hello|ls-ack|ls-request|ls-update] (enable|disable)
For example:
Related articles: Troubleshooting Tip: Troubleshooting OSPF getting stuck in a 2-way state Troubleshooting Tip: Unable to see OSPF Neighbor: No 'Hello' Packets | 
