Route convergence method and related device

Abstract

The embodiment of the invention provides a routing convergence method and a related device, and relates to the technical field of communication. Receiving a first-class routing revocation message sent by the central equipment; determining a plurality of five-class routes to be revoked according to the revocation message of the first-class route and a locally stored mapping relation between the first-class route and the five-class routes; wherein the first-class route revocation message is generated by any outlet VTEP equipment under the condition of determining that a next hop outlet router leading to any external route is unreachable and is sent to the central equipment, or the first-class route revocation message is generated by the central equipment under the condition of determining that any outlet VTEP equipment fails; and determining a plurality of pieces of target next-hop information according to the next-hop key value in any to-be-revoked five-type route and the corresponding relationship between the locally stored next-hop key value and the next-hop information, and performing invalidation processing on the plurality of pieces of target next-hop information. Therefore, the processing efficiency can be improved, and the convergence time and the service interruption duration can be shortened.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a routing convergence method and related apparatus. Background Technology

[0002] Currently, to achieve redundancy and backup at the access layer, data center networks typically employ three mainstream technical solutions: stacked access, MLAG (Multi-Chassis Link Aggregation Group) access, and EVPN (Ethernet Virtual Private Network) multi-homed access. Among these, the MLAG solution is widely used in the industry due to its simplicity and mature deployment; while the EVPN multi-homed access solution, based on standard protocols, possesses excellent cross-vendor interoperability, and its application scope in practical deployments has been continuously expanding in recent years.

[0003] For the EVPN multi-homing scheme, it adopts the load balancing mechanism at the overlay layer, that is, the remote device identifies multiple independent VXLAN (Virtual eXtensible Local Area Network) tunnel endpoints, and fault switching and load balancing are based on these independent tunnels.

[0004] However, in the current technical implementation, the fast convergence mechanism of the EVPN multi-homing scheme is mainly applicable to Layer 2 link aggregation access scenarios. However, when deploying with Layer 3 interface connections to the egress router, it can only use conventional routing protocols for convergence, updating the next route one by one through the control plane. Therefore, it suffers from low processing efficiency, long processing time, and long service interruption time.

[0005] For example, Figure 1 For a schematic diagram of an EVPN VXLAN multihomed deployment architecture, please refer to [link / reference]. Figure 1 Server 1 and Server 2 both access the VTEP group via EVPN multi-homing. VTEP3 and VTEP4 act as egress VTEPs (VXLAN Tunnel End Points), connected to the egress router via a Layer 3 interface. They can import external routes from egress routers 1 and 2 respectively, then convert these external routes into Category 5 routes and broadcast them internally to the central devices (Spine1 and Spine2), thereby reaching the internal VTEP devices VTEP1 and VTEP2. Upon receiving these Category 5 routes, VTEP1 and VTEP2 install them, enabling Server 1 to access the external network.

[0006] In this scenario, if VTEP3 fails or its link with the egress router 1 is interrupted, VTEP1 and VTEP2 will receive multiple Category 5 route cancellation messages reflected from the central device and update the affected route entries one by one, switching the next hop from VTEP3 to VTEP4. However, when the number of routes involved is large, this method of updating one by one will significantly prolong the convergence time, reduce processing efficiency, and result in a longer service interruption time. Summary of the Invention

[0007] In view of this, the purpose of this application is to provide a routing convergence method and related apparatus to achieve fast convergence for Layer 3 egress failures in an EVPN-VXLAN multihomed network architecture.

[0008] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, this application provides a routing convergence method applicable to any internal VTEP device, wherein the internal VTEP device is communicatively connected to multiple outgoing VTEP devices through at least one central device, the method comprising: The central device receives a type of route cancellation message; wherein the type of route cancellation message is generated and sent to the central device by any of the egress VTEP devices when it is determined that the next-hop egress router leading to any external route is unreachable, or by the central device when it is determined that any of the egress VTEP devices is faulty. Based on the type I route cancellation message and the mapping relationship between type I routes and type V routes stored locally, multiple type V routes to be cancelled are identified; Based on the correspondence between the next-hop key value in any of the five types of routes to be revoked and the locally stored next-hop key value and next-hop information, multiple target next-hop information are determined, and the multiple target next-hop information are invalidated.

[0009] In an optional implementation, prior to the step of receiving a route cancellation message sent by the central device, the method further includes: Receive at least one Category 1 route and multiple Category 5 routes sent by each of the aforementioned egress VTEP devices through the central device; Based on the next-hop key values ​​in each of the first-class routes and the next-hop key values ​​in each of the five-class routes, establish a mapping relationship between the first-class routes and the five-class routes; Next-hop information is generated for each of the five types of routes, and a correspondence is established between the next-hop key value of the five types of routes and the next-hop information.

[0010] In an optional implementation, each of the egress VTEP devices is communicatively connected to at least one egress router for obtaining multiple external routes through at least one egress router; The five types of routes are generated by the egress VTEP device based on the external routes, and each of the five types of routes corresponds to one external route; the next-hop key value in each of the five types of routes includes the device identifier of the egress router and the gateway identifier; the gateway identifier represents multiple external routes that have the same next-hop egress router; Each of the above types of routes is generated by the egress VTEP device based on the next-hop key value, and the next-hop key value contained in each of the above types of routes is different.

[0011] Secondly, this application provides a routing convergence method applied to any egress VTEP device, wherein the egress VTEP device is communicatively connected to multiple internal VTEP devices through at least one central device, the method comprising: The next-hop exit router leading to any external route is determined to be unreachable; If the next-hop exit router leading to any external route is unreachable, a route cancellation message is generated and sent to the central device. The central device then forwards the route cancellation message to each of the internal VTEP devices. Each internal VTEP device determines multiple Category 5 routes to be cancelled based on the route cancellation message sent by the central device and the mapping relationship between Category 1 routes and Category 5 routes stored locally. Based on the correspondence between the next-hop key value in any of the Category 5 routes to be cancelled and the next-hop key value and next-hop information stored locally, multiple target next-hop information is determined, and the multiple target next-hop information is invalidated.

[0012] In an optional implementation, generating a route revocation message and sending it to the central device when the next-hop exit router leading to any external route is unreachable includes: If the next-hop exit router leading to any external route is unreachable, a route cancellation message is generated based on the device identifier of the exit VTEP device and the gateway identifier corresponding to the external route, and the route cancellation message is sent to the central device.

[0013] Thirdly, this application provides a routing convergence device applied to any internal VTEP device, wherein the internal VTEP device is communicatively connected to multiple outgoing VTEP devices through at least one central device, and the device includes: The receiving module is used to receive a type of route cancellation message sent by the central device; wherein, the type of route cancellation message is generated and sent to the central device by any of the egress VTEP devices when it is determined that the next-hop egress router leading to any external route is unreachable, or is generated by the central device when it is determined that any of the egress VTEP devices is faulty; The receiving module is also used to determine multiple Class 5 routes to be revoked based on the Class 1 route cancellation message and the mapping relationship between Class 1 routes and Class 5 routes stored locally; The invalidation module is used to determine multiple target next-hop information based on the correspondence between the next-hop key value in any of the five types of routes to be revoked and the next-hop key value and next-hop information stored locally, and to invalidate the multiple target next-hop information.

[0014] Fourthly, this application provides a routing convergence device applied to any egress VTEP device, wherein the egress VTEP device is communicatively connected to multiple internal VTEP devices through at least one central device, and the device includes: The determination module is used to determine whether the next-hop exit router leading to any external route is unreachable; The generation module is used to generate a route cancellation message and send it to the central device when the next-hop exit router leading to any external route is unreachable. The central device then sends the route cancellation message to each of the internal VTEP devices. Each internal VTEP device determines multiple Class 5 routes to be cancelled based on the route cancellation message sent by the central device and the mapping relationship between Class 1 routes and Class 5 routes stored locally. Based on the next-hop key value in any of the Class 5 routes to be cancelled and the correspondence between the next-hop key value and the next-hop information stored locally, it determines multiple target next-hop information and invalidates the multiple target next-hop information.

[0015] Fifthly, this application provides a VTEP device, including a processor and a memory, the memory storing a computer program executable by the processor, the processor being able to execute the computer program to implement the method described in any of the foregoing embodiments.

[0016] Sixthly, this application provides a routing processing system, including the VTEP device described in the foregoing embodiments.

[0017] In a seventh aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the foregoing embodiments.

[0018] The routing convergence method and related apparatus provided in this application embodiment allow the egress VTEP device to generate a route cancellation message and send it to the internal VTEP device via a central device when the next-hop egress router leading to any external route is unreachable. Alternatively, the central device can generate a route cancellation message and send it to the internal VTEP device when any egress VTEP device is determined to be faulty. The internal VTEP device can then determine multiple Category 5 routes to be cancelled based on the route cancellation message and the mapping relationship between Category 1 and Category 5 routes stored locally. Subsequently, based on the next-hop key value in any Category 5 route to be cancelled and the correspondence between the next-hop key value and next-hop information stored locally, multiple target next-hop information is determined and invalidated. This allows for batch cancellation of multiple Category 5 routes using only one Category 1 route cancellation message in the control plane, and batch invalidation of multiple target next-hop information using the next-hop key value in any Category 5 route to be cancelled in the data plane. Therefore, it improves processing efficiency and shortens convergence time and service interruption duration.

[0019] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A schematic diagram of an EVPN VXLAN multi-homing deployment architecture is shown. Figure 2 A block diagram of the routing processing system provided in an embodiment of this application is shown; Figure 3 A block diagram of the VTEP device provided in an embodiment of this application is shown; Figure 4 This paper illustrates a flowchart of a routing convergence method provided in an embodiment of this application. Figure 5 This paper illustrates another flowchart of the routing convergence method provided in an embodiment of this application; Figure 6 This paper illustrates a functional block diagram of a routing convergence device provided in an embodiment of this application. Figure 7 A functional block diagram of another routing convergence device provided in an embodiment of this application is shown. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can be arranged and designed in various different configurations.

[0023] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0024] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0025] Figure 2 Please refer to the block diagram of the routing processing system provided in the embodiments of this application. Figure 2 The system includes multiple internal VTEP devices, multiple external VTEP devices, and at least one central device. Each internal VTEP device communicates with multiple external VTEP devices through at least one central device.

[0026] In this embodiment, the internal VTEP device stores the mapping relationship between Category 1 routes and Category 5 routes, as well as the correspondence between the next-hop key value and the next-hop information. Each Category 1 route corresponds to multiple Category 5 routes, and each next-hop key value corresponds to multiple next-hop information.

[0027] In one possible implementation, an egress VTEP device refers to a VTEP device connected to an egress router, and each egress VTEP device can also communicate as an internal VTEP device. For example, please see [link to example]. Figure 1 Server 2 can also send data to server 1 through the export VTEP device.

[0028] In this embodiment, the central device refers to the core device in the data center network that undertakes route reflection and forwarding control functions, such as the Spine device. This device acts as a bridge connecting the internal VTEP device and the egress VTEP device in the control plane. It is responsible for receiving EVPN routing information from the egress VTEP device and reflecting it back to the internal VTEP device. At the same time, it forwards the routing update messages from the internal VTEP device to the corresponding egress VTEP device.

[0029] Optionally, a Type I route refers to an EVPN Type 1 route, which is used to announce the reachability or withdrawal message of a specific next-hop exit router to an exit VTEP device. A Type V route refers to an EVPN Type-5 route, which is used to carry routing information obtained by the exit VTEP device from the external network and convert it into EVPN routing format for announcement.

[0030] It should be noted that in standard EVPNs, Type 1 routes are originally used for reachability announcements of Ethernet segments in Layer 2 multi-homed scenarios. However, in this application, this route type is extended to support Layer 3 egress scenarios. In this embodiment, the ESI (Ethernet Segment Identifier) ​​field carried in Type 1 and Type 5 routes is customized to enable support for Layer 3 egress scenarios.

[0031] exist Figure 2 On this basis, Figure 3 This is a block diagram of a VTEP device provided in an embodiment of this application. It can be understood that the VTEP device refers to... Figure 2 The internal VTEP equipment and the export VTEP equipment.

[0032] Please see Figure 3 The VTEP device includes a memory, a processor, and a communication module. These components are electrically connected directly or indirectly to enable data transmission or interaction. For example, they can be electrically connected via one or more communication buses or signal lines.

[0033] Memory is used to store computer programs or data that can be executed by a processor. Memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc.

[0034] The processor is used to read / write data or computer programs stored in the memory, and execute the computer program to implement the routing convergence method provided in the embodiments of this application.

[0035] The communication module is used to establish communication connections between the VTEP device and other communication terminals via the network, and to send and receive data via the network.

[0036] It should be understood that, Figure 3 The structure shown is only a schematic diagram of the VTEP device; the VTEP device may also include components such as... Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown. Figure 3 The components shown can be implemented using hardware, software, or a combination thereof.

[0037] The following is based on the above. Figure 2 The routing convergence method provided in this application is illustrated by taking any internal VTEP device as the execution subject and combining it with the flowchart.

[0038] Specifically, Figure 4 For a flowchart illustrating the routing convergence method provided in this application embodiment, please refer to [link / reference]. Figure 4 The method includes: Step S20: Receive a route cancellation message sent by the central device.

[0039] One type of route cancellation message is generated and sent to the central device by any egress VTEP device when it determines that the next-hop egress router leading to any external route is unreachable, or by the central device when it determines that any egress VTEP device is faulty.

[0040] Step S21: Based on the Type I route cancellation message and the mapping relationship between Type I routes and Type V routes stored locally, determine multiple Type V routes to be cancelled.

[0041] In this embodiment, after receiving a Type I route cancellation message forwarded by the central device, the internal VTEP device can identify multiple Type V routes associated with the Type I route cancellation message by combining the mapping relationship between Type I routes and Type V routes maintained locally, and mark these Type V routes as pending cancellation status so that the invalidation processing operation of the next hop information can be performed subsequently.

[0042] During the execution of the above steps, the internal VTEP device first receives a type of route cancellation message sent by the central device. Understandably, this information originates from the egress VTEP device or the central device itself.

[0043] Specifically, when an egress VTEP device detects that the next-hop egress router leading to a certain external route is unreachable, the egress VTEP device will generate a corresponding Type I route revocation message to indicate that the corresponding Layer 3 egress path cannot achieve communication and needs to be revoked. This message is then sent to the central device via the EVPN control plane. Upon receiving the message, the central device reflects it back to all connected internal VTEP devices. Alternatively, when the central device detects a failure in an egress VTEP device (such as an interruption in EVPN neighbor relationships), it will also proactively generate and send a corresponding Type I route revocation message.

[0044] Since each Class I route corresponds to multiple Class V routes, when the internal VTEP device receives a Class I route cancellation message, it can search for multiple matching Class V routes in the locally maintained mapping relationship between Class I and Class V routes based on the cancellation message, and mark them as Class V routes to be cancelled. The next-hop information of these Class V routes to be cancelled all depend on the Layer 3 exit path identified by the cancelled Class I route, so subsequent invalidation processing is required to achieve fast convergence.

[0045] Understandably, the above steps can trigger a batch identification and processing mechanism for multiple Category 5 routes in the control plane through a route cancellation message, rather than processing each Category 5 route individually, thereby significantly shortening the convergence time when a Layer 3 exit failure occurs.

[0046] Step S22: Based on the correspondence between the next-hop key value in any of the five types of routes to be revoked and the next-hop key value and next-hop information stored locally, determine multiple target next-hop information and invalidate the multiple target next-hop information.

[0047] In this embodiment, after completing the identification of multiple Type 5 routes, the internal VTEP device can further determine multiple next-hop information associated with the next-hop key value based on the next-hop key value carried by these Type 5 routes and the correspondence between the next-hop key value and the next-hop information maintained locally, and mark these next-hop information as invalid, so as to realize the rapid switching of data plane forwarding paths.

[0048] During the execution of the above steps, the internal VTEP device has established a correspondence between the next-hop key value and the next-hop information. When a certain Class I route is revoked, the internal VTEP device can search for all the next-hop information associated with the key value in the locally maintained correspondence based on the next-hop key value in the revoked Class V route, and invalidate this next-hop information as the target next-hop information.

[0049] Specifically, the invalidation handling operation includes, but is not limited to, deleting the next-hop information from the forwarding table of the data plane, marking its status as unreachable, or removing it from the candidate set of forwarding path selection, thereby ensuring that subsequent data traffic will no longer use these invalidated next-hop paths.

[0050] Understandably, the above steps can be based on the correspondence between multiple next-hop information and a single next-hop key value, enabling batch processing of multiple next-hop information in the data plane instead of updating them one by one, thereby significantly improving the convergence efficiency of EVPN-VXLAN multi-homed networks in Layer 3 exit failure scenarios.

[0051] The routing convergence method provided in this application allows the egress VTEP device to generate a route cancellation message and send it to the internal VTEP device via a central device when the next-hop egress router leading to any external route is unreachable. Alternatively, the central device can generate a route cancellation message and send it to the internal VTEP device when any egress VTEP device is determined to be faulty. The internal VTEP device can then determine multiple Category 5 routes to be cancelled based on the route cancellation message and the mapping relationship between Category 1 and Category 5 routes stored locally. Subsequently, based on the next-hop key value in any Category 5 route to be cancelled and the correspondence between the next-hop key value and next-hop information stored locally, multiple target next-hop information is determined and invalidated. This allows for batch cancellation of multiple Category 5 routes using only one Category 1 route cancellation message in the control plane, and batch invalidation of multiple target next-hop information using the next-hop key value in any Category 5 route to be cancelled in the data plane. Therefore, it improves processing efficiency and shortens convergence time and service interruption duration.

[0052] In one possible implementation, each egress VTEP device is communicatively connected to at least one egress router to obtain multiple external routes through the at least one egress router.

[0053] In this embodiment, in the EVPN-VXLAN multihomed network architecture, the VTEP device, acting as the egress node, establishes a connection with the egress router in the external network to learn and obtain multiple external routing information from the egress router through standard routing protocols (such as BGP, OSPF, etc.).

[0054] It should be noted that the "exit router" here refers to a Layer 3 network device located at the data center boundary and used to connect to external IP networks (such as the Internet or corporate WAN), while the "exit VTEP device" refers to the VXLAN tunnel endpoint device in the EVPN-VXLAN network inside the data center, which is responsible for interacting with external routing information.

[0055] In this embodiment, five types of routes are generated by the egress VTEP device based on external routes, and each type of route corresponds to one external route; the next-hop key value in each type of route includes the device identifier of the egress router and the gateway identifier; the gateway identifier represents multiple external routes with the same next-hop egress router; each type of route is generated by the egress VTEP device based on the next-hop key value, and the next-hop key values ​​contained in each type of route are different.

[0056] In this embodiment, after the egress VTEP device learns external routes in its local routing table, it can convert these routing information into Type 5 routing format (EVPN Type 5 format) and propagate it through the EVPN control plane.

[0057] Specifically, after receiving external routing information published by the egress router, the egress VTEP device generates a corresponding EVPN Type 5 route for each external route. This route includes the destination network prefix, the next-hop address, and a custom ESI field. The ESI field is used to identify the Layer 3 egress path status to which the route belongs, and it contains the next-hop key value.

[0058] It should be noted that, for compatibility reasons, when deploying an egress router using a Layer 3 interface, a custom ESI field command can be configured in the egress VTEP device beforehand. When the egress VTEP device detects that a custom ESI field command is set, it generates the custom ESI field. If no custom ESI field command is set, the default standard ESI field will still be used.

[0059] During the execution of the above steps, the egress VTEP device can assign the same gateway identifier to multiple external routes with the same next-hop egress router, and generate a corresponding next-hop key value based on the gateway identifier. The next-hop key value is composed of the device identifier of the egress VTEP device (e.g., represented as ROUTER-ID) and the gateway identifier (e.g., represented as GW-ID).

[0060] It's important to note that the "gateway" here is not a single IP address in the traditional sense, but rather a set of reachability information shared by a group of external routes that share the same next-hop egress router. This gateway identifier is dynamically assigned locally on the device, requiring no manual configuration, and the gateway identifiers between different egress VTEP devices are independent and uncoupled. Furthermore, the next-hop egress router here can be a single egress router, or it could be multiple load balancer next-hop routers or a primary / backup next-hop router.

[0061] In one example, please see [link to example]. Figure 1 If the egress VTEP3 is connected to both egress router 1 and egress router 2, and learns external routes with the same prefix from both egress routers simultaneously and forms a load, then the egress VTEP3 can create a shared gateway for these two next-hop paths and assign a unique gateway identifier.

[0062] In one possible implementation, the next-hop key value carried in each EVPN Type 5 route includes the device identifier of the egress VTEP device and the aforementioned gateway identifier. This information is encapsulated in an ESI field, whose Type field is set to a custom specified value of 0xF0 to distinguish it from the ESI type used in standard EVPNs for Layer 2 multihoming scenarios, and the last byte is reserved, for example, set to 0.

[0063] In this embodiment, the encapsulation format of the ESI field can be 0xF0: <router-id> : <gw-id>:<reserved>, where, " <router-id> : <gw-id>This is the next-hop key value. Through this custom field value, EVPN Type 5 routes can not only carry reachability information for external routes, but also establish a logical binding relationship with EVPN Type 1 routes via the ESI field. Simultaneously, the outgoing VTEP device generates corresponding EVPN Type 1 routes based on this next-hop key value, where each Type 1 route corresponds to a unique next-hop key value. Understandably, in EVPN Type 1 routes, this next-hop key value is also encapsulated in the ESI field, with its Type field set to the custom specified value 0xF0, and the last byte reserved.

[0064] Specifically, the egress VTEP device can generate a Type 1 route for each gateway identifier. Since different gateway identifiers correspond to different next-hop paths, the next-hop key values ​​contained in each Type 1 route are different, thereby ensuring the distinguishability and independence between different types of egress paths.

[0065] It should be noted that the outgoing VTEP device sends EVPN Type 1 routes to the internal VTEP device before sending EVPN Type 5 routes. This ensures that the internal VTEP device has established control plane information for subsequent fault handling before receiving the Type 5 routes. This sequential operation is a crucial prerequisite for ensuring the correctness and stability of the fast convergence mechanism for Layer 3 outgoing faults in EVPN-VXLAN multi-homed networks.

[0066] Understandably, the implementation of the above relies on the unified management mechanism of routing information in the control plane of the egress VTEP device. That is, multiple external routes with the same next-hop egress router are aggregated by gateway identifier, and a unified next-hop key value is used to identify them in EVPN Type 5 routes. At the same time, an EVPN Type 1 route corresponding to the key value is generated to support the batch processing of multiple Type 5 routes by withdrawing the Type 1 route in the event of a failure.

[0067] For example, please continue to see Figure 1 Both outgoing router 1 (ROUTER-ID: 1.1.1.1) and outgoing router 2 (ROUTER-ID: 2.2.2.2) can reach 10 external routes from 10.1.1.0 / 24 to 10.1.10.0 / 24.

[0068] The egress router VTEP3 (ROUTER-ID: 3.3.3.3, VTEP-IP: 3.3.3.3) can learn these 10 external routes from egress router 1 and assign the same gateway identifier (e.g., GW-ID: 10001) to these routes, thus generating the correspondence between external routes, gateway identifiers, and next-hop devices as shown in Table 1. It should be noted that for egress router VTEP3, the configured ROUTER-ID is an identifier used in the BGP protocol to identify the logical identity of a routing device. In the EVPN control plane, it is used to construct the Ethernet Segment Identifier (ESI) field of EVPN routes, especially in Type 1 and Type 5 routes, where it combines with the gateway identifier to form a "next-hop key value," realizing the abstraction and binding of the egress path. VTEP-IP, on the other hand, is the actual encapsulation source address used in the data plane to establish VXLAN tunnels, determining the forwarding path of packets in the Overlay network. The values ​​of ROUTER-ID and VTEP-IP can be the same or different. Although in this example, ROUTER-ID and VTEP-IP have the same value (both are 3.3.3.3), they are functionally independent and can be configured with different addresses according to networking requirements. That is, ROUTER-ID is mainly used for control plane routing identification and fault propagation, while VTEP-IP is dedicated to data plane traffic encapsulation and tunnel communication.

[0069] Table 1

[0070] Subsequently, export VTEP3 can generate an ESI field with the format "0xF0:<3.3.3.3>:". <10001> : <0> The system generates an EVPN Type 1 route for each external route and a corresponding EVPN Type 5 route for each external route, carrying the same ESI field. In this ESI field, the next-hop key value is <3.3.3.3>. <10001> .

[0071] Furthermore, the outgoing VTEP3 can first send the EVPN Type 1 route to VTEP1 and VTEP2 through the Spine device, and then send the corresponding EVPN Type 5 route to VTEP1 and VTEP2 through the Spine device.

[0072] In addition, VTEP4 (ROUTER-ID: 4.4.4.4, VTEP-IP: 4.4.4.4) can perform a similar operation, generating an ESI field of "0xF0:<4.4.4.4>: <20001> The routing information ":0" is used to generate EVPN Type 1 routes and EVPN Type 5 routes, which are then sent to VTEP1 and VTEP2.

[0073] Optionally, when the internal VTEP device receives Type I and Type V routes, it can establish a mapping relationship between Type I and Type V routes, as well as a correspondence between the next-hop key value and the next-hop information.

[0074] In one possible implementation, before receiving a Type I route cancellation message from the central device, the internal VTEP device may receive at least one Type I route and multiple Type V routes sent by each egress VTEP device through the central device. Based on the next-hop key values ​​in each Type I route and each Type V route, a mapping relationship between Type I routes and Type V routes is established. Next-hop information is generated for each Type V route, and a correspondence between the next-hop key value and the next-hop information of the Type V routes is established.

[0075] In this embodiment, after receiving the EVPN Type 1 route and EVPN Type 5 route sent by the central device, the internal VTEP device can construct a logical mapping structure between the control plane and the data plane based on the next-hop key value (ROUTER-ID + GW-ID) carried in the route, thereby providing a mechanism basis for rapid convergence in the event of a subsequent Layer 3 egress path failure.

[0076] During the above steps, after completing external route learning and gateway identifier allocation, the outgoing VTEP device generates Type 1 routes and Type 5 routes carrying custom ESI content (Type field is 0xF0), and sends this routing information to the central device, which then reflects the routing information to each internal VTEP device within the data center.

[0077] After receiving Type 1 and Type 5 routes, each internal VTEP device first extracts the ROUTER-ID and GW-ID from the ESI field of the Type 1 route to form a next-hop key. This key is then associated with the corresponding Type 1 route to identify the reachability status of the outbound path. Subsequently, the internal VTEP device further extracts the same next-hop key carried in the Type 5 routes and establishes a mapping relationship between multiple Type 5 routes and their corresponding Type 1 routes based on this key. This mapping relationship ensures that when a Type 1 route is withdrawn, the internal VTEP device can quickly identify all Type 5 routes associated with that key and perform batch processing.

[0078] Furthermore, the internal VTEP device can generate corresponding next-hop information based on the destination network prefix information carried in each Type 5 route, and establish a correspondence between the next-hop key value and the next-hop information based on the next-hop key value in the Type 5 route. This next-hop information includes the VTEP IP address or VXLAN tunnel identifier of the egress VTEP device, used for forwarding decisions in the data plane. Through this mechanism, multiple Type 5 routes can share the same next-hop key value, thereby enabling batch update operations in the data plane without requiring separate next-hop switching for each route.

[0079] It should be noted that the mapping relationship of each Type 1 route corresponding to multiple Type 5 routes means that a Layer 3 gateway identified by a Type 1 route may correspond to multiple external routes carried by that gateway. These external routes are converted into EVPN Type 5 routes via the egress VTEP device and carry the same next-hop key value, thus forming a mapping relationship of one Type 1 route to multiple Type 5 routes on the internal VTEP device. Similarly, the mapping relationship of each next-hop key value corresponding to multiple next-hop information means that multiple Type 5 routes may share the same next-hop key value in the data plane, but correspond to different forwarding path information. For example, multiple route entries may share different tunnel paths or load-sharing groups of the same egress VTEP device. This next-hop information is managed uniformly through the same next-hop key value.

[0080] Therefore, the execution process described above achieves a collaborative mapping between the control plane and the data plane: on the one hand, Type 1 routes are used to maintain the reachability status of outbound paths; on the other hand, Type 5 routes are used to carry specific external routing information and establish a binding relationship with Type 1 routes through next-hop key values. This mapping mechanism not only improves the response efficiency of internal VTEP devices in the event of a fault, but also ensures the accuracy and consistency of route update operations.

[0081] Please refer to the example above. VTEP1 and VTEP2 can receive EVPN Type 1 routes and EVPN Type 5 routes sent by outgoing VTEP3 and outgoing VTEP4, extract the ROUTER-ID and GW-ID from the ESI field of the EVPN Type 1 and EVPN Type 5 routes as next-hop key values, and establish the following correspondence: The next-hop key value <3.3.3.3,10001> corresponds to a Type 1 route and multiple Type 5 routes (10.1.1.0 / 24 to 10.1.10.0 / 24); the next-hop key value <4.4.4.4,20001> corresponds to a Type 1 route and multiple Type 5 routes; each next-hop key value corresponds to a next-hop information (such as the VTEP IP address of VTEP3 or VTEP4).

[0082] Taking VTEP1 as an example, the correspondence between external routes, next-hop key values, and actual next-hop exit information can be formed as shown in Table 2.

[0083] Table 2

[0084] At this point, the traffic forwarded on VTEP1 to the aforementioned 10 network segments will be loaded onto VTEP3 and VTEP4. The processing logic of VTEP2 is exactly the same as that of VTEP1, and will not be elaborated here.

[0085] When the link between VTEP3 and egress router 1 is interrupted, VTEP3 can determine that the interface IP address to egress router 1 is unreachable based on the interface status being "DOWN". It then invalidates gateway 10001 and immediately sends a Type 1 route cancellation message to the central device, which reflects this cancellation message back to VTEP1. Understandably, this Type 1 route cancellation message should carry the next-hop key value <3.3.3.3,10001>.

[0086] VTEP1 extracts the next-hop key value <3.3.3.3,10001> from the Type 1 route cancellation information, finds its corresponding next-hop information and invalidates it (e.g., deletes it), thereby quickly switching all external routes that depend on VTEP3 to VTEP4, achieving rapid convergence of Layer 3 exit paths.

[0087] The following is based on the above. Figure 2 Taking any of the exit VTEP devices in the process as the execution subject, the routing convergence method provided in the embodiments of this application is described executively with reference to the flowchart.

[0088] Specifically, Figure 5 For another flowchart illustrating the routing convergence method provided in this application embodiment, please refer to [link / reference]. Figure 5 The method includes: Step S30: Determine that the next-hop exit router leading to any external route is unreachable.

[0089] In this embodiment, the egress VTEP device can determine whether the interface IP address to the corresponding egress router is reachable based on the interface status connected to the external route, and further determine whether the failure of the egress router results in the failure of any external route.

[0090] For example, please continue to see Figure 1 If VTEP3 is connected to both VTEP1 and VTEP2 and learns external routes with the same prefix from both VTEP3 and forms a load, then the next-hop VTEP3 leading to the corresponding external route is unreachable only if the links between VTEP3 and both VTEP1 and VTEP2 are interrupted.

[0091] Step S31: If the next-hop exit router leading to any external route is unreachable, a Type I route revocation message is generated and sent to the central device. The central device then sends the Type I route revocation message to each internal VTEP device. Each internal VTEP device determines multiple Type I routes to be revoked based on the Type I route revocation message sent by the central device and the mapping relationship between Type I routes and Type V routes stored locally. Based on the correspondence between the next-hop key value in any Type V route to be revoked and the next-hop key value and next-hop information stored locally, multiple target next-hop information is determined, and the multiple target next-hop information is invalidated.

[0092] In addition, the central equipment can also detect whether there is an abnormality in the outgoing VTEP equipment. If so, it will directly generate a route cancellation message for the outgoing VTEP equipment and send it to the internal VTEP equipment.

[0093] The routing convergence method provided in this application allows the egress VTEP device to generate a route cancellation message and send it to the internal VTEP device via a central device when the next-hop egress router leading to any external route is unreachable. Alternatively, the central device can generate a route cancellation message and send it to the internal VTEP device when any egress VTEP device is determined to be faulty. The internal VTEP device can then determine multiple Category 5 routes to be cancelled based on the route cancellation message and the mapping relationship between Category 1 and Category 5 routes stored locally. Subsequently, based on the next-hop key value in any Category 5 route to be cancelled and the correspondence between the next-hop key value and next-hop information stored locally, multiple target next-hop information is determined and invalidated. This allows for batch cancellation of multiple Category 5 routes using only one Category 1 route cancellation message in the control plane, and batch invalidation of multiple target next-hop information using the next-hop key value in any Category 5 route to be cancelled in the data plane. Therefore, it improves processing efficiency and shortens convergence time and service interruption duration.

[0094] The following provides a possible implementation method for generating a route cancellation message and sending it to the central device when the next-hop exit router leading to any external route is unreachable.

[0095] Specifically, if the next-hop exit router leading to any external route is unreachable, the exit VTEP device generates a route cancellation message based on the device identifier of the exit VTEP device and the gateway identifier corresponding to the external route, and sends the route cancellation message to the central device.

[0096] In this embodiment, if the next-hop exit router leading to any external route is unreachable, the exit VTEP device can generate a next-hop key value based on the device identifier of the exit VTEP device and the gateway identifier corresponding to the external route, and then generate a custom ESI field content, thereby generating a type of route revocation message.

[0097] In one example, please refer to Table 1 above. If VTEP3 determines that the interface IP address of the egress router 1 is unreachable, it can generate a next-hop key value <3.3.3.3,10001> based on the correspondence and VTEP3's ROUTER-ID (3.3.3.3) and GW-ID (10001). This generates a corresponding Class I route cancellation message and sends it to VTEP1 and VTEP2. VTEP1 and VTEP2 can then determine the Class V routes to be cancelled based on the next-hop key value <3.3.3.3,10001> in the Class I route cancellation message, and delete the next-hop information corresponding to <3.3.3.3,10001> in the data plane. It should be noted that although the Type I route cancellation message carries a next-hop key value, which can be used directly to invalidate the next-hop information, it is still necessary to first determine the Type V route to be cancelled, and then determine the target next-hop information. This necessity stems from the logical distinction and coordination mechanism between the control plane and the data plane at the semantic and operational levels in the EVPN-VXLAN network.

[0098] In order to perform the corresponding steps in the above embodiments and various possible methods, an implementation of a routing convergence device is given below.

[0099] Based on the above Figure 2 Any internal VTEP device in the system shall be the execution subject. Figure 6 For a functional block diagram of a routing convergence device provided in an embodiment of this application, please refer to [link / reference]. Figure 6 It should be noted that the routing convergence device provided in this embodiment has the same basic principle and technical effect as the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. The routing convergence device includes: a receiving module and an invalidation module.

[0100] The receiving module is used to receive a type of route cancellation message sent by the central device. The type of route cancellation message is generated and sent to the central device by any egress VTEP device when it is determined that the next-hop egress router leading to any external route is unreachable, or by the central device when it is determined that any egress VTEP device is faulty.

[0101] Understandably, the receiving module can also be used to perform the above step S20.

[0102] The receiving module is also used to determine multiple Category 5 routes to be revoked based on the Category 1 route revocation message and the mapping relationship between Category 1 routes and Category 5 routes stored locally.

[0103] Understandably, the receiving module can also be used to perform the above step S21.

[0104] The invalidation module is used to determine multiple target next-hop information based on the next-hop key value in any of the five types of routes to be revoked and the correspondence between the next-hop key value and the next-hop information stored locally, and to invalidate the multiple target next-hop information.

[0105] Understandably, this invalid module can also be used to perform step S22 above.

[0106] Optionally, the receiving module is further configured to receive at least one Class 1 route and multiple Class 5 routes sent by each egress VTEP device through the central device; establish a mapping relationship between Class 1 routes and Class 5 routes based on the next-hop key values ​​in each Class 1 route and each Class 5 route; generate corresponding next-hop information based on each Class 5 route, and establish a correspondence between the next-hop key value of the Class 5 route and the next-hop information.

[0107] Based on the above Figure 2 Any of the export VTEP devices in the system shall be the executing entity. Figure 7 For a functional block diagram of another routing convergence device provided in this application embodiment, please refer to... Figure 7 It should be noted that the routing convergence device provided in this embodiment has the same basic principle and technical effect as the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. The routing convergence device includes: a determination module and a generation module.

[0108] This determination module is used to determine that the next-hop exit router leading to any external route is unreachable.

[0109] Understandably, this determining module can also be used to perform the above step S30.

[0110] This generation module is used to generate a route withdrawal message and send it to the central device when the next-hop exit router leading to any external route is unreachable. The central device then sends the route withdrawal message to each internal VTEP device. Each internal VTEP device determines multiple Category 5 routes to be withdrawn based on the route withdrawal message sent by the central device and the mapping relationship between Category 1 routes and Category 5 routes stored locally. Based on the next-hop key value in any Category 5 route to be withdrawn and the correspondence between the next-hop key value and the next-hop information stored locally, it determines multiple target next-hop information and invalidates the multiple target next-hop information.

[0111] Understandably, this generation module can also be used to perform step S31 as described above.

[0112] Optionally, the generation module is also used to generate a route cancellation message based on the device identifier of the egress VTEP device and the gateway identifier corresponding to the external route when the next-hop egress router leading to any external route is unreachable, and send the route cancellation message to the central device.

[0113] Optionally, the above modules can be stored in the form of software or firmware. Figure 3 The memory shown is either stored in or embedded in the operating system (OS) of the VTEP device, and can be used by... Figure 3 The processor executes the commands. Meanwhile, the data and program code required to execute these modules can be stored in memory.

[0114] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, can implement the routing convergence method provided in this application.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0116] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0117] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0118] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. < / router-id> < / router-id>

Claims

1. A method of routing convergence, the method comprising: The method is applied to any internal VTEP device, which is communicatively connected with a plurality of external VTEP devices through at least one center device, and comprises the following steps: receiving a type-1 route revocation message sent by the center device; wherein the type-1 route revocation message is generated and sent to the center device by any of the external VTEP devices in the case that the next hop egress router to any external route is unreachable, or is generated by the center device in the case that any of the external VTEP devices is faulty; determining a plurality of type-5 routes to be revoked according to the type-1 route revocation message and a mapping relationship between type-1 routes and type-5 routes stored locally; determining a plurality of target next hop information according to the next hop key value in any of the type-5 routes to be revoked and a corresponding relationship between the next hop key value and the next hop information stored locally, and invalidating the plurality of target next hop information.

2. The method of claim 1, wherein, Before the step of receiving the type-1 route revocation message sent by the center device, the method further comprises the following steps: receiving at least one type-1 route and a plurality of type-5 routes sent by each of the external VTEP devices through the center device; establishing a mapping relationship between the type-1 routes and the type-5 routes according to the next hop key value in each of the type-1 routes and the next hop key value in each of the type-5 routes; generating corresponding next hop information according to each of the type-5 routes, and establishing a corresponding relationship between the next hop key value of the type-5 route and the next hop information.

3. The method of claim 2, wherein, Each of the external VTEP devices is communicatively connected with at least one egress router, and is configured to obtain a plurality of external routes through the at least one egress router; The type-5 route is generated by the external VTEP device according to the external route, and each of the type-5 routes corresponds to an external route; The next hop key value in each of the type-5 routes comprises a device identifier and a gateway identifier of the egress router; The gateway identifier represents a plurality of external routes having the same next hop egress router; Each of the type-1 routes is generated by the external VTEP device based on the next hop key value, and the next hop key value contained in each of the type-1 routes is different.

4. A method of routing convergence, c h a r a c t e r i z e d b y, The method is applied to any external VTEP device, which is communicatively connected with a plurality of internal VTEP devices through at least one center device, and comprises the following steps: determining that the next hop egress router to any external route is unreachable; In a case that a next hop egress router to any external route is unreachable, a class route revocation message is generated and sent to the center device, so that the center device sends the class route revocation message to each of the internal VTEP devices, each of the internal VTEP devices determines a plurality of to-be-revoked five-class routes according to the class route revocation message sent by the center device and a mapping relationship between a locally-stored class route and a five-class route, determines a plurality of target next hop information according to a next hop key value in any of the to-be-revoked five-class routes and a corresponding relationship between a locally-stored next hop key value and next hop information, and invalidates the plurality of target next hop information.

5. The method of claim 4, wherein, The generating and sending of the class route revocation message to the center device in a case that a next hop egress router to any external route is unreachable comprises: In a case that a next hop egress router to any external route is unreachable, the class route revocation message is generated according to a device identifier of the egress VTEP device and a gateway identifier corresponding to the external route, and the class route revocation message is sent to the center device.

6. A device for routing convergence, characterized in that, The application is applied to any internal VTEP device, the internal VTEP device is in communication connection with a plurality of egress VTEP devices through at least one center device, and the device comprises: A receiving module is configured to receive a class route revocation message sent by the center device, wherein the class route revocation message is generated by any of the egress VTEP devices in a case that a next hop egress router to any external route is determined to be unreachable and is sent to the center device, or is generated by the center device in a case that any of the egress VTEP devices is determined to be faulty; The receiving module is further configured to determine a plurality of to-be-revoked five-class routes according to the class route revocation message and a mapping relationship between a locally-stored class route and a five-class route; An invalidating module is configured to determine a plurality of target next hop information according to a next hop key value in any of the to-be-revoked five-class routes and a corresponding relationship between a locally-stored next hop key value and next hop information, and invalidate the plurality of target next hop information.

7. A device for routing convergence, characterized in that, The application is applied to any egress VTEP device, the egress VTEP device is in communication connection with a plurality of internal VTEP devices through at least one center device, and the device comprises: A determining module is configured to determine that a next hop egress router to any external route is unreachable; The generating module is configured to generate a type of route revocation message and send the type of route revocation message to the center device in a case where a next hop egress router to any external route is unreachable, so that the center device sends the type of route revocation message to each of the internal VTEP devices, each of the internal VTEP devices determines a plurality of to-be-revoked type 5 routes according to the type of route revocation message sent by the center device and a mapping relationship between a locally stored type of route and a type 5 route, determines a plurality of target next hop information according to a next hop key value in any of the to-be-revoked type 5 routes and a corresponding relationship between the next hop key value and next hop information stored locally, and invalidates the plurality of target next hop information.

8. A VTEP device, comprising: A computer program product comprising a processor and a memory storing a computer program executable by the processor, the processor being executable to implement the method of any one of claims 1-3, or the method of any one of claims 4-5.

9. A routing processing system characterized by, The VTEP device of claim 8.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program product is executable by the processor to implement the method of any one of claims 1-3, or the method of any one of claims 4-5.

Images