OSPF sends different kinds of messages to communicate with each other in order to exchange LSDB. Open Shortest Path First (OSPF) requires only a few relatively simple commands to send OSPF LSA in a small- to medium-sized internetwork. However, behind those commands, there is a fairly complex routing protocol, with internals that can be sort of intimidating for those who are new to OSPF.
This article discusses different OSPF messages that are needed in order to build neighbors list. We will also talk about usage of DR and BDR and how default route works in OSPF.
If you think back to what you have already learned about OSPFv2 (An introduction to OSPF) in the earlier posts, you probably remember that the big ideas follow a logical sequence. The dotted lines on the left side of the figure below show the step-by-step application of commands (on the right side) that are needed to review the current configuration of a Cisco device.
Take a moment to fully understand the steps in the above figure. Start with the configuration, which enables OSPFv2 on some interfaces by using network commands. As a result, the router sends and receives OSPF Hellos on those interfaces, hoping to discover OSPF neighbors.
Once a potential neighbor is discovered, the neighbors check each others’ parameters, and if they pass, the neighbors flood their known LSAs to each other, completing their link-state databases (LSDB). Finally, the router’s shortest path first (SPF) algorithm calculates the best route to each subnet, putting those routes into the IPv4 routing table.
How OSPF discovers Neighbors and Exchanges LSDB
When a point-to-point link is down, OSPF cannot have any neighbors over that link. When the link comes up, the routers on the end of the links go through a couple of interim neighbor states while working through important steps, such as discovering the existence of the neighbor, checking parameters to see whether they are allowed to become neighbors, and exchanging their LSAs in a process known as Database Exchange.
Following the steps in the figure, the scenario begins with the link down, so the routers have no knowledge of each other as OSPF neighbors. As a result, they have no state (status) information about each other as neighbors. At Step 2, R1 sends the first Hello, so R2 learns about the existence of R1 as an OSPF router. At this point, R2 lists R1 as a neighbor, with an interim state of Init.
The process continues with step 3, when R2 sends back a Hello. This message tells R1 that R2 exists, and it allows R1 to move to a 2-way state. At Step 4, R2 receives the next Hello from R1, and R2 can also move to a 2-way state.
When a router receives a Hello from a potential neighbor, and that potential neighbor’s parameters match with the local router’s parameters, the local router believes it has seen a new legitimate neighbor on the link. Through these early steps, each router reaches a 2-way state with their neighbor. Now, the following two major things has already happened:
- The router received a Hello from the neighbor, with that router’s own RID listed as being seen by the neighbor.
- The router has checked all the parameters in the Hello message coming from the neighbor, without any problem. The router is now ready to become a neighbor.
Fully Exchanging OSPF LSAs with Neighbors
The OSPF neighbor state 2-way means that the router is available to exchange its LSDB with the neighbor. So, once two routers on a point-to-point link reach the 2-way state, they can immediately move on to the process of database exchange.
The database exchange process can be involved with several OSPF messages and several interim neighbor states. This section is more concerned with a few of the messages and the final state when database exchange has been completed.
After two routers decide to exchange databases, they do not simply send the contents of the entire database. First, they tell each other a list of Link State Advertisements (LSAs) in their respective databases; not all the details of the LSAs, just a list. Then, each router can check which LSAs it already has, and then ask the other router for only the LSAs that are not known yet.
For instance, R1 might send R2 a checklist that lists 10 LSAs (using an OSPF Database Description, or DD, packet). R2 then checks its LSDB and finds 6 of those 10 LSAs. So, R2 asks R1 using a Link-State Request packet (LSR) to send the four additional LSAs. In particular, the OSPF messages that actually send the LSAs between neighbors are called a Link-State Update (LSU) packet.
Figure below shows some of these terms and processes together, with an example.
The center shows the protocol messages, and the outer items show the neighbor states at different points in the process. Focus on two items in particular:
- The routers exchange the LSAs inside LSU packets.
- When finished, the routers reach a full state, meaning they have fully exchanged the contents of their LSDBs.
Maintaining Neighbors and the LSDB
Once neighbors reach a full state, they have done all the initial work to exchange OSPF information between the two neighbors. However, neighbors still have to do some small ongoing tasks to maintain the neighbor relationship.
First, routers monitor each neighbor relationship using Hello messages and two related timers. The Hello Interval and the Dead Interval. Routers send Hellos every Hello Interval to each neighbor. Each router expects to receive a Hello from each neighbor based on the Hello Interval, so if a neighbor is silent for the length of the Dead Interval (by default 4 times as long as the Hello Interval), the loss of Hellos means that the neighbor has failed.
Next, routers must react when the topology changes as well, and neighbors play a key role in that process. When something changes, one or more LSAs will change. Then the routers must flood the changed LSAs to each neighbor so that the neighbor can change its LSDB.
A third maintenance task done by neighbors is to re-flood each LSA occasionally, even when the network is completely stable. By default, each router that creates an LSA also has the responsibility to re-flood the LSA every 30 minutes, even if no changes occur. Note that each LSA has a separate timer, based on when the LSA was created, so it’s practically not possible that all routers in the network can overload the link by flooding simultaneous LSAs.
The following list summarizes these three maintenance tasks for easier review:
- Maintain neighbor state by sending Hello messages based on the Hello Interval, and listening for Hellos before the Dead Interval expires.
- Flood any changed LSAs to each neighbor.
- Re-flood unchanged LSAs as their lifetime expires (default 30 minutes).
Using Designated Routers on Ethernet Links
OSPF behaves differently on some interfaces, particularly comparing point-to-point and Ethernet links. In particular, on Ethernet links, OSPF selects one of the routers on the same subnet to act as the designated router (DR). The DR plays a key role in how the database exchange happens which is different with rules of a point-to-point link.
Router with the highest priority (number between 1 to 255) in the same subnet would be selected as a DR. By default the priority number is set to 1 on all routers but it is configurable. If there’s a tie between routers with equal priority, the router with the highest RID will be selected as a DR and the second highest RID would be the BDR.
The process of database exchange on an Ethernet link does not happen between every pair of routers on the same VLAN/subnet.
Instead, it happens between the DR and other routers, so that DR makes sure that all the other routers get a copy of the same LSA. In other words, the database exchange happens according to the figure on the left.
OSPF uses the BDR concept because the DR is so important for database exchange. The BDR watches the status of the DR and takes over the job of the DR fails. In a case like this, a new BDR is elected.
Because the DR and BDR both do full database exchange with all the other OSPF routers in the LAN, they reach a full state with all neighbors. However, routers that are neither a DR nor a BDR called DROthers by OSPF. These routers never reach a full state because they do not exchange database with each other. DROther routers list some neighbors permanently in a 2-way state. They never go into a full state.
OSPF Default Routes
The final section of this article looks at a different strategy for using default IP routes. Here, an OSPF router creates a default route and also advertises it so that other routers learn default routes dynamically.
The main purpose of using a routing protocol to advertise a default route has to do with when an enterprise network has connection to the Internet. As a strategy, a network engineer in an enterprise company uses these design goals:
- All routers learn specific routes for subnets inside the company; a default route is not needed when forwarding packets to these destinations.
- One router connects to the Internet, and it has a default route that points toward the Internet.
- All routers should dynamically learn a default route which is used as a gateway for sending the traffic to the Internet. Now, all Internet traffic must be forwarded towards this route.
On the far left, the three branch routers all have OSPF-learned default routes, pointing to R1. R1 itself also needs a default route, pointing to the ISP router, so that R1 can forward all Internet-bound traffic to the ISP.