We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 617 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)


374 New Members signed up the last 30 days!


100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,

Forum Replies

  1. Hi Kandhla,

    On multi-access interfaces OSPF will only establish a full adjacency with the DR and BDR router. DROTHERs will remain in the two-way state. Here’s an example of a router with three other OSPF neighbors:

    R1#show ip ospf neighbor 
    Neighbor ID     Pri   State           Dead Time   Address         Interface       1   2WAY/DROTHER    00:00:34     GigabitEthernet0/1       1   FULL/BDR        00:00:32     GigabitEthernet0/1       1   FULL/DR         00:00:39     GigabitEthernet0/1


  2. Oliver,
    You are correct. There is an Attempt state, and you would only see it under the following conditions:

        Your router is an NMBA environment
        You have manually configured a neighbor
        The router has sent a unicast Hello to a neighbor
        The dead timer for that neighbor has not yet expired


    • Kishor,
      I assume you mean the “ExStart” or “Exchange” state, so I will write about those. If OSPF is having an authentication problem, you will not see the routers stuck in ExStart or Exchange. In fact, you won’t see anything at all. The output for “show ip ospf neighbors” will just be blank (if a neighbor relationship hadn’t already formed). If a neighbor relationship already formed, and then an authentication problem is introduced, the neighbors will just drop once the dead interval is reached. The reason, in both cases, is because if there is an authentication mismatch, then the other router’s Hello message will simply be ignored. By ignoring Hello messages, the OSPF state machine will never even begin, let alone get to an ExStart phase.

      To answer your other question, the most common reason by far for OSPF to be stuck in ExStart is because of an MTU mismatch between neighbors. Besides MTU mismatches, other possibilities include duplicate router IDs, access-list that block unicast packets, or NAT misconfigurations.

      I recommend you check out a Cisco article that goes into great detail on OSPF getting stuck. You will find they have a very detailed 14 step explanation as to why an MTU mismatch causes this problem.


    • very good explanation thanks!

    • Hello Laz,

      Well explained, let me do the labbing for the same topology.
      Thanks alot.


    51 more replies! Ask a question or join the discussion by visiting our Community Forum