OSPF Packets and Neighbor Discovery

Lessons Discussion
62

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

63

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?

64

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

1 Like
65

I got it,
thanks, Laz

1 Like
66

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.

67

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

68

Great information - thanks Laz. :+1:

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

1 Like
69

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

70

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

71

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.

OSPF_stuck_in_Loading
OSPF_stuck_in_Loading.png700×107 8.56 KB

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.

2 Likes
72

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

73

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

1 Like
74

Thank you Laz. Its clear now

Thanks

1 Like
75

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?

76

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

77

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?

78

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:

79

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

80

Thanks again! Really loving this site so far!

81

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