This topic explain how single-area OSPF operates. Start learning CCNA 200-301 for free right now!!
Note: Welcome: This topic is part of Module 1 of the Cisco CCNA 3 course, for a better follow up of the course you can go to the CCNA 3 section to guide you through an order.
Table of Contents
Video – OSPF Operation
Click Play in the figure to view a video about OSPF operation.
OSPF Operational States
Now that you know about the OSPF link-state packets, this topic explains how they work with OSPF-enabled routers. When an OSPF router is initially connected to a network, it attempts to:
Create adjacencies with neighbors
Exchange routing information
Calculate the best routes
The table details the states OSPF progresses through while attempting to reach convergence:
No Hello packets received = Down.
Router sends Hello packets.
Transition to Init state.
Hello packets are received from the neighbor.
They contain the Router ID of the sending router.
Transition to Two-Way state.
In this state, communication between the two routers is bidirectional.
On multiaccess links, the routers elect a DR and a BDR.
Transition to ExStart state.
On point-to-point networks, the two routers decide which router will initiate the DBD packet exchange and decide upon the initial DBD packet sequence number.
Routers exchange DBD packets.
If additional router information is required then transition to Loading; otherwise, transition to the Full state.
LSRs and LSUs are used to gain additional route information.
Routes are processed using the SPF algorithm.
Transition to the Full state.
The link-state database of the router is fully synchronized.
Establish Neighbor Adjacencies
When OSPF is enabled on an interface, the router must determine if there is another OSPF neighbor on the link. To accomplish this, the router sends a Hello packet that contains its router ID out all OSPF-enabled interfaces. The Hello packet is sent to the reserved All OSPF Routers IPv4 multicast address 126.96.36.199. Only OSPFv2 routers will process these packets. The OSPF router ID is used by the OSPF process to uniquely identify each router in the OSPF area. A router ID is a 32-bit number formatted like an IPv4 address and assigned to uniquely identify a router among OSPF peers.
When a neighboring OSPF-enabled router receives a Hello packet with a router ID that is not within its neighbor list, the receiving router attempts to establish an adjacency with the initiating router.
Click each button below to step through the process routers use to establish adjacency on a multiaccess network.
When OSPFv2 is enabled, the enabled Gigabit Ethernet 0/0 interface transitions from the Down state to the Init state. R1 starts sending Hello packets out all OSPF-enabled interfaces to discover OSPF neighbors to develop adjacencies with.
R2 receives the Hello packet from R1 and adds the R1 router ID to its neighbor list. R2 then sends a Hello packet to R1. The packet contains the R2 Router ID and the R1 Router ID in its list of neighbors on the same interface.
R1 receives the Hello and adds the R2 Router ID to its list of OSPF neighbors. It also notices its own Router ID in the list of neighbors of the Hello packet. When a router receives a Hello packet with its Router ID listed in the list of neighbors, the router transitions from the Init state to the Two-Way state.
The action performed in Two-Way state depends on the type of interconnection between the adjacent routers, as follows:
If the two adjacent neighbors are interconnected over a point-to-point link, then they immediately transition from the Two-Way state to the ExStart state.
If the routers are interconnected over a common Ethernet network, then a designated router DR and a BDR must be elected.
Because R1 and R2 are interconnected over an Ethernet network, a DR and BDR election takes place. As shown in the figure, R2 becomes the DR and R1 is the BDR. This process only occurs on multiaccess networks such as Ethernet LANs.
Hello packets are continually exchanged to maintain router information.
Synchronizing OSPF Databases
After the Two-Way state, routers transition to database synchronization states. While the Hello packet was used to establish neighbor adjacencies, the other four types of OSPF packets are used during the process of exchanging and synchronizing LSDBs. This is a three step process, as follows:
Decide first router
Send an LSR
Click each button below to step through the process routers use to synchronize their LSDBs.
In the ExStart state, the two routers decide which router will send the DBD packets first. The router with the higher router ID will be the first router to send DBD packets during the Exchange state. In the figure, R2 has the higher router ID and sends its DBD packets first.
In the Exchange state, the two routers exchange one or more DBD packets. A DBD packet includes information about the LSA entry header that appears in the LSDB of the router. The entries can be about a link or about a network. Each LSA entry header includes information about the link-state type, the address of the advertising router, the cost of the link, and the sequence number. The router uses the sequence number to determine the newness of the received link-state information.
In the figure, R2 sends a DBD packet to R1. When R1 receives the DBD, it performs the following actions:
It acknowledges the receipt of the DBD using the LSAck packet.
R1 then sends DBD packets to R2.
R2 acknowledges R1.
The Need for a DR
Why is a DR and BDR election necessary?
Multiaccess networks can create two challenges for OSPF regarding the flooding of LSAs, as follows:
Creation of multiple adjacencies – Ethernet networks could potentially interconnect many OSPF routers over a common link. Creating adjacencies with every router is unnecessary and undesirable. It would lead to an excessive number of LSAs exchanged between routers on the same network.
Extensive flooding of LSAs – Link-state routers flood their LSAs any time OSPF is initialized, or when there is a change in the topology. This flooding can become excessive.
To understand the problem with multiple adjacencies, we must study a formula:
For any number of routers (designated as n) on a multiaccess network, there are n (n – 1) / 2 adjacencies.
For example, the figure shows a simple topology of five routers, all of which are attached to the same multiaccess Ethernet network. Without some type of mechanism to reduce the number of adjacencies, collectively these routers would form 10 adjacencies:
5 (5 – 1) / 2 = 10
This may not seem like much, but as routers are added to the network, the number of adjacencies increases dramatically. For example, a multiaccess network with 20 routers would create 190 adjacencies.
Creating Adjacencies With Every Neighbor
Number of Adjacencies = n (n – 1) / 2
n = number of routers
Example: 5 (5 – 1) / 2 = 10 adjacencies
LSA Flooding With a DR
A dramatic increase in the number of routers also dramatically increases the number of LSAs exchanged between the routers. This flooding of LSAs significantly impacts the operation of OSPF.
Click each button to compare the flooding of LSAs without and with a DR.
To understand the problem of extensive flooding of LSAs, play the animation in the figure. In the animation, R2 sends out an LSA. This event triggers every other router to also send out an LSA. Not shown in the animation are the required acknowledgments sent for every LSA received. If every router in a multiaccess network had to flood and acknowledge all received LSAs to all other routers on that same multiaccess network, the network traffic would become quite chaotic.
The solution to managing the number of adjacencies and the flooding of LSAs on a multiaccess network is the DR. On multiaccess networks, OSPF elects a DR to be the collection and distribution point for LSAs sent and received. A BDR is also elected in case the DR fails. All other routers become DROTHERs. A DROTHER is a router that is neither the DR nor the BDR.
Note: The DR is only used for the dissemination of LSAs. The router will still use the best next-hop router indicated in the routing table for the forwarding of all other packets.
Play the animation in the figure to see the role of the DR.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.