Route synchronization method, device, system and equipment among multiple SDN (Software Defined Network) clusters and medium

Abstract

The invention relates to the technical field of communication, and discloses a route synchronization method, device, system and equipment among multiple SDN clusters and a medium, and the method comprises the steps: obtaining neighbor configuration information issued by a central controller based on a target BGP service; establishing a neighbor relationship between the target BGP service and other BGP services according to the neighbor configuration information; obtaining first node address information of a target SDN cluster collected by the target SDN controller based on the target BGP service, and generating first routing information; and sending the first routing information to other BGP services which establish the neighbor relationship. According to the invention, the BGP service and the SDN controller are utilized to realize the coordination of the control planes, the BGP service and the SDN controller form a double-layer control plane, and the double-layer control plane is utilized to issue the routing forwarding strategy, so that flooding on the data plane is effectively avoided, and the routing synchronization efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a method, apparatus, system, device, and medium for synchronizing routing among multiple SDN clusters. Background Art

[0002] With the prevalence of multi-data center architectures in cloud computing, SDN (Software-Defined Networking) clusters based on technologies like OVN (Open Virtual Network) often need to be deployed independently due to resource isolation and geographical restrictions. These SDN clusters must maintain independence while also being interconnected at the underlay (basic network) and overlay (overlay network) levels to form a unified SDN network architecture to meet the complex communication requirements across SDN clusters (such as data centers). Summary of the Invention

[0003] In view of this, the present invention provides a method, apparatus, system, device and medium for synchronizing routing among multiple SDN clusters to achieve cross-SDN cluster communication.

[0004] In a first aspect, the present invention provides a method for synchronizing routing among multiple SDN clusters, which is applied to a target SDN cluster, wherein the target SDN cluster includes a target gateway device, and the target gateway device is deployed with a target BGP service. The method includes:

[0005] Obtaining neighbor configuration information issued by a central controller of the multi-SDN cluster based on the target BGP service;

[0006] Establishing a neighbor relationship between the target BGP service and other BGP services of other SDN clusters according to the neighbor configuration information;

[0007] Acquire first node address information of the target SDN cluster based on the target BGP service, and generate first routing information according to the first node address information, where the first node address information is collected by a target SDN controller of the target SDN cluster;

[0008] The first routing information is sent to other BGP services that have established neighbor relationships based on the target BGP service.

[0009] In some optional implementations, the target SDN cluster further includes a target SDN controller, and the method further includes:

[0010] Acquire, based on the target BGP service, second routing information sent by other BGP services, where the second routing information includes second node address information of other SDN clusters;

[0011] Sending the second node address information to the target SDN controller based on the target BGP service;

[0012] The target SDN controller is used to configure a forwarding rule according to the second node address information.

[0013] In some optional implementations, the target gateway device is provided with a virtual switch; and the process of the target SDN controller configuring a forwarding rule according to the second node address information includes:

[0014] Create a corresponding VXLAN port for the virtual switch, and configure a VXLAN tunnel between the VXLAN port and other SDN clusters according to the second node address information.

[0015] In some optional embodiments, the second node address information includes a node MAC address and a first remote node address;

[0016] The creating a corresponding VXLAN port for the virtual switch and configuring a VXLAN tunnel between the VXLAN port and another SDN cluster according to the second node address information includes:

[0017] Create a first VXLAN port for the first virtual switch of the target gateway device, and configure a first VXLAN tunnel pointing to the first remote node address for the first VXLAN port;

[0018] The node MAC address is associated with the first VXLAN port to forward a message with a destination MAC address of the node MAC address to the first VXLAN port.

[0019] In some optional implementations, associating the node MAC address with the first VXLAN port includes:

[0020] Add a forwarding table entry for the first virtual switch; the forwarding table entry indicates that the message with the destination MAC address being the node MAC address is forwarded to the first VXLAN port.

[0021] In some optional embodiments, the second node address information includes a subnet address and a second remote node address;

[0022] The creating a corresponding VXLAN port for the virtual switch and configuring a VXLAN tunnel between the VXLAN port and another SDN cluster according to the second node address information includes:

[0023] Create a second VXLAN port for the second virtual switch of the target gateway device, and configure a second VXLAN tunnel pointing to the second remote node address for the second VXLAN port;

[0024] The subnet address is associated with the second VXLAN port to forward the message whose destination IP address belongs to the subnet address to the second VXLAN port.

[0025] In some optional embodiments, the method further comprises:

[0026] Obtaining a data packet initiated by a virtual machine in the target SDN cluster, and determining address information of the data packet; the address information includes a destination IP address and / or a destination MAC address;

[0027] In a case where the address information corresponds to the address of another SDN cluster, the corresponding target VXLAN port is determined according to the address information, and the data packet is sent to the other SDN cluster corresponding to the address information through the VXLAN tunnel of the target VXLAN port.

[0028] In a second aspect, the present invention provides a routing synchronization device between multiple SDN clusters, which is applied to a target SDN cluster, wherein the target SDN cluster includes a target gateway device, and the target gateway device is deployed with a target BGP service. The device includes:

[0029] A configuration module, configured to obtain neighbor configuration information issued by a central controller of a multi-SDN cluster based on the target BGP service;

[0030] A neighbor module, configured to establish a neighbor relationship between the target BGP service and other BGP services of other SDN clusters according to the neighbor configuration information;

[0031] a routing module, configured to obtain first node address information of the target SDN cluster based on the target BGP service, and generate first routing information according to the first node address information, where the first node address information is collected by a target SDN controller of the target SDN cluster;

[0032] A processing module is used to send the first routing information to other BGP services that establish neighbor relationships based on the target BGP service.

[0033] In a third aspect, the present invention provides a routing synchronization system between multiple SDN clusters, comprising: a central controller and multiple SDN clusters, each SDN cluster being provided with an SDN controller and a gateway device, and the gateway device being deployed with a BGP service;

[0034] The SDN controller is used to report the topology information of the SDN cluster to the central controller;

[0035] The central controller is used to integrate the topology information, generate neighbor configuration information, and send the neighbor configuration information to the BGP service of the gateway device;

[0036] The SDN cluster is used to execute the routing synchronization method among multiple SDN clusters according to the first aspect or any corresponding embodiment thereof.

[0037] In a fourth aspect, the present invention provides a computer device comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to thereby execute the routing synchronization method between multiple SDN clusters according to the first aspect or any corresponding embodiment thereof.

[0038] In a fifth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the routing synchronization method between multiple SDN clusters according to the first aspect or any corresponding embodiment thereof.

[0039] In a sixth aspect, the present invention provides a computer program product, comprising computer instructions, which are used to enable a computer to execute the routing synchronization method between multiple SDN clusters according to the first aspect or any corresponding embodiment thereof.

[0040] The present invention deploys BGP services in an SDN cluster and utilizes BGP services and SDN controllers to achieve control plane collaboration. The BGP services and SDN controllers form a two-layer control plane. The SDN controller's control information can be sent to other clusters via the BGP service. The BGP service can also observe and respond to routing changes in other BGP services, thereby modifying the SDN controller's control information. By using the two-layer control plane to issue routing forwarding policies, this effectively avoids data plane flooding and improves routing synchronization efficiency. Furthermore, the SDN controllers achieve interconnection through plug-in BGP services, making them compatible with heterogeneous SDN controllers and enabling interconnection between them. This approach offers strong compatibility and a wide range of applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in related technologies, the following briefly introduces the drawings required for use in the specific embodiments or related technical descriptions. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0042] Figure 1 This is a schematic diagram of an architecture of a multi-SDN cluster according to an embodiment of the present invention;

[0043] Figure 2 1 is a flow chart of a method for synchronizing routing among multiple SDN clusters according to an embodiment of the present invention;

[0044] Figure 3 is a flow chart of another method for synchronizing routing among multiple SDN clusters according to an embodiment of the present invention;

[0045] Figure 4 This is a schematic diagram of data transmission according to an embodiment of the present invention;

[0046] Figure 5 is a structural block diagram of a routing synchronization device between multiple SDN clusters according to an embodiment of the present invention;

[0047] Figure 6 Schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0048] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present invention.

[0049] For the convenience of description, some terms involved in this embodiment are first explained. These explanations are intended to make the embodiments of this application easier to understand and should not be regarded as limiting the scope of protection claimed in this application.

[0050] SDN: Software-Defined Networking, a network architecture paradigm that achieves centralized network policy management and dynamic programmable control by decoupling the control plane from the data forwarding plane.

[0051] OVN: Open Virtual Network. A distributed network virtualization system built on open source virtual switch technology (such as OVS) that automates the configuration and management of overlay networks through a logical switch / router abstraction model.

[0052] BGP: Border Gateway Protocol. A path vector routing protocol (RFC 4271) defined by the Internet Engineering Task Force (IETF) for exchanging network layer reachability information between autonomous systems (ASs). It is a protocol for exchanging network routing information between core routers of the Internet.

[0053] VXLAN (Virtual Extensible LAN) is an overlay network tunneling technology that breaks through the network limitations of traditional VLANs (virtual local area networks) by encapsulating Layer 2 frames on existing IP networks (underlay) to build large-scale virtualized networks.

[0054] EVPN: Ethernet Virtual Private Network. A Layer 2 virtual private network technology based on the BGP protocol extensions (RFC 7432). It enables cross-data center Layer 2 network interconnection through MAC address learning and distribution mechanisms and supports VXLAN overlay network encapsulation.

[0055] To achieve multi-cluster SDN interoperability, current existing technologies mainly rely on SDN cluster interconnection, such as OVN-IC (Inter Connection), or manually configure VXLAN tunnels at the underlay layer using VXLAN (Virtual eXtensible Local Area Network).

[0056] With SDN cluster interconnection, there is only one control plane, and the entire cross-cluster SDN network is uniformly managed and controlled by a centralized SDN controller. However, cross-cluster routing involves a large amount of endpoint information, resulting in low routing synchronization efficiency and slow convergence. The centralized SDN controller can easily become a performance bottleneck in large-scale cross-cluster scenarios. In addition, this method cannot achieve the topological extension of the same network or subnet across different clusters.

[0057] Configuring VXLAN tunnels at the underlay layer presents challenges: Relying on manual configuration of VXLAN tunnels or static routes, it is difficult to dynamically scale and cannot support large-scale MAC address or route prefix synchronization in the overlay. This is prohibitively labor-intensive and impractical in large-scale data center environments. Adding new clusters also requires manual adjustments, lacking dynamic routing policy optimization. Furthermore, underlay networks are typically part of user infrastructure, making changes difficult to control after planning (due to security compliance or enterprise regulations, for example). This makes continuous, programmable underlay network configuration impractical.

[0058] To solve the problem of low routing synchronization efficiency in existing SDN clusters, an embodiment of the present invention provides a routing synchronization method between multiple SDN clusters. BGP services are deployed in the SDN cluster, and BGP services and SDN controllers are used to achieve control plane collaboration. Routing forwarding strategies are issued based on the two-layer control plane, which effectively avoids flooding on the data plane and improves routing synchronization efficiency.

[0059] In this embodiment, BGP services are deployed for each SDN cluster, and a global central controller is set up. Distributed BGP services, SDN controllers of each cluster, and the central controller are used to build a cross-cluster overlay network to achieve routing optimization.

[0060] Figure 1 A schematic diagram of the architecture of a multi-SDN cluster provided by this embodiment is shown in FIG. Figure 1 As shown, each SDN cluster contains multiple hosts, each of which functions as an SDNHost (SDN host) to transmit and receive data. Furthermore, one of the hosts functions as a gateway device, assuming the virtual edge of the cluster. For example, if the SDN cluster is a data center, the data center's edge nodes can serve as gateway devices.

[0061] Furthermore, the controller in this embodiment utilizes a two-tier architecture: a single-cluster SDN controller at the bottom and a global central controller at the top. A single-cluster SDN controller is tightly bound to a specific SDN type; the central controller can be deployed flexibly. For example, the central controller can be centrally deployed in a single SDN cluster, deployed across clusters in a master-slave mode, or deployed in a master-slave mode within a single cluster, though this embodiment does not limit this.

[0062] like Figure 1 As shown, each SDN cluster has a corresponding SDN controller, which manages the network devices (such as switches and routers) and terminal nodes (such as virtual machines and physical servers) within the cluster. The SDN controller can obtain topological information such as the underlying network connection relationship and device status through the southbound interface. For example, the SDN controller can be implemented based on OVN; as long as the network is reachable, the SDN controller can be deployed anywhere in the cluster and can also be deployed in a distributed manner to achieve high availability.

[0063] In addition, a common central controller is set up for multiple SDN clusters. As a cross-cluster management component, the central controller can communicate with each SDN controller through the northbound interface, obtain and summarize the topology information of multiple SDN clusters, form a global network view, and facilitate subsequent routing synchronization.

[0064] based on Figure 1The multi-SDN cluster architecture shown in the embodiment provides a routing synchronization method between multiple SDN clusters. Figure 2 is a flowchart of a method for routing synchronization between multiple SDN clusters according to an embodiment of the present invention. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0065] The routing synchronization method between multiple SDN clusters provided in this embodiment can be applied to any SDN cluster therein; for example, Figure 1 The method can be executed by SDN cluster 1, SDN cluster 2, etc. For the convenience of description, the SDN cluster that executes the method is called the target SDN cluster, and its corresponding gateway device and BGP service are respectively called the target gateway device and the target BGP service. That is, the target BGP service is deployed in the target gateway device of the target SDN cluster. Figure 2 As shown, the method includes the following steps.

[0066] Step S201: Obtain neighbor configuration information issued by a central controller of a multi-SDN cluster based on a target BGP service.

[0067] In this embodiment, when the SDN cluster is started, its SDN controller can actively send a registration request to the central controller. The registration request includes the topology information of the SDN cluster. The topology information may include the cluster ID, ASN (Autonomous System Number), etc., and may also include the IP address and port number of the SDN controller, and the VTEP (VXLAN Tunnel EndPoint) address pool and other information. Among them, the BGP service is deployed in the gateway device. In order to facilitate the establishment of neighbor relationships between the BGP services of each SDN cluster, the topology information may include the address information of the gateway device.

[0068] For example, the central controller can access and maintain the topology of each SDN cluster through the REST API (Representational State Transfer). When the SDN cluster topology changes (such as adding a new switch or expanding a subnet), the SDN controller proactively pushes updates to the central controller through the REST API, and the corresponding hash table entries are modified synchronously, eliminating the need for manual configuration.

[0069] The central controller can use a hash table to store the topology information corresponding to each SDN cluster, and generate corresponding neighbor configuration information based on the topology information of each SDN cluster. The neighbor configuration information is used to instruct each BGP service to establish a BGP neighbor relationship with the BGP services of other SDN clusters.

[0070] For example, the central controller specifies neighbor nodes for each BGP service based on the address of the node where the BGP service is located (i.e., the address of the gateway device) in the topology information, thereby generating corresponding neighbor configuration information and then sending it to the corresponding BGP service. For the target gateway device, the target BGP service can also obtain the corresponding neighbor configuration information.

[0071] Step S202: Establish a neighbor relationship between the target BGP service and other BGP services in other SDN clusters according to the neighbor configuration information.

[0072] In this embodiment, each BGP service including the target BGP service can establish a neighbor relationship with the BGP services of other SDN clusters based on the neighbor configuration information issued by the central controller.

[0073] Specifically, the BGP service deployed in the gateway device can be a GoBGP component (a BGP protocol stack implemented in Go) implemented in the Go language. The GoBGP component supports basic BGP functions such as neighbor establishment and maintenance, and also supports multi-protocol extended BGP (i.e., MP-BGP) such as EVPN. BGP neighbor relationships can be established between the GoBGP components of each SDN cluster. That is, GoBGP components can establish routing exchange channels through TCP (Transmission Control Protocol) connections to exchange BGP routing information.

[0074] Step S203: obtaining first node address information of the target SDN cluster based on the target BGP service, and generating first routing information according to the first node address information, where the first node address information is collected by the target SDN controller of the target SDN cluster.

[0075] In this embodiment, the target SDN cluster has multiple nodes, which may be, for example, virtual machines, containers, or physical servers. The target SDN controller can obtain address information of these nodes, namely, first node address information. This first node address information may include, for example, the IP address of the node. After collecting this first node address information, the SDN cluster can send the first node address information to the target BGP service based on the relevant interface of the target BGP service. The target BGP service can then generate corresponding routing information based on this first node address information, namely, first routing information.

[0076] The routing information is used to indicate the route corresponding to the communication with the corresponding node. Accordingly, the first routing information may indicate the route corresponding to the communication with the node in the target SDN cluster, such as the next hop node address.

[0077] Step S204: Send the first routing information to other BGP services with which neighbor relationships are established based on the target BGP service.

[0078] In this embodiment, after the target BGP service generates the first routing information, it can broadcast the first routing information, so that the first routing information can be sent to other BGP services that have established neighbor relationships with the target BGP service, thereby achieving routing synchronization between SDN clusters.

[0079] The routing message can be, for example, a BGPUpdate message. Through the network-wide broadcast nature of BGP services, BGP services in all SDN clusters can obtain global routing information, providing a routing foundation for cross-cluster communication. Furthermore, each BGP service maintains its own neighbor relationships. The central controller is only responsible for initial topology distribution and does not participate in ongoing BGP session maintenance. This ensures direct and efficient routing distribution while simplifying operation and maintenance complexity through centralized topology management.

[0080] The routing synchronization method between multiple SDN clusters provided in this embodiment deploys BGP services in the SDN cluster and utilizes BGP services and SDN controllers to achieve control plane collaboration. The BGP services and SDN controllers form a two-layer control plane. The control information of the SDN controller can be sent to other clusters via the BGP service. The BGP service can also observe and respond to routing changes in other BGP services, thereby changing the control information of the SDN controller. The routing forwarding policy is issued by the two-layer control plane, effectively avoiding flooding on the data plane and improving routing synchronization efficiency. In addition, the SDN controllers achieve interconnection through BGP services using a plug-in mechanism, which is compatible with heterogeneous SDN controllers and can achieve interconnection of heterogeneous SDN controllers. It has strong compatibility and a wide range of applications.

[0081] In this embodiment, another routing synchronization method between multiple SDN clusters is provided, which can be applied to any of the SDN clusters. Figure 3 As shown, the method includes the following steps.

[0082] Step S301: Obtain neighbor configuration information issued by a central controller of a multi-SDN cluster based on a target BGP service.

[0083] For details, please see Figure 2 Step S201 of the illustrated embodiment will not be described in detail here.

[0084] Step S302: Establish a neighbor relationship between the target BGP service and other BGP services in other SDN clusters according to the neighbor configuration information.

[0085] For details, please see Figure 2 Step S202 of the illustrated embodiment will not be described in detail here.

[0086] Step S303: Acquire first node address information of the target SDN cluster based on the target BGP service, and generate first routing information according to the first node address information, where the first node address information is collected by the target SDN controller of the target SDN cluster.

[0087] For details, please see Figure 2 Step S203 of the illustrated embodiment will not be described in detail here.

[0088] Step S304: Send the first routing information to other BGP services with which neighbor relationships are established based on the target BGP service.

[0089] For details, please see Figure 2 Step S204 of the illustrated embodiment will not be described in detail here.

[0090] Step S305: Acquire second routing information sent by other BGP services based on the target BGP service, where the second routing information includes second node address information of other SDN clusters.

[0091] Similar to sending the first routing information, other BGP services can also generate corresponding routing information, i.e., second routing information, based on the second node address information within their own SDN cluster, and broadcast the second routing information to BGP services with which neighbor relationships have been established, including the target BGP service, i.e., the target BGP service can receive the second routing information.

[0092] Step S306: Send the second node address information to the target SDN controller based on the target BGP service, and use the target SDN controller to configure a forwarding rule according to the second node address information.

[0093] In this embodiment, after the target BGP service obtains the second routing information of the other end, it can send the second node address information therein to the target SDN controller. Alternatively, the target BGP service can also directly send the second routing information to the target SDN controller. The target SDN controller can parse the second routing information to extract key information, namely, the second node address information.

[0094] It is understood that the second node address information is the address information of nodes in other SDN clusters. The target SDN controller can configure forwarding rules related to these nodes based on this second node address information. For example, the target SDN controller can update the local routing table. When nodes (such as virtual machines) in the target SDN cluster subsequently need to transmit data to nodes in other SDN clusters, they can implement message forwarding based on the forwarding rules configured at this time.

[0095] Step S307: Create a corresponding VXLAN port for the virtual switch, and configure a VXLAN tunnel between the VXLAN port and other SDN clusters based on the second node address information. Perform data transmission between SDN clusters based on the VXLAN tunnel.

[0096] In this embodiment, the target gateway device is provided with a virtual switch. For example, the virtual switch can be created based on OVS (Open vSwitch) technology. When the target SDN controller configures the forwarding rule according to the second node address information, it configures the virtual switch.

[0097] Specifically, after the target SDN controller receives the second node address information, it can determine whether the virtual switch has a suitable VXLAN port. If not, a corresponding VXLAN port is created for the virtual switch; for example, a VXLAN port can be created for the virtual switch based on the ovs-vsctl command. Moreover, since the second node address information is the address information of other SDN clusters, a VXLAN port can be configured based on the second node address information, and the address corresponding to the second node address information is used as the destination address of the VXLAN port, so that a corresponding VXLAN tunnel can be established with other SDN clusters. Messages that need to be transmitted across clusters in the subsequent target SDN cluster can be sent to other SDN clusters through the VXLAN tunnel, ultimately achieving data transmission.

[0098] In this embodiment, each SDN cluster establishes a neighbor relationship through BGP service and synchronizes address information. Subsequent data packets can be sent directly through the VXLAN tunnel without broadcasting. The subnets of different SDN clusters are logically in the same broadcast domain, which can realize the topological extension of subnets in different clusters.

[0099] In some optional implementations, node address information is transmitted between BGP services through EVPN routing. Specifically, the routing information transmitted between BGP services may be EVPN routing. The routing information (first routing information and second routing information) may be, for example, a Type 2 EVPN routing, which includes MAC / IP information and a remote node address representing a next-hop node.

[0100] Taking the first node address information as an example, the target SDN controller can obtain the address information of each node (such as a virtual machine) in the target SDN cluster, including the node MAC address, node IP address, etc., as well as the next hop address corresponding to the node, that is, the remote node address. The remote node address is generally an IP address, such as a VTEP IP address. Based on this first node address information, the corresponding first routing information can be constructed and transmitted to other SDN clusters.

[0101] Correspondingly, the second node address information corresponding to other SDN clusters may also include the node MAC address, node IP address, remote node address, etc., thereby generating corresponding second routing information. The node IP address may be optional, and the second node address information may specifically include the node MAC address and remote node address. For ease of description, the remote node address in the Type 2 second routing information is referred to as the first remote node address.

[0102] Furthermore, the above-mentioned step S306 of "creating a corresponding VXLAN port for the virtual switch and configuring a VXLAN tunnel between the VXLAN port and other SDN clusters according to the second node address information" may include steps A1 to A2.

[0103] Step A1: Create a first VXLAN port for a first virtual switch of a target gateway device, and configure a first VXLAN tunnel pointing to a first remote node address for the first VXLAN port.

[0104] In step A2, the node MAC address is associated with the first VXLAN port to forward a message whose destination MAC address is the node MAC address to the first VXLAN port.

[0105] In this embodiment, the target gateway device may be provided with a first virtual switch. After the target SDN controller obtains the second node address information, it may create a first VXLAN port for the first virtual switch and configure the first VXLAN port to create a VXLAN tunnel from the first VLXAN to other SDN clusters. It can be understood that the VXLAN tunnel is a logical channel, not a physical object.

[0106] Specifically, a first VXLAN port can be created for the first virtual switch based on the ovs-vsctl command, and the first VXLAN port can be configured to point to the first remote node address, so that a first VXLAN tunnel can be established between the first VXLAN port and the node corresponding to the first remote node address.

[0107] Furthermore, by associating the node MAC address with the first VXLAN port, packets with the node MAC address as the destination MAC address can be forwarded to the first VXLAN port. That is, packets with the node MAC address as the destination MAC address (since the node MAC address corresponds to another SDN cluster node, the packet needs to be forwarded to another SDN cluster) can be forwarded to the first VXLAN port, and then sent to the node corresponding to the first remote node address through the first VXLAN port, thus achieving data transmission across SDN clusters.

[0108] Among them, if the second node address information also includes the node IP address, the SDN controller can update the ARP (Address Resolution Protocol) routing table based on the node MAC address and the node IP address, so that the correspondence between the IP address and the MAC address can be determined based on the ARP routing table, and the corresponding MAC address can be found based on the IP address.

[0109] Optionally, the above step A2 of “associating the node MAC address with the first VXLAN port” may include step A21.

[0110] Step A21, adding a forwarding table entry for the first virtual switch; the forwarding table entry indicates that the message with the destination MAC address being the node MAC address is forwarded to the first VXLAN port.

[0111] In this embodiment, by adding a forwarding entry related to the first VXLAN port to the first virtual switch, the node MAC address and the first VXLAN port can be associated. The forwarding entry can be, for example, a flow table entry.

[0112] For example, the second routing information may be a Type 2 EVPN route, which includes: a node MAC address (e.g., 11:22:33:44:55:66), a node IP address (e.g., 10.0.0.100), and a next-hop node address, i.e., a first remote node address (e.g., 192.168.1.1). By setting the remote IP address of the first VXLAN port to the first remote node address, i.e., remote_ip = 192.168.1.1, a first VXLAN tunnel can be established between the two.

[0113] Furthermore, the ovs-ofctl command can be used to construct a flow entry that forwards packets whose destination MAC address is the node's MAC address to the first VXLAN port. For example, if the first remote node address is 192.168.1.1, a corresponding flow entry is configured for the first VXLAN port vxlan_100 of the first virtual switch vSwitch: ovs-ofctl add-flow vSwitchdl_src=11:22:33:44:55:66,actions=output:vxlan_100, thus associating the two.

[0114] Optionally, the routing information transmitted between BGP services may be a Type 5 EVPN route, which specifically includes the corresponding subnet address (i.e., IP prefix) and the remote node address representing the next hop node. Specifically, the second node address information includes the subnet address and the corresponding remote node address. For ease of distinction, this embodiment refers to it as the second remote node address.

[0115] Furthermore, the above-mentioned step S306 of "creating a corresponding VXLAN port for the virtual switch and configuring a VXLAN tunnel between the VXLAN port and other SDN clusters according to the second node address information" may include steps B1 to B2.

[0116] Step B1: Create a second VXLAN port for the second virtual switch of the target gateway device, and configure a second VXLAN tunnel pointing to the second remote node address for the second VXLAN port.

[0117] Step B2: Associating the subnet address with the second VXLAN port to forward packets whose destination IP address belongs to the subnet address to the second VXLAN port.

[0118] In this embodiment, similar to steps A1 and A2 above, a corresponding VXLAN port, namely a second VXLAN port, can also be created for the virtual switch of the target gateway device. The second virtual switch can be the same as or different from the first virtual switch, and the second VXLAN port can be the same as or different from the first VXLAN port. Furthermore, the routing information between BGP services can include both Type 2 and Type 5 EVPN routes, although this embodiment does not limit this.

[0119] For the Type 5 second routing information, similar to the method for generating the first VXLAN tunnel described above, a second VXLAN tunnel pointing to the second remote node address can also be configured for the second VXLAN port. For example, the tunnel can be established by setting the remote IP address of the second VXLAN port to the second remote node address.

[0120] Furthermore, by associating the subnet address with the second VXLAN port, packets whose destination IP address belongs to the subnet address can be forwarded to the second VXLAN port, thereby enabling cross-cluster packet forwarding through the second VXLAN tunnel. The association between the subnet address and the second VXLAN port can also be achieved based on flow table entries, etc., which will not be further described here.

[0121] In this embodiment, each SDN cluster (for example, a data center) is regarded as a logical hypervisor, and the virtual machines in the cluster are like running on this logical hypervisor, so that Layer 2 and Layer 3 communication can be carried out between virtual machines; gobgp is deployed on the gateway device nodes of each cluster, and this component is used to publish EVPN routes to announce the reachability information between clusters; when each cluster receives the other's EVPN route, it can automatically control the SDN controller to establish a VXLAN tunnel based on the EVPN route, facilitating subsequent data layer forwarding.

[0122] Optionally, the method further includes the following steps C1 to C2.

[0123] Step C1: Acquire a data message initiated by a virtual machine in a target SDN cluster and determine the address information of the data message; the address information includes a destination IP address and / or a destination MAC address.

[0124] In step C2, when the address information corresponds to the address of another SDN cluster, the corresponding target VXLAN port is determined according to the address information, and the data packet is sent to the other SDN cluster corresponding to the address information through the VXLAN tunnel of the target VXLAN port.

[0125] In this embodiment, when a virtual machine in the target SDN cluster needs to communicate, it can initiate a corresponding data packet, which includes the destination virtual machine to which the data packet needs to be sent, that is, the destination IP address and / or destination MAC address. If the data packet is an intra-cluster message, that is, the destination virtual machine is also located in the target SDN cluster, the message can be forwarded based on traditional methods.

[0126] If the address information corresponds to the address of another SDN cluster, data forwarding can be performed based on the VXLAN tunnel. At this time, the corresponding VXLAN port, that is, the target VXLAN port, can be determined based on the destination IP address and / or destination MAC address. Then, the data packet can be sent to the other SDN cluster corresponding to the address information through the VXLAN tunnel of the target VXLAN port.

[0127] Figure 4 Figure 1 shows a schematic diagram of data transmission. Figure 4As shown, if the virtual machine VM1 in a certain SDN cluster (i.e., the target SDN cluster) sends a data packet to the virtual machine VM2 in another SDN cluster, the data packet can be sent to the virtual switch of the gateway device 1 based on the flow table pre-configured by the SDN controller 1, and then the VXLAN tunnel between it and the virtual switch of the gateway device 2 is used to transmit the data packet to another SDN cluster and finally send it to the virtual machine VM2.

[0128] For example, if a data packet includes a destination MAC address, the target VXLAN port corresponding to the destination MAC address can be determined based on the relevant forwarding table entries, thereby achieving data forwarding. Similarly, if a data packet includes a destination IP address, the subnet address to which the destination IP address belongs can be determined, and then the target VXLAN port corresponding to the destination IP address can be determined based on the forwarding table entries corresponding to the subnet address, thereby also achieving data forwarding.

[0129] Compared with traditional physical switch-based or OVN-based interconnection solutions, the solution provided in this embodiment has the following effects as shown in Table 1:

[0130] Table 1

[0131]

[0132] As shown in Table 1, an overlay network is deployed using physical switches, with VTEP functionality carried by network devices. However, in large-scale network environments, customers often prohibit the configuration of network devices due to operational and management requirements. Furthermore, existing OVN native interconnect solutions cannot meet the requirements for cross-data center Layer 2 network expansion. The solution provided in this embodiment effectively addresses these issues.

[0133] The routing synchronization method between multiple SDN clusters provided in this embodiment is based on inter-cluster BGP services, greatly improving routing synchronization speed. BGP services such as GoBGP are easily integrated with SDN, making implementation convenient. The unified routing transmission by gateway devices can reduce the number of routing synchronization messages. By leveraging the EVPN function of the SDN controller and BGP services, forwarding policies are proactively issued through the BGP service weak control plane and then to the SDN control plane, effectively avoiding data plane flooding and improving data efficiency. It supports horizontal expansion of multiple SDN cluster interconnections, reducing reliance on manual configuration, and supports dynamic cluster joining / exiting. The time required to configure a new SDN cluster is reduced from hours to seconds (average of approximately 8.7 seconds), and the configuration accuracy is also high.

[0134] The embodiment of the present invention also provides a routing synchronization system between multiple SDN clusters, see Figure 1As shown, the system includes: a central controller and multiple SDN clusters, each SDN cluster is equipped with an SDN controller and a gateway device, and the gateway device is deployed with a BGP service;

[0135] The SDN controller is used to report the topology information of the SDN cluster to the central controller;

[0136] The central controller is used to integrate the topology information, generate neighbor configuration information, and send the neighbor configuration information to the BGP service of the gateway device;

[0137] The SDN cluster is used to execute the routing synchronization method between multiple SDN clusters provided in any of the above embodiments.

[0138] The working principle of the system and the corresponding technical effects can be found in Figure 1 The description of the related method embodiments will not be repeated here.

[0139] This embodiment also provides a routing synchronization device between multiple SDN clusters. This device is used to implement the above-mentioned embodiments and preferred implementations. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0140] This embodiment provides a routing synchronization device between multiple SDN clusters, which is applied to a target SDN cluster. The target SDN cluster includes a target gateway device, and the target gateway device is deployed with a target BGP service, such as Figure 5 As shown, including:

[0141] Configuration module 501, configured to obtain neighbor configuration information issued by a central controller of a multi-SDN cluster based on the target BGP service;

[0142] A neighbor module 502 is configured to establish a neighbor relationship between the target BGP service and other BGP services in other SDN clusters according to the neighbor configuration information;

[0143] A routing module 503 is configured to obtain first node address information of the target SDN cluster based on the target BGP service, and generate first routing information according to the first node address information, where the first node address information is collected by a target SDN controller of the target SDN cluster;

[0144] The processing module 504 is configured to send the first routing information to other BGP services with which neighbor relationships are established based on the target BGP service.

[0145] In some optional implementations, the target SDN cluster further includes a target SDN controller, and the processing module 504 is further configured to:

[0146] Acquire, based on the target BGP service, second routing information sent by other BGP services, where the second routing information includes second node address information of other SDN clusters;

[0147] Sending the second node address information to the target SDN controller based on the target BGP service;

[0148] The target SDN controller is used to configure a forwarding rule according to the second node address information.

[0149] In some optional implementations, the target gateway device is provided with a virtual switch; and the process of the target SDN controller configuring a forwarding rule according to the second node address information includes:

[0150] Create a corresponding VXLAN port for the virtual switch, and configure a VXLAN tunnel between the VXLAN port and other SDN clusters according to the second node address information.

[0151] In some optional embodiments, the second node address information includes a node MAC address and a first remote node address;

[0152] The processing module 504 creates a corresponding VXLAN port for the virtual switch and configures a VXLAN tunnel between the VXLAN port and another SDN cluster according to the second node address information, including:

[0153] Create a first VXLAN port for the first virtual switch of the target gateway device, and configure a first VXLAN tunnel pointing to the first remote node address for the first VXLAN port;

[0154] The node MAC address is associated with the first VXLAN port to forward a message with a destination MAC address of the node MAC address to the first VXLAN port.

[0155] In some optional implementations, the processing module 504 associates the node MAC address with the first VXLAN port, including:

[0156] Add a forwarding table entry for the first virtual switch; the forwarding table entry indicates that the message with the destination MAC address being the node MAC address is forwarded to the first VXLAN port.

[0157] In some optional embodiments, the second node address information includes a subnet address and a second remote node address;

[0158] The processing module 504 creates a corresponding VXLAN port for the virtual switch and configures a VXLAN tunnel between the VXLAN port and another SDN cluster according to the second node address information, including:

[0159] Create a second VXLAN port for the second virtual switch of the target gateway device, and configure a second VXLAN tunnel pointing to the second remote node address for the second VXLAN port;

[0160] The subnet address is associated with the second VXLAN port to forward the message whose destination IP address belongs to the subnet address to the second VXLAN port.

[0161] In some optional implementations, the processing module 504 is further configured to:

[0162] Obtaining a data packet initiated by a virtual machine in the target SDN cluster, and determining address information of the data packet; the address information includes a destination IP address and / or a destination MAC address;

[0163] In a case where the address information corresponds to the address of another SDN cluster, the corresponding target VXLAN port is determined according to the address information, and the data packet is sent to the other SDN cluster corresponding to the address information through the VXLAN tunnel of the target VXLAN port.

[0164] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0165] In this embodiment, the routing synchronization device between multiple SDN clusters is presented in the form of a functional unit. The unit here refers to an ASIC (Application Specific Integrated Circuit) circuit, including a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0166] The embodiment of the present invention also provides a computer device having the above Figure 5 The routing synchronization device between multiple SDN clusters is shown.

[0167] See also Figure 6 , Figure 6 is a structural diagram of a computer device provided by an optional embodiment of the present invention, such as Figure 6As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of a GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories. Equally, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 6 A processor 10 is taken as an example.

[0168] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0169] The memory 20 stores instructions that can be executed by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0170] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0171] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0172] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0173] The embodiment of the present invention also provides a computer-readable storage medium. The above-mentioned method according to the embodiment of the present invention can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0174] A portion of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium that can be accessed by the computer.

[0175] Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations should all be included in the scope of protection of the present invention.

Claims

1. A routing synchronization method between multiple SDN clusters, characterized in that: Applied to a target SDN cluster, the target SDN cluster includes a target gateway device, the target gateway device is deployed with a target BGP service, and the method includes: Obtaining neighbor configuration information issued by a central controller of the multi-SDN cluster based on the target BGP service; Establishing a neighbor relationship between the target BGP service and other BGP services of other SDN clusters according to the neighbor configuration information; Acquire first node address information of the target SDN cluster based on the target BGP service, and generate first routing information according to the first node address information, where the first node address information is collected by a target SDN controller of the target SDN cluster; The first routing information is sent to other BGP services that have established neighbor relationships based on the target BGP service.

2. The method according to claim 1, characterized in that The target SDN cluster further includes a target SDN controller, and the method further includes: Acquire, based on the target BGP service, second routing information sent by other BGP services, where the second routing information includes second node address information of other SDN clusters; Sending the second node address information to the target SDN controller based on the target BGP service; The target SDN controller is used to configure a forwarding rule according to the second node address information.

3. The method according to claim 2, characterized in that The target gateway device is provided with a virtual switch; and the target SDN controller configures a forwarding rule according to the second node address information, including: Create a corresponding VXLAN port for the virtual switch, and configure a VXLAN tunnel between the VXLAN port and other SDN clusters according to the second node address information.

4. The method according to claim 3, characterized in that The second node address information includes a node MAC address and a first remote node address; The creating a corresponding VXLAN port for the virtual switch and configuring a VXLAN tunnel between the VXLAN port and another SDN cluster according to the second node address information includes: Create a first VXLAN port for the first virtual switch of the target gateway device, and configure a first VXLAN tunnel pointing to the first remote node address for the first VXLAN port; The node MAC address is associated with the first VXLAN port to forward a message with a destination MAC address of the node MAC address to the first VXLAN port.

5. The method according to claim 4, characterized in that Associating the node MAC address with the first VXLAN port includes: Add a forwarding table entry for the first virtual switch; the forwarding table entry indicates that the message with the destination MAC address being the node MAC address is forwarded to the first VXLAN port.

6. The method according to claim 3, characterized in that The second node address information includes a subnet address and a second remote node address; The creating a corresponding VXLAN port for the virtual switch and configuring a VXLAN tunnel between the VXLAN port and another SDN cluster according to the second node address information includes: Create a second VXLAN port for the second virtual switch of the target gateway device, and configure a second VXLAN tunnel pointing to the second remote node address for the second VXLAN port; The subnet address is associated with the second VXLAN port to forward the message whose destination IP address belongs to the subnet address to the second VXLAN port.

7. The method according to any one of claims 3 to 6, characterized in that The method further comprises: Obtaining a data packet initiated by a virtual machine in the target SDN cluster, and determining address information of the data packet; the address information includes a destination IP address and / or a destination MAC address; In a case where the address information corresponds to the address of another SDN cluster, the corresponding target VXLAN port is determined according to the address information, and the data packet is sent to the other SDN cluster corresponding to the address information through the VXLAN tunnel of the target VXLAN port.

8. A routing synchronization device between multiple SDN clusters, characterized in that: Applied to a target SDN cluster, the target SDN cluster includes a target gateway device, the target gateway device is deployed with a target BGP service, and the apparatus includes: A configuration module, configured to obtain neighbor configuration information issued by a central controller of a multi-SDN cluster based on the target BGP service; A neighbor module, configured to establish a neighbor relationship between the target BGP service and other BGP services of other SDN clusters according to the neighbor configuration information; a routing module, configured to obtain first node address information of the target SDN cluster based on the target BGP service, and generate first routing information according to the first node address information, where the first node address information is collected by a target SDN controller of the target SDN cluster; A processing module is used to send the first routing information to other BGP services that establish neighbor relationships based on the target BGP service.

9. A routing synchronization system between multiple SDN clusters, characterized in that: include: A central controller and multiple SDN clusters, each SDN cluster is equipped with an SDN controller and a gateway device, and the gateway device is deployed with BGP service; The SDN controller is used to report the topology information of the SDN cluster to the central controller; The central controller is used to integrate the topology information, generate neighbor configuration information, and send the neighbor configuration information to the BGP service of the gateway device; The SDN cluster is used to execute the routing synchronization method among multiple SDN clusters according to any one of claims 1 to 7.

10. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the routing synchronization method between multiple SDN clusters according to any one of claims 1 to 7 by executing the computer instructions.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the routing synchronization method between multiple SDN clusters according to any one of claims 1 to 7.

Images