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


312 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. andrew says:

    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


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


  4. Hello sim!

    Concerning your question "Why R1 again sending an hello packet to multicast (sequence no 3 )"

    I assume you're talking about the cloudshark capture that Rene posted on this thread on November 8 2015. Just for reference, the cloudshark output can be found here: https://www.cloudshark.org/captures/111cb2076caa

    If you'll notice, R1 has an IP address of Sequence number 1 shows that R1 sent a hello packet, and sequence number 3 shows another hello packet from R1. Notice the time difference of 9.8 seconds. Remember that the default hello interval for OSPF is 10 seconds. So every 10 seconds, routers are expected to send out hellos. This is normal behaviour.

    And about your question "and why there is LSUPDATE packet before LSREQUEST packet ( sequence no 4 in the shark file )"

    Although it is true that an LSU is sent as a response to an LSR, it can also be sent under other circumstances. So an LSU is not always the response to an LSR. So the LSU that you see at sequence number 4 is not a response to the LSR that you see at sequence number 13. The LSUs that you see at sequence numbers 14 15 and 16 are the responses to the LSR.

    I hope this has been helpful!


  5. very good explanation thanks!

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