Routing policy processing method, device, equipment, medium and program product

Abstract

The invention provides a routing strategy processing method and device, equipment, a medium and a program product, and can relate to the technical field of cloud, and the method comprises the steps that each BGP service module receives a target routing strategy sent by a load balancer; the first BGP service module receives first routing information sent by the source equipment; the first BGP service module processes the first routing information based on the routing policy of the source device to obtain second routing information; the first BGP service module sends the second routing information to a second BGP service module connected with the target equipment; the second BGP service module processes the second routing information based on the routing policy of the target equipment to obtain third routing information; and the second BGP service module sends the third routing information to the target equipment. Since the BGP service modules corresponding to the source device and the target device associated with the target routing policy can obtain the target routing policy, it is ensured that the routing policy can be processed.

Description

Technical Field

[0001] This application relates to the field of cloud technology, and in particular to a routing policy processing method, apparatus, device, medium, and program product. Background Technology

[0002] In cloud network systems, Border Gateway Protocol (BGP) connections are typically established between network devices to enable dynamic scheduling of network traffic. BGP is a path vector routing protocol that enables route reachability between Autonomous Systems (AS) and selects the best route. The purpose of the BGP protocol itself is to transmit routing information.

[0003] As business grows rapidly, the number and types of services carried by the cloud network system are also increasing. Simply relying on automatic route learning between network devices to pass routing information is no longer sufficient to meet current business needs. Therefore, a BGP service module, or BGP service instance, was designed. This instance can establish BGP connections with all network devices within an AS (Application System) and provide a northbound Application Programming Interface (API), allowing operations personnel to issue routing policies and control network device traffic. However, as the number of network devices within the cloud network system increases, a single BGP service module may not be able to support the massive network scale. Therefore, it is necessary to consider clustering and scaling the BGP service module.

[0004] Currently, operations and maintenance personnel can issue routing policies to the load balancer, which then randomly sends the routing policies to a BGP service module in the BGP service cluster. However, the BGP service modules corresponding to the source and destination devices associated with the routing policy may not receive the routing policy, thus making it impossible to process the routing policy. Summary of the Invention

[0005] This application provides a routing policy processing method, apparatus, device, medium, and program product to ensure that the routing policy can be processed.

[0006] In a first aspect, embodiments of this application provide a routing policy processing method. This method is applied to a BGP service cluster in a cloud network system. The BGP service cluster includes multiple BGP service modules. The method includes: each BGP service module in the BGP service cluster receiving a target routing policy sent by a load balancer; wherein the target routing policy includes a routing policy for a source device and a routing policy for a destination device; a first BGP service module in the BGP service cluster receiving first routing information sent by the source device; the first BGP service module processing the first routing information based on the routing policy of the source device to obtain second routing information; the first BGP service module sending the second routing information to a second BGP service module connected to the destination device; the second BGP service module processing the second routing information based on the routing policy of the destination device to obtain third routing information; and the second BGP service module sending the third routing information to the destination device.

[0007] Secondly, embodiments of this application provide a routing policy processing method. This method is applied to a BGP service cluster in a cloud network system. The BGP service cluster includes multiple BGP service modules. The method includes: a first BGP service module in the BGP service cluster receiving a target routing policy sent by a load balancer; wherein the target routing policy includes a routing policy of a source device and a routing policy of a destination device; the first BGP service module storing the target routing policy in a shared cache of the BGP service cluster; a second BGP service module in the BGP service cluster receiving first routing information sent by a source device; the second BGP service module obtaining the routing policy of the source device; the second BGP service module processing the first routing information based on the routing policy of the source device to obtain second routing information; a third BGP service module in the BGP service cluster obtaining the routing policy of the destination device; the third BGP service module obtaining the second routing information; the third BGP service module processing the second routing information based on the routing policy of the destination device to obtain third routing information; and the third BGP service module sending the third routing information to the destination device.

[0008] Thirdly, embodiments of this application provide a routing policy processing method. This method is applied to a BGP service cluster in a cloud network system. The BGP service cluster includes multiple BGP service modules. The method includes: a first BGP service module in the BGP service cluster receiving a target routing policy sent by a load balancer; wherein the target routing policy includes a routing policy of a source device and a routing policy of a destination device; the first BGP service module storing the routing policy of the source device in a message queue corresponding to the source device; and storing the routing policy of the destination device in a message queue corresponding to the destination device; a second BGP service module in the BGP service cluster receiving first routing information sent by the source device; the second BGP service module reading the routing policy of the source device from the message queue corresponding to the source device; the second BGP service module processing the first routing information based on the routing policy of the source device to obtain second routing information; a third BGP service module in the BGP service cluster obtaining the second routing information; the third BGP service module reading the routing policy of the destination device from the message queue corresponding to the destination device; the third BGP service module processing the second routing information based on the routing policy of the destination device to obtain third routing information; and the third BGP service module sending the third routing information to the destination device.

[0009] Fourthly, embodiments of this application provide a routing policy processing apparatus, including multiple BGP service modules; each BGP service module in the BGP service cluster is used to receive a target routing policy sent by a load balancer; wherein, the target routing policy includes: a routing policy of the source device and a routing policy of the destination device; a first BGP service module in the BGP service cluster is used to receive first routing information sent by the source device; the first BGP service module is further used to process the first routing information based on the routing policy of the source device to obtain second routing information; the first BGP service module is further used to send the second routing information to a second BGP service module connected to the destination device; the second BGP service module is used to process the second routing information based on the routing policy of the destination device to obtain third routing information; the second BGP service module is further used to send the third routing information to the destination device.

[0010] Fifthly, embodiments of this application provide a routing policy processing apparatus, including multiple BGP service modules; a first BGP service module in a BGP service cluster is used to receive a target routing policy sent by a load balancer; wherein, the target routing policy includes: a routing policy of a source device and a routing policy of a destination device; the first BGP service module is further used to store the target routing policy in a shared cache of the BGP service cluster; a second BGP service module in the BGP service cluster is used to receive first routing information sent by a source device; the second BGP service module is further used to obtain the routing policy of the source device; the second BGP service module is further used to process the first routing information based on the routing policy of the source device to obtain second routing information; a third BGP service module in the BGP service cluster is used to obtain the routing policy of the destination device; the third BGP service module is further used to obtain the second routing information; the third BGP service module is further used to process the second routing information based on the routing policy of the destination device to obtain third routing information; the third BGP service module is further used to send the third routing information to the destination device.

[0011] In a sixth aspect, embodiments of this application provide a routing policy processing apparatus, including multiple BGP service modules; a first BGP service module in a BGP service cluster is used to receive a target routing policy sent by a load balancer; wherein, the target routing policy includes: a routing policy of a source device and a routing policy of a destination device; the first BGP service module is further used to store the routing policy of the source device in a message queue corresponding to the source device; and to store the routing policy of the destination device in a message queue corresponding to the destination device; a second BGP service module in the BGP service cluster is used to receive first routing information sent by the source device; the second BGP service module is further used to read the routing policy of the source device from the message queue corresponding to the source device; the second BGP service module is further used to process the first routing information based on the routing policy of the source device to obtain second routing information; a third BGP service module in the BGP service cluster is used to obtain the second routing information; the third BGP service module is further used to read the routing policy of the destination device from the message queue corresponding to the destination device; the third BGP service module is further used to process the second routing information based on the routing policy of the destination device to obtain third routing information; the third BGP service module is further used to send the third routing information to the destination device.

[0012] In a seventh aspect, embodiments of this application provide an electronic device, including: a processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to perform the methods as described in the first to third aspects or their respective implementations.

[0013] Eighthly, embodiments of this application provide a computer-readable storage medium for storing a computer program that causes a computer to perform the methods described in the first to third aspects or their respective implementations.

[0014] Ninthly, embodiments of this application provide a computer program product including computer program instructions that cause a computer to perform the methods as described in the first to third aspects or their respective implementations.

[0015] In a tenth aspect, embodiments of this application provide a computer program that causes a computer to perform the methods described in the first to third aspects or their respective implementations.

[0016] The technical solution provided in this application distributes routing policies to each BGP module via a load balancer, enabling the BGP service modules corresponding to the source and destination devices associated with the routing policies to obtain and process them. Alternatively, the load balancer distributes the routing policies to a single BGP module, which can store the routing policies in a shared cache of the BGP service cluster, allowing the corresponding BGP service modules to obtain and process them. Or, the load balancer distributes the routing policies to a single BGP module, which can store the routing policies for the source devices in the source device's message queue and the routing policies for the destination devices in the destination device's message queue, allowing the corresponding BGP service modules to obtain and process them. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of a BGP connection provided in an embodiment of this application;

[0018] Figure 2 This is a schematic diagram illustrating the connection between the BGP service module and the network device provided in an embodiment of this application.

[0019] Figure 3 A cloud network system architecture diagram provided for embodiments of this application;

[0020] Figure 4 An interactive flowchart of a routing policy processing method provided in an embodiment of this application;

[0021] Figure 5 An interactive flowchart illustrating an example of a routing policy processing method provided in this application embodiment;

[0022] Figure 6An interactive flowchart of another routing policy processing method provided in an embodiment of this application;

[0023] Figure 7 A schematic diagram of a cloud network system provided in an embodiment of this application;

[0024] Figure 8 An interactive flowchart illustrating another routing policy processing method provided in an embodiment of this application;

[0025] Figure 9 A schematic diagram of another cloud network system provided in the embodiments of this application;

[0026] Figure 10 An interactive flowchart illustrating another routing strategy processing method provided in this application embodiment;

[0027] Figure 11 This is a schematic block diagram of the electronic device 1100 provided in the embodiments of this application. Detailed Implementation

[0028] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0030] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0031] The technical solutions provided in the embodiments of this application may involve cloud technology, but are not limited thereto.

[0032] Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.

[0033] Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0034] Cloud computing is a computing model that distributes computing tasks across a large pool of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, resources in the "cloud" appear infinitely scalable, readily available, on-demand, and expandable, with payment based on usage.

[0035] As a provider of fundamental cloud computing capabilities, a cloud resource pool (referred to as a cloud platform, generally called Infrastructure as a Service (IaaS)) platform) is established. Various types of virtual resources are deployed in the resource pool for external customers to choose from. The cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0036] Based on logical function, a Platform as a Service (PaaS) layer can be deployed on top of the IaaS layer, followed by a Software as a Service (SaaS) layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is the platform for running software, such as databases and web containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally, SaaS and PaaS are upper layers compared to IaaS.

[0037] Cloud networking refers to a network architecture and service model based on cloud computing technology. It virtualizes traditional physical network devices and resources, and through the virtual network functions provided by the cloud platform, it enables the elastic allocation and management of network resources. The main characteristics of cloud networking include virtualization, elastic scaling, security, high availability, and Network Functions Virtualization (NFV).

[0038] A cloud network system is a network architecture based on virtualization technology. By virtualizing network resources, it exposes network capabilities adapted to cloud characteristics to users, thereby meeting the "cloud-edge-device" interconnection needs of enterprises during the process of migrating to the cloud.

[0039] In cloud network systems, such as Figure 1 As shown, BGP protocol connections are typically established between network devices to achieve dynamic scheduling of network traffic. The primary design principle of the BGP protocol is to facilitate the exchange of routing information and policy-based routing between Autonomous Systems (AS). BGP employs a path-based routing method, with each route carrying a complete Autonomous System path (AS-Path). This helps avoid routing loops and provides a basis for policy-based routing. Furthermore, BGP introduces many attributes, such as Next-Hop, Local Preference, and Multi-Exit Discriminator (MED), which allow for the implementation of more flexible routing policies.

[0040] As business grows rapidly, the number and types of services carried by cloud network systems are also increasing. Simply relying on automatic route learning between network devices to exchange routing information is no longer sufficient to meet the demands of today's business development. Therefore, we considered designing a BGP service module, i.e., a BGP service instance or BGP service, which can establish BGP connections with all network devices within an AS, such as... Figure 2 As shown, a BGP service module can establish BGP connections with two network devices. Furthermore, the BGP service module provides a northbound API, allowing operations personnel to issue routing policies and thus control network device traffic. The specific functions of the BGP service module include:

[0041] 1. Fine-grained network control: BGP services offer fine-grained network control, such as the ability to control routing rules between network devices, which is impossible with traditional automatic route learning and propagation. Fine-grained network control can optimize network performance and improve business operation efficiency.

[0042] 2. Improve network reliability: BGP services enable real-time network monitoring and fault warnings, allowing for timely detection and handling of network problems and improving network reliability. Furthermore, BGP services can be used to implement network redundancy design, further enhancing network reliability.

[0043] 3. Meeting Diverse Business Needs: The diverse nature of modern business needs leads to varying network requirements. BGP services can provide personalized network scheduling based on different business requirements, thus satisfying diverse needs.

[0044] As the number of network devices within a cloud network system increases, a single BGP service may not be able to support the massive network scale. Therefore, it is necessary to consider clustering and scaling the BGP service. Clustered BGP services can offer the following advantages:

[0045] 1. Load balancing: By distributing BGP services across multiple nodes, load balancing can be achieved, effectively distributing the pressure on individual nodes. As the network scales up, load balancing can ensure the stability and performance of BGP services.

[0046] 2. High Availability: Clustered BGP services can improve system availability. When a BGP service node fails, other BGP services can automatically take over the work of the failed node, ensuring the normal operation of the network system.

[0047] 3. Fault Isolation: Fault isolation can be achieved through clustered expansion. When a problem occurs in one BGP service, the functionality of the entire BGP service will not be affected, thus ensuring the stability of the entire network system.

[0048] 4. Dynamic scaling: Clustered BGP services can be dynamically scaled up or down according to actual business needs. During peak business periods, BGP services can be increased to cope with larger network loads; during off-peak periods, BGP services can be reduced to save resources.

[0049] 5. Easy to maintain and upgrade: Clustered BGP services can be smoothly upgraded and maintained, avoiding the interruption of the entire network system due to the maintenance or upgrade of a single BGP service.

[0050] The routing strategies involved in the embodiments of this application are described below:

[0051] A typical routing policy consists of two parts: the routing policy for the source device and the routing policy for the destination device.

[0052] The routing policy of the source device is mainly used to filter routing information received from the source device based on a series of preset conditions (called "conditions"). These conditions involve at least one of the following elements, but are not limited to: source IP address, destination IP address, protocol type, and port number. Only routes that meet all conditions will be selected. By setting these conditions, operations and maintenance personnel can achieve precise control over the flow of specific traffic, thereby optimizing network performance, enhancing security, or meeting specific business needs.

[0053] The routing policy of the destination device defines a series of actions to modify the selected routing information. These actions may include, but are not limited to, changing the destination address, next-hop node, priority, or routing metric of the route. By executing these actions, the path selection of network traffic can be flexibly adjusted to adapt to the ever-changing network environment and business needs.

[0054] Below is an example routing policy:

[0055]

[0056] Here, "Neighbor":"1.1.1.1" indicates that the source neighbor address is 1.1.1.1, and "Prefix":"192.168.1.0 / 24" means that for routing information from the source (i.e., the source device), routes with the prefix 192.168.1.0 / 24 are retained, i.e., routes with the prefix 192.168.1.0 / 24 are filtered out. "Neighbor":"1.1.1.2" indicates the destination neighbor address. When sending routes to the destination (i.e., the destination device), the Comminency "65535:65282" is added to the route (this is a well-known BGP community, representing NO_ADVERTISE, used to instruct the router not to pass routing information to any peers).

[0057] It should be understood that the aforementioned source neighbor address is relative to the BGP service module to which the source device is connected. Since the source device is a neighbor of this BGP service module, the address of the source device is referred to as the source neighbor address here. Similarly, the aforementioned destination neighbor address is relative to the BGP service module to which the destination device is connected. Since the destination device is a neighbor of this BGP service module, the address of the destination device is referred to as the destination neighbor address here.

[0058] It should be understood that, assuming only one BGP service module is currently configured, the BGP service module performs the following process for the routing policy shown in the example above: First, the BGP service module receives routing information from the source device with address 1.1.1.1. Second, according to the source device's routing policy, the BGP service module filters out routes with the prefix 192.168.1.0 / 24, and according to the destination device's routing policy, adds the Comminency "65535:65282" to the selected routes to obtain the processed routing information, and sends the processed routing information to the destination device with address 1.1.1.2.

[0059] It should be understood that if there is only one BGP service module in the cloud network system, and this BGP service module is connected to all network devices, then this BGP service module can properly handle the policy relationship between source and destination devices. However, when the BGP service is expanded to a cluster mode, currently, operations and maintenance personnel can issue routing policies to the load balancer, and the load balancer will then randomly send the routing policies to a BGP service module in the BGP service cluster. However, the BGP service modules corresponding to the source and destination devices associated with the routing policy may not receive the routing policy, resulting in the inability to process the routing policy.

[0060] To address the aforementioned technical problems, embodiments of this application propose enabling the BGP service modules corresponding to the source and destination devices associated with a routing policy to obtain the routing policy and process it. Specifically, a load balancer distributes the routing policy to each BGP module, allowing the corresponding BGP service modules of the source and destination devices to obtain and process the routing policy. Alternatively, a load balancer distributes the routing policy to a single BGP module, which can store the routing policy in a shared cache of the BGP service cluster, allowing the corresponding BGP service modules of the source and destination devices to obtain and process the routing policy. Or, a load balancer distributes the routing policy to a single BGP module, which can store the routing policy for the source device in the message queue corresponding to the source device and the routing policy for the destination device in the message queue corresponding to the destination device, allowing the corresponding BGP service modules of the source and destination devices to obtain and process the routing policy.

[0061] The embodiments of this application can be applied as follows: Figure 3 The cloud network system shown is not limited to this:

[0062] For example, Figure 3A cloud network system architecture diagram is provided for embodiments of this application, such as... Figure 3 As shown, the cloud network system includes: a load balancer 310, multiple BGP service modules 320, and multiple network devices 330.

[0063] The load balancer 310 is connected to each BGP service module 320, each network device 330 can be connected to one BGP service module 320, and one BGP service module 320 can be connected to at least one network device 330. Here, "connection" can be a BGP connection, i.e., a connection based on the BGP protocol.

[0064] In some implementations, the load balancer 310 can be a service module within the cloud network system, but is not limited to this. For example, the load balancer 310 can be a service module within the cloud network controller. From a hardware perspective, it can reside on one or more nodes in the cloud network system, where nodes can be understood as devices within the cloud network system, but are not limited to this.

[0065] In some implementations, the BGP service module 320 can be a service module within the cloud network system, but it is not limited to this. For example, the BGP service module 320 can be a service module within the cloud network controller. From a hardware perspective, it can reside on one or more nodes in the cloud network system. These nodes can be understood as devices within the cloud network system, but are not limited to this.

[0066] It should be understood that a cloud network controller refers to a controller located in the cloud, which is also known as a cloud controller, controller, etc.

[0067] In some implementations, the cloud network controller can be a software-defined networking (SDN) controller, but it is not limited to this.

[0068] In some implementations, network device 330 can be a switch or a router, but is not limited to these.

[0069] In this system, operations and maintenance personnel can issue routing policies through the load balancer 310, which can then distribute these policies. For example, the load balancer 310 can issue routing policies to each BGP module 320, enabling the BGP service modules 320 corresponding to the source and destination devices associated with the routing policies to obtain and process them. Alternatively, the load balancer 310 can issue routing policies to a single BGP module 320, which can then store the routing policies in a shared cache within the BGP service cluster. This allows the BGP service modules 320 corresponding to the source and destination devices associated with the routing policies to obtain and process them. Alternatively, the routing policy can be distributed to a BGP module 320 via the load balancer 310. However, the BGP module 320 can store the routing policy of the source device in the routing policy to the message queue corresponding to the source device, and store the routing policy of the destination device in the routing policy to the message queue corresponding to the destination device. This allows the BGP service modules 320 corresponding to the source device and the destination device associated with the routing policy to obtain the routing policy and process it.

[0070] It should be understood that, Figure 3 Taking a system comprising two BGP service modules and four network devices as an example, a cloud network system can actually include other numbers of BGP service modules and network devices. In short, the cloud network system used in the embodiments of this application is not limited to... Figure 3 The cloud network system.

[0071] The technical solution of this application is described in detail below:

[0072] Figure 4 This application provides an interactive flowchart of a routing policy processing method. The method is applied to a BGP service cluster, load balancer, source device, and destination device associated with a target routing policy in a cloud network system. The BGP service cluster includes multiple BGP service modules, each of which can be... Figure 3 The BGP service module 320 in the code is used, but is not limited to it; the load balancer can be... Figure 3 The load balancer 310 in the example is not limited to this; the source and destination devices can be... Figure 3 The two network devices 330 in the example are not limited to this, such as Figure 4 As shown, the routing policy processing method may include:

[0073] S410: The load balancer sends the target routing policy to each BGP service module in the BGP service cluster;

[0074] It should be understood that the target routing policy can be any routing policy from the load balancer. The target routing policy includes both the source device's routing policy and the destination device's routing policy. Explanations of the source and destination device's routing policies can be found above, and this application's embodiments do not impose limitations on them.

[0075] It should be understood that, in Figure 4 Only the first and second BGP service modules are shown in the diagram. In reality, the BGP service cluster can also include other BGP service modules, all of which can receive the target routing policy.

[0076] S420: The source device sends the first routing information to the first BGP service module in the BGP service cluster;

[0077] It should be understood that the first BGP service module refers to the BGP service module in the BGP service cluster that is connected to the source device.

[0078] In some implementations, the first routing information includes at least one route. Each route may include: a source IP address, a destination IP address, a next-hop IP address, etc. This application does not limit the definition of the first routing information or the routes.

[0079] S430: The first BGP service module processes the first routing information based on the routing policy of the source device to obtain the second routing information;

[0080] As described above, the routing policy of the source device is mainly used to filter routing information received from the source device based on a series of preset conditions. These conditions involve at least one of the following elements, but are not limited to: source IP address, destination IP address, protocol type, and port number. Only routes that meet all conditions will be selected. Based on this, the second routing information can be the routing information obtained after filtering the first routing information according to the above conditions.

[0081] For example, the target routing strategy is as follows:

[0082]

[0083]

[0084] In this example, the second routing information is the routing information with the prefix 192.168.1.0 / 24 in the first routing information.

[0085] S440: The first BGP service module sends the second routing information to the second BGP service module connected to the destination device;

[0086] It should be understood that the second BGP service module refers to the BGP service module in the BGP service cluster that is connected to the destination device.

[0087] In this embodiment of the application, the first BGP service module may send the second routing information in any of the following ways, but is not limited thereto:

[0088] One possible implementation is that the first BGP service module sends the second routing information to the load balancer, so that the load balancer sends the second routing information to other BGP service modules besides the first BGP service module.

[0089] It should be understood that in this implementation, it is assumed that the destination device and the source device are connected to different BGP service modules. Based on this, the load balancer does not need to know the BGP service module currently connected to the destination device. It can send the second routing information to all other BGP service modules except the first BGP service module, so that no matter which BGP service module the destination device is currently connected to, that BGP service module can obtain the second routing information.

[0090] In this implementation, even if the BGP service module connected to the destination device may change due to factors such as network quality, the BGP service module currently connected to it can obtain the second routing information, thereby ensuring the normal processing of the routing policy.

[0091] In the second possible implementation, the first BGP service module sends the second routing information to the load balancer, so that the load balancer sends the second routing information only to the second BGP service module.

[0092] In this implementation, the load balancer needs to know the BGP service module currently connected to the destination device, namely the second BGP service module. Based on this, after obtaining the second routing information, the load balancer can send the second routing information to the second BGP service module without sending it to other BGP service modules.

[0093] In some implementations, each BGP service module in a BGP service cluster can proactively report the changed connection relationship to the load balancer when its connection relationship with network devices changes.

[0094] In some implementations, changes in the connection relationship between the BGP service module and the network device include at least one of the following: an increase in the connection relationship between the BGP service module and the network device, a decrease in the connection relationship between the BGP service module and the network device, or an update in the connection relationship between the BGP service module and the network device.

[0095] For example, suppose BGP service module 1 connects to network devices 01 and 02 during the time period [t1, t2). As the number of network devices increases, BGP service module 1 establishes a connection with network device 03 at time t2. Based on this, at time t2, the network devices connected to BGP service module 1 include network device 01, network device 02, and network device 03. At this time, BGP service module 1 can report the network devices it is connected to to the load balancer so that the load balancer can know the latest connection relationship of BGP service module 1.

[0096] For example, suppose BGP service module 1 is connected to network device 01 and network device 02 during the time period [t1, t2). Suppose a network anomaly occurs at time t2, and BGP service module 1 disconnects from network device 01 at time t2. Based on this, at time t2, the network devices connected to BGP service module 1 include network device 02. At this time, BGP service module 1 can report its connected network devices to the load balancer, so that the load balancer can know the latest connection relationships of BGP service module 1.

[0097] For example, suppose BGP service module 1 is connected to network devices 01 and 02 during the time period [t1, t2). At time t2, BGP service module 1 disconnects from network device 01 and establishes a connection with network device 03. Based on this, at time t2, the network devices connected to BGP service module 1 include network device 02 and network device 03. At this time, BGP service module 1 can report the network devices it is connected to to the load balancer so that the load balancer knows the latest connection relationship of BGP service module 1.

[0098] In some implementations, the load balancer can also proactively obtain the latest connection relationships of each BGP service module in real time or periodically.

[0099] It should be understood that the embodiments of this application do not limit how the load balancer learns the latest connection relationship of each BGP service module.

[0100] In the third possible implementation, the first BGP service module determines the second BGP service module and sends the second routing information to the second BGP service module.

[0101] In this implementation, the first BGP service module needs to know the BGP service module currently connected to the destination device, namely the second BGP service module. Based on this, after obtaining the second routing information, the first BGP service module can send the second routing information to the second BGP service module without sending it to other BGP service modules.

[0102] In some implementations, each BGP service module in a BGP service cluster can proactively broadcast its changed connection relationship when its connection relationship with network devices changes, so that other BGP service modules can be aware of these changed connection relationships.

[0103] In some implementations, when the connection relationship between each BGP service module in the BGP service cluster changes with the network device, it can proactively report the changed connection relationship to the load balancer. The first BGP service module can proactively obtain the latest connection relationship of each BGP service module from the load balancer in real time or periodically.

[0104] It should be understood that the embodiments of this application do not limit how the first BGP service module learns the latest connection relationship of each BGP service module.

[0105] S450: The second BGP service module processes the second routing information based on the routing policy of the destination device to obtain the third routing information;

[0106] As described above, the routing policy of the destination device defines a series of actions to modify the selected route information. These actions may include at least one of the following, but are not limited to: changing the destination address, next-hop node, priority, and routing metric of the route.

[0107] For example, the target routing strategy is as follows:

[0108]

[0109] In this example, the third routing information is to add Comminity "65535:65282" to the selected route to obtain the processed routing information.

[0110] S460: The second BGP service module sends the third routing information to the destination device.

[0111] It should be understood that this embodiment can be applied to scenarios with a small number of routing policies, but is not limited thereto.

[0112] It should be understood that when the number of routing policies is small, the load balancer may no longer use a random allocation strategy, but can send all routing policies to each BGP service module. In this way, each BGP service module can obtain these routing policies, and for any routing policy, regardless of which BGP service module it is currently connected to, it can be ensured that the associated destination device can obtain the routing policy and process it.

[0113] The following example illustrates the routing policy processing method provided in this application:

[0114] For example, Figure 5 This application provides an example of an interactive flowchart for a routing policy processing method. The method is applied to a BGP service cluster, load balancer, and source and destination devices associated with a target routing policy in a cloud network system. The BGP service cluster includes BGP service module 1, BGP service module 2, and BGP service module 3. The source device is connected to BGP service module 1, and the destination device is connected to BGP service module 2. Figure 5 As shown, the routing policy processing method may include:

[0115] S510: The load balancer sends the target routing policy to BGP service module 1, BGP service module 2 and BGP service module 3;

[0116] The target routing policy includes: the routing policy of the source device and the routing policy of the destination device.

[0117] After receiving the target routing policy, BGP service module 1, BGP service module 2 and BGP service module 3 can store the target routing policy locally.

[0118] S520: The source device sends the first routing information to BGP service module 1;

[0119] S530: BGP service module 1 processes the first routing information based on the routing policy of the source device to obtain the second routing information;

[0120] S540: BGP service module 1 sends the second routing information to the load balancer;

[0121] S550: The load balancer sends the second routing information to BGP service module 2;

[0122] S560: The load balancer sends the second routing information to the BGP service module 3;

[0123] It should be understood that after receiving the second routing information, BGP service module 3 can ignore the second routing information because it determines that the routing policy of the destination device is irrelevant to it.

[0124] S570: BGP service module 2 processes the second routing information based on the routing policy of the destination device to obtain the third routing information;

[0125] S580: BGP service module 2 sends third-party routing information to the destination device.

[0126] This application provides a routing policy processing method, comprising: a load balancer sending a target routing policy to each BGP service module in a BGP service cluster; a source device sending first routing information to a first BGP service module; the first BGP service module processing the first routing information based on the source device's routing policy to obtain second routing information; the first BGP service module sending the second routing information to a second BGP service module connected to a destination device; the second BGP service module processing the second routing information based on the destination device's routing policy to obtain third routing information; and the second BGP service module sending the third routing information to the destination device. Since the BGP service modules corresponding to the source and destination devices associated with the target routing policy can obtain the target routing policy, it is ensured that the routing policy can be processed.

[0127] Furthermore, since each BGP service module can obtain the target routing policy, even if the connection relationship between some BGP service modules and some network devices changes, it can be guaranteed that the BGP service modules corresponding to the source and destination devices associated with the target routing policy can obtain the target routing policy, thereby ensuring that the routing policy can be processed.

[0128] Figure 6 This application provides an interactive flowchart of another routing policy processing method. The method is applied to a BGP service cluster, load balancer, source device, and destination device associated with a target routing policy in a cloud network system. The BGP service cluster includes multiple BGP service modules, each of which can be... Figure 3 The BGP service module 320 in the code is used, but is not limited to it; the load balancer can be... Figure 3 The load balancer 310 in the example is not limited to this; the source and destination devices can be... Figure 3 The two network devices 330 in the example are not limited to this, such as Figure 6 As shown, the routing policy processing method may include:

[0129] S610: The load balancer sends the target routing policy to the first BGP service module in the BGP service cluster;

[0130] It should be understood that the target routing policy can be any routing policy from the load balancer. The target routing policy includes both the source device's routing policy and the destination device's routing policy. Explanations of the source and destination device's routing policies can be found above, and this application's embodiments do not impose limitations on them.

[0131] In some implementations, the first BGP service module may be a BGP service module randomly selected by the load balancer from the BGP service cluster.

[0132] In some implementations, the first BGP service module can be the BGP service module with the smallest index in the BGP service cluster. For example, assuming the BGP service cluster includes BGP service module 1, BGP service module 2 and BGP service module 3, the first BGP service module can be BGP service module 1.

[0133] In some implementations, the first BGP service module can be the BGP service module with the largest index in the BGP service cluster. For example, assuming the BGP service cluster includes BGP service module 1, BGP service module 2 and BGP service module 3, the first BGP service module can be BGP service module 3.

[0134] In summary, this application embodiment does not restrict the selection method of the first BGP service module.

[0135] S620: The first BGP service module stores the target routing policy in the shared cache of the BGP service cluster;

[0136] For example, Figure 7 This is a schematic diagram of a cloud network system provided in an embodiment of this application, such as... Figure 7 As shown, assume the BGP service cluster includes BGP service module 1 and BGP service module 2, where BGP service module 1 and BGP service module 2 have a shared cache, and the destination routing policy can be stored in the shared cache. S630: The source device sends the first routing information to the second BGP service module in the BGP service cluster;

[0137] It should be understood that the second BGP service module refers to the BGP service module connected to the source device in the BGP service cluster. The second BGP service module and the first BGP service module can be the same BGP service module or different BGP service modules.

[0138] In some implementations, the first routing information includes at least one route. Each route may include: a source IP address, a destination IP address, a next-hop IP address, etc. This application does not limit the definition of the first routing information or the routes.

[0139] S640: The second BGP service module obtains the routing policy of the source device;

[0140] In some implementations, the second BGP service module reads the routing policy of the source device from a shared cache.

[0141] In some implementations, before the second BGP service module obtains the routing policy of the source device, when the second BGP service module determines that the routing policy of the source device is related to the source device, the second BGP service module stores the routing policy of the source device in the memory of the second BGP service module; correspondingly, the second BGP service module can read the routing policy of the source device from the memory of the second BGP service module.

[0142] In this implementation, if the second BGP service module fails to read the routing policy of the source device from its memory, then the second BGP service module reads the routing policy of the source device from the shared cache.

[0143] S650: The second BGP service module processes the first routing information based on the routing policy of the source device to obtain the second routing information;

[0144] It should be understood that the explanation of S650 can be found in the explanation of S430, and will not be repeated in this embodiment.

[0145] S660: The third BGP service module in the BGP service cluster obtains the routing policy of the destination device;

[0146] It should be understood that the third BGP service module refers to the BGP service module in the BGP service cluster that is connected to the destination device.

[0147] In some implementations, the third BGP service module can read the routing policy of the destination device from the shared cache.

[0148] In some implementations, before the third BGP service module obtains the routing policy of the destination device, when the third BGP service module determines that the routing policy of the destination device is related to the destination device, the third BGP service module stores the routing policy of the destination device in the memory of the third BGP service module; correspondingly, the third BGP service module can read the routing policy of the destination device from the memory of the third BGP service module.

[0149] In this implementation, if the third BGP service module fails to read the routing policy of the destination device from its memory, then the third BGP service module will read the routing policy of the destination device from the shared cache.

[0150] S670: The third BGP service module obtains the second routing information;

[0151] In some implementations, before the third BGP service module obtains the second routing information, the second BGP service module stores the second routing information in a shared cache; correspondingly, the third BGP service module reads the second routing information from the shared cache.

[0152] In some implementations, any routing information can be stored in a shared cache as a key-routing information pair. The key can be the address of the source device. Before the second BGP service module processes the first routing information, the routing information corresponding to the source device's address is the first routing information. After the second BGP service module processes the first routing information, the routing information corresponding to the source device's address becomes the second routing information. The third BGP service module can detect changes in the information corresponding to this key; that is, when the routing information changes from the first routing information to the second routing information, the third BGP service module can detect the second routing information pair.

[0153] In some implementations, the second BGP service module sends the second routing information to the third BGP service module.

[0154] In this embodiment of the application, the second BGP service module may send third routing information in any of the following ways, but is not limited thereto:

[0155] One possible approach is for the second BGP service module to send the second routing information to the load balancer, so that the load balancer can send the second routing information to other BGP service modules besides the second BGP service module.

[0156] It should be understood that in this implementation, it is assumed that the destination device and the source device are connected to different BGP service modules. Based on this, the load balancer does not need to know the BGP service module currently connected to the destination device. It can send the second routing information to all other BGP service modules except the second BGP service module, so that no matter which BGP service module the destination device is currently connected to, that BGP service module can obtain the second routing information.

[0157] In this implementation, even if the BGP service module connected to the destination device may change due to factors such as network quality, the BGP service module currently connected to it can obtain the second routing information, thereby ensuring the normal processing of the routing policy.

[0158] In the second possible implementation, the second BGP service module sends the second routing information to the load balancer, so that the load balancer sends the second routing information only to the third BGP service module.

[0159] In this implementation, the load balancer needs to know the BGP service module currently connected to the destination device, namely the third BGP service module. Based on this, after obtaining the second routing information, the load balancer can send the second routing information to the third BGP service module without sending it to other BGP service modules.

[0160] In some implementations, each BGP service module in a BGP service cluster can proactively report the changed connection relationship to the load balancer when its connection relationship with network devices changes.

[0161] In some implementations, changes in the connection relationship between the BGP service module and the network device include at least one of the following: an increase in the connection relationship between the BGP service module and the network device, a decrease in the connection relationship between the BGP service module and the network device, or an update in the connection relationship between the BGP service module and the network device.

[0162] In some implementations, the load balancer can also proactively obtain the latest connection relationships of each BGP service module in real time or periodically.

[0163] It should be understood that the embodiments of this application do not limit how the load balancer learns the latest connection relationship of each BGP service module.

[0164] In the third possible implementation, the second BGP service module determines the third BGP service module and sends the second routing information to the third BGP service module.

[0165] In this implementation, the second BGP service module needs to know the BGP service module currently connected to the destination device, namely the third BGP service module. Based on this, after obtaining the second routing information, the second BGP service module can send the second routing information to the third BGP service module without sending it to other BGP service modules.

[0166] In some implementations, each BGP service module in a BGP service cluster can proactively broadcast its changed connection relationship when its connection relationship with network devices changes, so that other BGP service modules can be aware of these changed connection relationships.

[0167] In some implementations, when the connection relationship between each BGP service module in the BGP service cluster changes with the network device, it can proactively report the changed connection relationship to the load balancer. The second BGP service module can proactively obtain the latest connection relationship of each BGP service module from the load balancer in real time or periodically.

[0168] It should be understood that the embodiments of this application do not limit how the second BGP service module learns the latest connection relationship of each BGP service module.

[0169] S680: The third BGP service module processes the second routing information based on the routing policy of the destination device to obtain the third routing information;

[0170] It should be understood that the explanation of S680 can be found in the explanation of S450, and will not be repeated in this embodiment.

[0171] S690: The third BGP service module sends the third routing information to the destination device.

[0172] It should be understood that this embodiment can be applied to scenarios with a large number of routing policies and a small number of BGP service modules in the BGP service cluster, but is not limited thereto.

[0173] It should be understood that for scenarios where the number of routing policies in a cloud network system is large and the number of BGP service modules in the BGP service cluster is small, if we follow... Figure 4 In a corresponding implementation, all routing policies are distributed to each BGP service module. This results in many routing policies being distributed and stored ineffectively, as some BGP service modules will not process them. Therefore, this approach may lead to redundancy in routing policy distribution and storage. Based on this, this embodiment proposes introducing a shared cache within the BGP service cluster to optimize the distribution and storage of routing policies.

[0174] This application provides a routing policy processing method, including: a load balancer sending a target routing policy to a first BGP service module in a BGP service cluster; the first BGP service module storing the target routing policy in a shared cache of the BGP service cluster; a source device sending first routing information to a second BGP service module in the BGP service cluster; the second BGP service module obtaining the routing policy of the source device; the second BGP service module processing the first routing information based on the routing policy of the source device to obtain second routing information; a third BGP service module in the BGP service cluster obtaining the routing policy of the destination device; the third BGP service module obtaining the second routing information; the third BGP service module processing the second routing information based on the routing policy of the destination device to obtain third routing information; and the third BGP service module sending the third routing information to the destination device. Since the BGP service modules corresponding to the source and destination devices associated with the target routing policy can obtain the target routing policy from the shared cache or their own memory, it is ensured that the routing policy can be processed.

[0175] Furthermore, even if the BGP service module corresponding to the source device changes, the BGP service module currently connected to it, i.e., the second BGP service module, can obtain the routing policy of the source device from the shared cache or local memory. And even if the BGP service module corresponding to the destination device changes, the BGP service module currently connected to it, i.e., the third BGP service module, can obtain the routing policy of the destination device from the shared cache or local memory, thereby ensuring that the target routing policy can be processed.

[0176] It is worth mentioning that, in this embodiment, by introducing a shared cache of the BGP service cluster, the distribution and storage of routing policies can be optimized, thereby reducing redundancy in the distribution and storage of routing policies.

[0177] Figure 8 This is an interactive flowchart of another routing policy processing method provided in an embodiment of this application. The method is applied to a BGP service cluster, load balancer, source device, and destination device associated with a target routing policy in a cloud network system. The BGP service cluster includes multiple BGP service modules, each of which can be... Figure 3 The BGP service module 320 in the code is used, but is not limited to it; the load balancer can be... Figure 3 The load balancer 310 in the example is not limited to this; the source and destination devices can be... Figure 3 The two network devices 330 in the example are not limited to this, such as Figure 8 As shown, the routing policy processing method may include:

[0178] S810: The load balancer sends the target routing policy to the first BGP service module in the BGP service cluster;

[0179] The target routing policy includes the routing policy of the source device and the routing policy of the destination device.

[0180] It should be understood that the explanation of S810 can be found in the explanation of S610, and will not be repeated in this embodiment.

[0181] S820: The first BGP service module stores the routing policy of the source device in the message queue corresponding to the source device; and stores the routing policy of the destination device in the message queue corresponding to the destination device;

[0182] It should be understood that each network device in a cloud network system corresponds to a message queue. For example, Figure 9 This is a schematic diagram of another cloud network system provided in the embodiments of this application, such as... Figure 9 As shown, assume that the BGP service cluster includes BGP service module 1 and BGP service module 2. BGP service module 1 is connected to network device 01 and network device 02, and BGP service module 2 is connected to network device 03 and network device 04. Each of these four network devices corresponds to a message queue.

[0183] In some implementations, for any given network device, the message queue corresponding to that network device can be used to store the routing policy corresponding to that network device. For example, the message queue includes: the routing policy of the source device when the network device is the source device; and the routing policy of the destination device when the network device is the destination device.

[0184] It should be understood that since a network device may be associated with multiple routing policies, to distinguish these policies, when all routing policies are stored in the message queue corresponding to the device, the entire routing policy, including the source device's routing policy and the destination device's routing policy, can be stored. Alternatively, when the network device acts as the source device, the message queue corresponding to that device can store the source device's routing policy and the identifier of the entire routing policy, or it can store the source device's routing policy and the address of the destination device. Based on this, after the BGP service module corresponding to the network device obtains the routing information, it can determine which routing policy in the message queue to use based on the source and destination addresses corresponding to the routing information. Similarly, when the network device acts as the destination device, the message queue corresponding to that device can store the destination device's routing policy and the identifier of the entire routing policy, or it can store the destination device's routing policy and the address of the source device. Based on this, after the BGP service module corresponding to the network device obtains the routing information, it can determine which routing policy in the message queue to use based on the source and destination addresses corresponding to the routing information.

[0185] In some implementations, for any given network device, the message queue corresponding to that network device can also be used to store routing information. For example, when the network device is the destination device, its corresponding message queue can store routing information processed by the BGP service module corresponding to the source device.

[0186] In some implementations, regardless of whether the first BGP service module is the second BGP service module, the first BGP service module can store the routing policy of the source device in the message queue corresponding to the source device.

[0187] In other possible implementations, if the first BGP service module is not the second BGP service module, then the first BGP service module stores the routing policy of the source device in the message queue corresponding to the source device. However, if the first BGP service module is the second BGP service module, then the first BGP service module receives the first routing information sent by the source device and processes the first routing information based on the routing policy of the source device to obtain the second routing information. In other words, if the first BGP service module is the second BGP service module, since it has already obtained the routing policy of the source device, it does not need to store the routing policy of the source device in the message queue corresponding to the source device; instead, it can directly process the first routing information based on the routing policy of the source device to obtain the second routing information.

[0188] In some implementations, regardless of whether the first BGP service module is the third BGP service module, the first BGP service module can store the routing policy of the destination device in the message queue corresponding to the destination device.

[0189] In other possible implementations, if the first BGP service module is not the third BGP service module, then the first BGP service module stores the routing policy of the destination device in the message queue corresponding to the destination device. However, if the first BGP service module is the third BGP service module, then the first BGP service module obtains the second routing information; processes the second routing information based on the routing policy of the destination device to obtain the third routing information; and sends the third routing information to the destination device. In other words, if the first BGP service module is the third BGP service module, since it has already obtained the routing policy of the destination device, it does not need to store the routing policy of the destination device in the message queue corresponding to the destination device. Instead, it can directly process the second routing information based on the routing policy of the destination device to obtain the third routing information and send the third routing information to the destination device.

[0190] S830: The source device sends the first routing information to the second BGP service module in the BGP service cluster;

[0191] It should be understood that the explanation of S830 can be found in the explanation of S630, and will not be repeated in this embodiment.

[0192] S840: The second BGP service module reads the routing policy of the source device from the message queue corresponding to the source device;

[0193] S850: The second BGP service module processes the first routing information based on the routing policy of the source device to obtain the second routing information;

[0194] It should be understood that the explanation of S850 can be found in the explanation of S430, and will not be repeated in this embodiment.

[0195] S860: The third BGP service module in the BGP service cluster obtains the second routing information;

[0196] It should be understood that the third BGP service module refers to the BGP service module in the BGP service cluster that is connected to the destination device.

[0197] In some implementations, before the third BGP service module in the BGP service cluster obtains the second routing information, the second BGP service module can store the second routing information in the message queue corresponding to the destination device; based on this, the third BGP service module reads the second routing information from the message queue corresponding to the destination device.

[0198] In some implementations, the second BGP service module sends the second routing information to the third BGP service module.

[0199] It should be understood that the method of sending the second routing information can be referred to the explanation of S670, and will not be repeated in this embodiment.

[0200] S870: The third BGP service module reads the routing policy of the destination device from the message queue corresponding to the destination device;

[0201] S880: The third BGP service module processes the second routing information based on the routing policy of the destination device to obtain the third routing information;

[0202] It should be understood that the explanation of S880 can be found in the explanation of S450, and will not be repeated in this embodiment.

[0203] S890: The third BGP service module sends the third routing information to the destination device.

[0204] It should be understood that this embodiment can be applied to scenarios with a large number of routing policies and a large number of BGP service modules in the BGP service cluster, but is not limited thereto.

[0205] It should be understood that for scenarios with a large number of routing policies in cloud network systems and many BGP service modules in the BGP service cluster, if... Figure 6 In a corresponding implementation, all routing policies are stored in a shared cache. However, since there are many BGP service modules, this could lead to a large number of BGP service modules concurrently querying routing policies. Therefore, this implementation proposes setting up a message queue for each network device, so that each BGP service module only queries the routing policy in the message queue of the network device it is connected to, thereby avoiding the aforementioned concurrent query problem.

[0206] It should be understood that once a BGP service module establishes a connection with a network device, it can subscribe to messages in the message queue corresponding to that network device. Of course, once a BGP service module disconnects from a network device, it can unsubscribe from messages in the message queue corresponding to that network device.

[0207] The following example illustrates the routing policy processing method provided in this application:

[0208] For example, Figure 10 This application provides an example of an interactive flowchart for a routing policy processing method. The method is applied to a BGP service cluster, a load balancer, and source and destination devices associated with a target routing policy in a cloud network system. The BGP service cluster includes BGP service module 1 and BGP service module 2. The source device is connected to BGP service module 1, and the destination device is connected to BGP service module 2. Figure 10 As shown, the routing policy processing method may include:

[0209] S1010: The load balancer sends the target routing policy to BGP service module 1;

[0210] The target routing policy includes: the routing policy of the source device and the routing policy of the destination device.

[0211] S1020: BGP service module 1 determines that the source device associated with the target routing policy is connected to BGP service module 1, and stores the routing policy of the source device locally.

[0212] S1030: BGP service module 1 determines that the destination device associated with the target routing policy is not connected to BGP service module 1, and can store the routing policy of the destination device in the message queue corresponding to the target device;

[0213] S1040: The source device sends the first routing information to BGP service module 1;

[0214] S1050: BGP service module 1 processes the first routing information based on the routing policy of the source device stored locally to obtain the second routing information;

[0215] S1060: BGP service module 1 stores the second routing information into the message queue corresponding to the destination device;

[0216] S1070: BGP service module 2 reads the second routing information and the routing policy of the destination device from the message queue corresponding to the destination device;

[0217] S1080: BGP service module 2 processes the second routing information based on the routing policy of the destination device to obtain the third routing information;

[0218] S1090: BGP service module 2 sends third-party routing information to the destination device.

[0219] This application provides a routing policy processing method, comprising: a load balancer sending a target routing policy to a first BGP service module in a BGP service cluster; the first BGP service module storing the routing policy of the source device in a message queue corresponding to the source device and storing the routing policy of the destination device in a message queue corresponding to the destination device; the source device sending first routing information to a second BGP service module in the BGP service cluster; the second BGP service module reading the routing policy of the source device from the message queue corresponding to the source device; the second BGP service module processing the first routing information based on the routing policy of the source device to obtain second routing information; a third BGP service module in the BGP service cluster obtaining the second routing information; the third BGP service module reading the routing policy of the destination device from the message queue corresponding to the destination device; the third BGP service module processing the second routing information based on the routing policy of the destination device to obtain third routing information; and the third BGP service module sending the third routing information to the destination device. Since the BGP service module corresponding to the source device associated with the target routing policy can read the routing policy of the source device from the message queue corresponding to the source device, and the BGP service module corresponding to the destination device associated with the target routing policy can read the routing policy of the destination device from the message queue corresponding to the destination device, it can be ensured that the routing policy can be processed.

[0220] Furthermore, even if the BGP service module corresponding to the source device changes, the BGP service module currently connected to it, i.e., the second BGP service module, can obtain the routing policy of the source device from the message queue corresponding to the source device. And even if the BGP service module corresponding to the destination device changes, the BGP service module currently connected to it, i.e., the third BGP service module, can obtain the routing policy of the destination device from the message queue corresponding to the destination device, thereby ensuring that the target routing policy can be processed.

[0221] It is worth mentioning that, in this embodiment, by introducing a message queue, concurrent query issues can be avoided, thereby improving the performance of the cloud network system. Furthermore, the message queue has good scalability and reliability, capable of meeting the needs of large-scale BGP service clusters.

[0222] This application provides a routing policy processing apparatus, including multiple BGP service modules. Each BGP service module in the BGP service cluster is used to receive a target routing policy sent by a load balancer. The target routing policy includes a routing policy of the source device and a routing policy of the destination device. A first BGP service module in the BGP service cluster is used to receive first routing information sent by the source device. The first BGP service module is further used to process the first routing information based on the routing policy of the source device to obtain second routing information. The first BGP service module is further used to send the second routing information to a second BGP service module connected to the destination device. The second BGP service module is used to process the second routing information based on the routing policy of the destination device to obtain third routing information. The second BGP service module is further used to send the third routing information to the destination device.

[0223] In some implementations, the first BGP service module is specifically used to: send the second routing information to the load balancer, so that the load balancer sends the second routing information to the second BGP service module.

[0224] In some implementations, the second routing information is sent by the load balancer to other BGP service modules besides the first BGP service module.

[0225] In some implementations, the second routing information is sent by the load balancer only to the second BGP service module.

[0226] In some implementations, the first BGP service module is specifically used to: determine the second BGP service module; and send the second routing information to the second BGP service module.

[0227] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details are omitted here. Specifically, the routing policy processing device can execute... Figure 4 The corresponding method embodiments, and the foregoing and other operations and / or functions of each module in the routing policy processing device are respectively for implementing Figure 4 For the sake of brevity, the corresponding processes in each method are not described in detail here.

[0228] The routing policy processing apparatus of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application embodiment can be completed by integrated logic circuits in the processor hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0229] This application embodiment also provides a routing policy processing apparatus, including multiple BGP service modules; wherein, a first BGP service module in the BGP service cluster is used to receive a target routing policy sent by a load balancer; wherein, the target routing policy includes: a routing policy of the source device and a routing policy of the destination device; the first BGP service module is also used to store the target routing policy in a shared cache of the BGP service cluster; a second BGP service module in the BGP service cluster is used to receive first routing information sent by the source device; the second BGP service module is also used to obtain the routing policy of the source device; the second BGP service module is also used to process the first routing information based on the routing policy of the source device to obtain second routing information; a third BGP service module in the BGP service cluster is used to obtain the routing policy of the destination device; the third BGP service module is also used to obtain the second routing information; the third BGP service module is also used to process the second routing information based on the routing policy of the destination device to obtain third routing information; the third BGP service module is also used to send the third routing information to the destination device.

[0230] In some implementations, the second BGP service module is specifically used to read the routing policy of the source device from the shared cache.

[0231] In some implementations, before the second BGP service module obtains the routing policy of the source device, the second BGP service module is further configured to: when the second BGP service module determines that the routing policy of the source device is related to the source device, store the routing policy of the source device in the memory of the second BGP service module; correspondingly, the second BGP service module is specifically configured to: read the routing policy of the source device from the memory of the second BGP service module.

[0232] In some implementations, the third BGP service module is specifically used to read the routing policy of the destination device from the shared cache.

[0233] In some implementations, before the third BGP service module in the BGP service cluster obtains the routing policy of the destination device, the third BGP service module is further configured to: store the routing policy of the destination device in the memory of the third BGP service module when the third BGP service module determines that the routing policy of the destination device is related to the destination device; correspondingly, the third BGP service module is specifically configured to: read the routing policy of the destination device from the memory of the third BGP service module.

[0234] In some implementations, before the third BGP service module obtains the second routing information, the second BGP service module is also used to store the second routing information in a shared cache; correspondingly, the third BGP service module is specifically used to read the second routing information from the shared cache.

[0235] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details are omitted here. Specifically, the routing policy processing device can execute... Figure 6 The corresponding method embodiments, and the foregoing and other operations and / or functions of each module in the routing policy processing device are respectively for implementing Figure 6 For the sake of brevity, the corresponding processes in each method are not described in detail here.

[0236] The routing policy processing apparatus of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application embodiment can be completed by integrated logic circuits in the processor hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0237] This application embodiment also provides a routing policy processing apparatus, including multiple BGP service modules; wherein, a first BGP service module in the BGP service cluster is used to receive a target routing policy sent by a load balancer; wherein, the target routing policy includes: a routing policy of a source device and a routing policy of a destination device; the first BGP service module is further used to store the routing policy of the source device in a message queue corresponding to the source device; and to store the routing policy of the destination device in a message queue corresponding to the destination device; a second BGP service module in the BGP service cluster is used to receive first routing information sent by the source device; the second BGP service module is further used to read the routing policy of the source device from the message queue corresponding to the source device; the second BGP service module is further used to process the first routing information based on the routing policy of the source device to obtain second routing information; a third BGP service module in the BGP service cluster is used to obtain the second routing information; the third BGP service module is further used to read the routing policy of the destination device from the message queue corresponding to the destination device; the third BGP service module is further used to process the second routing information based on the routing policy of the destination device to obtain third routing information; the third BGP service module is further used to send the third routing information to the destination device.

[0238] In some implementations, before the third BGP service module in the BGP service cluster obtains the second routing information, the second BGP service module is also used to store the second routing information in the message queue corresponding to the destination device; correspondingly, the third BGP service module is specifically used to read the second routing information from the message queue corresponding to the destination device.

[0239] In some implementations, the first BGP service module is specifically used to: if the first BGP service module is not the second BGP service module, store the routing policy of the source device in the message queue corresponding to the source device.

[0240] In some implementations, the first BGP service module is further configured to: if the first BGP service module is the second BGP service module, receive the first routing information sent by the source device; and process the first routing information based on the routing policy of the source device to obtain the second routing information.

[0241] In some implementations, the first BGP service module is specifically used to: if the first BGP service module is not the third BGP service module, store the routing policy of the destination device in the message queue corresponding to the destination device.

[0242] In some implementations, the first BGP service module is further configured to: if the first BGP service module is a third BGP service module, obtain the second routing information; process the second routing information based on the routing policy of the destination device to obtain the third routing information; and send the third routing information to the destination device.

[0243] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details are omitted here. Specifically, the routing policy processing device can execute... Figure 8 The corresponding method embodiments, and the foregoing and other operations and / or functions of each module in the routing policy processing device are respectively for implementing Figure 8 For the sake of brevity, the corresponding processes in each method are not described in detail here.

[0244] The routing policy processing apparatus of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application embodiment can be completed by integrated logic circuits in the processor hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0245] Figure 11 This is a schematic block diagram of the electronic device 1100 provided in an embodiment of this application. Figure 11 As shown, the electronic device 1100 may include:

[0246] The system includes a memory 1110 and a processor 1120. The memory 1110 stores a computer program 1130 and transfers the computer program 1130 to the processor 1120. In other words, the processor 1120 can retrieve and run the computer program 1130 from the memory 1110 to implement the methods described in the embodiments of this application.

[0247] For example, the processor 1120 can be used to execute the steps in the above method according to the instructions in the computer program 1130.

[0248] In some embodiments of this application, the processor 1120 may include, but is not limited to:

[0249] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0250] In some embodiments of this application, the memory 1110 includes, but is not limited to:

[0251] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0252] In some embodiments of this application, the computer program 1130 may be divided into one or more modules, which are stored in the memory 1110 and executed by the processor 1120 to complete the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 1130 in the electronic device.

[0253] like Figure 11 As shown, the electronic device 1100 may further include:

[0254] Transceiver 1140, which can be connected to processor 1120 or memory 1110.

[0255] The processor 1120 can control the transceiver 1140 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 1140 may include a transmitter and a receiver. The transceiver 1140 may further include antennas, and the number of antennas may be one or more.

[0256] It should be understood that the various components in the electronic device 1100 are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0257] According to one aspect of this application, a computer storage medium is provided that stores a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0258] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described in the above-described method embodiments.

[0259] In other words, when implemented using software, it can be implemented wholly or partially in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0260] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0261] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0262] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0263] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A routing policy processing method, characterized in that, The method is applied to a Border Gateway Protocol (BGP) service cluster in a cloud network system, wherein the BGP service cluster includes multiple BGP service modules, and the method includes: Each BGP service module in the BGP service cluster receives a target routing policy sent by the load balancer; wherein, the target routing policy includes: a routing policy for the source device and a routing policy for the destination device; The first BGP service module in the BGP service cluster receives the first routing information sent by the source device; The first BGP service module processes the first routing information based on the routing policy of the source device to obtain the second routing information; The first BGP service module sends the second routing information to the second BGP service module connected to the destination device; The second BGP service module processes the second routing information based on the routing policy of the destination device to obtain the third routing information; The second BGP service module sends the third routing information to the destination device.

2. The method according to claim 1, characterized in that, The first BGP service module sends the second routing information to the second BGP service module connected to the destination device, including: The first BGP service module sends the second routing information to the load balancer, so that the load balancer sends the second routing information to the second BGP service module.

3. The method according to claim 2, characterized in that, The second routing information is sent by the load balancer to other BGP service modules besides the first BGP service module.

4. The method according to claim 2, characterized in that, The second routing information is sent only to the second BGP service module by the load balancer.

5. The method according to claim 1, characterized in that, The first BGP service module sends the second routing information to the second BGP service module connected to the destination device, including: The first BGP service module determines the second BGP service module; The first BGP service module sends the second routing information to the second BGP service module.

6. A routing policy processing method, characterized in that, The method is applied to a BGP service cluster in a cloud network system, the BGP service cluster comprising multiple BGP service modules, the method comprising: The first BGP service module in the BGP service cluster receives the target routing policy sent by the load balancer; wherein, the target routing policy includes: the routing policy of the source device and the routing policy of the destination device; The first BGP service module stores the target routing policy in the shared cache of the BGP service cluster; The second BGP service module in the BGP service cluster receives the first routing information sent by the source device; The second BGP service module obtains the routing policy of the source device; The second BGP service module processes the first routing information based on the routing policy of the source device to obtain the second routing information; The third BGP service module in the BGP service cluster obtains the routing policy of the destination device. The third BGP service module obtains the second routing information; The third BGP service module processes the second routing information based on the routing policy of the destination device to obtain the third routing information; The third BGP service module sends the third routing information to the destination device.

7. The method according to claim 6, characterized in that, The second BGP service module obtains the routing policy of the source device, including: The second BGP service module reads the routing policy of the source device from the shared cache.

8. The method according to claim 6, characterized in that, Before the second BGP service module obtains the routing policy of the source device, it also includes: When the second BGP service module determines that the routing policy of the source device is related to the source device, the second BGP service module stores the routing policy of the source device in the memory of the second BGP service module. The second BGP service module obtains the routing policy of the source device, including: The second BGP service module reads the routing policy of the source device from the memory of the second BGP service module.

9. A routing policy processing method, characterized in that, The method is applied to a BGP service cluster in a cloud network system, the BGP service cluster comprising multiple BGP service modules, the method comprising: The first BGP service module in the BGP service cluster receives the target routing policy sent by the load balancer; wherein, the target routing policy includes: the routing policy of the source device and the routing policy of the destination device; The first BGP service module stores the routing policy of the source device in the message queue corresponding to the source device; and stores the routing policy of the destination device in the message queue corresponding to the destination device; The second BGP service module in the BGP service cluster receives the first routing information sent by the source device; The second BGP service module reads the routing policy of the source device from the message queue corresponding to the source device; The second BGP service module processes the first routing information based on the routing policy of the source device to obtain the second routing information; The third BGP service module in the BGP service cluster obtains the second routing information; The third BGP service module reads the routing policy of the destination device from the message queue corresponding to the destination device; The third BGP service module processes the second routing information based on the routing policy of the destination device to obtain the third routing information; The third BGP service module sends the third routing information to the destination device.

10. A routing policy processing device, characterized in that, Includes multiple BGP service modules; Each BGP service module in the BGP service cluster is used to receive the target routing policy sent by the load balancer; wherein, the target routing policy includes: the routing policy of the source device and the routing policy of the destination device; The first BGP service module in the BGP service cluster is used to receive the first routing information sent by the source device; The first BGP service module is further configured to process the first routing information based on the routing policy of the source device to obtain the second routing information; The first BGP service module is also used to send the second routing information to the second BGP service module connected to the destination device; The second BGP service module is used to process the second routing information based on the routing policy of the destination device to obtain the third routing information; The second BGP service module is also used to send the third routing information to the destination device.

11. A routing policy processing device, characterized in that, Includes multiple BGP service modules; The first BGP service module in the BGP service cluster is used to receive the target routing policy sent by the load balancer; wherein, the target routing policy includes: the routing policy of the source device and the routing policy of the destination device; The first BGP service module is also used to store the target routing policy in the shared cache of the BGP service cluster; The second BGP service module in the BGP service cluster is used to receive the first routing information sent by the source device; The second BGP service module is also used to obtain the routing policy of the source device; The second BGP service module is further configured to process the first routing information based on the routing policy of the source device to obtain the second routing information; The third BGP service module in the BGP service cluster is used to obtain the routing policy of the destination device. The third BGP service module is also used to obtain the second routing information; The third BGP service module is also used to process the second routing information based on the routing policy of the destination device to obtain the third routing information; The third BGP service module is also used to send the third routing information to the destination device.

12. A routing policy processing device, characterized in that, Includes multiple BGP service modules; The first BGP service module in the BGP service cluster is used to receive the target routing policy sent by the load balancer; wherein, the target routing policy includes: the routing policy of the source device and the routing policy of the destination device; The first BGP service module is further configured to store the routing policy of the source device in the message queue corresponding to the source device; and store the routing policy of the destination device in the message queue corresponding to the destination device; The second BGP service module in the BGP service cluster is used to receive the first routing information sent by the source device. The second BGP service module is also used to read the routing policy of the source device from the message queue corresponding to the source device; The second BGP service module is further configured to process the first routing information based on the routing policy of the source device to obtain the second routing information; The third BGP service module in the BGP service cluster is used to obtain the second routing information; The third BGP service module is also used to read the routing policy of the destination device from the message queue corresponding to the destination device; The third BGP service module is also used to process the second routing information based on the routing policy of the destination device to obtain the third routing information; The third BGP service module is also used to send the third routing information to the destination device.

13. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the method of any one of claims 1 to 9.

14. A computer-readable storage medium, characterized in that, Used to store a computer program that, when run on a computer, causes the computer to perform the method according to any one of claims 1 to 9.

15. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the method of any one of claims 1 to 9.

Images