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 606 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)


363 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. 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.


  3. very good explanation thanks!

  4. Hello Mohammad

    I just did a simulation where I had the following topology:

    The configuration for R1 is:
    router ospf 1
    network area 0
     network area 0

    and for R2

    router ospf 1
    network area 0
    network area 0

    So the router IDs are the same.

    The result that I get from the show ip ospf neighbor command is the following:

    Router1#show ip ospf neighbor
        Neighbor ID     Pri   State           Dead Time   Address         Interface           1   EXSTART/DR      00:00:34      GigabitEthernet0/0

    and from R2:

    Router#show ip ospf neighbor 
        Neighbor ID     Pri   State           Dead Time   Address         Interface           1   EXSTART/DR      00:00:30      GigabitEthernet0/0

    So I do indeed get the EXSTART state when the router IDs are the same. The reason for this is that during the EXSTART the routers exchange DBD packets. The router and its neighbour form a master slave relationship where the higher router ID becomes the master. If the router IDs are the same, this mechanism of choosing master/slave does not complete and the router gets stuck.

    I hope this has been helpful!


  5. 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