Route synchronization method, device and equipment and readable storage medium

Abstract

The invention provides a route synchronization method, device and equipment and a readable storage medium, and the method comprises the steps: obtaining network overlay route information, and reflecting the network overlay route information to a vBGP; host overlay routing information injected by the SDN controller is received through the independent communication channel; and the overlay routing information of the host is reflected to each BGP (Border Gateway Protocol) peer. According to the technical scheme of the invention, an independent communication channel is established between the route reflector and the SDN controller, the problems of main and standby switching and neighbor oscillation caused by vBGP are avoided, the stability and efficiency of route synchronization are improved, host overlay route information can be directly injected and reflected to each BGP peer by the SDN controller, and the reliability of route synchronization is improved. The routing management flexibility and reliability in the mixed Overlay networking environment are enhanced, the routing updating process is simplified, and the risk of routing errors and residues is reduced.

Description

Technical Field

[0001] This specification relates to the field of communication technologies, and in particular, to a routing synchronization method, apparatus, device, and readable storage medium. Background Art

[0002] To address the limitations of the two networking solutions of network Overlay networking and host Overlay networking, hybrid Overlay networking emerged. Hybrid Overlay networking can support both network Overlay and host Overlay simultaneously. It can not only connect to virtualized servers but also support the connection to non-virtualized physical servers, providing customers with autonomous and diverse choices. However, in hybrid Overlay networking, since the virtual switch (Open vSwitch) does not have the function of processing BGP EVPN routes, it is impossible to achieve hybrid Overlay under EVPN networking, thus restricting the networking options for users. To solve this problem, the SeerEngine-DC controller implements the hybrid Overlay function under EVPN networking, enabling the traffic between network Overlay and host Overlay in the networking to communicate with each other and solving the problem of being unable to deploy virtual switch access and physical switch access simultaneously.

[0003] There are still some problems with the hybrid Overlay networking technical solution. The synchronization of host overlay routes mainly relies on the interaction between vBGP (virtual BGP) and RR (route reflector). This solution has many deficiencies in practical applications. First, the primary / backup switchover of vBGP may cause oscillations between the RR and vBGP neighbors, resulting in the incorrect revocation or residue of host overlay routes, thus affecting the stability and reliability of the network. Currently, there is a lack of an effective routing synchronization mechanism between the controller and the RR device. In scenarios such as device activation, route update, and failure, it is impossible to ensure the accuracy and consistency of routes. These problems not only reduce the performance of the network but also increase the complexity and cost of network operation and maintenance. Summary of the Invention

[0004] In view of this, this specification provides a routing synchronization method, apparatus, electronic device, and readable storage medium to improve the above-mentioned problem of insufficient network stability.

[0005] Specific technical solutions are as follows:

[0006] This specification provides a routing synchronization method, which is applied to a route reflector. An independent communication channel is provided between the route reflector and the SDN controller, and the path of the independent communication channel does not include vBGP. The method includes: obtaining network overlay routing information, reflecting the network overlay routing information to vBGP, so that the SDN controller obtains the network overlay routing information from vBGP and distributes it to the virtual switch OVS in a specified manner according to the network overlay routing information; receiving the host overlay routing information injected by the SDN controller through the independent communication channel, where the host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay; reflecting the host overlay routing information to each BGP peer.

[0007] As a technical solution, the distributing to the virtual switch OVS in a specified manner according to the network overlay routing information includes: generating an Openflow flow table according to the second type, third type, and fifth type of routes included in the network overlay routing information, and distributing the Openflow flow table to the OVS.

[0008] As a technical solution, the host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay, including: the SDN controller obtains the virtual machine information of the online OVS according to the current state of the OVS of the host overlay and generates the second type, third type, and fifth type of routes of EVPN based on this, so as to generate the host overlay routing information.

[0009] As a technical solution, the receiving the host overlay routing information injected by the SDN controller through the independent communication channel includes: obtaining the identification information of the SDN controller and marking the injected host overlay routing information according to the identification information.

[0010] As a technical solution, in response to the event of the activation of this route reflector, traverse and search for the host overlay routing information injected by the SDN controller existing locally according to the marking, and set the host overlay routing information found through traversal to invalid.

[0011] As a technical solution, in response to the event of the completion of route injection, revoke the host overlay routing information set to invalid.

[0012] This specification also provides a routing synchronization device, which is applied to a route reflector. An independent communication channel is provided between the route reflector and the SDN controller, and the path of the independent communication channel does not include vBGP. The device includes: a first module, configured to obtain network overlay routing information and reflect the network overlay routing information to vBGP, so that the SDN controller obtains the network overlay routing information from vBGP and distributes it to the virtualized switch OVS in a specified manner according to the network overlay routing information; a second module, configured to receive the host overlay routing information injected by the SDN controller through the independent communication channel, where the host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay; a third module, configured to reflect the host overlay routing information to each BGP peer.

[0013] As a technical solution, the distributing to the virtualized switch OVS in a specified manner according to the network overlay routing information includes: generating an Openflow flow table according to the second-class, third-class, and fifth-class routes included in the network overlay routing information, and distributing the Openflow flow table to the OVS.

[0014] As a technical solution, the host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay, including: the SDN controller obtains the virtual machine information of the online OVS according to the current state of the OVS of the host overlay and generates the second-class, third-class, and fifth-class routes of EVPN accordingly to generate the host overlay routing information.

[0015] As a technical solution, the receiving the host overlay routing information injected by the SDN controller through the independent communication channel includes: obtaining the identification information of the SDN controller and marking the injected host overlay routing information according to the identification information.

[0016] As a technical solution, it includes a fourth module, configured to, in response to the event that this route reflector is activated, traverse and search for the host overlay routing information injected by the SDN controller existing locally according to the marking, and set the traversed and found host overlay routing information injected by the SDN controller to be invalid.

[0017] As a technical solution, the fourth module is further configured to, in response to the event that the route injection is completed, revoke the host overlay routing information set to be invalid.

[0018] This specification also provides an electronic device, including a processor and a readable storage medium. The readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the foregoing routing synchronization method.

[0019] This specification also provides a readable storage medium that stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions cause the processor to implement the foregoing routing synchronization method.

[0020] The above technical solutions provided by this specification at least bring the following beneficial effects:

[0021] By establishing an independent communication channel between the route reflector and the SDN controller, the problems of master-slave switchover and neighbor oscillation caused by vBGP are avoided, the stability and efficiency of routing synchronization are improved, the host overlay routing information can be directly injected by the SDN controller and reflected to each BGP peer, enhancing the flexibility and reliability of routing management in a hybrid Overlay networking environment, simplifying the routing update process, and reducing the risk of routing errors and residues. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the embodiments of this specification or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings of the embodiments of this specification.

[0023] Figure 1 is a flowchart of the routing synchronization method in an embodiment of this specification;

[0024] Figure 2 is a flowchart of the routing synchronization method in an embodiment of this specification;

[0025] Figure 3 is a schematic flowchart in an embodiment of this specification;

[0026] Figure 4 is a schematic flowchart in an embodiment of this specification;

[0027] Figure 5 is a schematic flowchart in an embodiment of this specification;

[0028] Figure 6 is a hardware structure diagram of the electronic device in an embodiment of this specification.

[0029] Reference numerals: first module 21, second module 22, third module 23. Detailed implementation

[0030] The terms used in the embodiments of this specification are only for the purpose of describing specific embodiments and do not limit this specification. The singular forms "a", "the" and "said" used in this specification and the claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to any or all possible combinations of one or more of the associated listed items.

[0031] It should be understood that although the terms first, second, third, etc. may be used in the embodiments of this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, in addition, the word "if" used may be interpreted as "when" or "while" or "in response to a determination".

[0032] The hybrid Overlay networking combines the advantages of the network Overlay and host Overlay networking modes. It can not only access virtualized servers but also support non-virtualized physical servers. This hybrid Overlay solution provides customers with more diverse and autonomous choices, enabling different types of servers to coexist and cooperate efficiently under the same network architecture. When implementing the hybrid Overlay under the EVPN (Ethernet Virtual Private Network) networking, since the virtual switch (vSwitch) itself does not have the ability to handle BGP EVPN routes, it limits the application scope and flexibility of the hybrid Overlay.

[0033] To overcome the above limitations, the SeerEngine-DC controller is introduced to implement the hybrid Overlay function under EVPN networking, enabling the traffic between the network Overlay and the host Overlay to communicate with each other and solving the problem of simultaneously deploying virtual switch access and physical switch access. However, there is a problem with the above solution. During the process of reflecting the network overlay side EVPN routes to the main vBGP through the RR, then converting them into Openflow flow tables by the controller and sending them to the OVS host, and finally reflecting the host overlay routes to each BGP peer through the RR, it is easy to trigger the problem of vBGP primary and standby switching.

[0034] Such a switch may occur not only due to reasons such as controller upgrades, server failures, or cluster events, but may also cause oscillations between the RR and vBGP neighbors, thereby causing logical problems, such as multiple BGP GRs resulting in incorrect revocation or residue of the host overlay routes, affecting the stability and reliability of the network.

[0035] In view of this, this specification provides a routing synchronization method, apparatus, electronic device, and readable storage medium to at least improve one of the above technical problems.

[0036] Specific technical solutions are as follows.

[0037] In one implementation, this specification provides a routing synchronization method applied to a route reflector. An independent communication channel is provided between the route reflector and the SDN controller, and the path of the independent communication channel does not include vBGP. The method includes: obtaining network overlay routing information, reflecting the network overlay routing information to vBGP, so that the SDN controller obtains the network overlay routing information from vBGP and issues it to the virtualized switch OVS in a specified manner according to the network overlay routing information; receiving the host overlay routing information injected by the SDN controller through the independent communication channel, where the host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay; reflecting the host overlay routing information to each BGP peer.

[0038] Specifically, as Figure 1 , it includes the following steps:

[0039] Step S11, obtaining network overlay routing information and reflecting the network overlay routing information to vBGP.

[0040] When the RR obtains the network overlay routing information, it reflects the EVPN routes on the network overlay side to the primary vBGP through the traditional BGP reflection mechanism.

[0041] Step S12, receiving the host overlay routing information injected by the SDN controller through the independent communication channel.

[0042] After the primary vBGP receives the network overlay routing information reflected by the RR, it reports these routing information to the SDN controller through the NETCONF protocol. The SDN controller receives the network overlay routing information, converts these routing information into Openflow flow tables according to the preset policies and algorithms, and issues these flow tables to the corresponding virtualized switch OVS.

[0043] RR receives the host overlay routing information injected by the SDN controller through an independent communication channel. This process is one of the key innovations of the present invention. The host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay. The SDN controller can perceive the state changes of the OVS in real time, including events such as the online and offline of virtual machines, and generate corresponding host overlay routing information according to these state changes. These routing information are directly injected into the RR through an independent communication channel, avoiding the routing oscillation problem caused by the vBGP primary and standby switching in the traditional solution, and ensuring the stability and accuracy of the host overlay routing information.

[0044] Step S13, reflect the host overlay routing information to each BGP peer.

[0045] RR will spread this routing information to other devices in the network according to the rules and policies of the BGP protocol.

[0046] For example, in a data center environment containing multiple virtual machines and physical servers, the synchronization of network overlay routing information is crucial for realizing the interconnection and interoperability between different devices. Suppose a virtual machine needs to access another physical server located in the network overlay. After the SDN controller converts the network overlay routing information into Openflow flow tables and distributes them to the OVS through the above process, the OVS can correctly encapsulate and forward the traffic of the virtual machine to the network overlay where the target physical server is located according to these flow table information, thus realizing the communication between the virtual machine and the physical server.

[0047] When a virtual machine goes online in the host overlay environment, the SDN controller perceives this event and generates corresponding host overlay routing information according to the information such as the IP address and MAC address of the virtual machine. After these routing information are injected into the RR through an independent communication channel, the RR will reflect these routing information to each BGP peer, thus realizing the synchronization of the host overlay routing information in the whole network. This process not only improves the efficiency of routing synchronization, but also reduces the risk of network interruption caused by routing oscillation.

[0048] In one implementation manner, the step of distributing the network overlay routing information to the virtualized switch OVS in a specified manner includes: generating Openflow flow tables according to the second type, third type, and fifth type of routes included in the network overlay routing information, and distributing the Openflow flow tables to the OVS.

[0049] In one embodiment, the host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay, including: the SDN controller obtains the virtual machine information of the online OVS according to the current state of the OVS of the host overlay, and generates the second, third, and fifth types of routes of the EVPN based on this, so as to generate the host overlay routing information.

[0050] In one embodiment, receiving the host overlay routing information injected by the SDN controller through an independent communication channel includes: obtaining the identification information of the SDN controller, and marking the injected host overlay routing information according to the identification information.

[0051] The routing source marking mechanism is used to mark the routing information injected by the SDN controller through NETCONF. When the RR device is activated, it will check whether there is routing information injected by the SDN controller, and mark these routing information as invalid. When the SDN controller injects routing information again, the invalid marking operation will be performed on the existing routing information, and the injection operation will be performed on the new routing information. After the injection is completed, the invalid marking operation on the routing information with the invalid marking will be revoked. This mechanism ensures that during the activation process of the RR device, the host overlay routing information can be accurately synchronized, preventing the problem of residual original routes caused by the connection oscillation between the device and the controller.

[0052] In one embodiment, in response to the event of the activation of this route reflector, the host overlay routing information injected by the SDN controller existing locally is searched and traversed according to the marking, and the host overlay routing information found by the traversal is set to be invalid.

[0053] In one embodiment, in response to the event of the completion of route injection, the host overlay routing information set to be invalid is revoked.

[0054] In one implementation, the route reflector obtains network overlay routing information from the physical or virtual devices it is connected to. This routing information typically includes path details to different subnets or hosts. Once this information is obtained, the route reflector reflects it to the vBGP instance, enabling the SDN controller to extract the necessary network overlay routing information from it. For example, in a data center network, the route reflector may collect routing information about the subnets where each server is located from multiple access switches and forward this information to vBGP. The SDN controller then listens for these routing updates and formulates and issues policies based on the information obtained. Suppose a new server comes online in the data center and its IP address needs to be known to all other servers for communication. The SDN controller identifies this new route based on the routing information received from vBGP and issues it to the relevant OVS instances in a specified manner. This specified manner may involve specific traffic control rules, QoS configurations, etc., to ensure that data packets can be transmitted to the target location efficiently and accurately.

[0055] To achieve the synchronization of host overlay routing information, the SDN controller directly injects routing information using an independent communication channel with the route reflector. The key here is that the host overlay routing information is generated based on the current state of the OVS, which means it contains the latest network topology and connection status. For example, when a virtual machine on a server running KVM virtualization migrates, the state of the OVS changes, and the SDN controller can quickly sense this change and generate new host overlay routing information accordingly. This information is then sent to the route reflector through the independent channel. Continuing with the previous example, assume that a virtual machine in the data center migrates due to resource requirements. Then the SDN controller will calculate the updated routing information based on the new state of the OVS and push it to the route reflector through the independent channel. The benefits of this are obvious: not only does it improve the speed of routing information updates, but it also avoids potential problems caused by vBGP primary / backup switching.

[0056] After the route reflector receives the host overlay route information injected by the SDN controller, it reflects this information to all BGP peers. This step ensures the consistency of route information in the entire network environment. For example, in a multi-tenant data center environment, different tenants may use their own subnets and routing policies. When a network change occurs within one tenant, such as adding a virtual firewall or adjusting access rules between some virtual machines, the corresponding route changes need to be propagated to all associated nodes in a timely manner. Through the role of the route reflector, these updates can be distributed quickly and reliably, ensuring the quality and security of network services. At the same time, this method also supports a flexible fault handling mechanism. If a BGP peer is temporarily unreachable, the route reflector can cache the route update information to be sent and retry immediately after the peer recovers, thus minimizing the possibility of route inconsistency.

[0057] In one implementation, the update mechanism is used to handle changes in host overlay route information. When the host overlay route information changes, the SDN controller immediately performs route injection or revocation operations on the RR. This mechanism ensures the timeliness and accuracy of the host overlay route information and can promptly reflect changes in the network status. For example, when a virtual machine migrates, the SDN controller will sense this event, update the host overlay route information according to the new location of the virtual machine, and then inject the updated route information into the RR through an independent communication channel. After the RR receives the updated route information, it reflects it to each BGP peer, thereby achieving synchronous update of the host overlay route information.

[0058] The loop prevention mechanism is used to prevent the generation of routing loops. When the SDN controller injects host overlay route information, it determines whether it is network overlay route information through the next-hop address of the route, thereby ensuring that the injected host overlay route information will not be re-published to the host overlay and avoiding the generation of routing loops.

[0059] The timed synchronization mechanism is used to periodically check the differences between the host overlay route information on the RR and the SDN controller. The SDN controller will periodically subscribe to the injected route information of the RR and compare it on the controller. If a difference is found, the SDN controller will inject or revoke the different routes as the standard to ensure that the host overlay route information on the RR is consistent with the SDN controller.

[0060] The fault handling mechanism is used to handle the situation where the RR is disconnected from the SDN controller. When the RR is disconnected from the SDN controller, the routing information may be out of sync. To solve this problem, the RR periodically detects the connection status with the SDN controller. When the local end is unreachable from the SDN controller, the peer end is reachable from the SDN controller, and the failure timer expires, the RR will revoke the routing information injected by the local SDN controller.

[0061] In a data center environment with two RRs, assume that the connection between one RR and the SDN controller fails, while the connection between the other RR and the SDN controller remains normal. In this case, the failure timer will start. If the connection between the faulty RR and the SDN controller is restored before the failure timer expires, the failure timer will be deleted and the routing information will remain unchanged. If the failure timer expires and the faulty RR still cannot establish a connection with the SDN controller, the faulty RR will revoke the routing information injected by the local SDN controller, thus avoiding network problems caused by inconsistent routing information.

[0062] In one implementation, a bidirectional routing synchronization mechanism based on an independent communication channel is proposed, which realizes the efficient coordination of network Overlay and host Overlay routing by reconstructing the interaction path between the route reflector and the SDN controller.

[0063] At the system architecture level, the route reflector needs to deploy an independent communication proxy module, which establishes a dedicated bidirectional data channel with the SDN controller. This channel is implemented using the lightweight remote procedure call (gRPC) protocol and is configured with an encryption transport layer based on TLS1.3 to ensure data security. The independent communication channel completely bypasses the vBGP protocol stack, and its physical path preferentially selects a direct network interface or is isolated through an independent VLAN to avoid competing for bandwidth resources with existing BGP traffic. To improve the reliability of the channel, the proxy module periodically sends heartbeat detection packets. If no response is received continuously for 3 times, the link will be automatically switched to the backup port, and an alarm log will be sent to the network management system. This design enables the route reflector and the controller to maintain communication through the independent channel even in the case of vBGP service anomalies or configuration errors, ensuring the continuous synchronization of critical routing information.

[0064] In the direction of network overlay routing synchronization, the route reflector obtains the original routing table entries from the physical network device (such as a core switch or router) through the BGP peer session. These entries contain attributes such as the target network prefix, the next hop address, and the autonomous system path (AS_PATH), which need to be converted into a format and filtered by the preprocessing module. Specifically, the preprocessing module first filters out the routing entries belonging to the overlay network according to the predefined strategy (for example, matching a specific community attribute or prefix range), and then encapsulates them into a message body in JSON format. The message structure contains fields such as the routing prefix, protocol version, timestamp, and checksum. After the encapsulation is completed, the route reflector reflects the processed network overlay routing information to the node where the SDN controller is located through the traditional vBGP channel. The main purpose of retaining the vBGP channel here is to be compatible with the existing controller interface, while taking advantage of the inherent routing aggregation and policy control capabilities of BGP, such as setting the LOCAL_PREF attribute to identify the routing priority, or using the MED value to achieve cross-data center routing optimization. After receiving the routing information announced by vBGP, the SDN controller will call the internal routing calculation engine to optimize the path, generate flow table rules suitable for the virtualized environment, and send them to each OVS instance in batches through the OpenFlow protocol. Taking a financial cloud platform as an example, when the core switch adds a route pointing to the 10.20.0.0 / 16 network segment, the route reflector completes information extraction and forwarding within 200 milliseconds, and the controller completes the update of the flow table of the entire network within 500 milliseconds, shortening the synchronization delay by 60% compared with the traditional solution.

[0065] In the direction of host Overlay route synchronization, the SDN controller continuously monitors the connection status and port traffic of each OVS instance. When a host-level route change is detected (such as a change in the MAC address binding caused by virtual machine migration), it dynamically generates host Overlay route information. This information includes metadata such as virtual network identifier (VNI), the mapping relationship between virtual machine IP and MAC addresses, and the physical port information of the current host. Different from traditional solutions, the controller no longer relies on vBGP to reverse announce this information, but directly injects the updated route entries into the route reflector through an independent communication channel. To achieve efficient transmission, the controller adopts a batch processing mechanism, merging multiple host route change events occurring within the same time period into a single message packet, and the message body is encoded using Protocol Buffers to reduce transmission overhead. For example, during the rolling upgrade of a container cluster, the IP addresses of 10 containers in a certain batch change. The controller will integrate these change records into an update instruction containing 10 route entries and send them to the route reflector in one go through the independent channel, reducing the number of network packets by 90% compared to the method of sending them one by one. After receiving the host Overlay route information, the route reflector immediately starts the verification process: first, it verifies the message signature to ensure data integrity, then checks the compatibility of the route entries with local policies (such as whether they belong to the permitted address range), and finally converts the valid route entries into the standard BGP UPDATE message format and reflects them to all peer devices through the iBGP session. During this process, the low-latency feature of the independent channel (end-to-end delay <5ms) enables the global synchronization of host routes to be completed within 100 milliseconds, effectively supporting the business continuity requirements of highly dynamic virtualized environments.

[0066] When the independent communication channel is temporarily interrupted due to a network failure, the local cache module of the route reflector will temporarily store the latest received host Overlay route information and perform incremental synchronization after the channel is restored to avoid data loss. At the same time, to address possible version compatibility issues, the proxy module will negotiate the supported protocol versions of both parties when establishing a connection and mark the data format version number in the message header to ensure a smooth transition between new and old version components. To improve the processing performance in large-scale deployments, the route reflector adopts a multi-threaded architecture to handle route updates in different directions: the main thread is responsible for collecting network Overlay routes and vBGP reflection, and the sub-thread is dedicated to parsing the host Overlay data of the independent channel and generating BGP UPDATE messages. The two are decoupled through a shared memory queue to prevent a single-point bottleneck. Measured data shows that in a data center scenario with more than 5000 OVSs, the system can achieve a throughput of processing 2000 route updates per second, and the CPU utilization rate remains stable below 40%.

[0067] The independent communication channel implements a fine-grained access control policy. The proxy module of the route reflector verifies the digital certificate of the SDN controller and restricts its operating permissions based on the Role-Based Access Control (RBAC) model. For example, the controller is only authorized to inject host route information within a specific VNI range. If an unauthorized operation request is detected, the proxy module will immediately terminate the session and generate a security audit log. In addition, all route change records transmitted through the independent channel are written to an immutable blockchain ledger, providing a credible credential for post-event traceability. In a deployment case in the highly regulated financial industry, this design successfully passed the Class-3 Information Security Protection Certification and effectively prevented malicious route injection attacks.

[0068] The independent communication channel supports pluggable protocol adapters, which can dynamically load encoding and decoding modules according to the interface specifications of controllers from different vendors. For example, when docking with a third-party controller based on the RESTful API, the adapter converts the route information into JSON format and transmits it via HTTPS; if docking with a controller that supports the gRPC interface, it directly uses ProtocolBuffers for efficient serialization. This flexibility enables the solution to quickly integrate into heterogeneous network environments and avoid being tied to the technologies of specific vendors. When a multinational enterprise promoted this solution in its global data centers, it only needed to configure the corresponding adapters for the controller types in each region to achieve unified route management for multi-vendor devices, saving 80% of the custom development cost.

[0069] The intelligent traffic shaping algorithm further improves the channel utilization rate. This algorithm monitors the bandwidth occupancy rate and queue depth of the independent channel in real time and dynamically adjusts the packet sending frequency and batch size. When the channel load is below 30%, it adopts a small-batch high-frequency sending mode to reduce the end-to-end delay; when the load exceeds 70%, it automatically switches to a large-data-packet batch sending mode to maximize the throughput. Test data shows that this optimization increases the effective bandwidth utilization rate of the channel in congested scenarios from 65% to 92% without increasing additional transmission delays. At the same time, to address the CPU hot-spot problem during the route reflection process, by offloading the assembly task of BGP UPDATE packets to a dedicated hardware acceleration card, the packet generation speed of the route reflector is increased by 3 times, fully matching the line-speed processing requirements of a 25Gbps network interface.

[0070] In addition to the conventional link on / off state monitoring, the operation and maintenance platform can display in real time key metrics such as the delay distribution of independent channels, the routing synchronization success rate, and the protocol conversion time consumption, and set thresholds to trigger automatic alarms. For example, when the end-to-end synchronization delay of the host Overlay route exceeds 150 milliseconds continuously for 5 times, the system will automatically start the root cause analysis process, check for controller processing bottlenecks or network congestion, and recommend optimization strategies (such as expanding the controller nodes or adjusting the QoS policy). In the actual operation and maintenance of a certain e-government cloud platform, this function has helped the operation and maintenance team shorten the mean time to repair (MTTR) from 45 minutes to 8 minutes, significantly improving the service level agreement (SLA) compliance rate.

[0071] In one implementation, as Figure 2 , this specification also provides a routing synchronization device applied to a route reflector. An independent communication channel is provided between the route reflector and the SDN controller, and vBGP is not included in the path of the independent communication channel. The device includes: a first module for obtaining network overlay route information, reflecting the network overlay route information to vBGP so that the SDN controller can obtain the network overlay route information from vBGP and issue it to the virtual switch OVS in a specified manner according to the network overlay route information; a second module for receiving the host overlay route information injected by the SDN controller through the independent communication channel, where the host overlay route information is generated by the SDN controller according to the current state of the OVS of the host overlay; a third module for reflecting the host overlay route information to each BGP peer.

[0072] In one implementation, issuing the network overlay route information to the virtual switch OVS in a specified manner includes: generating an Openflow flow table according to the second-class, third-class, and fifth-class routes included in the network overlay route information, and issuing the Openflow flow table to the OVS.

[0073] In one implementation, the host overlay route information is generated by the SDN controller according to the current state of the OVS of the host overlay, including: the SDN controller obtains the virtual machine information of the online OVS according to the current state of the OVS of the host overlay and generates the second-class, third-class, and fifth-class routes of EVPN based on this to generate the host overlay route information.

[0074] In one implementation, receiving the host overlay route information injected by the SDN controller through the independent communication channel includes: obtaining the identification information of the SDN controller and marking the injected host overlay route information according to the identification information.

[0075] In one embodiment, it includes a fourth module, which is used to, in response to an event of activation of this route reflector, find the host overlay route information injected by the SDN controller existing locally according to the tag traversal, and set the host overlay route information found through the traversal as invalid.

[0076] In one embodiment, the fourth module is further used to, in response to an event of completion of route injection, revoke the host overlay route information set as invalid.

[0077] In one embodiment, as Figure 3 , when the device is activated on the controller, to ensure the synchronization of the host overlay route between the controller and the device and prevent the residual of the original route caused by the connection oscillation between the device and the controller, route source marking is performed. For the route injected by the controller through netconf, mark the IP of the controller injecting this route. When the RR device is activated, check whether there is a route injected by this controller. If so, mark these routes as invalid. When injecting routes, perform an operation to delete the invalid mark for the existing routes and perform an injection operation for the new routes. After the injection is completed, perform a revocation operation on the routes with an invalid mark.

[0078] When the host overlay route changes, the controller immediately performs a route injection or revocation operation on the RR. For the route subscribed from vBGP, the controller can determine whether it is a network overlay route through the next-hop address of the route, ensuring that the injected host overlay route will not be published to the host overlay again to avoid route loops.

[0079] As Figure 4 , the controller subscribes to the injected routes of the RR periodically and performs a comparison on the controller. If there are differences, perform an injection or revocation operation on the different routes based on the controller to ensure that the host overlay routes on the RR are consistent with the controller.

[0080] As Figure 5 , if the RR is disconnected from the controller, there may be a situation where the route is not synchronized with the controller. To ensure the accuracy of the route, the RR needs to detect the connection status with the controller regularly. When the local end is unreachable from the controller, the peer end is reachable from the controller, and the invalid timer times out, revoke the routes injected by the local end controller.

[0081] Add a group of aggregation connections between RRs, allow the same VLAN to pass through, and set a detection IP for the VLAN interface. Create a keep-alive LoopBack interface on the RR and set a keep-alive IP, and configure the route so that the local detection IP can communicate with the peer keep-alive IP.

[0082] Detect whether the controller is reachable. When it is unreachable, the keep-alive LoopBack interface is closed. When it is reachable, the keep-alive LoopBack interface is opened. Detect whether the keep-alive IP of the peer RR is reachable. When it is reachable, it is considered that the peer is reachable with the controller. When it is unreachable, it is considered that the peer is unreachable with the controller.

[0083] When the local end is unreachable to the controller and the peer is reachable to the controller, start the failure timer. If an event occurs that the local end is reachable to the controller or the peer is unreachable to the controller, delete the failure timer. If the failure timer overflows, revoke the routes injected by the controller at the local end.

[0084] In one implementation, this specification provides an electronic device, including a processor and a readable storage medium. The readable storage medium stores machine-executable instructions that can be executed by the processor. The processor executes the machine-executable instructions to implement the foregoing route synchronization method. In terms of hardware level, the schematic diagram of the hardware architecture can be seen Figure 6 as shown.

[0085] In one implementation, this specification provides a readable storage medium. The readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by the processor, the machine-executable instructions cause the processor to implement the foregoing route synchronization method.

[0086] Here, the readable storage medium can be any electronic, magnetic, optical or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, the readable storage medium can be: RAM (Radom Access Memory, random access memory), volatile memory, non-volatile memory, flash memory, storage drive (such as a hard disk drive), solid state drive, any type of storage disk (such as optical disk, DVD, etc.), or similar storage medium, or a combination thereof.

[0087] The systems, devices, modules or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, and the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver device, a game console, a tablet computer, a wearable device, or a combination of any several of these devices.

[0088] For the convenience of description, when describing the above devices, various units are described separately according to functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0089] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, this specification can take the form of a complete hardware implementation, a complete software implementation, or an implementation combining software and hardware aspects. Moreover, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0090] This specification is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure 1 one or more of the flows Figure 1 or blocks or the combination of blocks.

[0091] Moreover, these computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in Figure 1 one or more of the flows Figure 1 or blocks or the combination of blocks.

[0092] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in Figure 1 one or more of the flows Figure 1 or blocks or the combination of blocks.

[0093] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0094] The above are only the embodiments of this specification and are not intended to limit this specification. For those skilled in the art, various changes and modifications can be made to this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims of this specification.

Claims

1. A routing synchronization method, characterized in that, Applied to a route reflector, an independent communication channel is provided between the route reflector and an SDN controller, and the path of the independent communication channel does not include vBGP. The method includes: Obtain network overlay routing information, and reflect the network overlay routing information to vBGP, so that the SDN controller obtains the network overlay routing information from vBGP, and issues it to a virtualized switch OVS in a specified manner according to the network overlay routing information; Receive the host overlay routing information injected by the SDN controller through the independent communication channel, where the host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay; Reflect the host overlay routing information to each BGP peer.

2. The method according to claim 1, characterized in that, The issuing to the virtualized switch OVS in a specified manner according to the network overlay routing information includes: Generate an Openflow flow table according to the second-class, third-class, and fifth-class routes included in the network overlay routing information, and issue the Openflow flow table to the OVS.

3. The method according to claim 1, wherein The host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay, including: The SDN controller obtains the virtual machine information of the online OVS according to the current state of the OVS of the host overlay, and generates the second-class, third-class, and fifth-class routes of EVPN accordingly to generate the host overlay routing information.

4. The method according to claim 1, characterized in that, The receiving the host overlay routing information injected by the SDN controller through the independent communication channel includes: Obtain the identification information of the SDN controller, and mark the injected host overlay routing information according to the identification information.

5. The method according to claim 4, wherein In response to the event of the activation of this route reflector, traverse and search for the host overlay routing information injected by the SDN controller existing locally according to the mark, and set the host overlay routing information found by traversing to be invalid.

6. The method according to claim 5, wherein In response to the event of the completion of route injection, revoke the host overlay routing information set to be invalid.

7. A routing synchronization device, characterized in that, Applied to a route reflector, an independent communication channel is provided between the route reflector and an SDN controller, and the path of the independent communication channel does not include vBGP. The device includes: A first module, configured to obtain network overlay routing information, and reflect the network overlay routing information to vBGP, so that the SDN controller obtains the network overlay routing information from vBGP, and issues it to a virtualized switch OVS in a specified manner according to the network overlay routing information; A second module, configured to receive the host overlay routing information injected by the SDN controller through the independent communication channel, where the host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay; A third module, configured to reflect the host overlay routing information to each BGP peer.

8. The device according to claim 7, wherein The above-mentioned network overlay routing information is distributed to the virtualized switch OVS in a specified manner, including: Generating an Openflow flow table based on the second, third, and fifth types of routes included in the network overlay routing information, and distributing the Openflow flow table to the OVS.

9. The device according to claim 7, wherein The above-mentioned host overlay routing information is generated by the SDN controller according to the current state of the OVS of the host overlay, including: The SDN controller obtains the virtual machine information of the online OVS according to the current state of the OVS of the host overlay, and generates the second, third, and fifth types of routes of the EVPN accordingly to generate the host overlay routing information.

10. The device according to claim 7, characterized in that, Receiving the host overlay routing information injected by the SDN controller through an independent communication channel, including: Obtaining the identification information of the SDN controller, and marking the injected host overlay routing information according to the identification information.

11. The device according to claim 10, wherein Including a fourth module, which is used to respond to the event of the activation of this route reflector, traverse and search for the host overlay routing information injected by the local SDN controller according to the above marking, and set the host overlay routing information injected by the SDN controller found through the traversal to be invalid.

12. The device according to claim 11, characterized in that, The fourth module is also used to respond to the event of the completion of route injection, and revoke the host overlay routing information set to be invalid.

13. An electronic device, characterized in that, Including: A processor and a readable storage medium, where the readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the method according to any one of claims 1-6.

14. A readable storage medium, characterized in that, The readable storage medium stores machine-executable instructions, and when the machine-executable instructions are called and executed by the processor, the machine-executable instructions cause the processor to implement the method according to any one of claims 1-6.

Images