Border gateway communication method and apparatus, and border gateway

Abstract

The application provides a border gateway communication method and device and a border gateway, and belongs to the technical field of computers.The method is applied to a vector data packet processing framework, a routing protocol suite is loaded in the form of a plug-in in the vector data packet processing framework, and a routing table is stored in the memory of the vector data packet processing framework; the method comprises the following steps: judging whether the routing table needs to be updated; in the case that it is determined that the routing table needs to be updated, calling the routing protocol suite, updating the routing table by the routing protocol suite, and obtaining a new routing table for data transmission. The method avoids kernel bottlenecks and message loss risks, greatly simplifies a routing synchronization path, significantly improves the speed and scalability of protocol face routing loading, can support large-scale deployment, guarantees the real-time performance and accuracy of routing updating, and improves the routing loading speed and scale at the protocol level.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a border gateway communication method, a border gateway communication device, a border gateway, a machine-readable storage medium, and an electronic device. Background Technology

[0002] Existing open-source border gateway frameworks typically employ Free Range Routing (FRR) for protocol processing, supporting Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Intermediate System to Intermediate System (IS-IS). FRR's seamless integration with the native Linux / Unix IP kernel protocol stack makes it a general-purpose routing stack suitable for various use cases, including connecting hosts, virtual machines (VMs), and containers to the network, local area network (LAN) switching and routing, and internet access routers. The data plane uses a Vector Packet Processing (VPP) + Data Plane Development Kit (DPDK) architecture for high-speed packet forwarding. Communication between VPP and the Linux kernel protocol stack is achieved through the VPP Linux Control Plane (LCP) plugin. This plugin utilizes the kernel-user space communication mechanism (netlink) to listen for routing change messages from the kernel protocol stack. (See [link to relevant documentation]). Figure 1 , Figure 1 The diagram illustrates the existing architecture's communication path. The specific process is as follows: FRR first distributes the calculated routes to the Linux kernel protocol stack, and then the VPP LCP plugin synchronizes the routing events in the kernel to VPP, thereby ensuring consistency between the control plane and the data plane.

[0003] However, in large-scale deployment environments, the above architecture faces significant challenges. On the one hand, when the number of Virtual Routing and Forwarding (VRF) and Linux Bridges exceeds 10,000, the Linux kernel experiences a significant increase in resource consumption and a sharp decline in performance, making it unable to effectively support such a large number of network virtualization instances. On the other hand, the routing synchronization path is lengthy, involving multiple modules such as FRR, kernel, LCP plugin, and VPP, increasing system complexity and potential points of failure. Especially under high-load scenarios, netlink messages may be lost due to insufficient kernel processing capacity, leading to routing synchronization delays or failures, severely impacting network convergence speed and forwarding correctness. Furthermore, this tightly coupled synchronization mechanism also limits the system's scalability and flexibility, making it difficult to meet the demands of cloud data centers and large service providers for high-performance, highly reliable virtualized networks.

[0004] Therefore, existing border gateway communication methods cannot meet the performance requirements in large-scale environments. Summary of the Invention

[0005] The purpose of this invention is to provide a border gateway communication method, a border gateway communication device, a machine-readable storage medium, and an electronic device. This method completely bypasses the Linux kernel as an intermediate layer by directly integrating a routing protocol suite into the VPP as a plug-in. Routing information is directly loaded into the VPP's memory space by the FRR (Functional Routing Instance), without going through the kernel routing table, thus avoiding kernel bottlenecks and the risk of message loss. This architecture significantly simplifies the route synchronization path, significantly improves the speed and scalability of protocol plane route loading, and can easily support large-scale deployments of over 10,000 VRF instances, while ensuring the real-time and accuracy of route updates. This meets the requirements of modern large-scale network environments for high-performance forwarding and fast route convergence. It avoids the performance issues of the Linux kernel in large-scale environments and improves the speed and scale of protocol-level route loading.

[0006] To achieve the above objectives, a first aspect of this application provides a border gateway communication method applied to a vector packet processing framework, wherein a routing protocol suite is loaded into the vector packet processing framework as a plug-in, and the vector packet processing framework stores a routing table in its memory; the method includes: Determine whether the routing table needs to be updated; If it is determined that the routing table needs to be updated, the routing protocol suite is invoked to update the routing table, resulting in a new routing table for data transmission.

[0007] In the above technical solution, by loading the routing protocol suite as a plug-in within the vector packet processing framework, deep integration and efficient collaboration between the control plane and the data plane are achieved. The vector packet processing framework stores a routing table in its memory. The framework determines whether the routing table needs updating. If an update is required, the VPP directly calls the plug-in module loaded within it, namely the routing protocol suite. This suite is responsible for processing protocol packets and performing route calculation and optimization. After generating optimized routing information based on the protocol packet content, the routing protocol suite directly updates the routing table in the VPP, resulting in a new routing table used to guide the high-speed forwarding of subsequent data packets. By directly integrating the routing protocol suite as a plug-in within the VPP, the intermediate layer of the Linux kernel is completely bypassed. Routing information is directly loaded into the VPP's memory space by the FRR, without going through the kernel routing table, thus avoiding kernel bottlenecks and the risk of message loss. This architecture significantly simplifies the route synchronization path, substantially improves the speed and scalability of protocol plane route loading, and can easily support large-scale deployments of over 10,000 VRF instances while ensuring the real-time and accuracy of route updates. This meets the requirements of modern large-scale network environments for high-performance forwarding and fast route convergence. It avoids the performance issues of the Linux kernel in large-scale environments and improves the speed and scale of protocol-level route loading.

[0008] In this embodiment of the application, determining whether the routing table needs to be updated includes: Get data packets; Determine whether the data packet is a protocol message; If the data packet is determined to be a protocol message, then the routing table needs to be updated.

[0009] In the above technical solution, by determining whether the data packet is a protocol message, it is possible to quickly and accurately determine whether the routing table needs to be updated, making data transmission more reliable.

[0010] In this embodiment of the application, the routing protocol suite includes a routing information processing process and a protocol processing process; The step of updating the routing table by the routing protocol suite to obtain a new routing table for data transmission includes: The protocol processing process obtains first optimized routing information based on the data packets; The routing information processing process updates the routing table based on the first optimized routing information to obtain a new routing table.

[0011] In the above technical solution, the routing table in VPP is updated in real time based on optimized routing information from FRR, generating a new routing table. This process ensures that the routing information between the control plane and the data plane remains consistent, enabling VPP to forward packets based on the latest routing decisions when processing vectorized packets.

[0012] In this embodiment of the application, there are multiple protocol processing processes, and different protocol processing processes are used to process different types of protocol messages; The process of obtaining the first optimized routing information based on the data packet by the protocol processing process includes: The routing protocol suite determines the corresponding protocol processing process based on the protocol message type of the data packet; The corresponding protocol processing process obtains the first optimized routing information based on the data packet.

[0013] In the above technical solution, through a multi-process collaborative mechanism, the system can dynamically learn and optimize the routing information of multiple routing protocols, ensuring that network traffic is always transmitted along the optimal path, and significantly improving the network's convergence speed, stability and forwarding efficiency.

[0014] In this embodiment of the application, the routing information processing process includes a main thread and a data plane thread; The step of updating the routing table based on the first optimized routing information by the routing information processing process to obtain a new routing table includes: The main thread creates a context structure based on the first optimized routing information and puts the context structure into the data plane thread queue; The data plane thread extracts the context structure from the data plane thread queue and calls the processing function in the vector packet processing framework based on the routing information in the context structure; The processing function updates the routing table based on the routing information in the context structure to obtain a new routing table.

[0015] In the above technical solution, the FRR main thread achieves seamless integration with VPP, which not only maintains the original processing method of the main thread, but also asynchronously distributes routes through the data plane thread, which significantly improves the routing update efficiency and system stability in large-scale network environments.

[0016] In this embodiment of the application, it also includes: If it is determined that the routing table does not need to be updated, the data packet is forwarded based on the routing table.

[0017] In the above technical solution, the data packets are forwarded according to the current routing table, thereby ensuring the accurate transmission of the data packets.

[0018] In this embodiment of the application, determining whether the routing table needs to be updated includes: If the local state information in the vector packet processing framework is updated, it is determined that the routing table needs to be updated.

[0019] In the above technical solution, when the local state information in the VPP is updated, the route will change, thus determining that the routing table needs to be updated, which helps to improve the reliability of the routing table.

[0020] In this embodiment of the application, the routing protocol suite includes a routing information processing process and a protocol processing process; The step of updating the routing table by the routing protocol suite to obtain a new routing table for data transmission includes: The routing information processing process updates the local state data in the routing protocol suite and sends the updated local state data to the protocol processing process. The protocol processing process obtains the second optimized routing information based on the updated local state data; The routing information processing process updates the routing table based on the second optimized routing information to obtain a new routing table.

[0021] In the above technical solution, the routing information processing process and the protocol processing process within the FRR work together to achieve rapid response to changes in the VPP's local state. This design ensures that the control plane always makes routing decisions based on the latest local state, while avoiding the performance bottlenecks and message loss risks caused by the Linux kernel in traditional solutions, significantly improving the efficiency and reliability of route updates in large-scale network environments.

[0022] In this embodiment of the application, the step of updating the local state data in the routing protocol suite by the routing information processing process and sending the updated local state data to the protocol processing process includes: The routing information processing process obtains the event notification message issued by the vector packet processing framework and updates the local state data in the routing protocol suite based on the event notification message; After updating the local state data in the routing protocol suite, the routing information processing process sends the updated local state data to the protocol processing process.

[0023] In the above technical solution, FRR can efficiently complete the entire process from receiving VPP event notifications and updating local state data to distributing update information to various protocol processes. This design ensures that the control plane can respond to changes in the data plane's state in real time, laying a reliable foundation for subsequent route recalculation and high-speed forwarding.

[0024] A second aspect of this application provides a border gateway communication device applied to a vector packet processing framework, wherein a routing protocol suite is loaded into the vector packet processing framework as a plug-in, and the vector packet processing framework stores a routing table in its memory; the device includes: The determination module is used to determine whether the routing table needs to be updated; The update module is used to, when it is determined that the routing table needs to be updated, invoke the routing protocol suite to update the routing table and obtain a new routing table for data transmission.

[0025] A third aspect of this application provides a border gateway, including a vector data packet processing framework, wherein the border gateway communicates using the border gateway communication method described above.

[0026] A fourth aspect of this application provides an electronic device, the electronic device comprising: At least one processor; A memory connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the at least one processor implements the border gateway communication method described above by executing the instructions stored in the memory.

[0027] A fifth aspect of this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the aforementioned border gateway communication method. Attached Figure Description

[0028] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings: Figure 1 This schematic illustrates the existing architecture's communication path; Figure 2 The illustration shows a flowchart of a border gateway communication method according to an embodiment of this application; Figure 3 This schematic diagram illustrates the overall architecture according to an embodiment of the present application; Figure 4A schematic diagram illustrating the Zebra dplane processing procedure according to an embodiment of this application is shown. Figure 5 This illustration schematically shows a structural diagram of a border gateway communication device according to an embodiment of this application; Figure 6 The diagram illustrates the internal structure of a computer device according to an embodiment of this application.

[0029] Explanation of reference numerals in the attached figures 410 - Judgment Module; 420 - Update Module; A01 - Processor; A02 - Network Interface; A03 - Internal Memory; A04 - Display Screen; A05 - Input Device; A06 - Non-Volatile Storage Medium; B01 - Operating System; B02 - Computer Program. Detailed Implementation

[0030] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the scope of the present invention.

[0031] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with relevant laws and regulations. In the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0032] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0033] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0034] Terminology Explanation: VPP: An extensible framework that provides out-of-the-box switch / router functionality.

[0035] FRRouting (FRR): A suite of routing protocols that supports BGP, OSPF, Routing Information Protocol (RIP), IS-IS, Protocol Independent Multicast (PIM), Label Distribution Protocol (LDP), Bidirectional Forwarding Detection (BFD), Babel Routing Protocol (Babel), Policy-Based Routing (PBR), and other protocols.

[0036] Zebra: A daemon in FRR that is responsible for integrating updates from routing protocol daemons and building forwarding tables.

[0037] DPDK: A collection of function libraries and drivers for fast packet processing, which can greatly improve data processing performance and throughput, and increase the efficiency of data plane applications.

[0038] Please refer to Figure 2 , Figure 2 The illustration shows a flowchart of a border gateway communication method according to an embodiment of this application. This embodiment provides a border gateway communication method applied to a vector packet processing framework, wherein a routing protocol suite is loaded into the vector packet processing framework as a plug-in, and the vector packet processing framework stores a routing table in its memory; the method includes the following steps: Step 210: Determine whether the routing table needs to be updated; In this embodiment, the Routing Protocol Suite (FRR) can be loaded into the Vector Packet Processing Framework (VPP) as a plugin. That is, a plugin with routing protocol suite functionality exists within VPP; for example, this plugin can be named the VPP-FRR plugin. Building plugins in VPP is a standardized development process. VPP provides a complete toolchain and templates, which can be used to load FRR into VPP, and will not be elaborated further here. VPP can pre-store routing tables in its memory. These routing tables can be used to determine the optimal next-hop forwarding path based on the destination address of a data packet, thereby guiding the efficient and accurate transmission of data packets in the network. The determination of whether the routing table needs updating can be based on the data type of the data packet. If the data type of the data packet is a protocol message, it needs to be updated; otherwise, it does not. Alternatively, the determination of whether the routing table needs updating can be based on whether the local state information in VPP has been updated. If it has, it needs to be updated; otherwise, it does not. The local state information includes: local network interface state information, routing information, etc.

[0039] In some embodiments, determining whether the routing table needs to be updated includes: First, obtain the data packet; In this embodiment, the aforementioned data packet can refer to a data packet obtained from the computing node. The data packet can be message data, which can be a protocol message or a normal message. The acquisition can be achieved by using a data plane development kit to obtain the data packet from a network interface. The aforementioned network interface can be a physical or virtual network interface of the computing node.

[0040] In practical implementation, a Data Plane Development Kit (DPDK) driver can be configured. The DPDK driver transmits and receives packets with the VPP. The DPDK driver obtains data packets from the compute node and transmits them to the VPP via DPDK packet transmission and reception. DPDK can bypass the traditional operating system kernel protocol stack and achieve zero-copy, polling mode driving and batch processing by directly accessing the network interface card in user space. This significantly reduces packet processing latency and increases throughput, thereby helping to improve the efficiency of the VPP.

[0041] Then, determine whether the data packet is a protocol message; In this embodiment, VPP can parse the data packet after acquiring it, and determine whether it is a protocol message based on the parsed data. In a specific implementation, a node can be added to VPP to determine whether the data packet is a protocol process message. For example, if the parsed message port is 179 (BGP protocol), it indicates that it is a protocol message.

[0042] Then, if the data packet is determined to be a protocol message, it is determined that the routing table needs to be updated.

[0043] In this embodiment, if the data packet is a protocol message, then the routing table needs to be updated. Otherwise, the routing table does not need to be updated.

[0044] By determining whether a data packet is a protocol message, it is possible to quickly and accurately determine whether the routing table needs to be updated, making data transmission more reliable.

[0045] In some embodiments, determining whether the routing table needs to be updated includes: If the local state information in the vector packet processing framework is updated, it is determined that the routing table needs to be updated.

[0046] In this embodiment, local status information in VPP may change for various reasons, such as the administrator modifying the interface configuration via command line, or the physical link interruption triggering a link status change.

[0047] When the local state information in the VPP is updated, the routes change, thus indicating that the routing table needs to be updated, which helps improve the reliability of the routing table.

[0048] Step 220: If it is determined that the routing table needs to be updated, the routing protocol suite is invoked to update the routing table and obtain a new routing table for data transmission.

[0049] In this embodiment, if it is determined that the routing table needs to be updated, FRR can be invoked. FRR can process protocol messages and thus update the routing table. For example, if the data packet is a protocol message, FRR can be invoked; otherwise, it means it is not a protocol message, and the normal message processing flow is followed. Since FRR is a plugin in VPP, after determining that the data packet is a protocol message, this plugin can be invoked to send the data packet to the routing protocol suite.

[0050] In some embodiments, the routing protocol suite includes a routing information processing process and a protocol processing process; correspondingly, the step of updating the routing table by the routing protocol suite to obtain a new routing table for data transmission includes: First, the protocol processing process obtains first optimized routing information based on the data packet; In this embodiment, the protocol processing process refers to a specific routing protocol daemon running within the FRR protocol suite. Upon receiving a data packet, this process first performs integrity verification and parsing, extracting the advertised network layer reachability information and related path attributes (next hop, local priority, multi-exit discriminator, etc.). Then, the protocol processing process uses the protocol's built-in routing optimization algorithm to optimize the obtained routing information, obtaining the first optimized routing information. Taking BGP as an example, the process compares this route with existing routes with the same prefix in the local routing information database, comparing each step of the BGP decision-making process (including prioritizing routes with the highest weight, highest local priority, best next-hop metric, oldest route, lowest neighbor address, etc.) to ultimately determine an optimal path as the active route. For OSPF, the path with the lowest cost is selected by calculating the total link cost to the destination. If equal-cost multipaths exist, all equal-cost paths are included in the optimized routing information.

[0051] In some embodiments, the number of protocol processing processes is multiple, and different protocol processing processes are used to process different types of protocol messages; In this embodiment, FRR can adopt a multi-process architecture, which can contain multiple independently running daemons, each responsible for handling a specific dynamic routing protocol. For example, BGP can be handled by the BGP protocol process, OSPF by the OSPF protocol process, and IS-IS by the ISIS protocol process. This multi-process design isolates the protocol modules from each other, ensuring that a failure in one process will not affect the normal operation of other protocols, while also facilitating independent maintenance and expansion.

[0052] Accordingly, the step of obtaining the first optimized routing information by the protocol processing process based on the data packet includes: The first step is for the routing protocol suite to determine the corresponding protocol processing process based on the protocol message type of the data packet; In this embodiment, after the system receives a protocol message from the network interface, it performs preliminary parsing to identify the protocol message type. Identification criteria include the transport layer port number used by the message, IP protocol fields, or specific encapsulation formats. For example, if the destination port of the message is 179 and the transport layer protocol is TCP, it is determined to be a BGP protocol message and should be processed by the BGP protocol process; if the IP protocol number is 89, it is determined to be an OSPF protocol message and should be processed by the OSPF protocol process. After identifying the protocol type, the system distributes the message to the corresponding protocol process through an inter-process communication mechanism. Upon receiving the protocol message, the FRR forwards it to the appropriate protocol process according to the protocol type.

[0053] The second step involves the corresponding protocol processing process obtaining first optimized routing information based on the data packet.

[0054] In this embodiment, after receiving a message, the corresponding protocol processing process first performs integrity verification and detailed parsing on the message to extract network topology change information or route advertisement content. Taking the BGP update message as an example, the process parses out the network layer reachability information, withdrawn routes, and various path attributes contained in the message. Subsequently, the BGP protocol processing process optimizes the route according to multiple steps of the BGP decision-making process: it compares the newly received route with existing routes with the same prefix in the local BGP routing table, and compares attributes such as weight, local priority, origin type, next-hop metric, oldest route, and neighbor router identifier in turn, finally determining an optimal path as the active route, thus obtaining the first optimized route information.

[0055] Through the aforementioned multi-process collaborative mechanism, the system can dynamically learn and optimize routing information from various routing protocols, ensuring that network traffic is always transmitted along the optimal path, significantly improving the network's convergence speed, stability, and forwarding efficiency.

[0056] Then, the routing information processing process updates the routing table based on the first optimized routing information to obtain a new routing table.

[0057] In this embodiment, the routing information processing process can be the Zebra process. This process is responsible for collecting optimized routing information submitted by the protocol processing process after optimization, and uniformly optimizing and integrating the routes of these protocols. Finally, the determined best route is sent to the data plane to guide the actual data packet forwarding. Specifically, the Zebra process needs to synchronize the finally determined optimized routing information to the routing table in the VPP. The routing table stores the next-hop information and outgoing interface information of all active routes. Data plane packets can be forwarded through the routing table.

[0058] Through this mechanism, the routing table in VPP can be updated in real time based on optimized routing information from FRR, generating a new routing table. This process ensures that the routing information in the control plane and data plane remains consistent, enabling VPP to forward packets based on the latest routing decisions when processing vectorized packets.

[0059] In some embodiments, the routing information processing process includes a main thread and a data plane thread; In this embodiment, the main thread can be the Zebra main thread, and the data plane thread can be the Dplane thread. The main thread is responsible for communicating with the protocol processing process, collecting optimized routing information, and performing control plane tasks such as cross-protocol routing optimization; the data plane thread is specifically responsible for interacting with the data plane VPP. This architecture design, which separates the main thread and the data plane thread, can avoid time-consuming data plane synchronization operations from blocking the main thread's processing flow, thereby improving the system's concurrent processing capability and response speed.

[0060] Accordingly, the step of updating the routing table based on the first optimized routing information by the routing information processing process to obtain a new routing table includes: The first step is for the main thread to create a context structure based on the first optimized routing information and put the context structure into the data plane thread queue; In this embodiment, after the main thread receives the first optimized routing information from the protocol processing process, it first performs cross-protocol optimization on this information to determine the final route entries that need to be sent to the data plane. Then, the main thread creates a context structure for each route to be sent. This context structure is a data container encapsulating all necessary information, including at least the following fields: operation type (e.g., adding or deleting a route), destination network prefix, mask length, next-hop address, outgoing interface index, route metric, and route tag. Additionally, this structure may also contain identifiers for callbacks or status tracking to confirm the completion of the operation later. After creation, the main thread uses a thread-safe queue mechanism to place the context structure into the dedicated task queue of the data plane thread. This process is non-blocking; the main thread can continue processing other control plane tasks immediately after enqueuing, without waiting for the data plane operation to complete.

[0061] The second step involves the data plane thread extracting the context structure from the data plane thread queue and calling the processing function in the vector packet processing framework based on the routing information in the context structure. In this embodiment, the data plane thread can be created during system initialization and enter an infinite loop to continuously monitor its task queue. When there is a context structure to be processed in the queue, the thread retrieves it in a first-in, first-out order. After retrieval, the data plane thread parses the routing information in the context structure, extracts the operation type and routing parameters, and determines the VPP processing function to be called based on these parameters.

[0062] The third step involves the processing function updating the routing table based on the routing information in the context structure to obtain a new routing table.

[0063] In this embodiment, the aforementioned processing function can perform the actual routing table update operation. This function can parse routing information and write it into the VPP's routing table. Specifically, the VPP will look up or create the corresponding routing entry in the routing table based on the destination network prefix, and set the next-hop information and outgoing interface information. If the operation type is adding a route, the new routing entry is inserted into the routing table; if it is deleting a route, the corresponding entry is removed from the routing table; if it is modifying a route, the attributes of the existing entry are updated. After the update is complete, the VPP's routing table becomes the new routing table, and subsequent arriving data packets will be forwarded based on this new table during vectorization processing.

[0064] For example, to achieve efficient communication between the main thread and the data plane thread, a dedicated data structure, `zebra_dplane_ctx` (data plane context structure), is defined. This structure serves as the carrier for transmitting routing information between the two, encapsulating all necessary routing attributes and operation instructions. After generating route entries to be issued, the main thread first allocates and populates a `zebra_dplane_ctx` structure instance, and then places this context structure into the dedicated task queue of the data plane thread through a thread-safe queue mechanism. When there are `zebra_dplane_ctx` entries to be processed in the queue, the dplane thread retrieves them in a first-in, first-out order, processes the ctx information using the function `vpp_dplane_process_func`, and then calls the corresponding processing function (e.g., route addition / deletion function) to perform the actual routing table update operation.

[0065] Through the above mechanism, FRR zebra achieves seamless integration with VPP, maintaining the original processing method of the main thread while asynchronously distributing routes through the data plane thread, significantly improving the routing update efficiency and system stability in large-scale network environments.

[0066] In some embodiments, it also includes: If it is determined that the routing table does not need to be updated, the data packet is forwarded based on the routing table.

[0067] In this embodiment, when the routing table does not need to be updated, it indicates that the current data packet is not a protocol message and can follow the normal message processing procedure, that is, the data packet is forwarded according to the current routing table, thereby ensuring the accurate transmission of the data packet.

[0068] In some embodiments, when the local state information in the VPP is updated, the routing protocol suite includes a routing information processing process and a protocol processing process; correspondingly, the updating of the routing table by the routing protocol suite to obtain a new routing table for data transmission includes: First, the routing information processing process updates the local state data in the routing protocol suite and sends the updated local state data to the protocol processing process. In this embodiment, the FRR maintains a local state data set, which mainly includes local network interface state information (such as interface link status, interface IP address, interface index, etc.) and local routing information (such as directly connected routes, static routes, and routing entries learned from various protocol neighbors). The data structure in the FRR records this information for subsequent route optimization and other processing. When the local state information in the VPP is updated, these changes need to be fed back to the routing protocol suite in real time to ensure that the local state data within the protocol suite is consistent with the actual state of the underlying data plane. Specifically, after detecting a change in local state, the VPP can transmit the change information to the routing protocol suite through a callback mechanism or event notification channel defined within the plugin. Upon receiving these updates, the routing protocol suite first modifies the internally recorded local state data accordingly to ensure that the FRR always has accurate local network topology information. During operation, the FRR can make routing decisions in real time based on this local state data. For example, when an interface link is disconnected, the FRR needs to cancel routes reachable through that interface; when the interface IP address changes, the relevant routing entries need to be recalculated.

[0069] Then, the protocol processing process obtains the second optimized routing information based on the updated local state data; In this embodiment, after receiving updated local state data, the protocol processing process can assess the impact of these changes on the current route and trigger a corresponding route recalculation process. Based on its respective protocol's routing algorithm, the protocol processing process combines the updated local state data with routing information collected from neighbors to re-run the optimization logic, generating a set of optimized routing information. This optimized routing information includes route entries that need to be added, modified, or withdrawn. Each entry contains complete attributes such as destination network, mask, next hop, outgoing interface, and route priority.

[0070] Finally, the routing information processing process updates the routing table based on the second optimized routing information to obtain a new routing table.

[0071] In this embodiment, the above update process is the same as the update process when the data packet is a protocol message, and will not be described again here.

[0072] Through the steps described above, the routing information processing process and protocol processing process within the FRR work together to achieve rapid response to changes in the VPP's local state. This design ensures that the control plane always makes routing decisions based on the latest local state, while avoiding the performance bottlenecks and message loss risks associated with traditional solutions that rely on the Linux kernel. This significantly improves the efficiency and reliability of route updates in large-scale network environments.

[0073] In some embodiments, the step of updating the local state data in the routing protocol suite by the routing information processing process and sending the updated local state data to the protocol processing process includes: The first step is for the routing information processing process to obtain the event notification message sent by the vector packet processing framework, and update the local state data in the routing protocol suite based on the event notification message; In this embodiment, when the local state in the VPP changes, the VPP can use the event notification mechanism defined within its plugin framework to transmit these changes to the FRR in real time via event notification messages. These event notification messages can be encapsulated in a standardized format, including the event type (e.g., interface state change, address change), the object identifier where the event occurred (e.g., interface index, VRF ID), and the specific parameters after the change (e.g., new state, new IP address). For example, the types of the aforementioned event notification messages include: LINK, the function vpp_link_change: creates, deletes, or updates information about network devices, including VRF, bridge-dominant, loop, interface, and other devices.

[0074] ADDR, the function vpp_addr_change: creates, deletes, or updates IP information for network devices.

[0075] ROUTE, the function vpp_route_change: creates, deletes, or updates routing information for network devices.

[0076] NEIGH, the function vpp_neigh_change: creates, deletes, or updates neighbor information for network devices.

[0077] RULE, the processing function vpp_rule_change: creates, deletes, or updates routing rule information.

[0078] Upon receiving these event notification messages, FRR first parses and validates the messages to confirm their legality and completeness. Then, based on the parsing results, the main thread updates its internally maintained local state database accordingly. Specifically, the main thread locates the affected interfaces or network objects and modifies their state fields or configuration parameters. For example, it adds or deletes specified IP addresses from the interface's IP address list. This update process ensures that the local network state perceived by FRR remains consistent with the actual state of the VPP data plane.

[0079] The second step involves the routing information processing process sending the updated local state data to the protocol processing process after the local state data in the routing protocol suite has been updated.

[0080] In this embodiment, after the main thread completes the update of its local state data, it needs to promptly notify all protocol processing processes that depend on this information. The main thread can use inter-process communication mechanisms to encapsulate the updated local state data into a specialized message format and send it to the protocol processing processes. The content sent can be a complete copy of the local state database or an incremental update containing only the changed parts, depending on the implementation strategy and the scale of the network environment. For incremental updates, the main thread constructs a concise event message containing only the changed objects and their old and new values ​​to reduce data transmission overhead and processing latency. After receiving these messages, each protocol processing process synchronously updates its internally maintained local state copy to ensure consistency with the main thread's local state data. After synchronization, the protocol processing processes can re-evaluate the effectiveness of existing routes based on the latest local state data and trigger the necessary route recalculation process to generate optimized route information, which is finally returned to the main thread for distribution to the VPP data plane.

[0081] Through the steps described above, FRR can efficiently complete the entire process from receiving VPP event notifications and updating local state data to distributing update information to various protocol processes. This design ensures that the control plane can respond to changes in the data plane's state in real time, laying a reliable foundation for subsequent route recalculation and high-speed forwarding.

[0082] In the above implementation, by loading the routing protocol suite as a plug-in within the vector packet processing framework, deep integration and efficient collaboration between the control plane and the data plane are achieved. The vector packet processing framework stores a routing table in its memory. The framework determines whether the routing table needs updating. If an update is needed, the routing protocol suite is invoked to update the routing table, resulting in a new routing table for data transmission. When an update is required, VPP directly calls the plug-in module, the routing protocol suite, which processes protocol packets and performs route calculation and optimization. After generating optimized routing information based on the protocol packet content, the routing protocol suite directly updates the routing table in VPP, resulting in a new routing table to guide high-speed forwarding of subsequent data packets. By directly integrating the routing protocol suite as a plug-in within VPP, the intermediate layer of the Linux kernel is completely bypassed. Routing information is directly loaded into VPP's memory space by FRR, without going through the kernel routing table, avoiding kernel bottlenecks and the risk of message loss. This architecture significantly simplifies the route synchronization path, substantially improves the speed and scalability of protocol plane route loading, and can easily support large-scale deployments of over 10,000 VRF instances while ensuring the real-time and accuracy of route updates. This meets the requirements of modern large-scale network environments for high-performance forwarding and fast route convergence. It avoids the performance issues of the Linux kernel in large-scale environments and improves the speed and scale of protocol-level route loading.

[0083] The following examples illustrate the solution; please refer to them. Figure 3 , Figure 3 The diagram schematically illustrates the overall architecture according to an embodiment of this application. The SDN controller manages the VPP using the NETCONF protocol through the configuration plane. A new `frr-input` node is added to the VPP, used to determine whether the acquired data packet belongs to a protocol process. The VPP-FRR plugin processes protocol packets and includes a protocol process and a routing information processing process. The protocol processes include ISIS, BGP, and OSPF processes. The VPP acquires data packets from the compute nodes through the DPDK driver.

[0084] First, if parsing the data packet reveals that the packet port is 179 (BGP protocol), it is sent to the BGP process in the VPP-FRR plugin for protocol packet processing. If it is not a protocol packet, the normal packet processing flow is followed.

[0085] Then, VPP-FRR optimizes the routing information and loads it into the VPP's forwarding table via the FRR Zebra process. Data plane packets are then forwarded through the forwarding table.

[0086] Please refer to the following: Figure 4 , Figure 4 The diagram illustrates the Zebra dplane processing procedure according to an embodiment of this application. The Zebra dplane processing procedure includes: The FRR zebra main thread processing method remains unchanged; `zebra_dplane_ctx` is a structure used for communication routing information between the zebra main thread and the dplane thread. The dplane thread function `vpp_dplane_process_func` processes the `ctx` information, calls the `vpp_put_msg` function to set the corresponding memory area for the VPP API Request / dump based on the operation type of `zebra_dplane_ctx`, and finally implements the routing information in VPP through the VPP API interface. The zebra main thread also obtains the message type returned by the VPP API, processes it, and sends it to the protocol process.

[0087] The above steps enable bidirectional state synchronization between the VPP and FRR: on one hand, the VPP receives protocol messages from the network and hands them over to the FRR for processing, generating a route update data plane; on the other hand, local state changes in the VPP are also synchronized back to the FRR, triggering route recalculation and updates. This closed-loop bidirectional synchronization mechanism ensures that the control plane always makes routing decisions based on the latest local state, avoiding routing black holes or forwarding errors caused by state inconsistencies. Furthermore, since all interactions are completed within the VPP, without going through the Linux kernel, the entire process is efficient, low-latency, and supports large-scale VRF instances and frequent state changes, significantly improving the system's robustness and scalability, and meeting the high-performance requirements of large-scale network environments.

[0088] This embodiment also provides a border gateway, including a vector data packet processing framework, wherein the border gateway communicates using the border gateway communication method described above.

[0089] In this embodiment, the routing protocol suite is loaded as a plug-in within the vector packet processing framework, achieving deep integration and efficient collaboration between the control plane and the data plane. The vector packet processing framework stores a routing table in its memory. The framework determines whether the routing table needs updating; if it does, the routing protocol suite is invoked to update the routing table, resulting in a new routing table for data transmission.

[0090] When a data packet is identified as a protocol message, VPP directly invokes the internal plugin module, the routing protocol suite, which handles the protocol message and performs route calculation and optimization. After generating optimized routing information based on the protocol message content, the routing protocol suite directly updates the routing table in VPP, resulting in a new routing table to guide the high-speed forwarding of subsequent data packets. By integrating the routing protocol suite directly into VPP as a plugin, the intermediate layer of the Linux kernel is completely bypassed. Routing information is loaded directly into VPP's memory space by FRR, without going through the kernel routing table, avoiding kernel bottlenecks and the risk of message loss. This simplifies the route synchronization path, significantly improving the speed and scalability of protocol plane route loading, easily supporting large-scale deployments of over 10,000 VRF instances while ensuring the real-time and accuracy of route updates, thus meeting the requirements of modern large-scale network environments for high-performance forwarding and fast route convergence. It avoids the performance issues of the Linux kernel in large-scale environments, improving the speed and scale of protocol-level route loading.

[0091] Please refer to Figure 5 , Figure 5 This illustration schematically shows a structural diagram of a border gateway communication device according to an embodiment of this application. This embodiment also provides a border gateway communication device applied to a vector packet processing framework, wherein a routing protocol suite is loaded into the vector packet processing framework as a plug-in, and the vector packet processing framework stores a routing table in its memory; the device includes a judgment module 410 and an update module 420, wherein: The judgment module 410 is used to determine whether the routing table needs to be updated; The update module 420 is used to call the routing protocol suite when it is determined that the routing table needs to be updated, so that the routing protocol suite updates the routing table to obtain a new routing table for data transmission.

[0092] The border gateway communication device includes a processor and a memory. The aforementioned judgment module 410 and update module 420 are stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0093] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and border gateway communication is performed by adjusting kernel parameters.

[0094] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0095] This invention provides a machine-readable storage medium storing a program that, when executed by a processor, implements the border gateway communication method.

[0096] This invention provides a processor for running a program, wherein the program executes the border gateway communication method during runtime.

[0097] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor A01, a network interface A02, a display screen A04, an input device A05, and a memory (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A06. The non-volatile storage medium A06 stores an operating system B01 and a computer program B02. The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A06. The network interface A02 is used for communication with external terminals via a network connection. When the computer program is executed by the processor A01, it implements a border gateway communication method. The display screen A04 can be a liquid crystal display (LCD) or an e-ink display. The input device A05 can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0098] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0099] In one embodiment, the border gateway communication device provided in this application can be implemented as a computer program, which can be implemented in the form of, for example, Figure 6 The computer device shown runs on this device. The computer device's memory can store the various program modules that make up the border gateway communication device, for example, Figure 5 The determination module 410 and update module 420 are shown. The computer program, composed of these various program modules, causes the processor to execute the steps in the border gateway communication methods of the various embodiments of this application described in this specification.

[0100] Figure 6 The computer equipment shown can be used as follows Figure 5 The judgment module 410 in the border gateway communication device shown executes step 210, and the update module 420 executes step 220.

[0101] This application provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. The device is applied to a vector packet processing framework, and a routing protocol suite is loaded into the vector packet processing framework as a plug-in. The vector packet processing framework stores a routing table in its memory. When the processor executes the program, it performs the following steps: Determine whether the routing table needs to be updated; If it is determined that the routing table needs to be updated, the routing protocol suite is invoked to update the routing table, resulting in a new routing table for data transmission.

[0102] In one embodiment, determining whether the routing table needs to be updated includes: Get data packets; Determine whether the data packet is a protocol message; If the data packet is determined to be a protocol message, then the routing table needs to be updated.

[0103] In one embodiment, the routing protocol suite includes a routing information processing process and a protocol processing process; The step of updating the routing table by the routing protocol suite to obtain a new routing table for data transmission includes: The protocol processing process obtains first optimized routing information based on the data packets; The routing information processing process updates the routing table based on the first optimized routing information to obtain a new routing table.

[0104] In one embodiment, the number of protocol processing processes is multiple, and different protocol processing processes are used to process different types of protocol messages; The process of obtaining the first optimized routing information based on the data packet by the protocol processing process includes: The routing protocol suite determines the corresponding protocol processing process based on the protocol message type of the data packet; The corresponding protocol processing process obtains the first optimized routing information based on the data packet.

[0105] In one embodiment, the routing information processing process includes a main thread and a data plane thread; The step of updating the routing table based on the first optimized routing information by the routing information processing process to obtain a new routing table includes: The main thread creates a context structure based on the first optimized routing information and puts the context structure into the data plane thread queue; The data plane thread extracts the context structure from the data plane thread queue and calls the processing function in the vector packet processing framework based on the routing information in the context structure; The processing function updates the routing table based on the routing information in the context structure to obtain a new routing table.

[0106] In one embodiment, it also includes: If it is determined that the routing table does not need to be updated, the data packet is forwarded based on the routing table.

[0107] In one embodiment, determining whether the routing table needs to be updated includes: If the local state information in the vector packet processing framework is updated, it is determined that the routing table needs to be updated.

[0108] In one embodiment, the routing protocol suite includes a routing information processing process and a protocol processing process; The step of updating the routing table by the routing protocol suite to obtain a new routing table for data transmission includes: The routing information processing process updates the local state data in the routing protocol suite and sends the updated local state data to the protocol processing process. The protocol processing process obtains the second optimized routing information based on the updated local state data; The routing information processing process updates the routing table based on the second optimized routing information to obtain a new routing table.

[0109] In one embodiment, the step of updating the local state data in the routing protocol suite by the routing information processing process and sending the updated local state data to the protocol processing process includes: The routing information processing process obtains the event notification message issued by the vector packet processing framework and updates the local state data in the routing protocol suite based on the event notification message; After updating the local state data in the routing protocol suite, the routing information processing process sends the updated local state data to the protocol processing process.

[0110] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0111] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0112] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0113] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0114] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0115] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0116] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0117] It should also be noted that 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 that element.

[0118] The above are merely embodiments of this application and are not intended to limit the scope of 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 scope of the claims of this application.

Claims

1. A border gateway communication method, characterized in that, The method is applied to a vector packet processing framework, in which a routing protocol suite is loaded as a plugin, and the framework stores a routing table in its memory; the method includes: Determine whether the routing table needs to be updated; If it is determined that the routing table needs to be updated, the routing protocol suite is invoked to update the routing table, resulting in a new routing table for data transmission.

2. The border gateway communication method according to claim 1, characterized in that, The step of determining whether the routing table needs to be updated includes: Get data packets; Determine whether the data packet is a protocol message; If the data packet is determined to be a protocol message, then the routing table needs to be updated.

3. The border gateway communication method according to claim 2, characterized in that, The routing protocol suite includes a routing information processing process and a protocol processing process; The step of updating the routing table by the routing protocol suite to obtain a new routing table for data transmission includes: The protocol processing process obtains first optimized routing information based on the data packets; The routing information processing process updates the routing table based on the first optimized routing information to obtain a new routing table.

4. The border gateway communication method according to claim 3, characterized in that, There are multiple protocol processing processes, and different protocol processing processes are used to process different types of protocol messages. The process of obtaining the first optimized routing information based on the data packet by the protocol processing process includes: The routing protocol suite determines the corresponding protocol processing process based on the protocol message type of the data packet; The corresponding protocol processing process obtains the first optimized routing information based on the data packet.

5. The border gateway communication method according to claim 3, characterized in that, The routing information processing process includes a main thread and a data plane thread; The step of updating the routing table based on the first optimized routing information by the routing information processing process to obtain a new routing table includes: The main thread creates a context structure based on the first optimized routing information and puts the context structure into the data plane thread queue; The data plane thread extracts the context structure from the data plane thread queue and calls the processing function in the vector packet processing framework based on the routing information in the context structure; The processing function updates the routing table based on the routing information in the context structure to obtain a new routing table.

6. The border gateway communication method according to claim 2, characterized in that, Also includes: If it is determined that the routing table does not need to be updated, the data packet is forwarded based on the routing table.

7. The border gateway communication method according to claim 1, characterized in that, The step of determining whether the routing table needs to be updated includes: If the local state information in the vector packet processing framework is updated, it is determined that the routing table needs to be updated.

8. The border gateway communication method according to claim 7, characterized in that, The routing protocol suite includes a routing information processing process and a protocol processing process; The step of updating the routing table by the routing protocol suite to obtain a new routing table for data transmission includes: The routing information processing process updates the local state data in the routing protocol suite and sends the updated local state data to the protocol processing process. The protocol processing process obtains the second optimized routing information based on the updated local state data; The routing information processing process updates the routing table based on the second optimized routing information to obtain a new routing table.

9. The border gateway communication method according to claim 8, characterized in that, The step of updating the local state data in the routing protocol suite by the routing information processing process and sending the updated local state data to the protocol processing process includes: The routing information processing process obtains the event notification message issued by the vector packet processing framework and updates the local state data in the routing protocol suite based on the event notification message; After updating the local state data in the routing protocol suite, the routing information processing process sends the updated local state data to the protocol processing process.

10. A border gateway communication device, characterized in that, The device is applied to a vector packet processing framework, in which a routing protocol suite is loaded as a plug-in, and the framework stores a routing table in its memory; the device includes: The determination module is used to determine whether the routing table needs to be updated; The update module is used to, when it is determined that the routing table needs to be updated, invoke the routing protocol suite to update the routing table and obtain a new routing table for data transmission.

11. A border gateway, characterized in that, The system includes a vector data packet processing framework, and the border gateway communicates using the border gateway communication method described in any one of claims 1-9.

12. An electronic device, characterized in that, The electronic device includes: At least one processor; A memory connected to the at least one processor; The memory stores instructions executable by the at least one processor, which implements the border gateway communication method according to any one of claims 1 to 9 by executing the instructions stored in the memory.

13. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the border gateway communication method according to any one of claims 1 to 9.

Images