OSPF Packets and Neighbor Discovery

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
!

Hi Laz,
I am getting same issue(above mentioned ) in my lab topology…no neighbourship is happening between R1 & R2…
So why we are not getting in our LAB ?
Waiting for your valuable response.

Thanks & Regards,
Arindom

Hello Mohammad and Arindom

This is interesting. It seems that there are two different behaviours that are occurring when the same configuration is implemented between routers. Researching the issue further I have found two Cisco documentations that indicate two different things. First, we are told that if there is no output from the show IP ospf neighbor command, this could be because of identical router IDs between the two routers:

Router IDs are used in order to identify each router in an OSPF network. Routers with the same Router ID will ignore HELLOs sent by each other, which prevents them from forming adjacency. The first line of show ip ospf command output displays the current Router ID of each router.

The above explanation refers to the results you are getting. This is documented here on page 3. Secondly, we are also told that:

MTU mismatch, although the most common, is not the only reason that OSPF neighbors get stuck in the exstart/exchange state. This can also be due to both routers having the same router ID (mis-configuration).

This is the case in my experimentation and is documented here.

This may be due to a platform issue or an IOS version issue. My test was done using two 1941 routers running IOS Version 15.1(4)M4. Can you both @waqar675 and @arindom.nag share your platforms and IOS versions? We’ll get to the bottom of this! :stuck_out_tongue:

Thanks!

Laz

Hi Laz,
Nice explanation…
Sorry for late reply…today morning i tried with your same platform or IOS and getting right output…plz find the details…

R1#sh version 
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Wed 23-Feb-11 14:19 by pt_team

ROM: System Bootstrap, Version 15.1(4)M4, RELEASE SOFTWARE (fc1)
cisco1941 uptime is 5 minutes, 30 seconds
System returned to ROM by power-on
System image file is "flash0:c1900-universalk9-mz.SPA.151-1.M4.bin"
Last reload type: Normal Reload

R1#sh ip ospf neighbor 


Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   EXSTART/BDR     00:00:34    192.168.12.2    GigabitEthernet0/0



R2#sh version 
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Wed 23-Feb-11 14:19 by pt_team

ROM: System Bootstrap, Version 15.1(4)M4, RELEASE SOFTWARE (fc1)
cisco1941 uptime is 5 minutes, 49 seconds
System returned to ROM by power-on
System image file is "flash0:c1900-universalk9-mz.SPA.151-1.M4.bin"
Last reload type: Normal Reload

R2#sh ip ospf neighbor 


Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   EXSTART/DR      00:00:38    192.168.12.1    GigabitEthernet0/0

Then i tried with different IOS Version 12.4(25d) for recheck and getting no ouput like as previous(which Mohammad and i got ) please find the details…

R4#sh version
Cisco IOS Software, 3700 Software (C3745-ADVIPSERVICESK9-M), Version 12.4(25d), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Wed 18-Aug-10 08:18 by prod_rel_team

R4#sh running-config | section ospf
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 192.168.12.0 0.0.0.255 area 0

R4#debug ip ospf adj
*Mar  1 00:05:38.275: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 192.168.12.1 on in    terface FastEthernet0/0
*Mar  1 00:05:11.367: OSPF: end of Wait on interface FastEthernet0/0
*Mar  1 00:05:11.367: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:05:11.367: OSPF: Elect BDR 1.1.1.1
*Mar  1 00:05:11.367: OSPF: Elect DR 1.1.1.1
*Mar  1 00:05:11.367: OSPF: Elect BDR 0.0.0.0
*Mar  1 00:05:11.367: OSPF: Elect DR 1.1.1.1
*Mar  1 00:05:11.367:        DR: 1.1.1.1 (Id)   BDR: none
*Mar  1 00:05:11.867: OSPF: No full nbrs to build Net Lsa for interface FastEthernet0/0

R4#sh ip ospf neighbor



----------------------------------------------------------
R3#sh version
Cisco IOS Software, 3700 Software (C3745-ADVIPSERVICESK9-M), Version 12.4(25d), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Wed 18-Aug-10 08:18 by prod_rel_team

R3#sh running-config | section ospf
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 192.168.12.0 0.0.0.255 area 0

R3#
*Mar  1 00:08:02.831: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 192.168.12.2 on interface FastEthernet0/0
R3#
*Mar  1 00:09:02.839: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 192.168.12.2 on interface FastEthernet0/0
R3#
*Mar  1 00:10:12.819: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 192.168.12.2 on interface FastEthernet0/0
R3#
*Mar  1 00:11:12.823: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 192.168.12.2 on interface FastEthernet0/0
R3#
*Mar  1 00:12:22.831: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 192.168.12.2 on interface FastEthernet0/0


R3#sh ip ospf neighbor

So Laz final conclusion is which was in my and Mohammad mind( why we didn’t reproduce in our LAB & no output was like you ) its happening due to IOS which you mentioned yesterday:smiley:

Aside Mohammad please go through the above mention output and you can try with this “Version 15.1(4)M4” then you can get which you and i expected.

Thanks & Regards,
Arindom

In the lesson, it states that lsack packets will be transferred upon receiving the dbd packets. However, when dbd packets are sent there is no lsack.

Say for example, the master sends a dbd packet, the slave receives and responds with a dbd packet (might include lsa headers) and the sequence number field is same as the packet that was sent by the master.

Please let me know if my understanding is wrong

https://www.cloudshark.org/captures/0062204357ab

Hello Sriguruprassad

This is a good point you bring up. An LSA acknowledgement does not always have to be in the form of an LSAck packet. Acknowledgements can also be implied with the receipt of a link state update. For example, the RFC for OSPF states the following:

Each newly received LSA must be acknowledged. This is usually done by sending Link State Acknowledgment packets. However, acknowledgments can also be accomplished implicitly by sending Link State Update packets.

So to more clearly state it, each DBD packet recieved must be acknowledged. This can be done using a LSAck packet or implicitly using a response such as a LS Update. Multiple LSAcks can also be grouped together and sent in a single LSAck packet as well. More info on this can be found in the RFC link below:

https://tools.ietf.org/html/rfc2328#page-152

Looking at the cloudshark output you sent, many of the DBD packets sent has been responded to with the LS update sent afterwards as an acknowledgement.

I hope this has been helpful!

Laz

1 Like

Hello all

I would like to make 2 questions.

  1. During the neighbor adjacency process will the DROTHER router send the DBD,LSUs to the unicast addresses of DR and BDR or to the multicast address of 224:0:0:6? What addresses will also the DR and BDR use to reply and send their DBD, LSUs to the DROTHER?
  2. Database description packets are only exchanged during the neighbor adjacency process? They are not sent after the adjacency is fully established? In this case updates are only sent directly through LSUs and without the use of DBD packets? Thank you for the reply.

Regards
Markos

Hello Markos

Concerning question 1, there is no clear cut answer given for the destination IP address for DBDs from DROTHER routers in the RFC2328 describing OSPFv2. It states what kinds of packets use what kind of address (unicast/multicast) except for the DBD. Take a look at Pages 58-59 on the RFC. However, researching further, there seems to be a consensus that the DBD packets are sent to the unicast addresses of the DR and BDR. Now according to the RFC:

On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, i.e., sent directly to the other end of the adjacency. In this case, the IP destination is just the Neighbor IP address associated with the other end of the adjacency … The only packets not sent as unicasts are on broadcast networks; on these networks Hello packets are sent to the multicast destination AllSPFRouters, the Designated Router and its Backup send both Link State Update Packets and Link State Acknowledgment Packets to the multicast address AllSPFRouters, while all other routers send both their Link State Update and Link State Acknowledgment Packets to the multicast address AllDRouters.

So it seems the DR and BDR send LSUs and LSAs to the AllSPFRouters multicast address.

For question 2, DBD packets will be sent to a neighbour depending on the neighbour’s state:

  1. In ExSTart, the router sends an empty DBD.
  2. In the Exchange state the DBD contain summaries of the link state information. Whether or not it is sent depends on whether the router is master or slave.
  3. In loading and full states, the slave must resend its last DBD in rspose to duplicate DBD packets received from the master, but this is done only once, as soon as these states have been reached.

Now when receiving DBD packets under various states, routers will either accept them or drop them, depending on the state of the neighbor adjacency. The conditions under which DBDs are sent or recieved are described in detail in the following sections of the RFC:

  • 10.6. Receiving Database Description Packets
  • 10.8. Sending Database Description Packets

The RFC link once again:

https://www.ietf.org/rfc/rfc2328.txt

I hope this has been helpful!

Laz

I have a question about “directly connected” and “OSPF neighbors”:
Suppose a hierarchical network with ten or twenty routers (each connected to at least one father and two sons, with some redundancies) in the same area. Then, one or several DRs and BDRs are elected. the OSPF neighbors of a router may be only its directly connected routers …for example if they are its DR or BDR. But the OSPF DR or BDR neighbors of this router may also not be connected to it directly; we can then discover routers whose OSPF neighbors are not directly connected to them.
Am I right ?
Or does each router have the other 19 routers as OSPF neighbors?

Hello Hugues

An OSPF adjacency can only be created by directly connected OSPF routers. Let me say it another way. The IP addresses of the interfaces connecting two OSPF routers must be in the same subnet in order to for a neighbor adjacency. In other words, if you have this:

(R1)—(R2)

where the interfaces connecting R1 and R2 are in the same subnet, then they become neighbors.

(R1)—(Layer 2 Switch)—(R2)

The above topology would also allow R1 and R2 to become neighbors, because they are on the same subnet once again.

Now if you have three or more routers connected to a switch on the same subnet, then you get the DR and BDR election. This results in a single adjacency, between each router and the DR. So if you have 5 routers on the same subnet, and all have OSPF activated on their interfaces, then you would have a DR, with one adjacency to each of the other routers.

Now if you have (R1)—(R2)—(R3) then you would have two adjacencies, one between R1 and R2, and another between R2 and R3. R3 and R1 will NOT be OSPF neighbors.

So to summarize:

  1. An OSPF adjacency will take place only if the routers are directly connected (either physically or via a L2 switch) and are on the same subnet.
  2. If there are more than two routers connected to a L2 switch that are on the same subnet, an OSPF adjacency will occur between each router and the elected DR.
  3. OSPF adjacencies will not occur between the interfaces of routers that are on different subnets.

I hope this has been helpful!

Laz

I got it,
thanks, Laz

1 Like

Hi Guys,

Just thinking about the different OSPF packet types and if they would be unicast or multicast?

I understand an initial hello is sent to 224.0.0.5 and the replies are unicast to the sender. So hello packets can be both unicast/multicast.

But what about the other packet types (DBD, LSU, LSR and LSAck)?

Also, you don’t list LSA as a packet type? Is this because it is contained within an LSU?

Thanks,

Gareth.

Hello Gareth

Concerning the other types of OSPF packets, the answer is that many of these can actually be both unicast and multicast. It depends on the way in which they are used. Specifically:

DBDs are sent using the unicast address that has been obtained from the hello exchanges. This involves the creation and maintenance of a master/slave relationship between neighbours to regulate communication.

Whether or not multicast addresses (and which multicast addresses) are used also depends on the existence of a DR and BDR. Link State Update packets are sent to the AllSPFRouters (224.0.0.5) address while all other routers send both their LSUs and LSAcks to the multicast address AllDRouters (224.0.0.6).

An LSAck can be unicast when a device wants to acknowledge a received LSA to a single neighbour. However, multiple LSAcks can be grouped into a single LSAck to improve efficiency. This enables a single LSAck to indicate acknowledgements to several neighbours at once using multicast. So LSAcks can be both unicast or multicast.

In addition, retransmissions of Link State Update packets are ALWAYS sent directly to the neighbour. On multi-access networks, this means that retransmissions should be sent to the neighbour’s IP address.

Most of this information can be found in the OSPFv3 RFC.

So you see there is no clear cut answer, but depending on the situation, either unicast or multicast will be used on an Ethernet network. On non-broadcast networks, unicast is always used.

I hope this has been helpful!

Laz

Great information - thanks Laz. :+1:

The non broadcast networks have to use unicast because broadcast/multicast is an ethernet concept… :wink:

1 Like

Hello
i have one Q
how i can configure OSPF in lab GNS3 to stuck in Loading and attempt state for adjacency
its neccessary

Hello Alil

Having a neighbor stuck in loading state is not a common problem. This will only occur in the event of corrupted LSAs, something that you cannot simulate easily. Whenever OSPF neighbors are stuck in loading state, Cisco recommends you contact their technical support, as this is probably a result of damaged or malfunctioning equipment rather than a bad config.

The following Cisco documentation describes this situation in detail, as well as other OSPF neighbor problems, and I believe you will find it useful.

I hope this has been helpful!

Laz

Hello Alil,
Attempt state is only valid on nonbrodcast networks, where it indicates that hello packet was sent towards specific nehighbor, but router still havent received any hello from the specific neighbor. You can lab this using GNS3 by telling OSPF to threat Ethernet interface as Non-Broadcast and specify neighbor with ip address in same subnet.
Imagine following scenario with one switch and one router. The switch is there only to allow interface g0/0 on R1 to be in up/up state. There are not any other routers connected to the switch.
OSPF_stuck_in_Atempt
Configuration like this:

R1# show run | section Ethernet0/0|ospf
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip ospf network non-broadcast
 media-type rj45
router ospf 1
 network 192.168.1.1 0.0.0.0 area 0
 neighbor 192.168.1.2

produces stuck in Attept state.

R1# show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
N/A               0   ATTEMPT/DROTHER    -        192.168.1.2     GigabitEthernet0/0

Producing stuck in Loading state can be more challenging. You can simulate it with this easy topology.


The key is to set mtu on switch interface to certain value. This value has to be big enough to let OSPF DB Descriptors pass but small enough to drop LS Update. This is why transit switch has mtu of 150 on its g0/1 interface. Because R1 has 8 loopback networks that need to be advertised to R2, the LS Update is going to have 194 bytes and this size causes transit switch in the middle to drop this LS Update.

Here is basic config of R1.

R1# show run | section router ospf
router ospf 1
 router-id 0.4.0.1
 limit retransmissions non-dc disable
 network 10.0.0.0 0.0.7.255 area 0
 network 192.168.12.1 0.0.0.0 area 0

R1# show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
0.4.0.2           1   FULL/BDR        00:00:36    192.168.12.2    GigabitEthernet0/0

In this case, adjacency state on R1 is FULL, because it has everything it needs from R2, but R2 is going to have adjacency in Loading state, because it requires LS Update from R1 and this update is not getting to him, thus R2 continues to retransmit LS Request and R1 is continuing to retransmit LS Update (which is being dropped).
By default retransmission limit is set to 25 and then neighborship is dropped, to make R2 stay in Loading state forever we disabled this limit.

R2# show run | section router ospf
router ospf 2
 router-id 0.4.0.2
 limit retransmissions non-dc disable
 network 192.168.12.2 0.0.0.0 area 0

R2# show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
0.4.0.1         255   LOADING/DR      00:00:35    192.168.12.1    GigabitEthernet0/3

This example is not so practical, but I hope it serves your needs.

1 Like

Hi,
I have a doubt in OSPF LSA synchronisation. If a router receives about a link from more than one neighbour, which one it will accept and what will happen to others update LSAs

Thanks,
Thulasiraman

Hello Balachandar

OSPF routers will receive LSAs from multiple neighbours. All LSAs are received, examined and processed. If an LSA contains newer information than that currently in the LSDB, then the information is added. If it has older information, then it is discarded.

A more detailed description of how LSAs are processed in this manner can be found in the following lesson:

Remember that OSPF maintains a complete picture of the topology, so information it receives from all routers is kept in the LSDB. It then chooses the best routes to each destination and places them into the routing table.

I hope this has been helpful!

Laz

Thank you Laz. Its clear now

Thanks

1 Like