OSPF Packets and Neighbor Discovery

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

Can you please help me understand the relationship between LSAs and the 5 types of OSPF packets mentioned in this lesson? Am I correct in thinking that LSAs are not ever just sent as raw LSAs and are only sent contained inside LSU packets?

If that is not the case then can you please explain why LSAs are not listed among the 5 OSPF packet types?

Hello Aaron

You point out a very important distinction between the terminology used in OSPF. The five types of OSPF packets described here are the types of messages exchanged between OSPF routers. These messages have headers, contain specific fields, and use source and destination IP addresses (some use unicast, others use multicast) to get from one router to another.

LSAs on the other hand are not “packets” that are exchanged between OSPF routers.

LSAs can be considered “data sets” which contain prefixes and routing information. LSAs are components of the Link State Database (LSDB) contained within each OSPF router. You can see LSAs of all types if you issue the show ip ospf database command. So an LSA is simply a data set found within the LSDB that contains the routes of that particular LSA type.

Now how are LSAs exchanged? By using two of the five OSPF packets described in this lesson. The DBD packet is initially exchanged and contains a summary of the LSDB. In a sense, it contains all of the LSAs that an OSPF router has. The other way, is indeed what you mention in your post, the use of the LSU.

The confusion arises when we use phrases like “The OSPF router sends a Type2 LSA…” which does give the impression that the LSA is a self-contained packet type. But it is not. The proper way to say it (strictly speaking) is “The OSPF router sends an LSU containing a Type 2 LSA…”. But we don’t usually say that and depend on context to make it clear…

I hope this has been helpful!

Laz

Thank you! I did a packet capture in my lab and saw all the LSUs created after entering clear ip ospf process. The strange thing was that in Wireshark, the LSU packets were all highlighted in black, which means they appeared to be out of order. Do you know why that might be?

Also, what triggers a DBD packet if not the clearing of the ospf database?

Quick update to me question here. I did some more packet capturing and I see that entering network statements causes a flurry of DBDs, LSRs, and LSUs. They still all show with black highlights in wireshark, meaning wireshark sees them as out of order (I think).

Is this because they lack sequence numbers? Since OSPF uses it’s own transport layer protocol (as opposed to TCP or UDP), I can’t find any sequence numbers in these packets. I’m wondering if that’s why wireshark thinks they are out of order.

Here’s a link to the capture file for reference:

Hello Aaron

OSPF DBD packets are sent at various times between neighbors. It’s quite complicated actually, but it is clearly described in the OSPFv2 RFC. For each neighbor adjacency, a “Master Slave” relationship is formed. Depending on which OSPF state the adjacency is at, the Master will usually initiate the exchange, while the slave will only send a DBD packet in response to a request from the Master. You can see it in more detail in the RFC.

As you have correctly stated, the black packets in wireshark are those that have been identified as having some problem. Because OSPF packets don’t have sequence numbers, wireshark considers them out of order so it marks them as black…

I hope this has been helpful!

Laz

Thanks again! Really loving this site so far!

Hello Aaron

Great to hear you like the site! We’re doing our best. Just one more thing about my previous post, the Master/Slave relationship for the purpose of DBD packet exchange goes beyond the CCNP level, and may only be found in the CCIE level certification exams.

Laz

Thanks for that, Laz. I’m finding while studying for the CCNP that I often don’t know exactly how deep to research certain topics. Some topics don’t seem to go much deeper than the CCNA level but others obviously do. I’ve been using a combination of the OCG and this site mostly but sometimes your lessons go far deeper than the OCG. I usually find myself going down a rabbit hole for whatever topic I’m currently studying and I have to force myself to move on and accept that I probably don’t need to learn every detail right now.

Hello Aaron

The question of how deep to go is indeed difficult to answer. It has to be a balance between requirements, curiosity, and time. Cisco’s exam topics blueprint are not always crystal clear as to the actual covered content, and by no means do they indicate how deep you should go in a topic. In addition to this, Cisco always states the following alongside their exam topics:

The following topics are general guidelines for the content likely to be included on the exam. However, other related topics may also appear on any specific delivery of the exam. To better reflect the contents of the exam and for clarity purposes, the guidelines below may change at any time without notice.

So there is no way to know how far to go. When you start going through a rabbit hole, you’ll just have to stop yourself, and ensure you understand the fundamentals well. In other cases, you may have to push yourself to cover all of the required subject matter in a particular area.

Ultimately, if you have done the labs, and you have gone over the material and have a good understanding of the topics and technologies, you should be OK.

I hope this has been helpful!

Laz

Liz sir,
I didn’t understand truly the function of master and slave in OSPF packet, would you please explain it to me in briefly?

Thanks and Regards.

Ajmal" Ahmadi"

Hello Ajmal

Take a look at this post:

I hope this has been helpful!

Laz