OSPF Neighbor Relationship and Neighbor Relationship

Source: Internet
Author: User

There are two kinds of connection relationships between routers in Ospf: the neighbor relationship and the adjacent relationship. This blog post will detail the establishment and working principles of these two relationships.

If two routers share a Public Data Link (there is no other router between the two routers, or there is a virtual connection between the two routers), and the parameters specified in the hello packet are successfully negotiated, then they become neighbors. If the two neighbors need to synchronize the LSDB, then they need to establish an adjacent relationship. If the two routers establish an adjacent relationship, their LSDB must be synchronized. LSA is transmitted only between vrouters with an adjacent relationship.

So how can we establish the relationship between the neighbor relationship and the adjacent relationship?The neighbor relationship is established through the hello message. The Hello message contains the following content:

1. router-id of the originating router

2. area-id of the originating router interface

3. Address Mask of the originating router interface

4. authentication type and authentication message of the originating router interface

5. hello-interval of the originating router interface

6. router dead-interval of the router interface

7. Router priority

8. Specify DR and BDR

9. 5 Flag spaces indicating the optional Performance

10. All valid neighbor router-IDs of the originating router (the originating router receives their hello packets)

Take the relationship between two routers as an example:

1. The neighbor field is blank when R1 sends a hello Message (multicast or unicast, depending on the link layer type ).

2. R2 receives the hello Message, establishes a neighbor data structure for R1, sets the neighbor status of R1 to init, and then sends the hello message to R1. The neighbor field contains the rougerID of R1, indicates that you have received the hello Message from R1.

3. After receiving the hello Message from R2, R1 establishes a neighbor data structure for R2, sets the neighbor status to 2way, and then sends the hello message to R2, the neighbor field of the packet contains the routerID of R2.

4. After receiving the hello Message from R1, R2 sets the neighbor status of R1 to 2way.

At this point, the neighbor relationship is established, and the neighboring routers send hello messages to keep them alive on time. If the hello Message times out, the router will invalidate the neighbor.

After the status of all routers reaches the 2way state, they will determine whether to elect DR and BDR based on the network type. If necessary, they will start to elect DR and BDR.

How can we determine whether an adjacent relationship needs to be established between neighboring routers?

1. If it is a point-to-point link, establish an adjacent relationship.

2. If it is a point-to-multipoint link, establish an adjacent relationship.

3. If the network type is virtual link, establish an adjacent relationship.

4. The local router is a DR on the network segment and an adjacent relationship needs to be established.

5. The local router is a BDR on the network segment and needs to establish an adjacent relationship.

6. The neighbor router is a DR on the network segment, and the adjacent relationship needs to be established.

7. The neighbor router is a BDR on the network segment and needs to establish an adjacent relationship

How can we establish an adjacent relationship?

In fact, LSDB is synchronized along with the process of establishing the adjacent relationship. The process is as follows:

The following three protocol packets are used to establish an adjacent relationship:

Hello Message type1, database description packet type2, Link Status Request Packet type3, link status update packet type4, link status validation packet type5

1. An interface of RT1 connected to the Broadcast Network activates the OSPF protocol and sends a HELLO packet (using the multicast address 224.0.0.5 ). The Neighbor field in the hello message is empty because RT1 has not found any neighbors in the CIDR block.

2. After RT2 receives the HELLO message sent by RT1, it creates a neighbor data structure for RT1 and sets the neighbor state machine of RT1 to Init. RT2 sends a HELLO message to respond to RT1, and fills in the Neighbor field in RT1's Router id, indicating that the HELLO message of RT1 has been received.

3. After RT1 receives the HELLO Message from RT2, it creates a neighbor data structure for RT2 and sets the neighbor state machine to Exstart. Next, both parties begin to send their respective link status databases.

To improve the sending efficiency, both parties need to first understand the LSA in the Peer database as needed (if an LSA already exists, the request is no longer needed ). The method is to send the DD packet first. The DD packet contains a brief description of the LSA in the local database (each Digest can uniquely identify an LSA, But it occupies less space ). Because OSPF directly uses IP packets to encapsulate their own protocol packets, the reliability of packet transmission must be considered during transmission.

To achieve this, the master-slave relationship between the two parties needs to be determined during the DD message transmission process. As the Master side defines a serial number seq, each time a new DD packet is sent, seq is added. As the Slave Party, each time the DD packet is sent, the seq in the received DD packet from the previous Master is used. In fact, this serial number mechanism is an implicit validation method. If each packet has a timeout retransmission, this transmission can be ensured to be reliable.

RT1 first sends a DD packet, declaring itself as a Master (MS = 1), and specifying the serial number as x. I = 1 indicates that this is the first DD packet. The packet does not contain the digest of LSA, but is used to negotiate the master-slave relationship. M = 1 indicates that this is not the last packet.

4. After receiving the DD packet of RT1, RT2 changes the neighbor state machine of RT1 to Exstart and responds to a DD packet (this packet also does not contain the digest information of LSA ). Because the RouterID of RT2 is large, RT2 considers itself as a Master in the message and re-specifies the serial number as y.

5. After receiving the packet, RT1 agrees that RT2 is the Master and changes the neighbor state machine of RT2 to Exchange. RT1 uses the serial number y of RT2 to send a new DD message, and the message begins to formally transmit the digest of LSA. In the message, RT1 sets MS to 0, indicating that it is Slave.

6. after receiving the packet, RT2 changes the neighbor state machine of RT1 to Exchange, and sends a new DD message to describe its own LSA digest. Note that: now, RT2 has changed the serial number of the message to y + 1.

7. The above process continues. RT1 repeat the serial number of RT2 to confirm that the packets of RT2 have been received. RT2 confirms that the RT1 packet has been received by adding the serial number + 1. When RT2 sends the last DD packet, M = 0 indicates that this is the last DD packet.

8. After receiving the last DD packet, RT1 finds that many LSA instances in the RT2 database do not own them, and changes the neighbor state machine to the Loading state. At this time, RT2 also receives the last DD packet of RT1, but the LSA and RT2 of RT1 already have the packet and do not need to request any more. Therefore, the neighbor state machine of RT1 is changed to the Full State directly.

9. The LSA required by RT1 to send the LS Request packet to RT2. RT2 uses the LS Update message to respond to the RT1 request. After RT1 receives the message, it needs to send the LS Ack message to confirm. The above process continues until the LSA in RT1 is fully synchronized with the LSA in RT2. In this case, RT1 changes the neighbor state machine of RT2 to the Full state.

Note:

The above process is the process in which the two routers establish the relationship between the two vrouters and the other vrouters. It can also be understood as the processing status when a new vro is added to the network. When the state machine between the two routers has reached the Full State, if there is another route change in the network at this time, you do not need to repeat all the above steps. Only one Party sends the LS Update message to notify the content to be updated, and the other party sends the LS Ack message to respond. The neighbor state machine of both parties does not change in this process.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.