OSPF is a complex routing protocol with many enhanced performance and stability features. Therefore, OSPF uses a large amount of data structures. Each data structure or information type is used to execute a specific task. All data structures share a common header, which is called an OSPF header. The OSPF header is 24 bytes in length and includes the following fields:
• Version number-the first byte allocated with the OSPF header is used to identify the version number. The current version is 2, but an older router may still be running RFC1131 version 1. RFC1247, 1583, 2178, and 2328 both regulate backward compatibility of OSPF version 2. Therefore, no further identifier is required.
• Type-the second byte indicates which of the five OSPF Packet types is appended to the header structure. Five types (HELLO, database description, link-State request, link-State update, and link-State response) are digitally identified.
• Message length-the following two bytes in the OSPF header are used to notify the receiving node of the total length of the message. The total length of a packet includes data and header.
• Vroid ID-each vro in the zone is assigned a unique, 4-byte ID. Before sending any OSPF message to other routers, the OSPF router fills the domain with its own ID number.
• Area ID-4 bytes are used in the header to identify the area number.
• Checksum-each OSPF header contains a 2-byte checksum and domain to check for packet damages during transmission. The sender runs mathematical calculations on each message and then stores the results in this domain. The receiver runs the same algorithm on the received packets and compares the results with those stored in the verification and domain. If the packets arrive lossless, the two results should be the same; otherwise, the OSPF packets are damaged during transmission. The receiver simply discards the damaged packets.
• Authentication type-OSPF can authenticate the sender of OSPF information to prevent attacks such as false routing information. The two-byte authentication format used in the domain ID information.
• Authentication-the remaining nine bytes in the header carry the authentication data. The receiver uses this information to determine the sender of the information. OSPF allows network administrators to use various levels of authentication: From unauthenticated, to simple authentication, to the most powerful MD authentication, the basic structure contains the information required by the OSPF node to determine whether packets should be received and processed further,
One point) and unauthenticated packets will be discarded. OSPF uses five different packet types. Each type is used to support different, dedicated network functions. The five types are:
• HELLO Message (type 1 ).
• Database description packet (Type 2 ).
• Link-Status Request Message (Type 3 ).
• Link-status update packet (Type 4 ).
• Link-status response packet (type 5 ). These five types of packets are sometimes indicated by numbers rather than names. Therefore, OSPF 5 packets actually refer to link-State response packets. All these packet types Use OSPF headers. Note that five basic OSPF data structures are represented by five pure numbers. The detailed discussion of these structures and sizes is beyond the scope of this chapter. On the contrary, this chapter only discusses the purpose and use of these data types.
1 HELLO Message
OSPF contains a protocol used to establish and maintain the relationship between adjacent sites (HELLO protocol ). These links are called connectivity. Connectivity is the basis for OSPF to exchange route data.
Through this protocol and packet type, OSPF nodes can find other OSPF nodes in the zone. Its name indicates its meaning. The HELLO protocol establishes communication between adjacent routers. The HELLO protocol uses a special sub-packet structure, which is appended to the standard 24-byte OSPF header. These structures constitute a HELLO message.
All routers in the OSPF network must comply with certain rules, which must be consistent throughout the network. These rules include:
• Network mask.
• HELLO message broadcast interval.
• The time when other routers in the network consider an unresponsive vro as dead nodes (the router dead interval ).
All routers in OSPF must use the same value for these parameters, otherwise the network may not work normally. These parameters are exchanged through HELLO packets. They form the basis for communication between adjacent nodes. They need to ensure that there is no adjacent relationship (connectivity) between vrouters of different networks, and all the members of the network need to reach a consensus on how long each other will be connected.
The HELLO message also contains a list of other routers that have recently been associated with it (using their own unique router ID ). This Neighbor domain makes the Neighbor discovery process possible. The HELLO message also contains several other domains, such as DesignatedRouter, BackupDesignatedRouter, and other domains. These domains are useful for maintaining connectivity and supporting the stable cycle and convergence of OSPF networks. The usefulness of DesignatedRouter and BackupDesignatedRouter will be described in later sections of this chapter.
2. Database description packets
When the two routers in OSPF initiate a connection, they need to exchange the database description (DD) packet. This packet type is used to describe, instead of actually transmitting the link-status database content of the OSPF router. Because the database content may be quite long, multiple database description reports may be required to describe the entire database. In fact, a domain is reserved to identify the database description packet sequence. The receiver sorts the packets so that they can copy the database description packets.
The DD exchange process is performed in the query/response mode. In this process, a vro acts as the primary router. The other vro acts as the slave router, and the master router sends its route table content to the slave router. Obviously, the relationship between the master and slave nodes varies with each DD exchange. All vrouters in the network work at different time points. In this process, they may be both master and slave.
3. Link-Status Request Message
The third type of OSPF packets is link-State request packets. This packet is used to request part of data in the database of the adjacent router link-status. On the surface, after receiving a DD update packet, the OSPF router can find that the adjacent information is neither updated nor completely updated. In this case, the router sends one or more link-State request packets to its neighbors (routers with updated information) to obtain more link state information.
The request information must be very specific. It must use the following standard specification to specify the required data:
• Link-status (LS) type number (1 to 5 ).
• Ls id.
• Advertise a vro.
These specifications indicate a specific OSPF database subset, rather than an example. An example is a subset of the same information. This subset has a temporary boundary (that is, a timestamp ). Remember, OSPF is a dynamic routing protocol that automatically responds to changes in the Link Status in the network. Therefore, the receiver of the LS request interprets the specific routing information as the latest data.
4. Link-status update packets
The link-status update packet is used to send the LSA to its adjacent nodes. These update packets are used to respond to LSA requests. There are 5 different types of LSA packets. These message types are identified by type numbers ranging from 1 to 5.
Note that OSPF generally regards link-State broadcast as LSA, which leads to potential confusion. However, in fact, the mechanism used to update a route table is link-State update packets-simplified to LSU. There is another message structure, the link-State response packet, abbreviated as LSA. For some unknown reasons, this packet is called Link-State response, while LSA usually refers to update packets.
The packet types and their LSA numbers are described as follows:
• RauterLSA (router LSA) (type 1)-router LSA describes the status and consumption of the router link to the zone. All such links must be described in an LSA message. At the same time, the router must generate a router LSA for each zone of the router. Therefore, a VBR generates multiple vrollsa, and only one such update is required for the vro In the VBR.
• NetworkLSA (Network LSA) (Type 2)-The network LSA is similar to the router LSA, which describes the link status and consumption information of all the routers connected to the network. The difference between the two is that the network LSA is the sum of all link-state and consumption information in the network. Only the specified vro of the network records this information and generates the network LSA.
• SummaryLSA-IPNetwork (Summary LSA-IP Network) (Type 3)-the name using the summary LSA-IP is somewhat inflexible, so OSPF designers use a numbering policy to record LSA! This type of LSA can be generated only by the vbr in the ospf network. This LSA type is used to exchange the summarized routing information of a zone with the router information of the neighboring zone in the ospf network. It often summarizes the default route rather than spreading the summarized OSPF information to other networks.
• SummaryLSA-AutonomousSystemBoundaryRouter (Summary LSA-Autonomous System border router) (Type 4)-type 4 is closely related to type 3LSA. The difference between the two is that type 3 describes routes in the region, and type 4 describes routes outside the OSPF network.
• AS-External LSA (type 5)-5th LSA is the external LSA of the autonomous system. Like its name, this LSA is used to describe the destination outside the OSPF network. These destinations can be specific hosts or external network addresses. As an ASBROSPF node associated with the external autonomous system, it is responsible for transmitting the external routing information in the entire zone it belongs.
These LSA types are used to describe different aspects of the OSPF routing domain. They are directly routed to each vro in the ospf area and transmitted simultaneously. This flooding ensures that all routers in the OSPF area have the same information about the five different aspects of the network (LSA type. The complete LSA data of the router is stored in the Link-status database. When the Dijkstra algorithm is applied to the content of these databases, the OSPF route table is obtained. The difference between a table and a database is that the database contains a complete set of raw data, and the route table contains a list of shortest paths from a specific router interface to a known destination.
You don't have to study the structure of each LSA type, just research their header is enough.
1. LSA Header
All LSAs use a common Header Format. This header is 20 bytes long and attached to the standard 24-byte OSPF header. The LSA header uniquely identifies each type of LSA. Therefore, it includes information about the LSA type, link-status ID, and advertised router ID. The following is the LSA header domain:
• LS age-the first two bytes in the LSA header contain the LSA age. This age is the time in seconds that have elapsed since the generation of LSA.
• OSPF option-the following bytes are composed of a series of labels that identify various optional services available in the OSPF network.
• LS-1-byte LS indicates one of the five LSA types. The format of each LSA type is different. Therefore, it is essential to indicate the type of data appended to the header.
• The Four-byte length of link-state ID-link-state ID field indicates the specific network environment area described by LSA. This domain is closely related to the previously mentioned LS type domain. In fact, the content of this field is directly dependent on the LS type. For example, in the router LSA, the link-status ID contains the OSPF router ID that generates the packet-the ID of the advertised router.
• LS sequence number-the OSPF router increments the serial number of each LSA packet. Therefore, the routers that receive two identical LSA instances have two options to determine which one is the latest packet, and the LS sequence number domain is 4 bytes long. Check this domain to determine how long the LSA has been transmitted over the network. Theoretically, a new LSA may be older than an old LSA, especially in a large and complex OSPF network. Therefore, the receiving router compares the LS sequence number. The large LSA is newly generated. This mechanism will not be damaged due to the change of dynamic routing, but should be considered as a more reliable method to determine the LSA time.
• LS checksum-the 3-byte LS checksum is used to check whether the LSA is damaged during transmission to the destination. The Checksum uses a simple mathematical algorithm. Its output results depend on its input and are highly consistent. Given the same input, the checksum algorithm always gives the same output. LS verification and domain use part of the LSA packet content (including the header, excluding the ls age and verification and domain) to generate verification and value. The source node runs the Fletcher algorithm and stores the results in LS verification and domain. The target node executes the same algorithm and compares the result with the result stored in the verification and domain. If the two values are different, the packet is damaged during transmission. Then, a transmission request is generated.
• LS length-the LS length field is used to notify the recipient of the LSA length (in bytes). This field is 1 byte long.
The rest of the LSA style contains a list of LSA. Each LSA describes one of five different aspects of the OSPF network. Therefore, the router LSA packet will broadcast the router information that is known in the zone.
2. Process LSA updates
The essential difference between an OSPF route table and other route tables is that its update is not directly used by the receiving site. The updates received from other routers include the information obtained from the "from the perspective of the sending router" network. Therefore, before using and interpreting the received LSA data, the Dijkstra algorithm must convert it into its own information.
On the surface, LSA transmission is performed because a router detects link status changes. Therefore, after receiving any type of LSA, the OSPF router must compare the content of the LSA with the corresponding part of its route table. The comparison can only be performed after the SPF algorithm uses new data to form a new network view. The SPF algorithm outputs a new view of the network. These results compare with the existing OSPF route table to see if its route is affected by the change in the network status.
If one or more routes must be changed due to state changes, a new route table must be created using new information.
3. Copy LSA
Considering that the LSA is extensive throughout the OSPF area, multiple instances of the same LSA type may exist at the same time. Therefore, the stability of the OSPF network requires that the router be able to identify the newest among multiple LSAs. When two or more routers of the same lsa type are received, the LS age, LS sequence number, and LS verification and domain in the LSA header are checked. Only information contained in the latest LSA is accepted and must be processed as described in the previous section.
4. Link-status Response Message
5th OSPF packets are link-State response packets. OSPF is characterized by the reliable distribution of LSA packets (LSA indicates the link-state announcement (advertisement), rather than the link-State response). Reliability means that the notification receiver must respond. Otherwise, the source node cannot know whether the LSA has reached the destination. Therefore, some mechanisms are required to respond to the LSA. This mechanism is a link-status Response Message.
The link-status response packet uniquely identifies the LSA packet to be responded. The ID is based on the information contained in the LSA header, including the LS sequence number and the advertised router. No 1-to-1 correspondence is required between the LSA and the Response Message. Multiple LSAs can use one message to respond.
5. Computing route
Although OSPF is complex, it uses one of the following two simple methods to calculate route consumption:
• Non-bandwidth-sensitive default values can be used for each OSPF interface.
• OSPF can automatically calculate the consumption of each routing interface.
Regardless of the method used, the consumption of any route can be calculated by adding the consumption of each router interface on the route. The shortest path tree of OSPF records the sum of consumption of each known destination.