Open Shortest Path First, in all its glory is a Link State routing protocol that does not only update routing tables with the “lower cost route” or best path to a destination or many, but maintains a full topological database among other features.
OSPF Uses the SPF (Shortest Path First) algorithm developed by Dijkstra and some of its features are that it:
- Maintains 3 tables (neighbour, topology and routing).
- Divides networks into multiple areas, and supports summarization to reduce bandwidth and processor utilization.
- All areas must connect to area 0, unless a Virtual Link is implemented.
- Supports authentication (in plain text or using M55 hashes).
- An efficient OSPF domain requires an IP addressing hierarchical design.
- Uses triggered updates generated by changes in the topology and Link State periodic updates on long intervals (usually every 30 minutes).
But for all of this to happen, OSPF routers must establish a neighbour relationship (except the authentication which takes place during the process of forming the adjacency) with all the other OSPF routers that belong to the same network segment. The process usually takes a few seconds in broadcast shared networks (Ethernet) or Point to Point networks, and a little bit longer on Non Broadcast Multi-access Networks (Frame Relay). However the process is complex and is essential to know the phases and steps that it goes through in order to accurately troubleshoot any issues that might take place when using this protocol.
1. Determine the Router ID
This is the identifier or “name” that the router will have in the OSPF process; there are three ways to determine this parameter:
- Manually configured ID (using the router-id command under the OSPF process).
- Highest loopback interface configured on the router.
- Highest ip address configured on an “UP” interface.
A manually configured ID is preferred or “beats” the highest loopback or ip address configured on the router during the election, and a loopback is preferred over an ip. It is recommended that you manually set up the ID on your routers. There are several advanced configurations (like the
Virtual Links) that require you to manually enter a neighbor’s router ID. Once the router ID is chosen another election will take place only if the OSPF process is cleared using the clear ip ospf process command from privileged mode, or if the router gets reloaded.
Cisco routers do not reboot very often during production, imagine what could happen if you are running an advanced configuration that depends on one of your neighbor’s ID and it is the highest loopback or ip; you then create a higher loopback for testing purposes on that neighbor and accidentally leave it on your router, once the router gets reloaded or the process cleared the new higher loopback will be elected and your configuration will make no sense at all. This is why Cisco recommends manually configured ID’s. You can view the ID using the show ip protocols command or the show ip ospf <process ID> both from privileged mode.
2. Add interfaces to the Link State Database
Once the Router ID has been defined it is time for OSPF to know which networks will be advertised in the OSPF process and on which interfaces will OSPF be running. This is defined via the network (A.B.C.D + wildcard bits + area) command under the OSPF process (configrouter).
These configurations will be reflected in the show ip protocols command.
3. Send Hello messages on predefined interfaces
Hello messages are the packets that build up and maintain the neighbor relationship; these are periodically sent every 10 seconds on broadcast and Point to Point networks, and every 30 seconds on Non Broadcast Multi-access Networks. After a period of time without receiving hellos on an interface a router takes down the neighbor relationship, this is known as a dead timer and is by default 4 times the hello timer (how often the router sends a hello message).
These timers must match on the routers that are attempting to establish a relationship, are manually configurable (but it is not recommended to do so) and can be viewed by using the show ip ospf interface command.
A router sends these packets on the interfaces that have assigned the addresses that where entered in the OSPF process using the network command. Once a router sends this packet for the very first time it reaches a “down state” that means the local router is waiting to hear back from the router that is to become a neighbor.
4. Receive Hello message
There are several values that must match between 2 routers for them to become neighbors, here is the list:
- Area ID
- Subnet Mask
- Hello and dead timers
- Authentication password
The receive hello stage is where all these parameters are checked, and the routers ensure that their future neighbor matches with the local values, and then reaches the init state; you can view the output of these process by issuing the debug ip ospf adj or debug ip ospf events commands.
All of these parameters are manually configurable. If you issue any of the previous debug commands or the show ip ospf neighbor command and you see a relationship bouncing between down state and init state it is because some of these values do not match between your routers, and the relationship will never reach a full state (final stage of the process).
5. Send reply Hello
Routers send hello packets constantly to their neighbors, whenever a hello message is received on a router’s interface after it has reached the init state the router must answer itself a question. Is the router I am receiving this hello message from already my neighbor?
· If it is, then the router just resets its local dead timer and continues with its full neighbor relationship.
· If not the router will reach the 2-way state for this future neighbor and will continue in the process of adding this router as a neighbor.
6. Determine Master-Slave status in the relationship
This stage is to determine basically who sends information first, and sets the routers in an exstart state, the information that the routers will be sending is known as a Database Description (DBD) and it’s a small update or summary that includes the networks that are to be advertised in the OSPF process and some information of the router that is sending it.
Each router sends its DBD and looks at the other router’s or routers’ parameter called priority (which is by default 1). The router with the highest priority value will be elected as a MASTER and if there is a tie of priority values the highest router ID wins the election. The priority is a per interface value. You can view this event in real time by issuing the debug ip ospf adj command.
The priority is a manually configurable command, and it can be tuned by using the ip ospf priority command under the desired interface (must be the one connected to the other OSPF running router), highest configurable priority is 255.
7. Database Descriptions acknowledged and reviewed
Once the MASTER and SLAVE statuses are assigned the slave sends the first packet, which is a Link State Request that the MASTER responds with a Link State Update (packet that contains one or many of the 11-type Link State Advertisements). Then the MASTER sends a LSR to the SLAVE that will respond with another LSU. This is known as the loading state or on newer IOS versions exchange state and the routers are basically exchanging all the routing information like remote networks and best way to get to them, within an area (LSAs type 1 and 2) , multiple areas (LSAs type 3) or even another routing protocol domain (redistribution, LSAs type 5).
No need to worry if you issue the show ip ospf neighbor command and you see the relationship in the loading state for a while (usually longer periods on Non Broadcast Multi-access networks), the routers are just exchanging their information and you can confirm that by using the debug ip ospf adj command.
8. Neighbors are synchronized
After the loading or exchange stage is completed the routers reach the full state and neighbor relationship is finally completed, routers are fully synchronized. Behold the output of the entire process courtesy of the debug ip ospf adj command.
POSSIBLE NEIGHBOUR STATES:
Down
This is the initial state of a neighbor conversation. It indicates that there has been no recent information received from the neighbor. On non-broadcast networks, Hello packets may still be sent to "Down" neighbors, although at a reduced frequency (see Section 9.5.1).
Attempt
This state is only valid for neighbors attached to non- broadcast networks. It indicates that no recent information has been received from the neighbor, but that a more concerted effort should be made to contact the neighbor. This is done by sending the neighbor Hello packets at intervals of HelloInterval (see Section 9.5.1).
Init
In this state, an Hello packet has recently been seen from the neighbor. However, bidirectional communication has not yet been established with the neighbor (i.e., the router itself did not appear in the neighbor's Hello packet). All neighbors in this state (or higher) are listed in the Hello packets sent from the associated interface.
2-Way
In this state, communication between the two routers is bidirectional. This has been assured by the operation of the Hello Protocol. This is the most advanced state short of beginning adjacency establishment. The (Backup) Designated Router is selected from the set of neighbors in state 2-Way or greater.
ExStart
This is the first step in creating an adjacency between the two neighboring routers. The goal of this step is to decide which router is the master, and to decide upon the initial DD sequence number. Neighbor conversations in this state or greater are called adjacencies.
Exchange
In this state the router is describing its entire link state database by sending Database Description packets to the neighbor. Each Database Description Packet has a DD sequence number, and is explicitly acknowledged. Only one Database Description Packet is allowed outstanding at any one time. In this state, Link State Request Packets may also be sent asking for the neighbor's more recent advertisements. All adjacencies in Exchange state or greater are used by the flooding procedure. In fact, these adjacencies are fully capable of transmitting and receiving all types of OSPF routing protocol packets.
Loading
In this state, Link State Request packets are sent to the neighbor asking for the more recent advertisements that have been discovered (but not yet received) in the Exchange state.
Full
In this state, the neighboring routers are fully adjacent. These adjacencies will now appear in router links and network links advertisements.
