OSPF Packets and Neighbor Discovery

Hi,

" When our routers receive the DBD from the other side they will do a couple of things:

Send an acknowledgement using the LSAck packet"

LSack packets coming right after the DBD ?

Or after the LSR and LSU being sent ?

Thanks

Gaurav,
The Master is determined by which router has the highest Router ID (not necessarily the same router which has the highest OSPF priority). The master is responsible for the following:

  1. Sends first DBD packet
  2. Increments the sequence numbers of the DBD
  3. Ensures that only one DBD packet is outstanding at once
  4. Retransmit a DBD if necessary. A slave cannot retransmit.

So essentially, the purpose of the master/slave relationship is just a matter of ordering and housekeeping–assigning who is responsible for certain functions.

Hi,
Why R1 again sending an hello packet to multicast 224.0.0.5 (sequence no 3 )
and why there is LSUPDATE packet before LSREQUEST packet ( sequence no 4 in the shark file )
Thanks

Hello sims!

To answer your question “LSack packets coming right after the DBD ? Or after the LSR and LSU being sent ?”

A router receives the DBD first. Once that has been completed, and only then, does the router send an LSAck packet acknowledging the successful receipt of the DBD. An LSR is then sent ONLY if new or newer information is contained within the DBD that was received requesting more information.

In other words, an LSR essentially says to the other router “I don’t have information concerning network X that you sent me. Tell me more about it!” The other router will respond with an LSU stating: “OK, here is the additional information about network X you asked for!”.

So to summarize, the sequence of events is:

  1. Rx sends the DBD to Ry
  2. Ry receives the DBD successfully and responds with an LSAck saying “I acknowledge the DBD you sent me”
  3. If (and only if) new or newer information exists, Ry sends an LSR requesting more information about the networks in question
  4. Rx responds with an LSU which contains the required information…

I hope this has been helpful!

Laz

1 Like

19 posts were merged into an existing topic: OSPF Packets and Neighbor Discovery

Hello sim!

Concerning your question “Why R1 again sending an hello packet to multicast 224.0.0.5 (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 192.168.12.1. 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!

Laz

2 Likes
R1#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.2       1   2WAY/DROTHER    00:00:34    192.168.1.2     GigabitEthernet0/1
192.168.1.3       1   FULL/BDR        00:00:32    192.168.1.3     GigabitEthernet0/1
192.168.1.4       1   FULL/DR         00:00:39    192.168.1.4     GigabitEthernet0/1

Hi Rene
In the example above is it accurate to say:
192.168.1.4 is the DR for the segment
192.168.1.3 is the BDR for the segment
Both 192.168.1.2 and r1 itself non designated routers?
Many thanks

Hello Shaun.

Yes, you are accurate in your description!

Laz

19 posts were merged into an existing topic: OSPF Packets and Neighbor Discovery

I had a question on this forum post. I was curious at what level you learn of this such as CCNP TSHOOT? or if this is not something you pick up any regular cisco training but from trouble shooting experience in real word. I think its great piece of information though especially for multi vendor companies such as mine that might have Brocade and Cisco and the possibility of different MTU`s

andrewAndrew P

Aug '16

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.

2http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13684-12.html#exstart2

Hello Brian

@andrew can tell us from his point of view, but I’d like to share my experience as well. I find that the basic theory necessary to be able to understand these things is given clearly in CCNA and CCNP where we learn about the different states of the OSPF process of convergence. The ExStart and Exchange states are actually first mentioned in CCNA, but are further examined in CCNP. So really, the theory is there from the certifications to be able to comprehend what is going on. The experience allows you to solidify the theory into more a comprehensive and clearer understanding of the concepts. When you face such an issue in the real world and you troubleshoot and figure it out, you fully understand the intricacies of its functionality. Without the experience, these concepts will not be fully understood. But without the theory provided by the certifications, you’ll never get a chance to gain the experience in the first place.

I hope this has been helpful!

Laz

1 Like

very good explanation thanks!

1 Like

Hi
Are DR , BDR and Master , Slave the same ?

Hi Heng,

These are two separate things.

* The master/slave roles are used during the DBD exchange.
* The DR/BDR are used on multi-access networks to reduce the number of neighbor adjacencies.

Rene

Dear andrew,

I test this Exstart behaviour by using same router ID on two differnet nodes, i didnt see any of the node goes to Exstart state.
But when changing the MTU on interface it stuck in Exstart state.

//BR
Waqar

Hello Mohammad

Having the same router ID can indeed lead to an OSPF node getting stuck in Exstart state. According to this Cisco Documentation, this can be the case.

In order to duplicate such a scenario however, it may be necessary to have more than two OSPF routers and to have the OSPF processes reset in all routers. It may take some experimentation to get the circumstances right.

I hope this has been helpful!

Laz

Hello laz,

I got your point but my concern here is that when there is MTU mismatch we see in (show ip ospf neighbor) command that neighor is in EXSTART state but with the Router ID scenario we didnt see any of the output depicting that its in EXSTART state although we see the blank output in (show ip ospf neighbor) command when its having same Router ID.
Thanks for the valuable feedback.

//BR
Waqar

Hello Mohammad

I just did a simulation where I had the following topology:
image
The configuration for R1 is:

router ospf 1
router-id 1.1.1.1
network 10.10.10.0 0.0.0.255 area 0
 network 10.10.101.0 0.0.0.255 area 0

and for R2

router ospf 1
router-id 1.1.1.1
network 10.10.10.0 0.0.0.255 area 0
network 10.10.102.0 0.0.0.255 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.1.1.1           1   EXSTART/DR      00:00:34    10.10.10.2      GigabitEthernet0/0

and from R2:

Router#show ip ospf neighbor 

    Neighbor ID     Pri   State           Dead Time   Address         Interface
    1.1.1.1           1   EXSTART/DR      00:00:30    10.10.10.1      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!

Laz

Hello Laz,

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

//BR
Waqar

1 Like

Hello Laz,

I used the same topology and configuration as you used above but in my case i am not seeing the desired results.

I enabled terminal logging and seeing the below logs:

*Mar 20 10:41:32.276: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 10.10.10.2 on interface GigabitEthernet0/1
*Mar 20 10:40:31.640: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 10.10.10.1 on interface GigabitEthernet0/2

and for the (show ip ospf neighbor) i am having Blank Output.

R1#sh ip ospf neighbor

There is the possibility that I am missing something which is stopping me to get the desired results.

R1#show running-config partition router ospf 1
Building configuration...
! Last configuration change at 10:39:04 UTC Tue Mar 20 2018
router ospf 1
 router-id 1.1.1.1
 network 10.10.10.0 0.0.0.255 area 0
 network 10.10.101.0 0.0.0.255 area 0

R2:

R2#show running-config partition router ospf 1
Building configuration...
! Last configuration change at 10:39:07 UTC Tue Mar 20 2018
router ospf 1
 router-id 1.1.1.1
 network 10.10.10.0 0.0.0.255 area 0
 network 10.10.102.0 0.0.0.255 area 0
!