Becoming neighbors, sharing of databases, and of message types.
Why are neighbor states necessary?
Every node running an OSPF process must maintain some level of state, as well as exchange that state with its neighbors. In order to properly exchange state, nodes must transition through a set of neighbor states in order to validate one another’s configuration and the sequence in which to share messages.
OSPF Message Types
To understand the different neighbor states, it’s important to first understand the OSPF message types. There are 5 different message types:
Hello A type 1 packet. Used as a keepalive message and for dynamic discovery of other nodes via the multicast destination 224.0.0.5 (All OSPF Routers destination). There are 3 fields within the hello packet that must be agreed upon by all neighbors: Dead Interval, Network Mask, and Hello Interval.
An example hello packet. Note that the sending node has both 10.99.0.12 and 10.99.0.13 listed in the ‘Active Neighbor’ fields. This means the sending node has seen hello messages from both of these nodes. This allows a node to confirm that bidirectional connectivity is functioning. If a node sees its router-id in the hello message from another node, it can safely assume that its own hello messages are being received.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | |
Database Description, or DBD A type 2 packet. Sent during initial stages of an adjacency. These packets contain LSA headers, which are used to describe the contents of a node’s OSPF database, or LSDB.
Link State Request A type 3 packet. This message is used by nodes to request certain portions of another node’s database.
Link State Update A type 4 packet. Used to message the full detail of LSAs. Sent via unicast or to the All OSPF routers address, 224.0.0.5.
Link State Acknowledgement A type 5 packet. Used to acknowledge the receipt of a LSU. Sent via unicast, to a the All OSPF routers address, or to the All DR Routers address.
Would you be my neighbor?
All adjacencies of an OSPF process exist in a neighbor state. Some neighbor states are transient and some are indefinite.
Down. This state is typical of when a peer is manually configured, but is not responding to hello attempts. Also seen in instances in which a dead timer has expired.
Attempt. The initial state of a manually configured neighbor. In this state, the OSPF process is attempting to form an adjacency with the neighbor through unicast hello messages (keep in mind that OSPF uses the multicast address of 224.0.0.5 for sending and receiving hellos). . If the adjacency fails to establish within the dead interval timer, the neighbor transitions to down.
Init. If a hello packet has been seen from a neighbor, but the local router’s ID is not seen in the hello packet. Essentially, this state means that a valid hello packet has been seen, but bidirectional communication has not been confirmed.
2-Way. A valid hello packet has been seen from a neighbor, and the local router’s ID is seen in the hello packet’s Active Neighbor field. Note that two nodes on a multiaccess segment that are neither DR or BDR will not progress past this state with one another.
ExStart. This state begins the exchange of Database Description messages (DBD). Neighbors that intend to become fully adjacent will use this state to exchange DBD messages.
Master/Slave. The ExStart state precedes the actual exchange of routing information. In order to synchronize this information across two neighbors, it’s necessary for both to agree upon sequencing and the order in which both will communicate their databases. This is determined by the master/slave election.
The neighbor with the numerically highest router ID will be elected as the master and will set the MS (Master/Slave) bit in all DBD messages sent to the slave. Router IDs are set in the OSPF header of every packet, and are compared during this state. A neighbor that considers itself the master of an adjacency will first transmit an empty DBD message indicating interface MTU, with the following bits set:
- I-bit, or init bit: Indicates that this is the first packet sent in the DBD exchange.
- M-bit, or more bit: Indicates that more DBD messages will follow.
- MS-bit, or master/slave bit: When set, this bit indicates that the sender believes itself to be the master in the exchange. When not set, indicates that the sender believes itself to be the slave.
Example of a DBD message with the I, M, and MS bits set - this would be the first packet sent:
1 2 3 4 5 6 7 8 9 10 11 | |
Exchange. Master/slave relationship has been agreed upon, and sequencing has been determined. This state marks the beginning of the actual exchange of routing information, or Link State Adjacencies (LSAs). DBD messages populated with LSA headers are exchanged – this header contains just enough information to uniquely identify the LSA. This information is comprised of the LS Type, Link State ID, and Advertising router. All DBD messages must be acknowledged, and only a single DBD message may be outstanding at a time. In this state, the OSPF neighbors can being sending link state requests to one another.
Loading. Link state request messages are being sent between peers, and all LSAs have been advertised. In this state, neighbors will attempt to request all LSAs and fully synchronize local link-state databases. Link state requests are sent, and responded to with link state updates. A link state request is a request message for a specific LSA.
An example of a link state request packet. Here the request indicates the LSA desired with the LS type, Link State ID, and Advertising router fields.
1 2 3 4 5 6 7 8 9 | |
An example of a link state update:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | |
Help, I'm Stuck and Cannot Get to Full!
Sometimes adjacencies will not progress to full. This can be due to neither nodes being DR or BDR on a multiaccess segment (at which point they will both remain in 2-Way), or due to a misconfiguration.
MTU Mismatch Remember that the IP MTU is communicated between OSPF nodes in DBD packets. Here we have a node sending a DBD packet with a MTU of 1500, the ubiquitous MTU for Ethernet segments:
1 2 3 4 5 6 7 8 9 10 11 | |
In the case that two nodes do not utilize the same IP MTU, the adjacency state will not progress past EXSTART.
Example of two nodes with differing IP MTUs attempting to form an adjacency (IOS):
1 2 | |
And the following debug message will be present:
1
| |
The fix is to either ensure both sides use the same IP MTU, or to configure “ip ospf mtu-ignore” on the interface involved.
Warning: “ip ospf mtu-ignore” is essentially a band-aid and can cause issues with flooding of LSAs between nodes. Keep IP MTUs consistent wherever possible.
Authentication Clearly, OSPF adjacencies will fail to progress to full when authentication fails between nodes. In the case of authentication failures, no state will be reached by nodes, and the following log messages may be seen:
1
| |
Or in the case that only one side is configured for authentication, the mismatch will occur on the authentication used:
1
| |
The fix is to ensure all nodes using authentication are using the same type (plain-text or MD5) and have the same password string configured.
Duplicate Router IDs Pretty straightforward. If two nodes share the same router-id, they will not form an adjacency:
1
| |
Mismatched Areas Staightforward again. If nodes attempt to become adjacent over a subnet but do not agree on the area of the subnet, they will not become adjacent:
1
| |
Mismatched Timers Both nodes must agree on the hello and dead timers. If these differ, the adjacency will fail to even reach INIT. The following mesages will appear in the debug of OSPF hellos on IOS:
1 2 3 | |
More
OSPF is a sophisticated protocol - it takes on some daunting computer science challenges and all without the aid of things like TCP.
Beyond the adjacency state process lies Dijkstra’s algorithm and OSPF’s ability to have distributed nodes determine best path from the same (in most cases) database.