Route synchronization method and device based on VPP, equipment and storage medium
By creating a corresponding VRF instance for each namespace, the routing synchronization problem in VPP routing forwarding is solved, the normal forwarding of the namespace is achieved, and the reliability of the network is improved.
Patent Information
- Application Number
- CN202410295373.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-03-14
- Publication Date
- 2025-09-16
AI Technical Summary
In the VPP routing and forwarding solution, routes in multiple namespaces cannot be synchronized, resulting in routing conflicts in network isolation scenarios and the inability to implement normal forwarding.
A corresponding virtual routing forwarding VRF instance is created for each newly created namespace. Based on the correspondence between namespaces and VRF instances, the target VRF instance is determined to send update messages, so that routes in each namespace can be synchronized to the VPP to avoid routing conflicts.
The routes of each namespace are synchronized to VPP, avoiding routing conflicts and ensuring the reliability of normal forwarding.
Smart Images
Figure CN120658754A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of cloud computing technology, and in particular to a VPP-based routing synchronization method, apparatus, device, and storage medium. Background Art
[0002] As the SDN (Software Defined Network) architecture gradually replaces the original network architecture, the management of network equipment is becoming increasingly convenient. Drawing on the ideas of SDN, SDWAN (Software Defined Wide Area Network) is also gradually replacing the original WAN (Wide Area Network) network management, making WAN deployment, management, and maintenance increasingly convenient, saving costs and improving efficiency.
[0003] When customers need to communicate between locations, for example, between locations A and B, the SDWAN controller establishes a tunnel connection between the vCPE and the vPE. The routes for location A and location B are published and synchronized, enabling intercommunication between locations A and B. For cost considerations, SDWAN service providers share the vPE between different users, allowing multiple users to share a single vPE. In this case, a single vPE must support multiple tunnels, and the tunnels and routes for different users must be isolated.
[0004] In solutions using Vector Packet Processing (VPP) for routing and forwarding, a Virtual Routing and Rorwarding (VRF) is typically bound to the default namespace, synchronizing routes in the default namespace to VPP. However, in scenarios requiring network isolation, if there are multiple namespaces, routes from other namespaces cannot be synchronized to VPP, disrupting forwarding. Summary of the Invention
[0005] The present application provides a VPP-based route synchronization method, apparatus, device, and storage medium, which enable each namespace to synchronize routes to the VPP, avoid route conflicts, achieve normal forwarding, and have high reliability.
[0006] In a first aspect, the present application provides a VPP-based routing synchronization method, comprising:
[0007] For each newly created namespace, a virtual routing forwarding VRF instance corresponding to the namespace is created;
[0008] If there is an update message for a target namespace in each of the created namespaces, determine a target VRF instance corresponding to the target namespace based on a correspondence between namespaces and VRF instances;
[0009] The update message is sent to the target VRF instance, so that the target VRF instance processes the update message.
[0010] Optionally, after creating a virtual routing forwarding VRF instance corresponding to each newly created namespace, the method further includes:
[0011] placing a specified Vector Packet Processing (VPP) interface into the VRF instance and placing a kernel virtual interface corresponding to the VPP interface into the namespace;
[0012] The sending the update message to the target VRF instance includes:
[0013] The update message is sent to the target VRF instance by calling the VPP interface corresponding to the target VRF instance.
[0014] Optionally, placing the specified Vector Packet Processing (VPP) interface into the VRF instance and placing the kernel virtual interface corresponding to the VPP interface into the namespace includes:
[0015] Traversing the VPP interfaces to determine an idle VPP interface, and placing the VPP interface into the VRF instance;
[0016] A kernel virtual interface corresponding to the VPP interface is created, and the created kernel virtual interface is placed in the namespace.
[0017] Optionally, it also includes:
[0018] Check whether the kernel virtual interface corresponding to each created namespace has data reception;
[0019] When data is received by the kernel virtual interface corresponding to any namespace, the data is sent to the corresponding VRF instance based on the correspondence between the namespace and the VRF instance, so that the VRF instance processes the data.
[0020] Optionally, it also includes:
[0021] Use the socket netlink technology through VPP to monitor the update messages of each created namespace;
[0022] The update message includes at least one of routing update, interface status and address configuration.
[0023] Optionally, the VPP exists in the form of a process, and the method further includes:
[0024] When operating an interface in a target namespace, if the namespace where the VPP process is located is different from the target namespace, the VPP process is switched from the current namespace to the target namespace.
[0025] In a second aspect, the present application provides a VPP-based routing synchronization device, comprising:
[0026] A creation module, configured to create a virtual routing forwarding (VRF) instance corresponding to a newly created namespace for each newly created namespace;
[0027] a determination module configured to determine, when an update message exists for a target namespace in each of the created namespaces, a target VRF instance corresponding to the target namespace based on a correspondence between namespaces and VRF instances;
[0028] A sending module is configured to send the update message to the target VRF instance so that the target VRF instance processes the update message.
[0029] Optionally, it also includes:
[0030] a configuration module, configured to place a specified Vector Packet Processing (VPP) interface into the VRF instance, and place a kernel virtual interface corresponding to the VPP interface into the namespace;
[0031] The sending module is used to:
[0032] The update message is sent to the target VRF instance by calling the VPP interface corresponding to the target VRF instance.
[0033] In a third aspect, the present application provides an electronic device, comprising: a processor and a memory communicatively connected to the processor;
[0034] The memory stores computer-executable instructions;
[0035] The processor executes the computer-executable instructions stored in the memory to implement the VPP-based routing synchronization method as described in any one of the first aspects.
[0036] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the VPP-based routing synchronization method described in any one of the first aspects.
[0037] In a fifth aspect, the present application provides a computer program product, comprising computer-executable instructions, which, when executed by a processor, implement the VPP-based routing synchronization method described in any one of the first aspects.
[0038] The VPP-based routing synchronization method, apparatus, device, and storage medium provided in this application provide a VPP-based routing synchronization solution. For each newly created namespace, a corresponding VRF instance is created for the namespace, so that each created namespace has its own corresponding VRF instance. In this way, when an update message is received in any namespace, the corresponding VRF instance is determined based on the correspondence between the namespace and the VRF instance, and the update message is sent to the VRF instance. This solution enables routing synchronization of each namespace to the VPP, avoiding routing conflicts, achieving normal forwarding, and providing high reliability. BRIEF DESCRIPTION OF THE DRAWINGS
[0039] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0040] Figure 1 This is a schematic diagram of a regional exchange visit process provided by this application;
[0041] Figure 2 This is a schematic diagram of a routing synchronization process provided by this application;
[0042] Figure 3 This is a schematic diagram of an application scenario provided by this application;
[0043] Figure 4 This is a flowchart of a VPP-based routing synchronization method provided by this application;
[0044] Figure 5 This is a flowchart of another VPP-based routing synchronization method provided by this application;
[0045] Figure 6 This is a schematic diagram of another routing synchronization process provided by this application;
[0046] Figure 7 This is a schematic diagram of another routing synchronization process provided by this application;
[0047] Figure 8 This is a schematic diagram of the structure of a VPP-based routing synchronization device provided by this application;
[0048] Figure 9 This is a structural diagram of an electronic device provided by this application.
[0049] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION
[0050] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
[0051] The terms "first," "second," etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. In the description of the following embodiments, "plurality" means more than two, unless otherwise specifically defined.
[0052] In order to clearly understand the technical solution of the present application, the solution of the prior art is first introduced in detail.
[0053] With the development of cloud computing, an increasing number of cloud-native applications are running in the cloud. Simultaneously, more and more enterprises are migrating their applications to the cloud, significantly increasing the demand for network access for these applications. As SDN architectures gradually replace traditional network architectures, the management of network devices is becoming increasingly convenient. Inspired by SDN concepts, SDWAN is also gradually replacing traditional WAN network management, making WAN deployment, management, and maintenance increasingly convenient, saving costs while improving efficiency.
[0054] Figure 1 Indicates a regional visit process, such as Figure 1 As shown in the figure, when customers need to communicate between locations, for example, locations A and B, the SDWAN controller establishes a tunnel connection between the vCPE (virtual customer premises equipment) and the vPE (virtual premises equipment). The routes for location A and location B are published and synchronized, allowing locations A and B to communicate with each other.
[0055] For cost reasons, SDWAN service providers often share vPEs between different users, meaning multiple users share a single vPE for communication. In this case, a single vPE must support the creation of multiple tunnels, and the tunnels and routes for different users must be isolated.
[0056] In a solution that uses VPP for routing forwarding, VRF is generally bound to the default namespace, so that the routes under the default namespace are synchronized to VPP.
[0057] Figure 2 This shows a routing synchronization process, such as Figure 2 As shown in the following example, in the first scenario, multiple VPN (virtual private network) instances include "VPN-1" and "VPN-X." Each VPN instance has a corresponding subnet IP address. If VPN-1 is bound to the default namespace, the routes under namespace-X cannot be synchronized to the VPP. In the second scenario, multiple VPN instances include "VPN-1" and "VPN-2." The default namespace carries "VPN-1" and "VPN-2," resulting in a routing conflict. The IP addresses "192.168.1.0 / 24" and "192.168.1.X / 24" are examples only.
[0058] Therefore, in scenarios where network isolation is required, if there are multiple namespaces, the routes of other namespaces cannot be synchronized to the VPP, and normal forwarding cannot be achieved. If multiple different VPN tunnels are carried in a namespace, routing conflicts will occur.
[0059] In response to the technical problems existing in the related technologies, the present application provides a routing synchronization solution based on VPP. Every time a new namespace is created, a corresponding VRF instance is created for the namespace, so that each created namespace has its own corresponding VRF instance. In this way, when there is an update message in any namespace, the corresponding VRF instance is determined according to the correspondence between the namespace and the VRF instance, and the update message is sent to the VRF instance. In this way, this solution enables each namespace to synchronize its routing to VPP, avoids routing conflicts, realizes normal forwarding, and has high reliability.
[0060] The following describes the application scenarios of the VPP-based routing synchronization method provided in the embodiments of the present application.
[0061] Figure 3 This is a schematic diagram of an application scenario provided by this application. Figure 3As shown, this application scenario includes: Electronic Device 1. Electronic Device 1 is a device used to implement vPE. For cost considerations, SDWAN service providers share vPEs between different users, meaning multiple users share a single vPE for communication. In this case, a single vPE must support the creation of multiple tunnels, and the tunnels and routes of different users must be isolated. Electronic Device 1 implements resource isolation through namespaces and route isolation through VRF.
[0062] In this embodiment, each time the electronic device 1 creates a new namespace, it creates a corresponding VRF instance for the namespace, so that each created namespace has its own corresponding VRF instance. In this way, when there is an update message in any namespace, the corresponding VRF instance is determined based on the correspondence between the namespace and the VRF instance, and the update message is sent to the VRF instance, so that each namespace can be routed and synchronized to the VPP to achieve normal forwarding.
[0063] The following specific embodiments describe in detail the technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The execution subject of each embodiment provided in this application is a VPP-based routing synchronization device, which is integrated into an electronic device.
[0064] Figure 4 This is a flowchart of a VPP-based routing synchronization method provided by this application. Figure 4 As shown, the VPP-based routing synchronization method provided in this embodiment includes the following steps:
[0065] In step S101, for each newly created namespace, a VRF instance corresponding to the namespace is created.
[0066] The namespace refers to the network namespace. Multiple namespaces can be set in an electronic device to achieve resource isolation.
[0067] In this embodiment, each time a namespace is created, a VRF instance corresponding to the namespace is created, wherein the VRF instance exists in the form of a VPN instance, and the VPN instance is used to run in the namespace.
[0068] Step S102 : When there is an update message for a target namespace in each of the created namespaces, a target VRF instance corresponding to the target namespace is determined based on a correspondence between namespaces and VRF instances.
[0069] There are multiple namespaces created, and the target namespace refers to any one of the multiple namespaces created.
[0070] In this embodiment, each time a namespace and a VRF instance corresponding to the namespace are created, a correspondence between the namespace and the VRF instance is stored. Accordingly, the electronic device stores at least one correspondence.
[0071] Exemplarily, each namespace is monitored for update messages. If an update message exists in the target namespace, the at least one corresponding relationship is obtained, thereby determining the target VRF instance corresponding to the target namespace from the at least one corresponding relationship.
[0072] Exemplarily, the update message includes at least one of a routing update, an interface status, an address configuration, and other update messages.
[0073] Step S103: Send an update message to the target VRF instance, so that the target VRF instance processes the update message.
[0074] In this embodiment, after the target VRF instance is determined, an update message is sent to the target VRF instance so that the VRF instance processes the update message.
[0075] The present application provides a routing synchronization solution based on VPP. For each newly created namespace, a corresponding VRF instance is created for the namespace, so that each created namespace has its own corresponding VRF instance. In this way, when an update message is received in any namespace, the corresponding VRF instance is determined based on the correspondence between the namespace and the VRF instance, and the update message is sent to the VRF instance. As a result, this solution enables routing synchronization of each namespace to VPP, avoids routing conflicts, realizes normal forwarding, and has high reliability.
[0076] In an exemplary embodiment, both the VRF instance and the namespace receive data through an interface. Accordingly, after step S101, the following step S104 is further included:
[0077] Step S104: Place the designated VPP interface in the VRF instance, and place the kernel virtual interface corresponding to the VPP interface in the namespace.
[0078] The VPP provides multiple interfaces. One interface is selected from these interfaces and placed in a VRF instance, allowing the VRF instance to receive data through this interface. The selected VPP interface also includes a corresponding kernel virtual interface, through which the namespace receives data. Exemplarily, the kernel virtual interface is a kernel TUN (a type of virtual network device) virtual interface.
[0079] Accordingly, the implementation of step S103 includes:
[0080] Send an update message to the target VRF instance by calling the VPP interface corresponding to the target VRF instance.
[0081] In this embodiment, after creating a namespace and a corresponding VRF instance, corresponding interfaces are configured for the VRF instance and the namespace, respectively, so that the VRF instance and the namespace can receive data through the interfaces, providing support for data transmission and reception.
[0082] In an exemplary embodiment, the implementation of step S104 includes the following steps S1041-S1042:
[0083] Step S1041 , traverse the VPP interfaces to determine an idle VPP interface, and place the VPP interface in the VRF instance.
[0084] Step S1042 : Create a kernel virtual interface corresponding to the VPP interface, and place the created kernel virtual interface into the namespace.
[0085] Among them, VPP provides multiple interfaces. By traversing these multiple VPP interfaces, an idle VPP interface is determined and placed in the VRF instance. It should be noted that when traversing the VPP interfaces, loopback interfaces must be excluded.
[0086] This embodiment provides a specific solution for configuring interfaces. An idle VPP interface is selected by traversing VPP interfaces instead of creating a new VPP interface, thereby saving interface resources.
[0087] In an exemplary embodiment, the operation of monitoring whether there is an update message in each namespace can be implemented by VPP. Accordingly, the method provided by this application further includes:
[0088] VPP uses Netlink technology to monitor update messages for each created namespace. The Netlink mechanism implements communication through a set of special sockets. The detailed implementation of Netlink technology can be found in related articles and will not be detailed here.
[0089] In this embodiment, the update messages of each namespace are monitored through VPP, and the monitoring is performed directly using a common inter-process communication mechanism provided by Linux (an operating system kernel), namely, netlink technology. The monitoring method is easy to implement.
[0090] In addition to the above update messages, the namespace can also receive data through the kernel virtual interface. In an exemplary embodiment, the method provided by the present application also includes:
[0091] Check whether the kernel virtual interface corresponding to each created namespace has data reception;
[0092] When data is received by the kernel virtual interface corresponding to any namespace, the data is sent to the corresponding VRF instance based on the correspondence between the namespace and the VRF instance, so that the VRF instance processes the data.
[0093] The data exists in the form of data packets.
[0094] For example, the method of detecting whether the kernel virtual interface corresponding to each created namespace has data received can be implemented by VPP using the netlink technology.
[0095] Exemplarily, based on the correspondence between the namespace and the VRF instance, the manner of sending data to the corresponding VRF instance is the same as that of step S102 to step S103, and is not repeated here.
[0096] In this embodiment, by detecting whether the kernel virtual interface has data to receive, the data is sent to the corresponding VRF instance so that the VRF instance processes the data, thereby providing a path for the VRF instance to process the data.
[0097] In an exemplary embodiment, the VPP exists in the form of a process, and the method provided by the present application further includes:
[0098] When operating an interface in a target namespace, if the namespace where the VPP process is located is different from the target namespace, the VPP process is switched from the current namespace to the target namespace.
[0099] The interface refers to the kernel virtual interface. For example, the VPP process is located in the default namespace by default. Namespaces have corresponding identifiers. By comparing the identifier of the target namespace with the identifier of the namespace where the VPP process resides, the identity of the VPP process is determined to be the same as the target namespace. The identifier is used to distinguish between different namespaces and can be set as needed; this embodiment does not limit this.
[0100] In this embodiment, since the VPP process is located in a namespace, when the interface of the target namespace needs to be operated through the VPP process, the VPP process is switched from the current namespace to the target namespace, thereby facilitating the VPP process to operate the interface of the target namespace.
[0101] Figure 5 This is a flowchart of another VPP-based routing synchronization method provided by this application. Based on any of the above embodiments, this embodiment relates to a specific VPP-based routing synchronization process, such as Figure 5 As shown, the process includes the following steps:
[0102] In step S201, for each newly created namespace, a VRF instance corresponding to the namespace is created.
[0103] Step S202: traverse the VPP interfaces to determine an idle VPP interface, and place the VPP interface in the VRF instance.
[0104] Step S203: Create a kernel virtual interface corresponding to the VPP interface, and place the created kernel virtual interface into the namespace.
[0105] Step S204: Using the VPP and the netlink technology, monitor the update messages of each created namespace.
[0106] Step S205 : When there is an update message for the target namespace in each of the created namespaces, a target VRF instance corresponding to the target namespace is determined based on the correspondence between the namespace and the VRF instance.
[0107] Step S206: Send an update message to the target VRF instance by calling the VPP interface corresponding to the target VRF instance.
[0108] Step S207: Process the update message through the target VRF instance.
[0109] The implementation of each step in this embodiment refers to the above embodiment and will not be repeated here.
[0110] For example, Figure 6 This shows a routing synchronization process, such as Figure 6As shown, multiple VPN instances include "VPN-1", "VPN-X" and "VPN-Y", each VPN instance has a corresponding subnet IP address: "192.168.1.0 / 24", "192.168.1.X / 24" and "192.168.1.Y / 24", and each VPN instance is carried in a different namespace. Through the VPP-based routing synchronization method provided in this application, different VPN instances are isolated by namespace, and the network published by the client is synchronized to the namespace through the routing protocol. Since the namespace is bound to the VRF, the routing table can be synchronized to the VPP to achieve normal forwarding.
[0111] For example, Figure 7 This shows a routing synchronization process, such as Figure 7 As shown in the figure, a vPE supports multiple tunnels. Publishing network A and publishing network B share a vPE for communication. Tunnels and routes for different users are isolated by namespace. Publishing network A communicates via VPP-X and loop-X, while publishing network B communicates via VPP-Y and loop-Y. bgpd is an implementation of the BGP protocol (Border Gateway Protocol).
[0112] Figure 8 This is a schematic diagram of the structure of a VPP-based routing synchronization device provided by this application. Figure 8 As shown, in this embodiment, the VPP-based route synchronization device 300 can be set in an electronic device, and the VPP-based route synchronization device 300 includes:
[0113] A creation module 301 is configured to create a virtual routing forwarding (VRF) instance corresponding to each newly created namespace.
[0114] A determination module 302 is configured to determine a target VRF instance corresponding to the target namespace based on a correspondence between namespaces and VRF instances when an update message exists for the target namespace in each of the created namespaces;
[0115] The sending module 303 is configured to send the update message to the target VRF instance so that the target VRF instance processes the update message.
[0116] Optionally, it also includes:
[0117] A configuration module is used to place the specified Vector Packet Processing (VPP) interface into the VRF instance and place the kernel virtual interface corresponding to the VPP interface into the namespace;
[0118] The sending module 303 is used to:
[0119] Send an update message to the target VRF instance by calling the VPP interface corresponding to the target VRF instance.
[0120] Optionally, a configuration module is used to:
[0121] Traverse the VPP interfaces to identify an idle VPP interface and place the VPP interface in the VRF instance;
[0122] Create a kernel virtual interface corresponding to the VPP interface and place the created kernel virtual interface in the namespace.
[0123] Optionally, it also includes:
[0124] A detection module is used to detect whether the kernel virtual interface corresponding to each created namespace has data received;
[0125] The sending module 303 is further configured to, when the kernel virtual interface corresponding to any namespace receives data, send the data to the corresponding VRF instance based on the correspondence between the namespace and the VRF instance, so that the VRF instance processes the data.
[0126] Optionally, it also includes:
[0127] The monitoring module is used to monitor the update messages of each created namespace using the socket netlink technology through VPP;
[0128] The update message includes at least one of routing update, interface status and address configuration.
[0129] Optionally, the VPP exists in the form of a process and also includes:
[0130] The switching module is used to switch the VPP process from the current namespace to the target namespace when operating an interface in the target namespace if the namespace where the VPP process is located is different from the target namespace.
[0131] The VPP-based route synchronization device provided in this embodiment can implement the technical solution of the corresponding method embodiment. Its implementation principle and technical effects are similar to those of the corresponding method embodiment, and will not be described in detail here.
[0132] The embodiment of the present application further provides an electronic device. Exemplarily, the electronic device is a device for implementing vPE. Figure 9 This is a schematic diagram of the structure of an electronic device provided by this application. Figure 9 As shown, the electronic device 400 includes: a processor 401 and a memory 402 communicatively connected to the processor 401 .
[0133] The memory 402 stores computer-executable instructions; the processor 401 executes the computer-executable instructions stored in the memory 402 to implement the VPP-based routing synchronization method provided in this application.
[0134] In the embodiment of the present application, the memory 402 and the processor 401 are connected via a bus. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be classified as address buses, data buses, control buses, and the like. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.
[0135] In an exemplary embodiment, a computer-readable storage medium is further provided. The computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the VPP-based routing synchronization method provided in this application.
[0136] In an exemplary embodiment, a computer program product is further provided, including computer-executable instructions. When the computer-executable instructions in the computer program product are executed by a processor, the computer-executable instructions are used to implement the VPP-based routing synchronization method provided in the present application.
[0137] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all optional embodiments, and the actions and modules involved are not necessarily required by this application.
[0138] It should be further noted that, although the various steps in the flowchart are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps may be performed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but may be performed at different times. The execution order of these sub-steps or stages is not necessarily to be performed in sequence, but may be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.
[0139] It should be understood that the above-described device embodiments are merely illustrative, and the device of the present application may also be implemented in other ways. For example, the division of units / modules in the above-described embodiments is merely a logical functional division, and actual implementations may employ other division methods. For example, multiple units, modules, or components may be combined or integrated into another system, or some features may be omitted or not implemented.
[0140] In addition, unless otherwise specified, the functional units / modules in the various embodiments of the present application may be integrated into a single unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The aforementioned integrated units / modules may be implemented in the form of hardware or software program modules.
[0141] If the integrated unit / module is implemented in hardware, the hardware may be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor may be any appropriate hardware processor, such as a central processing unit (CPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a digital signal processor (DSP), a programmable logic device (PLD), a field programmable gate array (FPGA), a controller, a microcontroller, a microprocessor, or other electronic components. Unless otherwise specified, the memory can be implemented by any type of volatile or non-volatile memory device or a combination of them, such as a USB flash drive, random-access memory (RAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), enhanced dynamic random-access memory (EDRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), resistive random access memory (RRAM), high-bandwidth memory (HBM), hybrid memory cube (HMC), etc. Cube), magnetic storage, flash memory, magnetic disk, optical disk, mobile hard disk or disk and other media that can store program code.
[0142] If the integrated unit / module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a memory and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application.
[0143] In the above embodiments, the description of each embodiment has its own emphasis. For parts not described in detail in a particular embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined in any way. To keep the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0144] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.
[0145] It should be understood that the present application is not limited to the exact structure described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.
Claims
1. A routing synchronization method based on VPP, characterized in that: include: For each newly created namespace, a virtual routing forwarding VRF instance corresponding to the namespace is created; If there is an update message for a target namespace in each of the created namespaces, determine a target VRF instance corresponding to the target namespace based on a correspondence between namespaces and VRF instances; The update message is sent to the target VRF instance, so that the target VRF instance processes the update message.
2. The method according to claim 1, characterized in that After creating a virtual routing forwarding VRF instance corresponding to each newly created namespace, the method further includes: placing a specified Vector Packet Processing (VPP) interface into the VRF instance and placing a kernel virtual interface corresponding to the VPP interface into the namespace; The sending the update message to the target VRF instance includes: The update message is sent to the target VRF instance by calling the VPP interface corresponding to the target VRF instance.
3. The method according to claim 2, characterized in that Placing the specified Vector Packet Processing (VPP) interface into the VRF instance and placing the kernel virtual interface corresponding to the VPP interface into the namespace includes: Traversing the VPP interfaces to determine an idle VPP interface, and placing the VPP interface into the VRF instance; A kernel virtual interface corresponding to the VPP interface is created, and the created kernel virtual interface is placed in the namespace.
4. The method according to claim 2, characterized in that Also includes: Check whether the kernel virtual interface corresponding to each created namespace has data reception; When data is received by the kernel virtual interface corresponding to any namespace, the data is sent to the corresponding VRF instance based on the correspondence between the namespace and the VRF instance, so that the VRF instance processes the data.
5. The method according to claim 1, wherein Also includes: Use the socket netlink technology through VPP to monitor the update messages of each created namespace; The update message includes at least one of routing update, interface status and address configuration.
6. The method according to claim 1, characterized in that The VPP exists in the form of a process, and the method further includes: When operating an interface in a target namespace, if the namespace where the VPP process is located is different from the target namespace, the VPP process is switched from the current namespace to the target namespace.
7. A routing synchronization device based on VPP, characterized in that: include: A creation module, configured to create a virtual routing forwarding (VRF) instance corresponding to a newly created namespace for each newly created namespace; a determination module configured to determine, when an update message exists for a target namespace in each of the created namespaces, a target VRF instance corresponding to the target namespace based on a correspondence between namespaces and VRF instances; A sending module is configured to send the update message to the target VRF instance so that the target VRF instance processes the update message.
8. The device according to claim 7, characterized in that Also includes: a configuration module, configured to place a specified Vector Packet Processing (VPP) interface into the VRF instance, and place a kernel virtual interface corresponding to the VPP interface into the namespace; The sending module is used to: The update message is sent to the target VRF instance by calling the VPP interface corresponding to the target VRF instance.
9. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 6.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 6 when executed by a processor.