Network intercommunication method, system, electronic device, storage medium and program product

Abstract

The present application discloses a network intercommunication method, system, electronic device, storage medium and program product, which relate to the field of cloud computing, including: for first virtual machine traffic output by a virtual machine in a computing node and whose destination node is a physical server node, routing matching is performed on the first virtual machine traffic through the routing table corresponding to the first virtual routing and forwarding instance in the computing node; instructing the target switch to send the obtained second virtual machine traffic to the physical server node, so that the virtual machine and the physical server node can achieve network intercommunication, and the target switch is respectively connected to the physical server node, the route reflector and the computing node. The method solves the problem that the soft gateway used between the virtual machine in the computing node and the bare metal node in the cloud computing environment has a bandwidth forwarding bottleneck and a high solution cost, which leads to poor network intercommunication between the virtual machine and the bare metal node, and improves the network intercommunication between the virtual machine and the bare metal node.

Description

Technical Field

[0001] The present application relates to the field of cloud computing, and in particular to a network intercommunication method, system, electronic device, storage medium, and program product. Background Art

[0002] With the rapid development of cloud computing, Bare Metal services (also known as bare metal nodes) offer a computing service that combines the elasticity of virtual machines with the performance of physical machines, providing individuals and businesses with dedicated cloud-based physical servers. They deliver exceptional computing performance while ensuring data security for critical application systems, high-performance computing, big data, core databases, and other businesses. Creating a bare metal cloud physical server is similar to creating a virtual machine: simply specify the required hardware (such as the central processing unit (CPU), memory, etc.), image, and network requirements to create the desired bare metal cloud physical server. Users can also apply flexibly and use it on demand.

[0003] Bare metal service gateways are primarily soft gateways, which fall into two categories: centralized gateways, where bare metal service traffic is forwarded through active and standby gateway nodes. Distributed gateways, which typically utilize Smart NICs (Smart Network Interface Cards), forward traffic between individual bare metal nodes. However, centralized gateways suffer from bandwidth forwarding bottlenecks, making them unable to meet the high-bandwidth forwarding requirements of advanced services. They also lack support for physical NIC isolation, which is required by databases like Oracle. Distributed gateways also face challenges with Smart NIC solutions, such as high cost and a high barrier to entry.

[0004] Regarding the related technologies, the soft gateway used between the virtual machines and bare metal nodes in the computing nodes in the cloud computing environment has the defects of bandwidth forwarding bottleneck and high solution cost, which leads to poor network interoperability between the virtual machines and bare metal nodes. This problem has not yet been effectively solved. Summary of the Invention

[0005] The present application provides a network intercommunication method, system, electronic device, storage medium and program product to at least solve the problem in the related art that the soft gateway used between the virtual machines and bare metal nodes in the computing nodes in the cloud computing environment has a bandwidth forwarding bottleneck and high solution cost, thereby resulting in poor network intercommunication between the virtual machines and the bare metal nodes.

[0006] The present application provides a network intercommunication method, including: when the destination node of the first virtual machine traffic is a physical server node, performing route matching on the first virtual machine traffic through the routing table corresponding to the first virtual routing and forwarding instance to obtain the second virtual machine traffic, wherein the computing node includes: a virtual machine that outputs the first virtual machine traffic and the first virtual routing and forwarding instance, and the routing information of the physical server node has been synchronized to the routing table through a route reflector connected to the computing node; sending the second virtual machine traffic to a target switch, and instructing the target switch to send the second virtual machine traffic to the physical server node, so that the virtual machine and the physical server node achieve network intercommunication, wherein the target switch is respectively connected to the physical server node, the route reflector and the computing node.

[0007] The present application also provides a network interconnection device, including: a computing node, which is used to perform route matching on the first virtual machine traffic through the routing table corresponding to the first virtual routing and forwarding instance when the destination node of the first virtual machine traffic is a physical server node, obtain the second virtual machine traffic, and send the second virtual machine traffic to the target switch, wherein the computing node includes: a virtual machine that outputs the first virtual machine traffic and the first virtual routing and forwarding instance, and the routing information of the physical server node has been synchronized to the routing table through the route reflector connected to the computing node; the target switch is connected to the physical server node, the route reflector and the computing node respectively, and is used to send the second virtual machine traffic to the physical server node.

[0008] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned network intercommunication methods when executing the computer program.

[0009] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned network intercommunication methods are implemented.

[0010] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned network intercommunication methods when executed by a processor.

[0011] Through this application, for the first virtual machine traffic output by the virtual machine in the computing node and whose destination node is the physical server node, the first virtual machine traffic is routed and matched through the routing table corresponding to the first virtual routing and forwarding instance in the computing node; the routing information of the physical server node has been synchronized to the routing table through the route reflector connected to the computing node; the obtained second virtual machine traffic is sent to the target switch, so that the target switch sends the second virtual machine traffic to the physical server node, thereby enabling the virtual machine and the physical server node to achieve network interconnection, wherein the target switch is respectively connected to the physical server node, the route reflector and the computing node. Therefore, the technical problem in the related art that the soft gateway used between the virtual machine in the computing node and the bare metal node in the cloud computing environment has a bandwidth forwarding bottleneck and a high solution cost, thereby resulting in poor network interconnection between the virtual machine and the bare metal node can be solved, thereby improving the network interconnection between the virtual machine and the bare metal node. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0013] Figure 1 This is a hardware structure block diagram of a computer terminal of a network intercommunication method according to an embodiment of the present application;

[0014] Figure 2 is a flow chart of a network intercommunication method according to an embodiment of the present application;

[0015] Figure 3 is a schematic diagram of the architecture of a network intercommunication system according to an embodiment of the present application (I);

[0016] Figure 4 is a schematic diagram (2) of the architecture of the network intercommunication system according to an embodiment of the present application;

[0017] Figure 5 It is an architectural diagram of a network intercommunication system according to an embodiment of the present application. DETAILED DESCRIPTION

[0018] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0019] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0020] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0021] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the network intercommunication method depends, the specific application environment architecture or specific hardware architecture is described here.

[0022] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a hardware structure diagram of a computer terminal of a network intercommunication method according to an embodiment of the present application. Figure 1 As shown, the computer terminal may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. The computer terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal may also include Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0023] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the network intercommunication method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the computer terminal 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.

[0024] Transmission device 106 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a computer terminal's communications provider. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0025] Figure 2 This is a flow chart of a network intercommunication method according to an embodiment of the present application, which is applied to computing nodes in a cloud computing environment. Figure 2 As shown, the process includes the following steps:

[0026] Step S202: When the destination node of the first virtual machine traffic is a physical server node, route matching is performed on the first virtual machine traffic through a routing table corresponding to a first virtual routing and forwarding instance to obtain second virtual machine traffic, wherein the computing node includes: a virtual machine that outputs the first virtual machine traffic and the first virtual routing and forwarding instance, and routing information of the physical server node has been synchronized to the routing table through a route reflector connected to the computing node;

[0027] It should be noted that the physical server nodes in the embodiments of this application refer to bare metal servers (also known as bare metal nodes, bare metal services, bare metal, or bare machines), which are generally used to indicate physical servers that do not yet have an operating system installed. It should also be noted that in the field of cloud computing, the concept corresponding to bare metal servers in cloud platforms is cloud physical machines. Among them, bare metal servers in cloud platforms that have already had an operating system installed can be referred to as cloud physical machines.

[0028] It should also be noted that Virtual Routing and Forwarding (VRF) is a technology that allows multiple virtual routing tables to coexist on the same router.

[0029] Step S204: Send the second virtual machine traffic to the target switch, and instruct the target switch to send the second virtual machine traffic to the physical server node, so that the virtual machine and the physical server node can achieve network intercommunication, wherein the target switch is connected to the physical server node, the route reflector, and the computing node respectively.

[0030] Through the above steps, for the first virtual machine traffic output by the virtual machine in the computing node and whose destination node is the physical server node, the first virtual machine traffic is routed and matched through the routing table corresponding to the first virtual routing and forwarding instance in the computing node; the routing information of the physical server node has been synchronized to the routing table through the route reflector connected to the computing node; the obtained second virtual machine traffic is sent to the target switch, so that the target switch sends the second virtual machine traffic to the physical server node, thereby enabling the virtual machine and the physical server node to achieve network interconnection, wherein the target switch is respectively connected to the physical server node, the route reflector and the computing node. Therefore, the technical problem in the related technology that the soft gateway used between the virtual machine in the computing node and the bare metal node in the cloud computing environment has a bandwidth forwarding bottleneck and a high solution cost, thereby resulting in poor network interconnection between the virtual machine and the bare metal node can be solved, thereby improving the network interconnection between the virtual machine and the bare metal node.

[0031] The embodiments of the present application provide a network intercommunication method, and the method is described in detail in conjunction with the execution process of the network intercommunication method.

[0032] In an exemplary embodiment, before performing route matching on the first virtual machine traffic through the routing table corresponding to the first virtual routing and forwarding instance to obtain the second virtual machine traffic, the method further includes: obtaining the autonomous system number, layer 2 virtual network identifier and layer 3 virtual network identifier corresponding to the virtual machine from the control node connected to the computing node through an agent component; and establishing a first preset protocol tunnel between the computing node and the route reflector according to the autonomous system number and the preset protocol through a free range routing instance.

[0033] It should be noted that the aforementioned default protocol is the Border Gateway Protocol (BGP), a protocol used to exchange routing information between different autonomous systems (ASs). Furthermore, the aforementioned first default protocol tunnel is a BGP tunnel established between the compute node and the route reflector. This BGP tunnel specifically refers to a logical connection established via the BGP protocol, used to transmit routing information between different network nodes. Free Range Routing (FRR) is an open-source Internet Protocol (IP) routing protocol suite that provides dynamic routing capabilities for routers and supports multiple routing protocols, including BGP.

[0034] In the embodiments of the present application, it is described how to effectively establish a network tunnel between a computing node and a route reflector through the interaction between the proxy component and the control node, and by utilizing a free range routing (FRR) instance and a preset protocol in a cloud computing environment, especially in the application scenario of a bare metal enhanced gateway (equivalent to the above-mentioned target switch), thereby achieving accurate routing and efficient transmission of virtual machine traffic.

[0035] First, the agent component obtains information from the control node. The agent component on the compute node (for example, ovn-bgp-agent) communicates with the control node. The control node is typically the central management platform in a cloud environment (such as Neutron, OpenStack's network service), responsible for global network configuration and policies. When a virtual machine is created or the network configuration is changed, the agent component obtains relevant network parameters from the control node, including the virtual machine's autonomous system number (such as BGP-AS), Layer 2 virtual network identifier (L2 VNI), and Layer 3 virtual network identifier (L3 VNI).

[0036] The autonomous system number (BGP-AS) is used in the BGP protocol to identify an autonomous system on the Internet. In cloud environments, the autonomous system number is used to establish BGP tunnels between compute nodes and route reflectors (RRs), enabling network isolation and communication in multi-tenant environments.

[0037] L2 VNI and L3 VNI: Virtual Network Identifiers (VNIs) in VXLAN (Virtual eXtensible Local Area Network) are used to identify different network spaces. L2 VNIs are used for Layer 2 network isolation, while L3 VNIs are used for routing isolation in Layer 3 networks. These VNIs are key identifiers for communication between virtual machines (VMs) in an overlay network, or between a VM and bare metal.

[0038] Next, the FRR instance is used to establish a tunnel. On the compute node, the FRR instance is used to establish the first pre-defined protocol tunnel between the compute node and the route reflector based on the BGP AS and pre-defined protocol obtained from the proxy component. This tunnel is used to transmit BGP control plane information, such as routing updates and Media Access Control (MAC) addresses. This ensures that the VMs on the compute node and the bare metal servers on the bare metal enhanced gateway can share routing information, enabling Layer 2 and Layer 3 interoperability.

[0039] Finally, each VRF on a compute node is an independent routing and forwarding environment with its own routing table. When traffic from the first virtual machine arrives at the compute node, it is matched against the first virtual routing and forwarding instance's routing table, and a Layer 3 route match is performed based on the retrieved L3 VNI to determine the next-hop destination. The result of the route match determines the subsequent flow of the traffic, for example, whether it is sent to the bare metal enhanced gateway or directly forwarded to the local network. It should be noted that "secondary virtual machine traffic" actually refers to the traffic in its encapsulated or unencapsulated state after passing the compute node's VRF route match and is ready for further transmission. If the traffic is destined for another virtual machine, it may need to be encapsulated again and sent via VXLAN or other overlay technologies. However, if the destination is a resource within the same VRF, the traffic can be directly forwarded at Layer 2 or Layer 3.

[0040] Through the above steps, the embodiment of the present application uses a combination of preset protocols (such as BGP), VRF instances and VNI identifiers to establish an efficient and isolated network connection between computing nodes and route reflectors, enabling virtual machines and bare metal servers to achieve seamless and secure communication in a complex cloud environment, while optimizing network performance and resource utilization efficiency.

[0041] In an exemplary embodiment, the autonomous system number, the layer 2 virtual network identifier and the layer 3 virtual network identifier corresponding to the virtual machine are obtained from a control node connected to the computing node through an agent component, including: monitoring the southbound database in the control node through the agent component; when it is detected that the external identifier of the network port corresponding to the virtual machine is synchronized to the southbound database, extracting the autonomous system number, the layer 2 virtual network identifier and the layer 3 virtual network identifier from the external identifier, wherein the autonomous system number, the layer 2 virtual network identifier and the layer 3 virtual network identifier are added to the external identifier by the driver component in the control node when the network port is created.

[0042] It's important to note that cloud network controllers (such as OpenStack's Neutron or the southbound database of Open Virtual Network (OVN)) store configuration information for all network ports (including those of virtual machines, bare metal resources, and other resources). This configuration information includes external identifiers (external_ids), which contain additional parameters related to the network port, such as the autonomous system number, Layer 2 virtual network identifier, and Layer 3 virtual network identifier.

[0043] The embodiment of the present application continuously monitors the southbound database through an agent component (such as ovn-bgp-agent) pre-deployed on the computing node to capture any changes related to the virtual machine network port information. When a new virtual machine network port is created, the driver component (such as bgpvpn-ovn-driver) in the control node will add the necessary network parameters to the external identifier of the port, including the autonomous system number, the layer 2 virtual network identifier, and the layer 3 virtual network identifier. When the agent component detects that the external identifier of the virtual machine network port is synchronized to the southbound database, it extracts the autonomous system number, the layer 2 virtual network identifier, the layer 3 virtual network identifier, etc. from the external identifier. This process is automated, ensuring the rapid response and accuracy of the virtual machine network configuration, and avoiding delays and errors that may be caused by manual intervention.

[0044] In summary, this embodiment builds a dynamic and highly adaptable network environment through the real-time monitoring and automated parameter extraction capabilities of the proxy component. This mechanism ensures rapid and accurate response to network configuration changes, even in complex cloud architectures, enabling efficient and secure communication between virtual machines and bare metal servers. It also reduces the workload of operations and maintenance personnel and improves overall network automation and management efficiency.

[0045] In an exemplary embodiment, after establishing a first preset protocol tunnel between the computing node and the route reflector according to the autonomous system number and the preset protocol through a free range routing instance, the method further includes: synchronizing the routing information of the virtual machine to the route reflector through the first preset protocol tunnel, so as to synchronize the routing information of the virtual machine to the target switch through the route reflector; and synchronizing the routing information in the route reflector to the routing table corresponding to the first virtual routing and forwarding instance through the first preset protocol tunnel, wherein the routing information in the route reflector includes: routing information of the physical server node.

[0046] In cloud computing environments, especially scenarios involving bare metal enhanced gateways, ensuring accurate and efficient synchronization of network information (such as routing information) between different compute nodes, route reflectors, and target switches is key to achieving seamless communication between virtual machines and bare metal servers in the overlay network.

[0047] In this embodiment of the present application, after obtaining the autonomous system number, the compute node establishes a first preset protocol tunnel from the compute node to the route reflector through the FRR instance based on the obtained autonomous system number and the preset BGP protocol. Control plane information, such as routing updates and MAC address learning results, can be transmitted between the compute node and the route reflector via the first preset protocol tunnel.

[0048] Based on the first pre-defined protocol tunnel, the compute node synchronizes the VM's routing information, such as the VM's MAC address and VXLAN Tunnel Endpoint (VTEP) information, to the route reflector. After receiving the VM's routing information, the route reflector reflects it to other connected compute nodes and the target switch (i.e., the bare metal enhanced gateway), ensuring that network devices across the entire cloud platform have the latest routing information for efficient data forwarding.

[0049] The route reflector not only receives and reflects routing information for virtual machines but also collects and manages routing information for physical server nodes (such as bare metal servers). This routing information is also synchronized to the routing table corresponding to the first virtual routing and forwarding instance of the compute node through the preset first preset protocol tunnel.

[0050] This embodiment enables network devices in a cloud environment (including compute nodes, route reflectors, and target switches) to maintain a unified and updated routing information database, ensuring that traffic, regardless of whether it is destined for a virtual machine or a bare metal server, is forwarded along the optimal path. This avoids the bandwidth bottlenecks and latency issues that can arise from traditional centralized gateways. Furthermore, by utilizing the standardized BGP protocol, this solution offers excellent scalability and hardware compatibility, supporting the network connectivity requirements of large-scale cloud environments without increasing complexity.

[0051] In an exemplary embodiment, after obtaining the autonomous system number, layer 2 virtual network identifier and layer 3 virtual network identifier corresponding to the virtual machine from the control node connected to the computing node through the agent component, the method further includes: creating the first virtual routing and forwarding instance based on the layer 3 virtual network identifier; establishing a virtual Ethernet pair between a first bridging device and a second bridging device, wherein the first bridging device is a bridging device corresponding to the first virtual routing and forwarding instance, and the second bridging device is a bridging device corresponding to an open virtual switch; and configuring a target component in the first virtual routing and forwarding instance through the layer 2 virtual network identifier and the layer 3 virtual network identifier, wherein the target component includes: a layer 2 port and a layer 3 port corresponding to the layer 2 bridging device and the layer 3 bridging device respectively, and the layer 2 port and the layer 3 port are both used to transmit the first virtual machine traffic.

[0052] In an embodiment of the present application, the compute node creates a first virtual routing and forwarding instance based on a Layer 3 virtual network identifier obtained from the control node. A VRF instance can be understood as a network-isolated environment that includes independent routing and forwarding tables, allowing the construction of multiple logical networks on a physical network, each with its own routing policies and network resources.

[0053] On the compute node, a virtual Ethernet pair is established between the first bridge device (br-vrf) and the second bridge device (br-int, which is the integrated bridge of OpenvSwitch (OVS)). This virtual Ethernet pair allows direct communication between the two bridge devices, thereby supporting transparent forwarding of traffic between VRF and OVS.

[0054] Furthermore, the compute node also configures corresponding Layer 2 and Layer 3 bridging devices in the created first virtual routing and forwarding instance based on the Layer 2 virtual network identifier and the Layer 3 virtual network identifier. Each bridging device has a corresponding port for receiving and sending traffic from the first virtual machine. Specifically, the Layer 2 port is responsible for processing Layer 2 traffic, performing VXLAN encapsulation and decapsulation using the L2 VNI configured in the first virtual routing and forwarding instance to ensure interoperability within the Layer 2 network. The Layer 3 port is responsible for routing and forwarding Layer 3 traffic, performing VXLAN processing based on the L3 VNI, directing traffic to the correct next hop, and supporting routing decisions within the Layer 3 network.

[0055] In an exemplary embodiment, after configuring the target component in the first virtual routing and forwarding instance through the second-layer virtual network identifier and the third-layer virtual network identifier, the method also includes: receiving physical server traffic sent by the physical server node through the first virtual routing and forwarding instance; sending the physical server traffic to the open virtual switch through the virtual Ethernet pair; and when determining that the destination node of the physical server traffic is the virtual machine, sending the physical server traffic to the virtual machine through the open virtual switch.

[0056] When a physical server node sends traffic to a virtual machine, the traffic originates from the physical server node and enters the first virtual routing and forwarding instance of the compute node. The virtual Ethernet pair (veth pair) between the first virtual routing and forwarding instance and OVS acts as a bridge between the two, allowing traffic to flow seamlessly between the VRF environment and OVS. After the physical server traffic is received and processed by the first virtual routing and forwarding instance, the traffic is sent to OVS via the virtual Ethernet pair. Once the physical server traffic reaches OVS, OVS checks the destination node of the traffic based on the flow table rules. If it determines that the destination of this traffic is a virtual machine, OVS follows the corresponding forwarding logic and sends the traffic directly to the target virtual machine. In this way, the physical server traffic can quickly pass through the OVS forwarding rules and reach the target virtual machine directly, avoiding unnecessary network paths and processing delays, and achieving more efficient and direct packet transmission.

[0057] In an exemplary embodiment, after sending the second virtual machine traffic to the target switch and instructing the target switch to send the second virtual machine traffic to the physical server node so that the virtual machine and the physical server node can achieve network intercommunication, the method further includes: sending the second virtual machine traffic to the target switch through the first virtual routing and forwarding instance; and instructing the target switch to send the second virtual machine traffic to the physical server node through the second virtual routing and forwarding instance in the target switch so that the virtual machine and the physical server node can achieve network intercommunication.

[0058] In an embodiment of the present application, when a computing node receives traffic from a first virtual machine and its destination node is identified as a physical server, the traffic will be processed by the computing node's first virtual routing and forwarding instance. The routing table of the first virtual routing and forwarding already contains the routing information of the physical server node, which is synchronized by the route reflector (router-reflector) connected to the computing node. Then, through the route matching in the first virtual routing and forwarding instance, the first virtual machine traffic is converted to the second virtual machine traffic. This process includes VXLAN encapsulation of the traffic to adapt to the transmission requirements of the overlay network.

[0059] The compute node sends the second VM's traffic to the target switch through the first virtual routing and forwarding instance. In this scenario, the target switch acts as an enhanced gateway, connecting the physical server nodes and compute nodes (including VMs). The target switch connects not only to the compute nodes but also to the physical server nodes and route reflectors. This allows the target switch to receive traffic from the compute nodes, obtain routing information from the route reflectors, and communicate directly with the physical server nodes.

[0060] It should be noted that in all embodiments of the present application, connections (such as the connection between the target switch and any one of the computing nodes, route reflectors, and physical server nodes, the connection between the route reflector and the computing node, and the connection between the computing node and the control node) include: physical connections and communication connections.

[0061] After receiving the second VM traffic, the target switch processes it through its internal second virtual routing and forwarding instance. This processing may include VXLAN decapsulation and Layer 2 or Layer 3 routing decisions based on the destination address. The second virtual routing and forwarding instance sends the processed second VM traffic to the physical server node, enabling network connectivity between the VM and the physical server. This process ensures traffic security while also leveraging hardware acceleration to improve forwarding efficiency and optimize traffic management in the overlay network. This enables efficient network connectivity between the VM and the physical server node, while also ensuring network security and stability.

[0062] In an exemplary embodiment, instructing the target switch to send the second virtual machine traffic to the physical server node through the second virtual routing and forwarding instance in the target switch includes: instructing the target switch to parse a target virtual network identifier corresponding to the second virtual machine traffic, wherein the target virtual network identifier includes one of the following: a Layer 2 virtual network identifier corresponding to the virtual machine, a Layer 3 virtual network identifier corresponding to the virtual machine; instructing the second virtual routing and forwarding instance to determine the tenant network identifier corresponding to the physical server node based on the target virtual network identifier; and instructing the second virtual routing and forwarding instance to send the second virtual machine traffic to the physical server node through the tenant network identifier.

[0063] In this embodiment of the present application, when the second virtual machine traffic arrives at the destination switch, the first step is to parse the target virtual network identifier it carries. This identifier can be a Layer 2 virtual network identifier or a Layer 3 virtual network identifier, depending on the nature of the traffic (i.e., whether it is Layer 2 traffic or Layer 3 traffic). Identifying the target virtual network identifier is the basis for subsequent traffic processing and routing decisions. It guides the destination switch on how to decapsulate, identify, and further process the traffic, ensuring that the traffic enters the correct VRF instance and is subsequently sent to the correct destination.

[0064] The second virtual routing and forwarding instance determines the tenant network identifier associated with the physical server node based on the resolved target virtual network identifier. This step is based on the switch configuration and mapping rules, which define the correspondence between different virtual network identifiers and specific tenant networks. Determining the tenant network identifier is key to accurate traffic routing. It ensures that traffic flows only within the correct network environment, effectively preventing cross-tenant traffic misrouting and improving network security and efficiency.

[0065] The second virtual routing and forwarding instance uses the identified tenant network identifier to route the second virtual machine's traffic to the corresponding physical server node. This process may involve VXLAN decapsulation and further forwarding decisions based on MAC addresses (for Layer 2 traffic) or IP addresses (for Layer 3 traffic). Through the precise processing of the second virtual routing and forwarding instance, traffic can efficiently and accurately reach the physical server node, enabling network connectivity between the virtual machine and the physical server.

[0066] Through a series of operations in the second virtual routing and forwarding instance on the target switch, including resolution of the target virtual network identifier, determination of the tenant network identity, and final forwarding of traffic, a precise transmission path is established from the virtual machine to the physical server. This mechanism not only ensures efficient and secure processing and forwarding of traffic in the overlay network environment, but also maintains network isolation between different tenants, improving the network performance and security of the entire cloud computing platform.

[0067] In an exemplary embodiment, before performing route matching on the first virtual machine traffic through the routing table corresponding to the first virtual routing and forwarding instance to obtain the second virtual machine traffic, the method further includes: instructing the target switch to create the second virtual routing and forwarding instance; instructing the target switch to establish a second preset protocol tunnel between the target switch and the route reflector through the second virtual routing and forwarding instance and the preset protocol, and instructing the target switch to synchronize routing information with the route reflector through the second preset protocol tunnel.

[0068] It should be noted that the preset protocol in this embodiment is BGP, and the second preset protocol tunnel is a BGP tunnel established between the target switch and the route reflector. The target switch then synchronizes routing information of the physical server nodes with the route reflector through the second preset protocol tunnel and obtains routing information from the route reflector. The route reflector's routing information includes routing information for virtual machines.

[0069] In summary, by pre-creating a second virtual routing and forwarding instance on the target switch, establishing a preset protocol tunnel between the target switch and the route reflector, and continuously synchronizing routing information, this embodiment demonstrates how to optimize network interconnection in a cloud computing environment and provides a solid technical foundation for network interoperability between virtual machines and physical servers.

[0070] In order to better understand the process of the above-mentioned network intercommunication method, the implementation process of the above-mentioned network intercommunication method is described below in combination with optional embodiments, but it is not used to limit the technical solution of the embodiments of this application.

[0071] The centralized gateway and distributed gateway solutions currently used in bare metal nodes each have their own flaws. Enhanced gateways with switch forwarding can be used to resolve the bandwidth forwarding bottleneck problem of centralized gateways. At the same time, switches can be used to replace smart network cards to solve the cost and threshold issues of smart network cards.

[0072] The bare metal nodes of the enhanced gateway forward traffic through a Top-of-Rack (TOR) switch. This application provides a bare metal enhanced gateway based on a hardware switch, enabling Layer 2 and Layer 3 connectivity between bare metal nodes and virtual machine overlay networks within a cloud platform.

[0073] The enhanced bare metal gateway solves overlay network connectivity issues between bare metal VMs and compute nodes in cloud computing environments. In cloud computing scenarios, bare metal is typically provided independently to tenants, and VXLAN encapsulation is not possible on bare metal in overlay networks. Therefore, the enhanced gateway is used to address this issue. Layer 2 and 3 connectivity between bare metal and VMs requires considerations such as ensuring co-planarity between the bare metal and VMs, establishing Layer 2 connectivity between the VMs on the compute node and the bare metal on the enhanced gateway switch, ensuring that the MAC addresses of VMs on the compute node are learned by the bare metal on the enhanced gateway, and ensuring that traffic originating from the VMs on the compute node reaches the bare metal on the enhanced gateway.

[0074] Optional, for the above issues to be considered, such as Figure 3 As shown, the present application adopts a route reflector (router-reflector) to solve the co-planarity problem of the virtual machine on the computing node side and the bare metal on the enhanced gateway (i.e., the target switch) side. The virtual machine on the computing node establishes a Border Gateway Protocol BGP tunnel (equivalent to the first preset protocol tunnel in the above embodiment) with the router-reflector through the computing node, and synchronizes the MAC and VTEP information of the virtual machine to the router-reflector through the FRR service pulled up by the ovn-bgp-agent of the computing node. The existing routes of the router-reflector will also be learned and generated into the routing table of the virtual routing and forwarding VRF. Similarly, the enhanced gateway and the router-reflector also establish a BGP link (equivalent to the second preset protocol tunnel in the above embodiment), and the MAC of the bare metal on the enhanced gateway side and the VTEP configured on the switch will be synchronized to the router-reflector through the BGP link, and all the current routing information of the router-reflector will also be received.

[0075] The following is an explanation of the technical terms used in the above content:

[0076] An overlay network is a virtual network layer built on top of the underlying physical network. It allows logical connections between devices in the network without being restricted by the underlying physical topology or network address space. This network structure is well-suited for multi-tenant environments, such as cloud platforms, because it provides each tenant with an independent, isolated network space, even if they share the same physical infrastructure.

[0077] 3) Media Access Control MAC: The hardware address of a network device, a unique identifier used for network communication.

[0078] 4) Route reflector: In BGP, a route reflector is a mechanism used to reduce the number of BGP sessions within an autonomous system (AS). It reflects routing information to other BGP neighbors, eliminating the need for all BGP routers to connect to each other.

[0079] 5) VXLAN tunnel endpoint: The terminal of VXLAN, used to encapsulate and decapsulate network packets.

[0080] Combine Figure 3 Traffic from VMs on the compute node (equivalent to the first VM traffic in the above embodiment) first enters the OVS Integrated Bridge of Open vSwitch (br-int). Flow table rules added by the ovn-bgp-agent then determine traffic destined for bare metal. If the traffic is destined for bare metal, the flow table rules route it to the VRF (i.e., the first virtual routing and forwarding instance in the above embodiment), where a route match is performed (this is because the bare metal routes have been synchronized to the compute node's VRF via the router-reflector). VM traffic destined for bare metal is then overlay-encapsulated in the compute node's VRF (the traffic after route matching or encapsulation is equivalent to the second VM traffic in the above embodiment) and delivered to the VTEP of the enhanced gateway. Upon reaching the enhanced gateway, the traffic undergoes VXLAN decapsulation and, based on the VXLAN virtual network identifier (VNI) value (equivalent to the target virtual network identifier in the above embodiment), finds the corresponding VLAN. The traffic is then delivered to the bare metal based on the MAC address.

[0081] Further, such as Figure 4 The specific implementation scheme of the enhanced gateway and the specific implementation scheme of Layer 2 and Layer 3 overlay network interconnection between bare metal and virtual machines in combination with the enhanced gateway are as follows:

[0082] First, design the control panel process for the compute node side:

[0083] Deploy the Network Service (Neutron), ovn-nb, ovn-sb, and Neutron's OVN plug-in bgpvpn-ovn-driver on the control node. Deploy the ovn-bgp-agent and ovn-controller components on the compute node. (The northbound database ovn-nb corresponds to Figure 4 ovn-nb-db in the southbound database ovn-sb Figure 4 ovn-sb-db in the . This is specifically achieved through steps 31 to 35 below.

[0084] Step 31: During the creation of the virtual machine (VM) network port Neutron port, the bgpvpn-ovn-driver adds additional information, such as BGP AS, L2 VNI, and L3 VNI, to the VM port's external identifiers (external_ids) and writes it to ovn-nb. The data is then synchronized from ovn-nb to ovn-sb.

[0085] Step 32: Ovn-BGP-agent runs on the compute node. When the VM's Neutron port data is synchronized from Ovn-nb to Ovn-sb, Ovn-BGP-agent detects this synchronization and extracts the BGP AS, L2 VNI, and L3 VNI information from the Ovn-sb port information. It then writes the information to local memory. At this point, the attribute information in the port's external_ids has been passed from the Neutron control node to the compute node where the VM resides.

[0086] Step 33: ovn-bgp-agent configures evpnbgp (Enhanced Virtual Private Network, EVPN) using the BGP as information extracted in step 32 through frr vtysh, establishes a BGP link to router-reflector, creates VM routes, and synchronizes the routes to router-reflector using the evpn bgp protocol. It also synchronizes other routing information in router-reflector to the VRF.

[0087] Step 34: For the L2 and L3 VNIs extracted by the ovn-bgp-agent, create a VRF based on the L3 VNI and specify the VRF table as the L3 VNI. Create the br-ovs and br-vrf veth pairs (equivalent to the virtual Ethernet pair in the above example) to direct OVS traffic to the VRF. Create a Linux bridge within the VRF based on the L2 and L3 VNIs and attach the br-vrf to the br-l2. The L2 VNI is the tunnel's VNI value, and the L3 VNI is a one-to-one binding between the evpn L3 VNI and the tenant. Create VXLAN ports on br-l2 and br-l3, with the VNIs set to the L2 and L3 VNIs, respectively.

[0088] Step 35: ovn-bgp-agent adds a high-priority flow table to OVS. For bare metal ports (a baremetal port is a network port connected to a bare metal server), outbound traffic bypasses the Geneve encapsulation process and is directed to the VRF. Within the VRF, Layer 2 and Layer 3 traffic is distinguished and sent out through the corresponding L2-br VXLAN or L3 VXLAN port. Similarly, inbound VXLAN traffic is decapsulated in the kernel and then redirected to the corresponding OpenFlow table via the br-ovs high-priority flow table.

[0089] The technical terms in steps 31 to 35 are explained below.

[0090] 1) Neutron: In the OpenStack cloud infrastructure, Neutron is a service that provides cloud networking capabilities. It supports the creation and management of various virtual network resources, including but not limited to networks, subnets, routers, firewalls, and load balancers. It is a key component in OpenStack for defining and managing network topologies, allowing users to customize complex network structures to meet the networking needs of resources such as virtual machines and containers.

[0091] 2) ovn-nb-db: This is a database in the OVN architecture that stores network topology information, including networks, ports, and routes. The northbound database is where data is exchanged between the controller and network applications, and is used to control the logical network state of the control plane. ovn-sb-db: This is another database in OVN, primarily used to store state information related to the data plane, such as flow table rules. The southbound database is where data is exchanged between the controller and network devices (such as OVS switches), and is used to reflect the status of actual network devices.

[0092] 3) bgpvpn-ovn-driver: BGP-based Virtual Private Network for Open Virtual Network Driver (bgpvpn-ovn-driver). This Neutron plugin is used to integrate bgpvpn with OVN in an OpenStack environment. It allows users to define and manage bgpvpn services and synchronize service parameters to ovn-nb-db, thereby automatically configuring the OVN network to support bgpvpn.

[0093] 4) ovn-bgp-agent, the Open Virtual Network Border Gateway Protocol agent, is a component running on compute nodes. It is responsible for exchanging routing information with Router-Reflector through the BGP protocol, enabling compute nodes to understand the reachability of other nodes in the network and synchronize information such as the virtual machine's MAC address and VTEP to Router-Reflector.

[0094] 5) ovn-controller: The Open Virtual Network Controller is a core component of the OVN architecture. It processes requests from northbound databases and sends instructions to southbound databases, ultimately influencing data plane behavior. ovn-controller is central to controlling network policies and flow table rules, ensuring correct network configuration and traffic handling.

[0095] 6) Neutron Port: A network port. In OpenStack's Neutron networking service, a network port represents a connection point for network resources and can be attached to a virtual machine, bare metal server, or other network resource. A Neutron port is the basic unit for defining a network connection and includes IP addresses, MAC addresses, security groups, and other network attributes.

[0096] 7) external_ids: In ovn-nb-db, external_ids is a key-value pair collection used to store information that is not part of the standard OVN database model. For example, when a virtual machine port is created, external_ids can be used to store additional metadata such as the associated BGP AS number, L2 VNI, and L3 VNI values.

[0097] 8) frr vtysh: This is a command-line interface (CLI) tool within the FRR software suite for configuring and managing routing protocols. It allows administrators to perform detailed configuration and status queries on routing devices through the command-line interface. FRR is an open-source routing software package that supports multiple routing protocols, including BGP, OSPF, and RIP.

[0098] 9) Layer 2 bridge br-l2 and Layer 3 bridge br-l3: br-l2 and br-l3 represent bridges that handle Layer 2 and Layer 3 traffic, respectively. In the VXLAN and EVPN architecture, br-l2 handles Layer 2 VXLAN traffic, while br-l3 handles Layer 3 routing information and traffic associated with EVPN.

[0099] 10) Veth pair: A veth pair is a virtual network device provided by the Linux kernel. It allows the creation of a pair of full-duplex virtual Ethernet devices within the kernel. It is typically used to establish connections between different network namespaces and forward traffic. In this application, a veth pair is used to connect br-ovs and br-vrf, ensuring that traffic can correctly enter the VRF environment from the OVS bridge.

[0100] 11) Geneve: Generic Network Encapsulation (Geneve). Geneve is a network encapsulation protocol primarily used to build overlay networks within data centers. It encapsulates Layer 2 network packets and transmits them over Layer 3 networks, while providing high efficiency, flexible header formats, and multiple encapsulation options.

[0101] 12) OpenFlow Table: In Open vSwitch (OVS) or any network device that implements the OpenFlow protocol, flow tables store flow rules. Flow rules define how packets are processed and forwarded within the device. Each flow table entry contains a match condition and an action to be performed. When a packet arrives at an OpenFlow switch, it is checked to see if it matches a rule in the flow table. If a match is found, the packet is processed according to the rule, such as being forwarded to a specific port, having certain network operations performed, or being dropped. If no matching flow table entry is found, the packet may be sent to the controller for further processing. In OVS, flow tables reside within bridge devices and are a core component of the OpenFlow architecture, used to filter and forward network packets according to predefined rules. Controllers, such as ovn-controller, can remotely modify these flow tables to adapt to network changes or policy updates, ensuring correct packet processing and routing behavior.

[0102] Second, design the control panel process for switch logic testing.

[0103] This is specifically achieved through the following steps 41 to 45.

[0104] Step 41: Plan access vlans for the switch ports connected to the vtep ip addresses of the computing nodes, and create vlan if (vlan interface, which refers to the virtual interface associated with a specific VLAN) for the corresponding VLAN. Configure the vtep ip on the vlan if as the vtep ip on the bare metal side. This ensures that the bare metal can be interconnected with all computing node VTEPs through the switch. Figure 4 As shown in the figure, 192.168.122.0 / 24 is planned as the VTEP network, and VLAN 88 is planned. The vtep IP of the compute node is 192.168.122.8, the VTEP of the enhanced gateway is 192.168.122.6, and it falls on the VLAN if of VLAN 88 of the switch. The router-reflector node is configured with 192.168.122.4 to ensure that the VTEP network can communicate with each other through BGP.

[0105] Step 42: Create the bare metal access tenant's access VLAN, the tenant's EVPN L3 VNI VLAN, and the tunnel's L2 VNI. Create the tenant's VRF (equivalent to the second virtual routing and forwarding instance in the above embodiment) and bind the access VLAN, EVPN L3 VNI VLAN, and tunnel's L2 VNI to the VRF.

[0106] Step 43: Configure the switch to establish BGP, activate the neighbor router-reflector in the address-family l2vpn evpn, and advertise advertise-all-vni. The tunnels communicate using the router bgp as instance, transmitting evpn type 2 and type 3 messages.

[0107] Step 44: Enable EVPN type-5 route advertising in the corresponding VRF on the switch. Use the network and redistribute connected commands to advertise type-5 routes. Steps 43 and 44 enable route advertising and learning between the switch and the router-reflector. The learned routes are synchronized to the corresponding VRF.

[0108] Step 45: Configure the switch L3 EVPN tunnel. Create the L3 EVPN tunnel, specify the VTEP's access VLANIF as the source IP address of the overlay-EVPN, and configure the mapping between the VRF and the VNI (equivalent to the target virtual network identifier in the above embodiment) in the L3 EVPN tunnel, as well as the mapping between the bare metal access side tenant VLAN (equivalent to the tenant network identifier in the above embodiment) and the VNI.

[0109] Combining the control plane process design on the compute node side and the compute-to-bare metal node side, the data plane traffic transmission solution between the virtual machines in the compute node and the bare metal node is as follows:

[0110] 1) Layer 2 and Layer 3 traffic from virtual machines to bare metal machines.

[0111] When VM traffic enters the OVS OpenFlow table and matches control rules, if the destination port is a bare metal port, it will match the higher-priority flow control rule and enter the VRF through br-ovs. Within the VRF, Layer 2 and Layer 3 routes are matched against the destination IP address. Based on the EVPN control rules, if the traffic is Layer 2, it is encapsulated with an L2 VNI; if it is Layer 3, it is encapsulated with an EVPN L3 VNI and sent out. When the packet reaches the corresponding bare metal switch (VTEP), the switch decapsulates the VTEP, maps the VXLAN VNI to the corresponding VLAN and VRF, and then performs a route lookup to send the packet to the corresponding bare metal switch.

[0112] 2) Layer 2 and 3 traffic from the bare metal server to the virtual machine server.

[0113] Similarly, bare metal traffic is matched to the corresponding VRF through the access VLAN. After entering the VRF, it is matched to the corresponding routing rule through the destination IP address for VXLAN encapsulation and then sent to the corresponding compute node vxlan vtep port. After VXLAN decapsulation, the VRF traffic is connected to OVS through the br-vrf and br-ovs veth pairs. The high-priority flow control rules issued by ovn-bgp-agent directly jump to the corresponding table for processing.

[0114] In summary, the bare metal enhanced gateway, as a network optimization solution for cloud computing scenarios, mainly brings the following benefits:

[0115] 1) High performance and low latency.

[0116] The enhanced gateway performs VXLAN encapsulation / decapsulation by reusing bare metal TOR (Top of Rack Switch). The data plane is completely processed by hardware devices, without the need for software gateway participation, avoiding the performance loss of the traditional virtualization layer.

[0117] Supporting the same network bandwidth as physical machines, the end-to-end path is completed directly by hardware devices, reducing intermediate forwarding steps. This makes it suitable for high-throughput scenarios such as high-performance computing (HPC) and core databases. Furthermore, through switch hardware acceleration, it can carry higher-density network traffic, meeting the stability and real-time requirements of enterprise-level applications.

[0118] 2) Significant cost-effectiveness.

[0119] Eliminating the need to purchase additional Smart NICs or dedicated gateway devices, existing switches can be leveraged for functionality, significantly reducing hardware investment costs. Compared to Smart NIC solutions, enhanced gateways offer lower deployment costs and are compatible with devices from multiple vendors, creating a more open ecosystem. Furthermore, the use of standardized switch hardware avoids the upgrade complexity and operational risks associated with the tight coupling of Smart NICs with the cloud platform.

[0120] 3) Enhanced security and stability.

[0121] The bare metal server itself provides physical-level isolation, and the enhanced gateway implements VPC network encapsulation through hardware devices, further ensuring data transmission security and avoiding potential attacks at the virtualization layer.

[0122] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0123] This embodiment also provides a network intercommunication device for implementing the above-mentioned embodiments and preferred implementations. Details already described will not be repeated. 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.

[0124] Figure 5 is an architecture diagram of a network intercommunication system according to an embodiment of the present application, such as Figure 5 As shown, the system includes:

[0125] Compute node 52, route reflector 54, target switch 56, physical server node 58;

[0126] a computing node, configured to, when the destination node of the first virtual machine traffic is a physical server node, perform route matching on the first virtual machine traffic using a routing table corresponding to a first virtual routing and forwarding instance to obtain second virtual machine traffic, and send the second virtual machine traffic to a destination switch, wherein the computing node includes: a virtual machine that outputs the first virtual machine traffic and the first virtual routing and forwarding instance, and routing information of the physical server node has been synchronized to the routing table via a route reflector connected to the computing node;

[0127] The target switch is connected to the physical server node, the route reflector, and the computing node respectively, and is used to send the second virtual machine traffic to the physical server node.

[0128] Through the above system, for the first virtual machine traffic output by the virtual machine in the computing node and whose destination node is the physical server node, the first virtual machine traffic is routed and matched through the routing table corresponding to the first virtual routing and forwarding instance in the computing node; the routing information of the physical server node has been synchronized to the routing table through the route reflector connected to the computing node; the obtained second virtual machine traffic is sent to the target switch, so that the target switch sends the second virtual machine traffic to the physical server node, thereby enabling the virtual machine and the physical server node to achieve network interconnection, wherein the target switch is respectively connected to the physical server node, the route reflector and the computing node. Therefore, the technical problem in the related art that the soft gateway used between the virtual machine in the computing node and the bare metal node in the cloud computing environment has a bandwidth forwarding bottleneck and a high solution cost, thereby resulting in poor network interconnection between the virtual machine and the bare metal node can be solved, thereby improving the network interconnection between the virtual machine and the bare metal node.

[0129] In an exemplary embodiment, the system further includes: a control node connected to the computing node; the computing node further includes: an agent component and a free-range routing instance; the agent component is used to obtain the autonomous system number, layer 2 virtual network identifier and layer 3 virtual network identifier corresponding to the virtual machine from the control node; the free-range routing instance is used to establish a first preset protocol tunnel between the computing node and the route reflector based on the autonomous system number and the preset protocol.

[0130] In an exemplary embodiment, the control node also includes: a southbound database and a driver component; the driver component is used to add the autonomous system number, the layer 2 virtual network identifier and the layer 3 virtual network identifier to the external identifier of the network port when the network port corresponding to the virtual machine is created; the agent component is also used to monitor the southbound database in the control node, and when it is detected that the external identifier is synchronized to the southbound database, extract the autonomous system number, the layer 2 virtual network identifier and the layer 3 virtual network identifier from the external identifier.

[0131] In an exemplary embodiment, the computing node is further used to synchronize the routing information of the virtual machine to the route reflector through the first preset protocol tunnel, and the route reflector is used to synchronize the routing information of the virtual machine to the target switch; the computing node is further used to synchronize the routing information in the route reflector to the routing table corresponding to the first virtual routing and forwarding instance through the first preset protocol tunnel, wherein the routing information in the route reflector includes: routing information of the physical server node.

[0132] In an exemplary embodiment, the computing node further includes: the first virtual routing and forwarding instance created based on the three-layer virtual network identifier, and a virtual Ethernet pair established between a first bridging device and a second bridging device, wherein the first bridging device is a bridging device corresponding to the first virtual routing and forwarding instance, and the second bridging device is a bridging device corresponding to an open virtual switch; the first virtual routing and forwarding instance includes: a target component, the target component includes: a layer 2 port and a layer 3 port corresponding to a layer 2 bridging device and a layer 3 bridging device, respectively, wherein the target component is configured in the first virtual routing and forwarding instance through the layer 2 virtual network identifier and the layer 3 virtual network identifier, and both the layer 2 port and the layer 3 port are used to transmit the first virtual machine traffic.

[0133] In an exemplary embodiment, the computing node is further used to receive physical server traffic sent by the physical server node through the first virtual routing and forwarding instance; the computing node is further used to send the physical server traffic to the open virtual switch through the virtual Ethernet pair; the computing node is further used to send the physical server traffic to the virtual machine through the open virtual switch when it is determined that the destination node of the physical server traffic is the virtual machine.

[0134] In an exemplary embodiment, the computing node is further configured to send the second virtual machine traffic to the target switch through the first virtual routing and forwarding instance; the target switch further includes: a second virtual routing and forwarding instance configured to send the second virtual machine traffic to the physical server node, so that the virtual machine and the physical server node can achieve network intercommunication.

[0135] In an exemplary embodiment, the target switch is further used to parse out the target virtual network identifier corresponding to the second virtual machine traffic, wherein the target virtual network identifier includes one of the following: a Layer 2 virtual network identifier corresponding to the virtual machine, a Layer 3 virtual network identifier corresponding to the virtual machine; the second virtual routing and forwarding instance is further used to determine the tenant network identifier corresponding to the physical server node based on the target virtual network identifier; and send the second virtual machine traffic to the physical server node through the tenant network identifier.

[0136] For the description of the features in the embodiment corresponding to the network intercommunication system, reference can be made to the relevant description of the embodiment corresponding to the network intercommunication method, which will not be repeated here.

[0137] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above network intercommunication method embodiments.

[0138] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned network intercommunication method embodiments when running.

[0139] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0140] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned network intercommunication method embodiments are implemented.

[0141] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned network intercommunication method embodiments are implemented.

[0142] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0143] The above is a detailed introduction to the network intercommunication provided by this application. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above embodiments is only intended to help understand the method and core ideas of this application. It should be noted that for those skilled in the art, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A network intercommunication method, characterized in that: include: Obtaining, through the proxy component, an autonomous system number, a layer 2 virtual network identifier, and a layer 3 virtual network identifier corresponding to the virtual machine from a control node connected to the computing node; Establishing a first preset protocol tunnel between the computing node and the route reflector according to the autonomous system number and the preset protocol through a free range routing instance; Creating a first virtual routing and forwarding instance according to the Layer 3 virtual network identifier; Establishing a virtual Ethernet pair between a first bridging device and a second bridging device, wherein the first bridging device is a bridging device corresponding to the first virtual routing and forwarding instance, and the second bridging device is a bridging device corresponding to the open virtual switch; and Configuring a target component in the first virtual routing and forwarding instance using the Layer 2 virtual network identifier and the Layer 3 virtual network identifier, wherein the target component includes: a Layer 2 port and a Layer 3 port corresponding to a Layer 2 bridge device and a Layer 3 bridge device, respectively, the Layer 2 port and the Layer 3 port being used to transmit traffic of the first virtual machine; In a case where the destination node of the first virtual machine traffic is a physical server node, performing route matching on the first virtual machine traffic through a routing table corresponding to a first virtual routing and forwarding instance to obtain second virtual machine traffic, wherein the computing node includes: a virtual machine that outputs the first virtual machine traffic and the first virtual routing and forwarding instance, and routing information of the physical server node has been synchronized to the routing table through a route reflector connected to the computing node; Send the second virtual machine traffic to a target switch, and instruct the target switch to send the second virtual machine traffic to the physical server node, so that the virtual machine and the physical server node can achieve network intercommunication, wherein the target switch is connected to the physical server node, the route reflector, and the computing node respectively.

2. The network intercommunication method according to claim 1, wherein: Obtaining, through an agent component, an autonomous system number, a layer 2 virtual network identifier, and a layer 3 virtual network identifier corresponding to the virtual machine from a control node connected to the computing node, including: Monitoring the southbound database in the control node by the proxy component; When it is detected that the external identifier of the network port corresponding to the virtual machine is synchronized to the southbound database, the autonomous system number, the layer 2 virtual network identifier, and the layer 3 virtual network identifier are extracted from the external identifier, wherein the autonomous system number, the layer 2 virtual network identifier, and the layer 3 virtual network identifier are added to the external identifier by the driver component in the control node when the network port is created.

3. The network intercommunication method according to claim 1, wherein: After establishing a first preset protocol tunnel between the computing node and the route reflector according to the autonomous system number and the preset protocol through a free-range routing instance, the method further includes: Synchronizing the routing information of the virtual machine to the route reflector through the first preset protocol tunnel, so as to synchronize the routing information of the virtual machine to the target switch through the route reflector; and Synchronize the routing information in the route reflector to the routing table corresponding to the first virtual routing and forwarding instance through the first preset protocol tunnel, wherein the routing information in the route reflector includes routing information of the physical server node.

4. The network intercommunication method according to claim 1, wherein: After configuring the target component in the first virtual routing and forwarding instance using the layer-2 virtual network identifier and the layer-3 virtual network identifier, the method further includes: receiving, through the first virtual routing and forwarding instance, physical server traffic sent by the physical server node; sending the physical server traffic to the open virtual switch via the virtual Ethernet pair; When it is determined that the destination node of the physical server traffic is the virtual machine, the physical server traffic is sent to the virtual machine through the open virtual switch.

5. The network intercommunication method according to claim 1, wherein: Sending the second virtual machine traffic to a target switch, and instructing the target switch to send the second virtual machine traffic to the physical server node, so that the virtual machine and the physical server node achieve network intercommunication, includes: Sending the second virtual machine traffic to the target switch via the first virtual routing and forwarding instance; The target switch is instructed to send the second virtual machine traffic to the physical server node through a second virtual routing and forwarding instance in the target switch, so that the virtual machine and the physical server node achieve network intercommunication.

6. The network intercommunication method according to claim 5, characterized in that: Instructing the target switch to send the second virtual machine traffic to the physical server node through a second virtual routing and forwarding instance in the target switch, comprising: Instruct the target switch to parse a target virtual network identifier corresponding to the second virtual machine traffic, wherein the target virtual network identifier includes one of the following: a layer 2 virtual network identifier corresponding to the virtual machine, or a layer 3 virtual network identifier corresponding to the virtual machine; Instructing the second virtual routing and forwarding instance to determine a tenant network identifier corresponding to the physical server node based on the target virtual network identifier; Instruct the second virtual routing and forwarding instance to send the second virtual machine traffic to the physical server node through the tenant network identifier.

7. The network intercommunication method according to claim 5, characterized in that: Before obtaining the second virtual machine traffic by performing route matching on the first virtual machine traffic using the routing table corresponding to the first virtual route and forwarding instance, the method further includes: Instructing the target switch to create the second virtual routing and forwarding instance; Instruct the target switch to establish a second preset protocol tunnel between the target switch and the route reflector through the second virtual routing and forwarding instance and the preset protocol, and instruct the target switch to synchronize routing information with the route reflector through the second preset protocol tunnel.

8. A network intercommunication system, characterized in that: include: a computing node, configured to, when the destination node of the first virtual machine traffic is a physical server node, perform route matching on the first virtual machine traffic using a routing table corresponding to a first virtual routing and forwarding instance to obtain second virtual machine traffic, and send the second virtual machine traffic to a destination switch, wherein the computing node includes: a virtual machine that outputs the first virtual machine traffic and the first virtual routing and forwarding instance, and routing information of the physical server node has been synchronized to the routing table via a route reflector connected to the computing node; The target switch is connected to the physical server node, the route reflector and the computing node respectively, and is used to send the second virtual machine traffic to the physical server node. Wherein, the system further comprises: a control node connected to the computing node; The computing node also includes: a proxy component and a free range routing instance; The agent component is configured to obtain the autonomous system number, the layer 2 virtual network identifier, and the layer 3 virtual network identifier corresponding to the virtual machine from the control node; The free range routing instance is used to establish a first preset protocol tunnel between the computing node and the route reflector according to the autonomous system number and the preset protocol, The computing node further includes: the first virtual routing and forwarding instance created according to the Layer 3 virtual network identifier, and a virtual Ethernet pair established between a first bridging device and a second bridging device, wherein the first bridging device is a bridging device corresponding to the first virtual routing and forwarding instance, and the second bridging device is a bridging device corresponding to an open virtual switch; The first virtual routing and forwarding instance includes: a target component, the target component including: a layer 2 port and a layer 3 port corresponding to a layer 2 bridging device and a layer 3 bridging device, respectively, wherein the target component is configured in the first virtual routing and forwarding instance through the layer 2 virtual network identifier and the layer 3 virtual network identifier, and the layer 2 port and the layer 3 port are both used to transmit the first virtual machine traffic.

9. The network intercommunication system according to claim 8, characterized in that: The control node further includes: a southbound database and a driver component; the driver component is configured to add the autonomous system number, the layer 2 virtual network identifier, and the layer 3 virtual network identifier to the external identifier of the network port when the network port corresponding to the virtual machine is created; The agent component is further configured to monitor the southbound database in the control node, and extract the autonomous system number, the layer 2 virtual network identifier, and the layer 3 virtual network identifier from the external identifier when detecting that the external identifier is synchronized to the southbound database.

10. The network intercommunication system according to claim 8, characterized in that: The computing node is further configured to synchronize the routing information of the virtual machine to the route reflector through the first preset protocol tunnel; The route reflector is configured to synchronize the routing information of the virtual machine to the target switch; The computing node is further configured to synchronize the routing information in the route reflector to the routing table corresponding to the first virtual routing and forwarding instance through the first preset protocol tunnel, wherein the routing information in the route reflector includes routing information of the physical server node.

11. The network intercommunication system according to claim 8, characterized in that: The computing node is further configured to receive physical server traffic sent by the physical server node through the first virtual routing and forwarding instance; The computing node is further configured to send the physical server traffic to the open virtual switch via the virtual Ethernet pair; The computing node is further configured to, when determining that the destination node of the physical server traffic is the virtual machine, send the physical server traffic to the virtual machine through the open virtual switch.

12. The network intercommunication system according to claim 8, characterized in that: The computing node is further configured to send the second virtual machine traffic to the target switch via the first virtual routing and forwarding instance; The target switch further includes: a second virtual routing and forwarding instance, configured to send the second virtual machine traffic to the physical server node, so that the virtual machine and the physical server node can achieve network intercommunication.

13. The network intercommunication system according to claim 12, characterized in that: The target switch is further configured to parse a target virtual network identifier corresponding to the second virtual machine traffic, wherein the target virtual network identifier includes one of the following: a layer 2 virtual network identifier corresponding to the virtual machine, or a layer 3 virtual network identifier corresponding to the virtual machine; The second virtual routing and forwarding instance is further used to determine the tenant network identifier corresponding to the physical server node based on the target virtual network identifier; and send the second virtual machine traffic to the physical server node through the tenant network identifier.

14. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the network intercommunication method according to any one of claims 1 to 7 when executing the computer program.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the network intercommunication method according to any one of claims 1 to 7.

16. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the network intercommunication method according to any one of claims 1 to 7 are implemented.

Images