Shulou(Shulou.com)06/01 Report--

To understand the working principle of OSPF routing protocol, especially the routing update mechanism, we must first have a comprehensive understanding of its various message formats. There are mainly five kinds of OSPF messages: Hello message, DD (Database Description) message, LSR (LinkState Request) message, LSU (LinkState Update) message and LSAck (LinkState Acknowledgment) message. They play different roles in OSPF routing updates, and there are also great differences in message formats.

9.2 OSPF header and various message formats

OSPF messages are directly encapsulated into IP protocol messages, because OSPF is a routing protocol specially designed for TCP/IP networks. The five OSPF messages mentioned above use the same OSPF header format, as shown in figure 9-9.

Figure 9-9 OSPF protocol header format

L Version

The version field, which occupies 1 byte, indicates the OSPF protocol version number used. Currently, the highest version is OSPF v4, that is, the value is 4 (corresponding to 0100 in binary).

L PacketType

The message type field identifies the type of the corresponding message. As mentioned earlier, there are five kinds of messages in OSPF, namely: Hello message, DD message, LSR message, LSU message and LSAck message. The details will be described in the following sections.

L PacketLength: packet length field, accounting for 2 bytes. It refers to the byte length of the entire message, including the OSPF header part and the subsequent message content part.

L RouterID: router ID field, which occupies 4 bytes, and specifies the source router ID that sends the message.

L AreaID: the area ID field, which occupies 4 bytes, specifies the OSPF area number corresponding to the router that sent the message.

L Checksum: the checksum field, which occupies 2 bytes, is the checksum of the entire message (including the OSPF header and the specific contents of each message, but not the Authentication field below). It is used by the peer router to verify the integrity and correctness of the message.

L AuType: authentication type field, accounting for 2 bytes, which specifies the authentication type to be used. 0 is not authenticated, 1 is simple authentication, and 2 is MD5 authentication.

Authentication: authentication field, accounting for 8 bytes. The specific value varies according to different authentication types: when the authentication type is unauthenticated, there is no data in this field. When the authentication type is simple authentication, this field is the authentication password, and when the authentication type is MD5 authentication, this field is a MD5 summary message.

9.2.1 OSPF Hello message and format

The OSPF protocol uses a message called Hello to establish and maintain links between neighboring routers. This message is very simple, small in size, and is only used to prove its existence to neighboring routers, just like a greeting between people. We already know in Chapter 8 that the adjacency establishment between RIP neighbor routers is carried out by periodic routing update messages, through periodic routing updates to prove their existence to neighboring RIP routers at the same time. Obviously, this kind of Hello message of OSPF is simpler and can greatly reduce the traffic of message transmission in the network.

The Hello message is sent periodically (the default is 10 seconds) to the neighboring router interface. If the Hello message from the other OSPF router is not received within the set time (the default is 40 seconds, which is usually at least 4 times the Hello packet sending time indirectly), the local router will consider the other router invalid. The message includes some timer settings, DR, BDR, and neighbor routers known to this router. The whole Hello message format is shown in figure 9-10, the upper part is divided into the OSPF header part shown in figure 9-9, and the lower part is divided into the Hello message content part. The fields in the content part of the Hello message are described in Table 9-1.

Table 9-1 description of fields in the contents of Hello messages

Field name

Length

Function

Network Mask

4 byt

Subnet mask where the interface for sending Hello messages is located

HelloInterval

2 byt

Specifies the interval at which Hello messages are sent. The default is 10 seconds.

Options

1 byte

Optional, including E: allow flooding AS-external-LAS;MC: allow forwarding of IP group reply messages; Namp P: allow processing of Type 7 LSA; DC: allow processing of on-demand links

Rtr Pri

1 byte

Specifies the DR priority, which defaults to 1. If set to 0, this router will not participate in the DR/BDR election.

RouterDeadInterval

4 byt

Specifies the router failure time, which defaults to 40 seconds. If the Hello message from the neighbor router is not received within this time, the neighbor router is considered invalid.

Designated Router

4 byt

Specify the interface IP address of the DR

Backup Designated Router

4 byt

Specify the interface IP address of the BDR

Neighbor

4 byt

Specifies the RID of the neighbor router. The following ellipsis (… ) indicates that multiple neighbor routers RID can be specified

Figure 9-10 Hello message format

As can be seen from the above, the sending cycle of Hello messages can be configured on OSPF routers (equivalent to Hello message sending timers, which are configured based on interfaces), which will be described later in this chapter.

9.2.2 OSPF DD message and format

DD message is used to describe the link-state database (LSDB) of the local router. When two OSPF routers initialize the connection, they exchange DD messages and synchronize the database.

The content of the DD message includes the serial number of the DD message and the header of each LSA in the LSDB, as shown in figure 9-11, and the description of each field is shown in Table 9-2. The peer router can determine whether the DD already exists according to the OSPF header in the received LSA message. Because the content of the database may be quite long, multiple database description messages may be required to describe the entire database. Therefore, there are three bits specifically used to identify the sequence of messages described in the database, namely, the I, M and Mhand S bits in the DD message format. The receiver reorders the message so that it can actually copy the database description message.

The DD exchange process is carried out according to the query / reply mode. In the DD message exchange, one is the Master (master) role and the other is the Slave (slave) role. The Master router sends the contents of its routing table to the slave router and specifies the starting sequence number. Every time a DD message is sent, the sequence number plus 1m Slave uses the sequence number of Master to confirm the reply. But obviously, the relationship between master and slave varies according to the exchange of each DD. All routers in the network function at different times, and may be both master and slave routers in the process.

Figure 9-11 DD message format

Table 9-2 description of the fields in the DD message content section

Field name

Length

Function

Interface MTU

2 byt

Indicates the maximum length of DD messages that can be sent by the interface that sends IP messages without segmenting.

Options

1 byte

Optional, including E: allow flooding AS-external-LAS;MC: allow forwarding of IP group reply messages; Namp P: allow processing of Type 7 LSA; DC: allow processing of on-demand links

I

1 bit

Specifies that multiple DD messages are sent continuously. If it is the first DD message, it is set to 1, and the others are set to 0.

M

1 bit

Specifies that multiple DD messages are sent successively, and set 0 if it is the last DD message, otherwise all set 1

M/S

1 bit

Set the master-slave relationship between the two sides of the DD message. If the local end is a Master role, set 1, otherwise set 0

DD Sequence Number

4 byt

Specifies the serial number of the DD message sent. Both master and slave use serial numbers to ensure the reliability and integrity of DD message transmission.

LSA Header

4 byt

Specifies the LSA header included in the DD message. The following ellipsis (… ) indicates that multiple LSA headers can be specified

Because DD packets are exchanged by DD only when the two OSPF routers initiate a connection, it has no transmission cycle, and future data inventory synchronization is synchronized through LSR, LSU, and LSAck messages.

9.2.3 OSPF LSR message and format

LSR messages are used to request part of the data in the link-state database of neighboring routers. When the two routers exchange DD packets with each other, they know which LSA of the peer router is not available in this LSDB, and which LSA has failed, then they need to send a LSR message to request the required LSA from the other side.

The content of the LSR message includes the required LSA summary, the specific format is shown in figure 9-12, and the fields in the content part of the LSR message are described in Table 9-3.

Table 9-3 Field description of LSR message content

Field name

Length

Function

LS type

4 byt

Specify the type of LSA requested, which is divided into 7 categories. For more information, please see Section 9.2.5.

Link State ID

4 byt

Used to specify part of the area described by ospf. The use of this field varies depending on the type of LSA: when LSA 1, the value is the Router-ID of the router that generated LSA 1, when LSA 2, the value is the interface address of DR, when it is LSA 3, the value is the network address of the destination network, when it is LSA 4, the value is the Router-ID of ASBR, when it is LSA 5. The field value is the network address of the destination network

Advertising Router

4 byt

Specify the router ID that generates the LSA you want to request

Figure 9-12 LSR message format

9.2.4 OSPF LSU message and format

The LSU message is used to send the required LSA to the peer router at the request of the LSR message, and the content is a collection of the complete content of multiple LSA. The LSU message content part includes the total number of LSA sent this time and the complete content of each LSA, as shown in figure 9-13, and the three fields of the message content part are shown in Table 9-4.

Figure 9-13 LSU message format

See section 9.1.5 of this chapter for the types of LSA.

LSU packets flood the LSA over links that support multicast and multi-access, and retransmit the LSA that does not receive an acknowledgement reply (that is, the LSAck message that will be described below), but the LSA is sent directly to the neighbor router that does not receive the acknowledgment reply, rather than flooding.

Table 9-4 Field description of LSU message content

Field name

Length

Function

Number of LSA

4 byt

Specifies the total number of LSA sent in this message

LSAs

4 byt

Is a specific piece of complete LSA information, followed by an ellipsis indicating that there can be more than one LSA

9.2.5 OSPF LSAck message and format

The LSAck message is the acknowledgement reply message sent by the router after receiving the LSU message sent by the peer. The content is the LSA header (LSA Headers) that needs to be acknowledged. The format of the whole LSAck message is shown in figure 9-14. LSAck messages are sent in the form of unicast or multicast according to different links.

Figure 9-14 LSAck message format

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.