CN114422435A

CN114422435A - Notification method of interface address, verification method of network equipment accessibility and equipment

Info

Publication number: CN114422435A
Application number: CN202011086960.6A
Authority: CN
Inventors: 储伯森; 蒋宇; 李良格
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-10-12
Filing date: 2020-10-12
Publication date: 2022-04-29

Abstract

The application provides an interface address notification method, a network equipment accessibility verification method and equipment, and belongs to the technical field of communication. In the application, the network device carries the IPv6 global unicast address of the local interface in the OSPFv3hello packet or OSPFv3 DD packet and sends the packet to the neighbor, so that the neighbor can check the reachability of the network device by using the IPv6 global unicast address, which is helpful for avoiding the network resource waste caused by the neighbor notifying the end.x SID under the condition that the next hop bound by the end.x SID is unreachable.

Description

Notification method of interface address, verification method of network equipment accessibility and equipment

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method for notifying an interface address, a method for verifying reachability of a network device, and a device.

Background

Segment Routing (SR) is a protocol designed based on the concept of source Routing to forward packets in a network. The SR divides the network path into segments, assigns Segment IDs (SID) to the segments or nodes, and enables the data packets to be transmitted through the forwarding path indicated by the segment IDs by carrying the segment IDs arranged in sequence in the data packets. The internet protocol version 6 (segment routing) 6 (SRv 6) is to combine SR technology with internet protocol version 6 (IPv 6) protocol, define the format of IPv6 address as instantiated SRv6 SID, and implement SR function based on the forwarding plane of IPv 6.

End point with Layer-3 cross-connect-segment id (end.x SID) is an SRv6 SID used to identify a link in a network. In the process of forwarding the message, if the destination address of the message hits the end.x SID in the local SID list, the network device forwards the message to the next hop connected to the link, that is, the next hop bound by the end.x SID, through the outgoing interface corresponding to the link identified by the end.x SID, that is, the outgoing interface bound by the end.x SID. When the end.x SID is configured on the network device, the network device needs to notify the end.x SID for Topology reporting and Topology-Independent Loop-free backup Fast ReRoute (TI-LFA FRR) route calculation.

If the next hop bound by the end.X SID is unreachable, the fact that the end.X SID is announced is meaningless, and a large amount of network resources are occupied.

Disclosure of Invention

The embodiment of the application provides an interface address notification method, a network equipment accessibility verification method and equipment, which are beneficial to avoiding network resource waste caused by the fact that an end.X SID is still notified when the next hop bound by the end.X SID cannot be reached. The technical scheme is as follows:

in a first aspect, a communication method is provided, where, for example, a first network device is executed by the first network device, the first network device generates an open shortest path first version 3 (OSPFv 3) message, where the OSPFv3 message is an ospv 3hello (hello) message or an OSPFv3 Database Description (DD) message, the OSPFv3 message includes a global unicast address (also referred to as IPv6 global address) of a first interface or an Internet Protocol sixth version 6 (IPv 6), and the first interface is an interface included in the first network device, where the first network device is connected to a second network device through the first interface; and the first network equipment sends the OSPFv3 message to the second network equipment.

In the above method, the first network device carries the IPv6 global unicast address of the local interface in the OSPFv3hello packet or OSPFv3 DD packet, and sends the packet to the neighbor (the second network device), so that the neighbor can check the reachability of the first network device by using the IPv6 global unicast address, which is helpful for avoiding the network resource waste caused by notifying the end.x SID when the next hop bound by the end.x SID is unreachable. Further, since the OSPFv3hello packet or the OSPFv3 DD packet is an interactive packet before the full state of the OSPFv3 neighbor establishment process, the neighbor can acquire the IPv6 global unicast address of the peer interface in advance before the neighbor reaches the full state, and the time delay consumed by the neighbor to acquire the IPv6 global unicast address of the peer interface is reduced.

Optionally, the OSPFv3 message includes a local-link signaling data block (LLS data block) including an IPv6 global unicast address of the first interface.

Through the above manner, an implementation manner compatible with the existing protocol architecture of the OSPFv3 is provided for how to expand the IPv6 global unicast address carrying the local interface in the OSPFv3hello message or the OSPFv3 DD message, and the availability of the scheme is improved.

Optionally, the LLS data block includes an interface address type length value TLV, where the type of the interface address TLV is used to identify an IPv6 global unicast address carried by the interface address TLV, and the value of the interface address TLV includes an IPv6 global unicast address of the first interface.

Through newly adding a type of TLV to carry the IPv6 global unicast address of the interface and carrying the newly added type of TLV in the LLS data block, the realization complexity is low and the practicability is high.

In a second aspect, a method for verifying reachability of network devices is provided, in which a second network device receives a first open shortest path first, version 3 OSPFv3 message from a first network device, where the first OSPFv3 message is an OSPFv3hello message or an OSPFv3 database description DD message, the first OSPFv3 message includes an internet protocol, version 6 IPv6 global unicast address of a first interface, and the first interface is an interface included in the first network device, and the first network device is connected to the second network device through the first interface; the second network device checks reachability of the first network device using the IPv6 global unicast address of the first interface.

Optionally, the checking, by the second network device, the reachability of the first network device using the IPv6 global unicast address of the first interface includes: the second network device checks the reachability of a next hop bound by an endpoint three-layer cross-connection segment identifier end.x SID by using the IPv6 global unicast address of the first interface, where the end.x SID is an internet protocol version 6 segment routing segment identifier SRv6 SID that is local to the second network device and is used to identify a three-layer connection between the first network device and the second network device, and the next hop bound by the end.x SID is the first network device.

Through the method, on one hand, the next hop bound by the announced end.X SID can be ensured to be reachable, and the network resource waste and the equipment performance overhead caused by the unreachable end.X SID of the announced next hop are avoided. On the other hand, the condition that the address of the wrong next hop is also checked to pass due to the fact that the reachability of the next hop is checked only by the IPv6 prefix is avoided, so that the accuracy of checking the reachability of the next hop bound by the end.X SID is obviously improved, and the effectiveness of operation of notifying the end.X SID is further improved.

Optionally, the verifying, by the second network device, reachability of a next-hop of an end.x SID binding using an IPv6 global unicast address of the first interface, includes: the second network device matches the address of the next hop bound by the end.X SID with the IPv6 global unicast address of the first interface; and if the address of the next hop bound by the end.X SID is the same as the IPv6 global unicast address of the first interface, the second network equipment determines that the next hop bound by the end.X SID is reachable.

Optionally, the verifying, by the second network device, reachability of a next-hop of an end.x SID binding using an IPv6 global unicast address of the first interface, includes: the second network device matches the address of the next hop bound by the end.X SID with the IPv6 global unicast address of the first interface; and if the address of the next hop bound by the end.X SID is different from the IPv6 global unicast address of the first interface, the second network equipment determines that the next hop bound by the end.X SID is unreachable.

Optionally, after the second network device checks reachability of a next hop of end.x SID binding using the IPv6 global unicast address of the first interface, the method further includes: and if the next hop bound by the end.X SID is reachable, the second network device advertises a second OSPFv3 message, wherein the second OSPFv3 message is used for issuing the end.X SID.

Optionally, after the second network device checks reachability of a next hop of end.x SID binding using the IPv6 global unicast address of the first interface, the method further includes: and if the next hop bound by the end.X SID is not reachable, the second network equipment does not announce the end.X SID.

Optionally, the first OSPFv3 message includes a local link signaling LLS data block including an IPv6 global unicast address of the first interface.

In a third aspect, a network device is provided, where the network device has a function of implementing the first network device in the first aspect or any one of the optional manners of the first aspect. The network device comprises at least one unit configured to implement the method provided by the first aspect or any one of the alternatives of the first aspect. In some embodiments, the unit in the network device provided by the third aspect is implemented by software, and the unit in the network device is a program module. In other embodiments, the unit in the network device provided in the third aspect is implemented by hardware or firmware. For specific details of the network device provided in the third aspect, reference may be made to the first aspect or any optional manner of the first aspect, which is not described herein again.

In a fourth aspect, a network device is provided, which has the function of implementing the second network device in the second aspect or any optional manner of the second aspect. The network device comprises at least one unit configured to implement the method provided by the second aspect or any of the alternatives of the second aspect. In some embodiments, the unit in the network device provided in the fourth aspect is implemented by software, and the unit in the network device is a program module. In other embodiments, the unit in the network device provided in the fourth aspect is implemented by hardware or firmware. For specific details of the network device provided in the fourth aspect, reference may be made to the second aspect or any optional manner of the second aspect, which is not described herein again.

In a fifth aspect, a network device is provided, which includes a main control board and an interface board. The main control board includes: a first processor and a first memory. The interface board includes: a second processor, a second memory, and an interface card. The main control board is coupled with the interface board.

The first memory may be configured to store program code, and the first processor is configured to call the program code in the first memory to perform the following: generating an open shortest path first (OSPFv) 3 rd version (OSPFv) 3 message, wherein the OSPFv3 message is an OSPFv3hello message or an OSPFv3 Database Description (DD) message, the OSPFv3 message comprises an Internet protocol 6 th version (IPv 6) global unicast address of a first interface, the first interface is an interface included by the first network equipment, and the first network equipment is connected with the second network equipment through the first interface;

the second memory may be configured to store program code, and the second processor may be configured to invoke the program code in the second memory to trigger the interface card to perform the following: and sending the OSPFv3 message to the second network equipment.

For specific details of the first network device provided in the fifth aspect, reference may be made to the first aspect or any optional manner of the first aspect, and details are not described here again.

In a sixth aspect, a network device is provided, which includes a main control board and an interface board. The main control board includes: a first processor and a first memory. The interface board includes: a second processor, a second memory, and an interface card. The main control board is coupled with the interface board.

The first memory may be configured to store program code, and the first processor is configured to call the program code in the first memory to perform the following: receiving a first open shortest path first (OSPFv) version 3 OSPFv3 message from a first network device, wherein the first OSPFv3 message is an OSPFv3hello message or an OSPFv3 Database Description (DD) message, the first OSPFv3 message comprises an Internet protocol version 6 IPv6 global unicast address of a first interface, the first interface is an interface comprised by the first network device, and the first network device is connected with a second network device through the first interface;

the second memory may be configured to store program code, and the second processor may be configured to invoke the program code in the second memory to trigger the interface card to perform the following: the reachability of the first network device is checked using the IPv6 global unicast address of the first interface.

For specific details of the network device provided by the sixth aspect, reference may be made to the second aspect or any optional manner of the second aspect, which is not described herein again.

In a seventh aspect, a computer-readable storage medium is provided, in which at least one program code is stored, and the instructions are read by a processor to cause a first network device to execute the method provided by the first aspect or any one of the optional manners of the first aspect.

In an eighth aspect, a computer-readable storage medium is provided, in which at least one program code is stored, and the instructions are read by a processor to cause a second network device to execute the method provided by the second aspect or any one of the alternatives of the second aspect.

In a ninth aspect, a computer program product is provided that includes computer instructions stored in a computer readable storage medium. The processor of the first network device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the first network device to perform the method provided by the first aspect or any of the alternatives of the first aspect.

In a tenth aspect, a computer program product is provided that includes computer instructions stored in a computer readable storage medium. The processor of the second network device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the second network device to perform the method provided by the second aspect or any of the alternatives of the second aspect.

In an eleventh aspect, a chip is provided, which when run on a first network device, causes the first network device to perform the method provided in the first aspect or any one of the alternatives of the first aspect.

In a twelfth aspect, a chip is provided, which when running on a second network device, causes the second network device to perform the method provided by the second aspect or any of the alternatives of the second aspect.

In a thirteenth aspect, a network system is provided, where the network system includes a first network device and a second network device, the first network device is configured to perform the method according to the first aspect or any of the options of the first aspect, and the second network device is configured to perform the method according to the second aspect or any of the options of the second aspect.

In a fourteenth aspect, a network device is provided, which includes a processor and a memory, where at least one program code is stored in the memory, and the at least one program code is loaded by the processor and executed to implement the method of the first aspect or any of the alternatives of the first aspect.

In a fifteenth aspect, a network device is provided, which comprises a processor and a memory, wherein at least one program code is stored in the memory, and the at least one program code is loaded and executed by the processor to implement the method provided by the second aspect or any of the alternatives of the second aspect.

Drawings

FIG. 1 is a diagram of a system architecture 100 according to an embodiment of the present application;

FIG. 2 is a diagram of a system architecture 200 according to an embodiment of the present application;

fig. 3 is a schematic diagram of a message format according to an embodiment of the present application;

fig. 4 is a schematic diagram of a message format according to an embodiment of the present application;

fig. 5 is a schematic diagram of a message format according to an embodiment of the present application;

fig. 6 is a schematic diagram of a message format according to an embodiment of the present application;

fig. 7 is a flowchart of a method for checking network device reachability provided by an embodiment of the present application;

fig. 8 is a schematic structural diagram of a network device 400 according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a network device 500 according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a network device 600 according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a network device 700 according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a network system 800 according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The method provided by the embodiment of the application can be applied to a scene of announcing the end.X SID in the field of SRv 6. Specifically, the method of the embodiment of the present application can be applied to a scenario in which a locally configured end.x SID is notified based on an open shortest path first for IPv6 (OSPFv 3), and determines whether to notify the end.x SID according to whether a next hop is reachable by checking reachability of a next hop IPv6 global unicast address (also referred to as IPv6 global address) of the end.x SID.

Since the embodiments of the present application relate to the application of SRv6 technology, for ease of understanding, the related concepts in SRv6 technology related to the embodiments of the present application will be described first.

SRv6 is a protocol designed based on the concept of source routing to forward IPv6 messages over a network. Based on SRv6 of an IPv6 forwarding plane, a Segment Routing Header (SRH), a routing extension header, is inserted into an IPv6 message, an explicit IPv6 address stack is pressed into the SRH, and the intermediate node continuously updates the destination address and the offset address stack to complete hop-by-hop forwarding.

The end.x SID refers to an SRv6 SID used to identify a three-layer connection. In the process of forwarding SRv6 data packets, a data packet with the destination address of end.x SID will be sent out from the designated interface after hitting the local SID list, and sent to the designated neighbor. The specified interface is determined by the end.x SID bound interface (interface). The specified neighbor is determined by the next hop (next hop) bound by the end.x SID.

The three-layer connection means that one hop between two nodes is reachable, in other words, the two nodes have a relationship between a previous hop and a next hop. For example, node a has interface a and node B has interface B. The meaning of establishing a three-layer connection between the interface a of the node a and the interface B of the node B is that when the interface a of the node a sends an IPv6 message, the hop-limit (hop-limit) in the IPv6 message is reduced by one and then reaches the interface B of the node B, that is, the node B is the next hop of the node a. It should be noted that two nodes establish a three-layer connection, and do not mean that the two nodes must be physically connected directly. Establishing a three-layer connection between two nodes includes the case where two nodes are physically connected directly, and certainly includes the case where two nodes are not physically connected directly. For example, node a and node B may also be via a two-layer switching network (e.g., one or more switches).

For example, referring to FIG. 1, in the system architecture 100 shown in FIG. 1, an end.X SID (2001::1) is manually configured on the intermediate node RT2, and is used to identify the link RT2- > PE2 between RT2 and PE 2. The intermediate node RT2 advertises the end.X SID via the OSPFv3 protocol (2001:: 1). Alternatively, the intermediate node RT2 sends the end.X SID (2001::1) up to the controller via OSPFv 3. After receiving the OSPFv3 notification issued by the intermediate node RT2, the head node PE1 performs path calculation according to the end.x SID. Or after receiving the upload message of the intermediate node RT2, the controller performs path calculation according to the end.x SID, and sends the obtained path to the head node PE1, and the head node PE1 receives the path sent by the controller. The path calculated from the end.x SID is represented by a segment identification list (segment list).

For example, referring to fig. 1, the destination address of the data packet is a private network IP address 192.168.1.2. After the data message reaches the head node PE1, the head node encapsulates an SRH for the data message, the SRH carries a calculated segment identifier list, and the segment identifier list contains the end.X SID (2001:: 1). When the intermediate node receives the data message containing SRH, if the next SID in the segment identification list is the end.X SID (2001::1), the intermediate node uses the end.X SID (2001::1) to replace the Destination Address (DA) in the data message, and forwards the replaced data message to the next node. For example, in the scenario shown in fig. 1, after the intermediate node RT2 receives the data packet, it matches the SID in the local SID table with the destination address in the data packet. If the destination address in the data message hits the SID in the local SID table, the intermediate node RT2 replaces the destination address in the data message with the next SID, or strips the SRH in the data message, and forwards the data message according to the link RT2- > PE2 associated with the hit SID.

Referring to fig. 2, the system architecture 200 shown in fig. 2 is an illustration of a configuration end.x SID scenario. System architecture 200 includes two network elements in system architecture 100. The network elements involved in the system architecture 200 include two types of nodes, one type of node being a sender of an IPv6 global unicast address and the other type of node being a receiver of an IPv6 global unicast address. The network elements involved in the system architecture 200 have OSPFv3 protocol processing capabilities as well as SRv6 capabilities. The network elements involved in the system architecture 200 are, for example, network devices such as routers and switches.

System architecture 200 includes network device RT2 and network device PE 2. A three-tier connection is established between network device RT2 and network device PE 2. In some embodiments, network device RT2 and network device PE2 are both routers. In some embodiments, the node sending the IPv6 global unicast address is network device PE2, and the node receiving the IPv6 global unicast address is network device RT 2.

The network device RT2 includes an interface named Ethernet 3/0/0. The interface name Ethernet3/0/0 means that the type of interface is Ethernet (Ethernet), slot number (slot) is 3, card number (card) is 0, and port number (port) is 0.

The network device PE2 includes an interface named Ethernet 3/0/1. The name of the interface Ethernet3/0/1 means that the type of the interface is Ethernet, the slot number is 3, the card number is 0, and the port number is 1. Three-layer connection is established between the interface Ethernet3/0/0 and the interface Ethernet 3/0/1.

The network device RT2 has an end.x SID configured thereon. The end.X SID configured on the network device RT2 is, for example, 2001:: 1. end.X SID (2001::1) is used to identify the three-layer connection between interface Ethernet3/0/0 and interface Ethernet 3/0/1. The end.X SID (2001::1) binds the outgoing interface and the IPv6 global unicast address of the next hop.

The egress interface bound by the end.X SID (2001::1) is Ethernet 3/0/0. Under normal conditions, the address of the next hop bound by the end.X SID (2001::1) is the IPv6 global unicast address of the peer interface Ethernet 3/0/1. In some embodiments, the address of the next hop bound by the end.X SID (2001::1) is the IPv6 global unicast address of interface Ethernet3/0/1 that does not contain masking information. In the SRv6 forwarding process, the destination address of the data packet hits the end.X SID (2001::1) in the local SID table, and since the egress interface bound by the end.X SID (2001::1) is Ethernet3/0/0, the data packet will be sent out from the interface Ethernet 3/0/0. And, when forwarding based on the end.x SID, it needs to find the Media Access Control Address (MAC) Address of the next hop according to the next hop Address bound by the end.x SID, and performs link layer encapsulation. Under normal conditions, the next hop address bound by the end.x SID is an IPv6 global unicast address of the peer interface Ethernet3/0/1, so that the network device RT2 uses the IPv6 global unicast address to find the MAC address of the network device PE2, and the network device RT2 performs link layer encapsulation according to the MAC address and then sends the data packet to the interface Ethernet3/0/1 of the network device PE 2.

In the scenario shown in fig. 1 or fig. 2, the end.x SID configured on the network device RT2 needs to be notified based on OSPFv3 for topology reporting and TI-LFA FRR routing. When end.X SID (2001::1) information is advertised in OSPFV3 Link-State advertisement (LSA), the premise of whether the end.X SID information is encapsulated into the LSA is: the link identified by the end.x SID is reachable. Reachable here may refer to the Ethernet3/0/0 bound by the end.X SID and the next hop 2001: DB8:2 to correctly identify the link between the interface Ethernet3/0/0 and the interface Ethernet3/0/1 shown in FIG. 2. If the end.X SID does not correctly identify the link, that is, the address of the next hop bound by the end.X SID is incorrect, or the next hop bound by the end.X SID cannot be reached, the action of notifying the end.X SID information has no meaning.

In the related art, IPv6 prefix information is communicated among OSPFv3 neighbors through a Link-Link state advertisement (Link-LSA), and not an IPv6 global unicast address is communicated. In conjunction with the scenario shown in fig. 1 or fig. 2, RT2 may not be able to obtain the IPv6 global unicast address of the peer interface Ethernet3/0/1 on PE 2. If the next-hop reachability is checked only with the IPv6 prefix, when the address of the next-hop bound by the end.X SID is configured as 2001: DB8:2: 3, the network device RT2 matches the IPv6 prefix with 2001: DB8:2: 3, the IPv6 prefix is successfully matched with 2001: DB8:2: 3, so that the address of the next-hop bound by the end.X SID is checked to pass. However, the configuration of the address of the next hop bound by the end.X SID is wrong, because the address of the next hop bound by the end.X SID should be 2001: DB8:2::2 instead of 2001: DB8:2::3, and the network device RT2 cannot find the MAC address of PE2 according to 2001: DB8:2::3, and thus cannot forward the packet to the network device PE 2.

In view of this, it is desirable to provide a method for accurately checking the reachability of the next hop of the end.x SID binding. More specifically, a method needs to be proposed to accurately check whether the next hop of the end.x SID binding is the IPv6 global unicast address, i.e., to accurately check the reachability of the next hop of the end.x SID, so that OSPFv3 determines whether to advertise according to whether the next hop is reachable.

Some embodiments of the present application expand an OSPFv3 protocol packet, and a network device sends an OSPFv3hello packet or an OSPFv3 DD packet to a neighbor by carrying an IPv6 global unicast address of a home terminal interface in an OSPFv3hello packet or an OSPFv3 DD packet, so as to notify the neighbor of the IPv6 global unicast address of the home terminal interface, so that the neighbor can acquire the IPv6 global unicast address of an opposite terminal interface before reaching a full state, and the neighbor can check the reachability of a next hop bound by an end.x SID using the IPv6 global unicast address of the opposite terminal interface. For the sake of understanding, the following description will be made about the concept of the terms related to the OSPFv3 protocol according to the embodiments of the present application.

(1)OSPFv3

Open Shortest Path First (OSPF) is a link state-based Interior Gateway Protocol (IGP) developed by the Internet Engineering Task Force (IETF) organization. Currently, OSPF Version 2 (abbreviated as OSPFv2) is used for the IPv4 protocol, and OSPF Version 3 (abbreviated as OSPFv3) is used for the IPv6 protocol. OSPFv3 is an OSPF routing protocol operating in IPv 6. OSPFv3 is an independent routing protocol enhanced on the basis of OSPFv 2. The OSPFv3 message mainly comprises five types: an OSPFv3hello (hello) message, an OSPFv3 Database Description (DD) message, an OSPFv3 Link State Request (LSR) message, an OSPFv3 Link State Update (LSU) message, and an OSPFv3 Link State Acknowledgement (LSACK) message.

(2) Neighbor establishment procedure of OSPFv3 and various states in the neighbor establishment procedure

In total, eight states may occur in the neighbor establishment process, which are a close (down) state, an initial (init) state, a two-way (two-way) state, an early start (extart) state, an exchange (exchange) state, a loading (loading) state, and a full (full) state. For example, in the neighbor establishing process, the states of the routers may be, in chronological order, down state → init state → two-way state → exstart state → exchange state → loading state → full state.

Specifically, the neighbor establishment process of OSPFv3 is roughly divided into three phases: stage (1) establishing a neighbor relation; stage (2) establishing respective topological tables; stage (3) establishes adjacency relationships. Stage (1) is the first, stage (2) is the second, and stage (3) is the latest. In phase (1), the states are down state → init state → two-way state in the order. In phase (2), the states are the exstart state → the exchange state in the order named. In stage (3), the states are in the order of loading state → full state.

(3) init state

When the OSPFv3 nodes are in the init state, OSPFv3hello messages are mutually sent among a plurality of OSPFv3 nodes, so that the neighbor relation is established. When in the init state, routing information is not synchronized among multiple OSPFv3 nodes.

(4) full state

The full state is also called a full adjacencies (full adjacency). The full state is reached after the interaction of routing information among the plurality of OSPFv3 nodes is completed. When in full state, different OSPFv3 nodes have established adjacency and LSDB synchronization is achieved.

(5) LLS data block

A local-link signaling data block (LLS data block) is a data block used for OSPF routers to perform local-link signaling functions. The LLS data block can be appended to an OSPFv3hello message or an OSPFv3 DD message. The data contained in the LLS data block in the OSPFv3hello message is used, for example, for dynamic signaling. The data contained in the LLS data block in the OSPFv3 DD message is used, for example, for dynamic signaling. The data contained in the LLS data block in the OSPFv3 DD message is communicated, for example, as part of the adjacency establishment procedure. Detailed definition of the LLS data block please refer to the introduction of RFC 5613 to "LLS data block" in request for comments (RFC, a series of files that are arranged by number).

(6) OSPFv3hello message

The OSPFv3hello messages are used to establish and maintain adjacencies between different OSPFv3 nodes. For example, an OSPFv3 node periodically sends OSPFv3hello messages to neighboring nodes at fixed time intervals. The OSPFv3hello messages are sent to each other when the OSPFv3 node is in the init state.

(7) OSPFv3 DD message

The OSPFv3 DD message is used to describe a Link State Database (LSDB) of the local router. When two OSPF nodes initiate connection, OSPFv3 DD message is exchanged, so that LSDB synchronization is carried out. The OSPFv3 DD messages are sent to each other when the OSPFv3 node is in exchange state.

(8) OSPFv3 extended-Link State advertisement (E-Link-LSA) message

The OSPFv 3E-Link-LSA message is an extension of the OSPFv3 Link-LSA message. The OSPFv 3E-Link-LSA message is sent after OSPFv3 DD messages are exchanged between different OSPFv3 nodes.

The above describes the concept of terms related to the OSPFv3 protocol, and the following describes the message format provided in this embodiment in detail.

The overall format of the OSPFv3 message carrying the IPv6 global unicast address of the interface can be seen with reference to fig. 3. The role of the OSPFv3hello message or OSPFv3 DD message can be referred to the description of the above terminology introduction.

How to use the IPv6 global unicast address of the OSPFv3hello message or OSPFv3 DD message carrying interface includes various ways. In some embodiments, the IPv6 global unicast address of the interface is carried by the extended LLS block. Specifically, the OSPFv3hello message or OSPFv3 DD message includes an LLS data block including an IPv6 global unicast address of an interface. The LLS data block can be referred to the description of the introductory portion of the terminology above. Wherein the LLS data block is located behind the OSPFv3 header and OSPFv3 data portion. The length of the LLS data block is not included in the length of the OSPFv3 message. The length of the LLS data block is contained in the length carried by the IPv6 basic header (IPv6 header). For example, the length field of the OSPFv3 header carries a length that represents the sum of the lengths of the OSPFv3 header (OSPFv3 header) and the OSPFv3 data (OSPFv3 data) portions. The length carried by the length field of the IPv6 basic header indicates the sum of the lengths of the IPv6 basic header, OSPFv3 header, OSPFv3 data portion and the LLS data block, etc.

Referring to fig. 4, fig. 4 shows the format of the LLS data block carrying the interface IPv6 global unicast address in OSPFv 3. The LLS data block includes a checksum (checksum) field, an LLS data length (LLS data length) field, and at least one LLS TLV. Wherein the checksum field carries the checksum of the entire LLS data block. The LLS data length field carries the length of the entire LLS data block.

Wherein the format of LLS TLV is shown in figure 5. The LLS TLV includes a type (type) field, a length (length) field, and a value (value) field. The type field includes the type of the LLS TLV. The length field includes the length of the value field of the LLS TLV. The value field includes a specific IPv6 global unicast address carried by the LLS TLV.

In some embodiments, the IPv6 global address of the interface is carried by adding one new TLV type. Taking the example that the IPv6 global address carrying the interface is called interface address TLV, referring to fig. 6, the LLS data block includes the interface address TLV as shown in fig. 6. The interface address TLV is carried in, for example, an OSPFv3hello message, or the interface address TLV is carried in an OSPFv3 DD message. The interface address TLV includes a type field, a length field, and a value field. Fig. 6 is an illustration of fig. 5, and the IPv6 global unicast address field of the interface in fig. 6 is the value field in fig. 5. The interface address TLV shown in fig. 6 includes a plurality of IPv6 global unicast addresses, and the plurality of IPv6 global unicast addresses are in a parallel relationship. For example, in a scenario where one interface configures multiple IPv6 global unicast addresses, the network device carries all the multiple IPv6 global unicast addresses of one interface in one interface address TLV, and sends the multiple IPv6 global unicast addresses of the interface to a neighbor together by sending one interface address TLV to the neighbor.

The type field in the interface address TLV includes the type of the interface address TLV. In some embodiments, the type field occupies 16 bits (bit) in the interface address TLV. The type of the interface address TLV is used for identifying the IPv6 global unicast address of the interface carried by the interface address TLV. Optionally, the type of the interface address TLV is 22.

The length field in the interface address TLV includes the length of the value field of the interface address TLV. In some embodiments, the length field in the interface address TLV is 16 bits. The length field includes the length of the value field of the interface address TLV.

The value field in the interface address TLV includes the IPv6 global unicast address of the interface. In some embodiments, the value field in the interface address TLV includes a 16-byte IPv6 address sequence.

It is worth mentioning that the interface address TLV in the embodiments of the present application may have different names. For example, different standards, different versions of the same standard, different vendors, different application scenarios may have different names for the "interface address TLV". For example, an "Interface Address TLV" may sometimes also be referred to as a "Local Interface IPv6 Address TLV" or a Local Interface IPv6 Address TLV.

It should be noted that, in the embodiment of the present application, the number of interface address TLVs included in the LLS data block is not limited. The LLS data block optionally contains one interface address TLV or contains multiple interface address TLVs.

The present embodiment utilizes the above message format to notify the neighbor of the IPv6 global unicast address of the home terminal interface, and can achieve at least the following two effects:

on one hand, compared with a correlation scheme that an IPv6 global unicast address of an interface is carried in an E-Router-LSA and then issued to a neighbor, the correlation scheme needs to issue the global address through the E-Router-LSA, so that the neighbor can acquire the global address only when reaching a full state, and the waiting time for acquiring the global address is long. In some embodiments of the present application, by improving the message format, the IPv6 global unicast address of the interface is carried in the LLS data block to be issued to the neighbor, so that the neighbor is allowed to acquire the IPv6 global unicast address of the interface in advance before the neighbor reaches the full state. Particularly, when an IPv6 global unicast address of an interface is carried by an OSPFv3hello message, the IPv6 global unicast address of the interface can be notified to a neighbor in an init state in advance, and the neighbor can acquire the IPv6 global unicast address of an opposite-end interface in the init state.

On the other hand, in some embodiments, since the IPv6 global unicast address of the advertisement interface and the advertisement end.x SID are both implemented by using the OSPFv3 protocol, it is not necessary to use other protocols other than the OSPFv3 protocol, and the software and hardware infrastructure of the OSPFv3 can be multiplexed, thereby reducing the types of protocols supported by the network device and reducing the requirements on the network device; meanwhile, the work complexity of network managers is reduced, and the managers do not need to be required to be skilled in various protocols. Thus, the implementation complexity is significantly reduced.

The above describes a system architecture and a message format, and the following describes a method flow based on the system architecture and the message format.

Referring to fig. 7, fig. 7 is a flow chart of a method 300 provided by an embodiment of the present application.

The interaction agent of method 300 includes a first network device and a second network device. For example, the first network device is the network device PE2 in the system architecture shown in fig. 1 or fig. 2. The second network device is the network device RT2 in the system architecture shown in fig. 1 or fig. 2. A three-layer connection is established between a first network device and a second network device.

The method 300 relates to an advertisement flow of interface addresses and a verification flow of network device reachability. In particular, the method 300 relates to how a first network device advertises an IPv6 global unicast address for a home interface to a second network device, and how the second network device verifies reachability of the first network device by the interface IPv6 global unicast address advertised by the first network device.

Optionally, the method 300 is processed by a general Central Processing Unit (CPU), or may be processed by the CPU and a Network Processor (NP) together, or may not be used with the NP but may be used with another processor suitable for message forwarding, which is not limited in the embodiment of the present application.

Illustratively, the method 300 includes S310 to S340.

S310, the first network equipment generates a first OSPFv3 message.

Specifically, the first network device generates a first OSPFv3 message according to the IPv6 global unicast address of the first interface.

The first interface is an interface included in the first network device. Optionally, the first interface is a physical interface; alternatively, the first interface is a logical interface. The first network device is connected with the second network device through the first interface. For example, referring to FIG. 2, interface Ethernet3/0/1 of PE2 establishes a three-layer connection with interface Ethernet3/0/0 of RT 2. In this scenario, PE2 is an illustration of a first network device, interface Ethernet3/0/1 is an illustration of a first interface, IPv6 global unicast address 2001: DB8:2 of interface Ethernet 3/0/1:: 2 is an illustration of IPv6 global unicast address of the first interface.

The first OSPFv3 message is OSPFv3hello message or OSPFv3 DD message. The first OSPFv3 message includes the IPv6 global unicast address of the first interface. In some embodiments, the first OSPFv3 message includes an LLS data block that includes an IPv6 global unicast address of the first interface. In some embodiments, the LLS data block includes an interface address TLV, a type of the interface address TLV is used to identify an IPv6 global unicast address of the interface carried by the interface address TLV, and a value of the interface address TLV includes an IPv6 global unicast address of the first interface.

S320, the first network device sends a first OSPFv3 message to the second network device.

S330, the second network device receives a first OSPFv3 message from the first network device.

S340, the second network device uses the IPv6 global unicast address of the first interface to check the reachability of the first network device.

In some embodiments, the second network device checks reachability of the next hop of the end.x SID binding using the IPv6 global unicast address of the first interface.

The end.x SID is an SRv6 SID local to the second network device for identifying a three-tier connection between the first network device and the second network device. The next hop bound by the end.X SID is the first network device. And the output interface bound by the end.X SID is the interface of the second network equipment. And the end.X SID is used for indicating that the second network equipment forwards the message to the next hop bound by the end.X SID through the exit interface bound by the end.X SID under the condition that the destination address of the message hits the end.X SID. The end.X SID is, for example, a SID stored in a local SID table of the second network device. The next hop for end.x SID binding is indicated by the address of the next hop. Optionally, the address of the next hop is an IPv6 global unicast address of the first interface. Optionally, the address of the next hop is an IPv6 global unicast address that does not contain mask information.

For example, referring to FIG. 2, the end.X SID is 2001::1 configured at RT 2. end.X SID (2001::1) is used to identify the triple-layer connection between RT2 and PE 2. The egress interface bound by the end.X SID (2001::1) is Ethernet3/0/0 at RT 2. The next hop for the end.X SID (2001::1) binding is PE 2.

In some embodiments, the second network device matches the address of the next hop of the end.x SID binding to the IPv6 global unicast address of the first interface; and if the address of the next hop bound by the end.X SID is the same as the IPv6 global unicast address of the first interface, the second network equipment determines that the next hop bound by the end.X SID can be reached, namely the check is passed. And if the address of the next hop bound by the end.X SID is different from the IPv6 global unicast address of the first interface, the second network equipment determines that the next hop bound by the end.X SID cannot be reached, namely, the check is failed.

In some embodiments, the second network device receives an advertisement request for the end.x SID, and performs step S340 in response to the advertisement request, so as to determine whether to advertise according to the matching result. Wherein the advertisement request is for instructing the second network device to advertise the end.x SID in the SRv6 network. For example, referring to FIG. 2, after RT2 receives a request for local advertisement of end.X SID (2001::1) based on OSPFv3 protocol, it obtains the address of the next hop of end.X SID from the local configuration of RT2 and reads the IPv6 global unicast address of interface Ethernet3/0/1 sent before the peer PE2 (as 2001: DB8:2:: 2). The RT2 compares the address of the next hop with the IPv6 global unicast address of Ethernet3/0/1 (e.g., 2001: DB8:2:: 2).

In some embodiments, the second network device determines whether to advertise the end.x SID based on reachability of a next hop to which the end.x SID is bound. Specifically, if the next hop bound by the end.x SID is reachable, the second network device advertises (advertisise) the second OSPFv3 message. And if the next hop bound by the end.X SID is not reachable, the second network equipment does not announce the end.X SID.

Wherein, the second OSPFv3 message is used for issuing end.x SID. The second OSPFv3 message includes OSPFv3 LSA and OSPFv3 LSA includes end.x SID. Specifically, the second network device encapsulates the end.x SID into OSPFv3 LSA, thereby generating a second OSPFv3 message according to the end.x SID. Among them, the means of advertising end.x SID using OSPFv3 LSA can refer to draft-ietf-lsr-OSPFv3-srv 6-extensions.

This embodiment does not limit the object of the second network device that advertises the second OSPFv3 message or the end.x SID. For example, the second network device advertises the second OSPFv3 message or end.x SID to a neighbor (e.g., the first network device); as another example, the second network device advertises the second OSPFv3 message or the end.x SID to the controller.

By using the OSPFv3 protocol to publish the IPv6 global unicast address of the direct connection interface and announce the end.X SID, on one hand, the problem that the OSPFv3 cannot check the reachability when the next hop of the end.X SID is configured as the IPv6 global unicast address is solved. On the other hand, because the release and the verification of the end.X SID are realized by using the OSPFv3 protocol, other protocols except the OSPFv3 protocol are not needed, the working complexity of network managers is reduced, and the managers do not need to be required to be skillfully mastered by various protocols. In addition, the function of the network equipment for checking the end.X SID can reuse software and hardware infrastructure for processing the OSPFv3, reduce the types of protocols supported by the network equipment, and reduce the requirements on the network equipment, thereby reducing the implementation complexity.

The embodiment provides a method capable of accurately checking the reachability of the next hop bound by the end.x SID. The reachability of the next hop bound by the end.x SID is checked by matching the address of the next hop bound by the end.x SID with the IPv6 global unicast address of the interface on the neighbor before advertising the end.x SID. In case the next hop address matches successfully with the IPv6 global unicast address of the interface, the end.x SID checks pass, allowing the end.x SID to be advertised. On one hand, the next hop bound by the advertised end.X SID is ensured to be reachable, and network resource waste and equipment performance overhead caused by the unreachable end.X SID of the advertised next hop are avoided. On the other hand, the condition that the address of the next hop which is wrong due to the fact that the next hop reachability is only checked by the IPv6 prefix is also checked to pass is avoided, and therefore the accuracy of checking the next hop reachability of the end.X SID binding is remarkably improved.

The method 300 of the embodiment of the present application is introduced above, and the network device of the embodiment of the present application is introduced below. The network device described below has any of the functionality of the first network device or the second network device in method 300 described above.

Fig. 8 shows a schematic diagram of a possible structure of the first network device involved in the above embodiment. The network device 400 shown in fig. 8 implements, for example, the functionality of the first network device in the method 300, or the network device 400 implements the functionality of the network device PE2 shown in fig. 2.

Referring to fig. 8, the network device 400 includes a generating unit 401 and a transmitting unit 402. Various elements of network device 400 are configured to perform the corresponding functions of the first network device or network device PE2 of method 300 described above. Specifically, the generating unit 401 is configured to support the network device 400 to execute S310. The sending unit 402 is configured to support the network device 400 to execute S320. For a specific implementation process of the network device 500, please refer to the detailed description of the corresponding steps in the method 300, which is not repeated herein.

The various elements in network device 400 are implemented in whole or in part by software, hardware, firmware, or any combination thereof.

The division of the unit in the embodiment of the present application is schematic, and is only a logic function division, and there may be another division manner in actual implementation. In some embodiments, various functional units in network device 400 are integrated into one processing unit. For example, the functional units in the network device 400 are integrated on the same chip. The chip comprises a processing circuit, and an input interface and an output interface which are connected and communicated with the inside of the processing circuit. The generation unit 401 is implemented by processing circuitry in the chip. The sending unit 402 is implemented by an output interface in the chip. For example, the chip may be implemented using one or more field-programmable gate arrays (FPGAs), Programmable Logic Devices (PLDs), controllers, state machines, gate logic, discrete hardware components, any other suitable circuitry, or any combination of circuitry capable of performing the various functions described throughout this application.

In other embodiments, each functional unit of network device 400 exists physically separately. In other embodiments, a part of the functional units of the network device 400 exist separately and physically, and another part of the functional units are integrated into one unit. For example, in some embodiments, the generating unit 401 and the sending unit 402 are the same unit. In other embodiments, generating unit 401 and transmitting unit 402 are different units. In some embodiments, the integration of different functional units is implemented in hardware, i.e. different functional units correspond to the same piece of hardware. As another example, the integration of different functional units is implemented in the form of software functional units.

In the case of being implemented by hardware in the network device 400, the generation unit 401 in the network device 400 is implemented by, for example, the central processor 631, the central processor 611, the central processor 641 in the network device 600 or the processor 701 in the network device 700. The transmitting unit 402 in the network device 400 is implemented, for example, by a physical interface card 633 in the network device 600 or a communication interface 704 in the network device 700.

In the case of being implemented by software in the network device 400, each unit in the network device 400 is, for example, software generated by the central processor 631, the central processor 611, the central processor 641 in the network device 600 or the processor 701 in the network device 700 reading the program code stored in the memory. For example, network device 400 is a virtualized device. The virtualization device includes, but is not limited to, at least one of a virtual machine, a container, and a Pod. In some embodiments, network device 400 is deployed on a hardware device (e.g., a physical server) in the form of a virtual machine. For example, Network device 400 is implemented based on a general purpose physical server in conjunction with Network Function Virtualization (NFV) technology. When implemented as a virtual machine, network device 400 is, for example, a virtual host, a virtual router, or a virtual switch. Those skilled in the art can simulate the network device 400 on the general physical server by combining the NFV technology through reading the present application. In other embodiments, network device 400 is deployed on a hardware device in the form of a container (e.g., a docker container). For example, the processes performed by network device 400 to perform the above-described method embodiments are encapsulated in an image file, and the hardware device creates network device 400 by running the image file. In other embodiments, network device 400 is deployed on a hardware device in the form of a Pod. The Pod includes a plurality of containers, each container for implementing one or more functional units in the network device 400.

Fig. 9 shows a schematic diagram of a possible structure of the second network device involved in the above embodiment. The network device 500 shown in fig. 9 implements, for example, the functionality of the second network device in the method 300, or the network device 500 implements the functionality of the network device RT2 shown in fig. 2.

Referring to fig. 9, the network device 500 includes a receiving unit 501 and a checking unit 502. The various elements in network device 500 are implemented in whole or in part by software, hardware, firmware, or any combination thereof. The respective units in the network device 500 are configured to perform the respective functions of the second network device or the network device RT2 in the above-described method embodiments. Specifically, the receiving unit 501 is configured to support the network device 500 to execute S330. The verification unit 502 is configured to support the network device 500 to perform S340. In some embodiments, the network device 500 further comprises a sending unit for supporting the network device 500 to advertise the second OSPFv3 message. For a specific implementation process of the network device 500, please refer to the detailed description of the corresponding steps in the method 300, which is not repeated herein.

The division of the unit in the embodiment of the present application is schematic, and is only a logic function division, and there may be another division manner in actual implementation.

In some embodiments, various functional units in network device 500 are integrated into one processing unit. For example, the functional units in the network device 500 are integrated on the same chip. The chip comprises a processing circuit, and an input interface and an output interface which are connected and communicated with the inside of the processing circuit. The receiving unit 501 is implemented by an input interface in the chip. The verification unit 502 is implemented by processing circuitry in the chip. For example, the chip may be implemented by one or more FPGAs, PLDs, controllers, state machines, gated logic, discrete hardware components, any other suitable circuitry, or any combination of circuitry capable of performing the various functions described throughout this application.

In other embodiments, the various functional units of network device 500 exist physically separate. In other embodiments, a part of the functional units of the network device 500 exist separately and physically, and another part of the functional units are integrated into one unit. In some embodiments, the integration of different functional units is implemented in hardware, i.e. different functional units correspond to the same piece of hardware. As another example, the integration of different functional units is implemented in the form of software functional units.

In case of being implemented in hardware in the network device 500, the receiving unit 501 in the network device 500 is implemented, for example, by a physical interface card 633 in the network device 600 or a communication interface 704 in the network device 700. The verification unit 502 in the network device 500 is implemented by, for example, the central processor 631, the central processor 611 in the network device 600 or the processor 701 in the network device 700.

In the case of being implemented by software in the network device 500, each unit in the network device 500 is, for example, software generated by the central processor 631 in the network device 600, the central processor 611, or the processor 701 in the network device 700 reading the program code stored in the memory. For example, network device 500 is a virtualized device. The virtualization device includes, but is not limited to, at least one of a virtual machine, a container, and a Pod. In some embodiments, network appliance 500 is deployed on a hardware device (e.g., a physical server) in the form of a virtual machine. For example, network device 500 is implemented based on a general purpose physical server in conjunction with NFV technology. When implemented as a virtual machine, the network device 500 is, for example, a virtual host, a virtual router, or a virtual switch. A person skilled in the art can simulate the network device 500 on the general physical server by combining the NFV technology through reading the present application. In other embodiments, network device 500 is deployed on a hardware device in the form of a container (e.g., a docker container). For example, the processes performed by the network device 500 to perform the above-described method embodiments are encapsulated in an image file, and the hardware device creates the network device 500 by running the image file. In other embodiments, network device 500 is deployed on a hardware device in the form of a Pod. The Pod includes a plurality of containers, each container for implementing one or more functional units in the network device 500.

How to implement the first network device or the second network device is described above from the perspective of logical functions through the network device 400 and the network device 500. How to implement the first network device and the second network device is described below from a hardware perspective by the network device 600 and the network device 700. The network device 600 and the network device 700 shown in fig. 9 are illustrations of the hardware configuration of the first network device or the second network device.

The network device 600 or the network device 700 corresponds to the first network device or the second network device in the method 300, and for implementing various steps and methods implemented by the first network device or the second network device in the method embodiment, the detailed flow of how the network device 600 or the network device 700 advertises the interface address or checks the reachability of the network device may be referred to in the method 300 for specific details, and for brevity, no further description is provided here. The steps of method 300 are performed by instructions in the form of hardware, integrated logic circuits, or software in a processor of network device 600 or network device 700. The steps of a method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in a processor. The software module is located in a storage medium, such as a ram, a flash memory, a rom, a prom, or an eeprom, a register, etc., which are well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and performs the steps of the above method in combination with hardware thereof, which are not described in detail herein to avoid repetition.

Referring to fig. 10, fig. 10 is a schematic structural diagram of a network device provided in an exemplary embodiment of the present application, and the network device 600 is configured as, for example, a first network device or a second network device. The network device 600 includes: a main control board 610 and an interface board 630.

The main control board is also called a Main Processing Unit (MPU) or a route processor card (route processor card), and the main control board 610 is used for controlling and managing each component in the network device 600, including routing computation, device management, device maintenance, and protocol processing functions. The main control board 610 includes: a central processor 611 and a memory 612.

The interface board 630 is also referred to as a Line Processing Unit (LPU), a line card (line card), or a service board. The interface board 630 is used for providing various service interfaces and forwarding data packets. The service interfaces include, but are not limited to, Ethernet interfaces, such as Flexible Ethernet services interfaces (FlexE Ethernet Clients), POS (Packet over SONET/SDH) interfaces, and the like. The interface board 630 includes: a central processor 631, a network processor 632, a forwarding table entry memory 634, and a Physical Interface Card (PIC) 633.

The central processor 631 on the interface board 630 is used for controlling and managing the interface board 630 and communicating with the central processor 611 on the main control board 610.

The network processor 632 is configured to implement a forwarding process of the packet. The network processor 632 is in the form of a forwarding chip, for example. Specifically, the network processor 632 is configured to forward the received message based on the forwarding table stored in the forwarding table entry memory 634, and if the destination address of the message is the address of the network device 600, send the message to a CPU (e.g., the central processing unit 611) for processing; if the destination address of the message is not the address of the network device 600, the next hop and the outgoing interface corresponding to the destination address are found from the forwarding table according to the destination address, and the message is forwarded to the outgoing interface corresponding to the destination address. The processing of the uplink message comprises the following steps: processing a message input interface and searching a forwarding table; and (3) downlink message processing: forwarding table lookups, and the like.

The physical interface card 633 is used to implement the interfacing function of the physical layer, from which the original traffic enters the interface board 630, and the processed messages are sent out from the physical interface card 633. The physical interface card 633, also called a daughter card, may be installed on the interface board 630, and is responsible for converting the optical signal into a message, performing validity check on the message, and forwarding the message to the network processor 632 for processing. In some embodiments, a central processor may also perform the functions of network processor 632, such as implementing software forwarding based on a general purpose CPU, so that network processor 632 is not required in physical interface card 633.

Optionally, the network device 600 includes a plurality of interface boards, for example, the network device 600 further includes an interface board 640, and the interface board 640 includes: central processor 641, network processor 642, forward entry store 644, and physical interface card 643.

Optionally, the network device 600 further comprises a switch web board 620. The switch board 620 is also called a Switch Fabric Unit (SFU), for example. In the case of a network device having a plurality of interface boards 630, the switch board 620 is used to complete data exchange between the interface boards. For example, interface board 630 and interface board 640 communicate, for example, through switch board 620.

The main control board 610 is coupled to an interface board 630. For example. The main control board 610, the interface board 630, the interface board 640, and the switch board 620 are connected to the system backplane through the system bus to realize intercommunication. In a possible implementation manner, an inter-process communication (IPC) channel is established between the main control board 610 and the interface board 630, and the main control board 610 and the interface board 630 communicate through the IPC channel.

Logically, network device 600 includes a control plane including a main control panel 610 and a central processor 631, and a forwarding plane including various components that perform forwarding, such as a forwarding table entry memory 634, a physical interface card 633, and a network processor 632. The control plane performs functions of a router, generating a forwarding table, processing signaling and protocol messages, configuring and maintaining the state of the device, and the like, and issues the generated forwarding table to the forwarding plane, and in the forwarding plane, the network processor 632 looks up the table of the message received by the physical interface card 633 and forwards the table based on the forwarding table issued by the control plane. The forwarding table issued by the control plane is stored in the forwarding table entry storage 634, for example. In some embodiments, the control plane and the forwarding plane are, for example, completely separate and not on the same device.

It should be understood that the operations on the interface board 640 in the embodiment of the present application are the same as the operations of the interface board 630, and therefore, for brevity, detailed descriptions are omitted. It should be understood that the network device 600 of this embodiment may correspond to the network device in each of the above method embodiments, and the main control board 610 and the interface boards 630 and/or 640 in the network device 600 implement, for example, functions and/or various steps implemented by the network device in each of the above method embodiments, and therefore, for brevity, no repeated description is provided here.

It should be noted that there may be one or more main control boards, and when there are more than one main control boards, for example, the main control boards include a main control board and a standby main control board. The interface board may have one or more blocks, and the stronger the data processing capability of the network device, the more interface boards are provided. There may also be one or more physical interface cards on an interface board. The exchange network board may not have one or more blocks, and when there are more blocks, the load sharing redundancy backup can be realized together. Under the centralized forwarding architecture, the network device does not need a switching network board, and the interface board undertakes the processing function of the service data of the whole system. Under the distributed forwarding architecture, the network device can have at least one switching network board, and the data exchange among a plurality of interface boards is realized through the switching network board, so that the high-capacity data exchange and processing capacity is provided. Therefore, the data access and processing capabilities of network devices in a distributed architecture are greater than those of devices in a centralized architecture. Optionally, the form of the network device may also be only one board card, that is, there is no switching network board, and the functions of the interface board and the main control board are integrated on the one board card, at this time, the central processing unit on the interface board and the central processing unit on the main control board may be combined into one central processing unit on the one board card to perform the function after the two are superimposed, and the data switching and processing capability of the device in this form is low (for example, network devices such as a low-end switch or a router, etc.). Which architecture is specifically adopted depends on the specific networking deployment scenario, and is not limited herein.

Referring to fig. 11, fig. 11 is a schematic structural diagram of a network device provided in an exemplary embodiment of the present application, where the network device 700 may be configured as a network device. The network device 700 may be a host, server, personal computer, or the like. The network device 700 may be implemented by a generic bus architecture.

Network device 700 includes at least one processor 701, a communication bus 702, memory 703, and at least one communication interface 704.

The processor 701 is, for example, a Central Processing Unit (CPU), a Network Processor (NP), a Graphics Processing Unit (GPU), a neural-Network Processing Unit (NPU), a Data Processing Unit (DPU), a microprocessor, or one or more integrated circuits for implementing the present disclosure. For example, the processor 701 may include an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. PLDs are, for example, Complex Programmable Logic Devices (CPLDs), field-programmable gate arrays (FPGAs), General Array Logic (GAL), or any combination thereof.

A communication bus 702 is used to transfer information between the above components. The communication bus 702 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in FIG. 11, but this is not intended to represent only one bus or one type of bus.

The Memory 703 is, for example, but is not limited to, a read-only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only Memory (EEPROM), a compact disk read-only Memory (CD-ROM) or other optical disk storage, optical disk storage (including compact disk, laser disk, optical disk, digital versatile disk, blu-ray disk, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 703 is, for example, separate and coupled to the processor 701 via a communication bus 702. The memory 703 may also be integrated with the processor 701.

The communication interface 704 uses any transceiver or the like for communicating with other devices or a communication network. The communication interface 704 includes a wired communication interface, and may also include a wireless communication interface. The wired communication interface may be an ethernet interface, for example. The ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a Wireless Local Area Network (WLAN) interface, a cellular network communication interface, or a combination thereof.

In particular implementations, processor 701 may include one or more CPUs, such as CPU0 and CPU1 shown in fig. 11, as one example.

In particular implementations, network device 700 may include multiple processors, such as processor 701 and processor 705 shown in FIG. 11, for example, as an example. Each of these processors may be a single-Core Processor (CPU) or a multi-Core Processor (CPU). A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In particular implementations, network device 700 may also include an output device and an input device, as one embodiment. An output device is in communication with the processor 701 and may display information in a variety of ways. For example, the output device may be a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, a projector (projector), or the like. The input device is in communication with the processor 701 and may receive user input in a variety of ways. For example, the input device may be a mouse, a keyboard, a touch screen device, or a sensing device, among others.

In some embodiments, the memory 703 is used for storing program code 710 for implementing the present solution, and the processor 701 may execute the program code 710 stored in the memory 703. That is, the network device 700 may implement the method provided by the method embodiment through the processor 701 and the program code 710 in the memory 703.

The network device 700 of the present embodiment may correspond to the first network device or the second network device in the above-described various method embodiments, and the processor 701, the communication interface 704, and the like in the network device 700 may implement the functions of the first network device or the second network device in the above-described various method embodiments and/or various steps and methods implemented by the first network device or the second network device. For brevity, no further description is provided herein.

Referring to fig. 12, an embodiment of the present application provides a network system 800, where the network system 800 includes: a first network device 801 and a second network device 802. Optionally, the first network device 801 is the network device 400 shown in fig. 8 or the network device 600 shown in fig. 10 or the network device 700 shown in fig. 11, and the second network device 802 is the network device 500 shown in fig. 9 or the network device 600 shown in fig. 10 or the network device 700 shown in fig. 11.

Those of ordinary skill in the art will appreciate that the various method steps and elements described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both, and that the steps and elements of the various embodiments have been described above generally in terms of their functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the unit is only one logical functional division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may also be an electric, mechanical or other form of connection.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiments of the present application.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The terms "first," "second," and the like, in this application, are used for distinguishing between similar items and items that have substantially the same function or similar functionality, and it is to be understood that "first" and "second" do not have a logical or temporal dependency, nor do they define a quantity or order of execution. It will be further understood that, although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first OSPFv3 message may be referred to as a second OSPFv3 message, and similarly, a second OSPFv3 message may be referred to as a first OSPFv3 message, without departing from the scope of the various examples. The first OSPFv3 message and the second OSPFv3 message may both be OSPFv3 messages and, in some cases, may be separate and distinct OSPFv3 messages.

The term "at least one" in this application means one or more, and the term "plurality" in this application means two or more.

It is also understood that the term "if" may be interpreted to mean "when" ("where" or "upon") or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined." or "if [ a stated condition or event ] is detected" may be interpreted to mean "upon determining.. or" in response to determining. "or" upon detecting [ a stated condition or event ] or "in response to detecting [ a stated condition or event ]" depending on the context.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive various equivalent modifications or substitutions within the technical scope of the present application, and these modifications or substitutions should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer program instructions. When loaded and executed on a computer, produce, in whole or in part, the procedures or functions according to the embodiments of the application. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device.

The computer program instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer program instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center by wire or wirelessly. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that includes one or more of the available media. The available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., Digital Video Disks (DVDs), or semiconductor media (e.g., solid state disks), among others.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for advertising an interface address, the method comprising:

a first network device generates an open shortest path first (OSPFv) version 3 (OSPFv) 3 message, wherein the OSPFv3 message is an OSPFv3hello (hybrid open shortest path first) message or an OSPFv3 (hybrid open shortest path first) Database Description (DD) message, the OSPFv3 message comprises an Internet protocol version 6 (IPv 6) global unicast address of a first interface, the first interface is an interface included by the first network device, and the first network device is connected with a second network device through the first interface;

and the first network equipment sends the OSPFv3 message to the second network equipment.

2. The method of claim 1 wherein the OSPFv3 message comprises a Local Link Signaling (LLS) data block comprising an IPv6 global unicast address of the first interface.

3. The method of claim 2, wherein the LLS data block comprises an interface address type length value TLV, wherein the type of the interface address TLV is used to identify an IPv6 global unicast address of an interface carried by the interface address TLV, and wherein the value of the interface address TLV comprises an IPv6 global unicast address of the first interface.

4. A method for verifying reachability of a network device, the method comprising:

receiving, by a second network device, a first open shortest path first, OSPFv3 version 3 message from a first network device, where the first OSPFv3 message is an OSPFv3hello message or an OSPFv3 database description DD message, the first OSPFv3 message includes an internet protocol, version 6 IPv6, global unicast address of a first interface, and the first interface is an interface included in the first network device, and the first network device is connected to the second network device through the first interface;

the second network device checks reachability of the first network device using the IPv6 global unicast address of the first interface.

5. The method of claim 4, wherein the second network device checking reachability of the first network device using the IPv6 global unicast address of the first interface comprises:

the second network device checks the reachability of a next hop bound by an endpoint three-layer cross-connection segment identifier end.x SID by using the IPv6 global unicast address of the first interface, where the end.x SID is an internet protocol version 6 segment routing segment identifier SRv6 SID that is local to the second network device and is used to identify a three-layer connection between the first network device and the second network device, and the next hop bound by the end.x SID is the first network device.

6. The method of claim 5, wherein the second network device verifying reachability of an end point three-layer cross-connect segment identifying a next-hop of an end.x SID binding using an IPv6 global unicast address for the first interface, comprises:

the second network device matches the address of the next hop bound by the end.X SID with the IPv6 global unicast address of the first interface;

and if the address of the next hop bound by the end.X SID is the same as the IPv6 global unicast address of the first interface, the second network equipment determines that the next hop bound by the end.X SID is reachable.

7. The method of claim 5, wherein the second network device verifying reachability of an end point three-layer cross-connect segment identifying a next-hop of an end.x SID binding using an IPv6 global unicast address for the first interface, comprises:

and if the address of the next hop bound by the end.X SID is different from the IPv6 global unicast address of the first interface, the second network equipment determines that the next hop bound by the end.X SID is unreachable.

8. The method of any of claims 5-7, wherein after the second network device checks reachability of the next-hop of end.x SID binding using the IPv6 global unicast address of the first interface, the method further comprises:

and if the next hop bound by the end.X SID is reachable, the second network device advertises a second OSPFv3 message, wherein the second OSPFv3 message is used for issuing the end.X SID.

9. The method of any of claims 5-7, wherein after the second network device checks reachability of the next-hop of end.x SID binding using the IPv6 global unicast address of the first interface, the method further comprises:

and if the next hop bound by the end.X SID is not reachable, the second network equipment does not announce the end.X SID.

10. The method of any of claims 4 to 9 wherein the first OSPFv3 message comprises a local link signaling LLS data block comprising an IPv6 global unicast address of the first interface.

11. The method of claim 10, wherein the LLS data block comprises an interface address type length value TLV, wherein the type of the interface address TLV is used to identify an IPv6 global unicast address of an interface carried by the interface address TLV, and wherein the value of the interface address TLV comprises an IPv6 global unicast address of the first interface.

12. A network device, wherein the network device is a first network device, the network device comprising:

a generating unit, configured to generate an open shortest path first OSPFv3 message of version 3, where the OSPFv3 message is an OSPFv3hello message or an OSPFv3 database description DD message, the OSPFv3 message includes an internet protocol version 6 IPv6 global unicast address of a first interface, the first interface is an interface included in the first network device, and the first network device is connected to the second network device through the first interface;

a sending unit, configured to send the OSPFv3 message to the second network device.

13. The network device of claim 12, wherein the OSPFv3 message comprises a Local Link Signaling (LLS) data block comprising an IPv6 global unicast address of the first interface.

14. The network device of claim 13, wherein the LLS data block includes an interface address type length value TLV, wherein the type of the interface address TLV is used to identify an IPv6 global unicast address of an interface carried by the interface address TLV, and wherein the value of the interface address TLV includes an IPv6 global unicast address of the first interface.

15. A network device, wherein the network device is a second network device, the network device comprising:

a receiving unit, configured to receive a first open shortest path first, OSPFv3, version 3 OSPFv3 message, where the first OSPFv3 message is an OSPFv3hello message or an OSPFv3 database description DD message, the first OSPFv3 message includes an internet protocol, version 6 IPv6, global unicast address of a first interface, where the first interface is an interface included in the first network device, and the first network device is connected to the second network device through the first interface;

a checking unit, configured to check reachability of the first network device using an IPv6 global unicast address of the first interface.

16. The network device of claim 15, wherein the check unit is configured to check reachability of a next hop of an endpoint three-tier cross-connect segment identification (end.x SID) binding using an IPv6 global unicast address of the first interface, wherein the end.x SID is an Internet protocol version 6 segment routing segment identification (SRv 6) SID local to the second network device that identifies a three-tier connection between the first network device and the second network device, and wherein the next hop of the end.x SID binding is the first network device.

17. The network device of claim 16, wherein the checking unit is configured to match an address of a next hop of the end.x SID binding with an IPv6 global unicast address of the first interface; and if the address of the next hop bound by the end.X SID is the same as the IPv6 global unicast address of the first interface, determining that the next hop bound by the end.X SID can reach.

18. The network device of claim 16, wherein the checking unit is configured to match an address of a next hop of the end.x SID binding with an IPv6 global unicast address of the first interface; and if the address of the next hop bound by the end.X SID is different from the IPv6 global unicast address of the first interface, determining that the next hop bound by the end.X SID is unreachable.

19. The network device of any of claims 16-18, wherein the sending unit is further configured to advertise a second OSPFv3 message if a next hop for the end.x SID binding is reachable, the second OSPFv3 message being configured to publish the end.x SID.

20. The network device according to any of claims 16-18, wherein the sending unit is further configured to not advertise the end.x SID if a next hop bound by the end.x SID is unreachable.

21. The network device of any of claims 15 to 20, wherein the first OSPFv3 message comprises a local link signaling LLS data block comprising an IPv6 global unicast address of the first interface.

22. The network device of claim 21, wherein the LLS data block includes an interface address type length value TLV, a type of the interface address TLV is used to identify an IPv6 global unicast address of an interface carried by the interface address TLV, and a value of the interface address TLV includes an IPv6 global unicast address of the first interface.

23. A network system, characterized in that the network system comprises a network device according to any of claims 12 to 14 and a network device according to any of claims 15 to 22.

24. A computer-readable storage medium, having stored therein at least one program code, which is readable by a processor to cause a network device to perform the method of any one of claims 1 to 11.