Packet types for OSPF

OSPF sends packets to neighbors to establish and maintain adjacencies, send and receive requests, ensure reliable delivery of Link-state advertisements (LSAs) between neighbors, and to describe link-state databases. Link-state databases are generated from all the LSAs that an area router sends and receives. The link-state database is then used to calculate the shortest-path spanning tree, using the Shortest Path First (SPF) algorithm.

The following packet types are supported for i5/OS in an OSPF environment

Hello packet

This packet is sent by the OMPROUTED server to discover OSPF neighbor routers and to establish bidirectional communications with them.

When several systems or routers that run OSPF have interfaces attached to a common network, the Hello protocol determines the designated router (DR). The DR is adjacent to all routers on the network, and its role is to generate and flood the LSAs, on behalf of the network. In a broadcast network, such as Ethernet, having a DR reduces the amount of router protocol traffic that is generated.

The DR is also responsible for maintaining the network topology database that is replicated at all other routers that are within the same OSPF area on the network.

The concept of a DR does not exist for point-to-point connections.

Database description packet

Once the Hello packets are exchanged and two-way communications are established, the i5/OS and other area routers are neighbors. At this point the OMPROUTED server knows with which neighbors it must establish adjacencies and then starts forming OSPF adjacencies. Bringing up an adjacency is the important OSPF protocol function of synchronizing databases between routers. The database description packets are sent using the exchange database protocol. The exchange database protocol exchanges a description of the link-state databases between adjacent partners, using the database description packet.

Link-state update packet

Until the OMPROUTED databases are fully synchronized, they request and exchange more information from adjacent routers using link-state request and link-state updates packets.

The router or i5/OS whose router identifier is numerically higher, assumes the primary role and the other assumes the secondary role. The primary router sends its database descriptions, one at a time. The secondary router acknowledges each one and includes in the acknowledgement its own database descriptions. The records are compared according to the type, advertising router, and link-state ID. A sequence number in the record determines whether the record is newer or older. If the new description indicates that this record is newer than the recipient already has in its database, this description is saved.

Link-state request packet

After all descriptions are received, the neighbors send out database requests for more complete information about the records that were requested. These requests are followed with a flooding of Link-state updates containing the requested information. Each link-state update packet is acknowledged, either explicitly with a link-state acknowledgment packet or implicitly in the link-state packets. The routers are fully adjacent when the link-state databases are fully synchronized.

OSPF adjacency states are Down, Init, Attempt, 2-way, Exstart, Exchange, Loading, and Full. On i5/OS, 2-way is represented by *WAY2 and means that the router is fully adjacent only with the DR or the backup designated router (BDR). When the adjacency state is *FULL, this means that many neighbor states might be *WAY2 and therefore an individual router might know about a neighbor but not be fully adjacent with it.

If the database synchronization process is too long, consider setting the database exchange timeout value higher than the default value that is specified by the inactive router interval. Set the database exchange timeout value when adding or changing an interface with the ADDOSPFIFC or CHGOSPFIFC command. If the database exchange timeout is set higher than the default time, the following occurs:
  • The database synchronization fails due to insufficient time.
  • The neighbor process never stabilizes beyond neighbor State of *WAY2.

Link-state acknowledgment packet

Each newly received LSA must be acknowledged by its recipient to verify its delivery. This is done by sending a link-state acknowledgment packet, which contains one or more acknowledgements. An acknowledgment packet is either sent immediately or delayed, based on a specified time interval.

To display the status of adjacencies, specify IPv4 or IPv6 on the Display OSPF (DSPOSPF) command, and display the state of the OSPF neighbors by setting the STATE parameter: