A cloud-on-cloud two-layer network intercommunication system and method

Abstract

The application relates to the technical field of network communication, in particular to a cloud-on-cloud and cloud-under two-layer network intercommunication system and method. The system comprises a cloud-on VPC module and a cloud-under IDC module connected through a tunnel module; the cloud-on VPC module comprises a cloud-on subnet unit and an L2GW network element, the cloud-on subnet unit is used for providing a cloud-on network environment for a cloud-on host; the cloud-under IDC module comprises a cloud-under subnet unit, the cloud-under subnet unit is used for providing a cloud-under network environment for a cloud-under host; the L2GW network element is connected with the cloud-on host through an L2-Connection port, and is used for processing two-layer communication events between the cloud-on host and the cloud-under host. The L2GW network element is used for realizing direct connection of the cloud-on network and the cloud-under network at the data link layer, maintaining the continuity of the network and the consistency of the broadcast domain, and enhancing the flexibility and expandability of the cloud-under service.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network communication, in particular to a cloud-on-cloud two-layer network intercommunication system and method. BACKGROUND

[0002] With the development of cloud computing technology, more and more enterprises choose to migrate their businesses to the cloud. However, many enterprises have established their own IDC (Internet Data Center) facilities to provide services before considering moving to the cloud. When the enterprise wants to migrate part of the business to the cloud, it faces the problem of how to realize the intercommunication between the local IDC and the cloud VPC (Virtual Private Cloud).

[0003] The traditional intercommunication method is to build a VPN (Virtual Private Network) or DC (Data Center) between the user's cloud IDC subnet and the cloud VPC subnet to establish a three-layer connection. This three-layer connection method solves the demand of cloud-on-cloud intercommunication to a certain extent. The three-layer access method is based on IP address for addressing, which requires that the subnet segments of the cloud IDC subnet and the cloud VPC subnet cannot overlap. If the segments overlap, a large amount of manpower is required to physically modify the IP address, delaying the user's cloud migration progress. In addition, using the traditional three-layer connection method, the hosts on the cloud and the cloud cannot realize non-sensing interaction, that is, the master and standby nodes can only be located on the cloud or on the cloud, and cannot realize the more flexible deployment method of master node on the cloud and standby node on the cloud, which limits the choice of enterprises when building high-availability businesses, and may lead to the business being unable to be effectively protected in the face of certain specific fault scenarios, affecting user experience and business stability.

[0004] In the above scheme, the traditional three-layer connection method through VPN or DC can realize basic cloud-on-cloud intercommunication, but there are problems such as segment limitation and inflexible host interaction, which brings many inconveniences to enterprise users when migrating to the cloud. SUMMARY

[0005] Therefore, the present application provides a cloud-on-cloud two-layer network intercommunication system and method to solve the problems of the traditional three-layer connection method through VPN or DC, such as segment limitation and inflexible host interaction, which brings many inconveniences to enterprise users when migrating to the cloud.

[0006] In a first aspect, the present application provides a cloud-on-cloud two-layer network intercommunication system, which comprises a cloud VPC module and a cloud IDC module connected through a tunnel module.

[0007] The cloud VPC module comprises a cloud subnet unit and an L2GW network element, and the cloud subnet unit is used to provide a cloud network environment for the cloud host in the cloud VPC module.

[0008] The cloud IDC module comprises a cloud offline subnet unit, which is configured to provide a cloud offline network environment for cloud offline hosts in the cloud IDC module; and a cloud online subnet unit is connected with the cloud offline subnet unit through the tunnel module;

[0009] The L2GW network element is connected with cloud online hosts in the cloud online VPC module through an L2-Connection port, and is configured to process a layer 2 communication event between the cloud online hosts and the cloud offline hosts.

[0010] In an optional embodiment, the cloud online subnet unit comprises a tunnel subnet and a first connection subnet, and the cloud online hosts are arranged in the first connection subnet;

[0011] The first connection subnet is configured to provide a connection network node for the cloud online hosts and other network devices, and the other network devices comprise the L2GW network element and the cloud offline hosts.

[0012] The tunnel subnet comprises an L2GW port, and is configured to carry the encapsulated data packet of the cloud online VPC module, so as to realize layer 2 network intercommunication between the cloud online hosts and the cloud offline hosts.

[0013] One end of the L2GW network element is connected with the cloud online hosts in the first connection subnet through the L2GW port and the L2-Connection port in sequence, and the other end of the L2GW network element is connected with the tunnel module through a VTEP port.

[0014] In an optional embodiment, the tunnel module comprises a VXLAN tunnel, and the VXLAN tunnel comprises a DC dedicated line and a VPN virtual private network line.

[0015] The other end of the L2GW network element is connected with the cloud offline IDC module through the VTEP port and the DC dedicated line in sequence.

[0016] The other end of the cloud online VPC module is also connected with the cloud offline IDC module through the VTEP port and the VPN virtual private network line in sequence.

[0017] In an optional embodiment, the cloud offline IDC module further comprises a switch unit, and the cloud offline subnet unit comprises a second connection subnet.

[0018] The second connection subnet is configured to provide a connection network node for the cloud offline hosts and other network devices, and the other network devices comprise the L2GW network element and the cloud online hosts.

[0019] Another end of the L2GW network element is connected to one end of the switch unit through the VTEP port and the DC dedicated line in sequence.

[0020] Another end of the cloud VPC module is also connected to one end of the switch unit through the VTEP port and the VPN virtual private network line in sequence.

[0021] Another end of the switch unit accesses the second connection subnet.

[0022] In an optional embodiment, the L2GW network element is deployed in a cluster mode, and a plurality of the L2GW network elements share one virtual IP address.

[0023] In a second aspect, the present application provides a cloud-to-cloud two-layer network intercommunication method, which is applied to a cloud-to-cloud two-layer network intercommunication system as described above, and the method comprises the following steps:

[0024] When the cloud host communicates, a first data packet is sent to the L2GW network element, and the first data packet comprises a virtual IP address of the L2GW network element, an IP address of the cloud host, a MAC address of the cloud host, an IP address of the cloud host and a MAC address of the L2-Connection Port port;

[0025] When the L2GW network element receives the first data packet, a virtual IP address of a VGW virtual gateway, VTEP port information and tunnel subnet information of the cloud host are added to the first data packet to obtain a second data packet, and the second data packet is forwarded to a tunnel module;

[0026] When the tunnel module receives the second data packet, VNI identifier information and VTEP port information of the user dedicated line are added to the second data packet to obtain a third data packet after encapsulation, and the third data packet is subjected to VXLAN tunnel analysis processing and transmitted to the cloud host;

[0027] When the cloud host receives the third data packet subjected to the VXLAN tunnel analysis processing, the third data packet subjected to the VXLAN tunnel analysis processing is subjected to reverse-process decapsulation processing through the tunnel module and the L2GW network element in sequence, so that the cloud host obtains a target data packet subjected to decapsulation.

[0028] In an optional embodiment, the reverse-process decapsulation processing comprises:

[0029] The VNI identifier information and the VTEP port information of the user dedicated line in the third data packet subjected to the VXLAN tunnel analysis processing are removed through the tunnel module to obtain a fourth data packet;

[0030] The target data packet is obtained by removing the tunnel subnet information and the virtual IP address of the VGW virtual gateway from the L2GW network element, and then the target data packet is sent to the cloud host.

[0031] In one optional implementation, the L2GW network element is used to learn ARP information of cloud-based hosts and on-premises hosts, and the method further includes:

[0032] When the on-premises host communicates with the cloud host, the on-premises host sends a first ARP request to the L2GW network element;

[0033] After receiving the first ARP request, the L2GW network element performs a proxy response to the first ARP request and provides the MAC address of the cloud host to the on-premises host, so that the on-premises host can communicate with the cloud host based on the MAC address of the cloud host.

[0034] When the cloud host communicates with the on-premises host, the cloud host sends a second ARP request to the L2GW network element; the source MAC address of the second ARP request is the MAC address of the L2-Connection port of the first connection subnet where the cloud host is located;

[0035] After receiving the second ARP request, if the ARP table of the L2GW network element does not contain an entry for the on-premises host corresponding to the second ARP request, then the L2GW network element will send the second ARP request to the on-premises host.

[0036] After receiving the second ARP request, the on-premises host sends its MAC address to the L2GW network element for the L2GW network element to learn.

[0037] The L2GW network element sends the learned MAC address of the on-premises host to the cloud host, so that the cloud host can communicate with the on-premises host based on the MAC address of the on-premises host.

[0038] In one optional implementation, the L2GW network element processes Layer 2 communication events between the cloud host and the on-premises host based on the HAVIP service, and the method further includes:

[0039] When both the primary and backup nodes of the HAVIP service are deployed on the cloud VPC module, if a switch between the primary and backup nodes is performed, the local table of the L2GW network element is updated through the controller in the cloud VPC module, and the ARP information synchronization operation of the on-premises host is triggered.

[0040] When the master node and the backup node are both deployed on the IDC module under the cloud, if the master node and the backup node are switched, the host under the cloud sends ARP information to the L2GW network element, and the host on the cloud updates the flow table of the host on the cloud and the local table of the L2GW network element;

[0041] When the master node is deployed on the VPC module on the cloud, and the backup node is deployed on the IDC module under the cloud, if the master node and the backup node are switched, the host under the cloud sends ARP information to the L2GW network element to update the ARP table of the L2GW network element, and the host on the cloud updates the flow table of the host on the cloud and the local table of the L2GW network element;

[0042] When the master node is deployed on the IDC module under the cloud, and the backup node is deployed on the VPC module on the cloud, if the master node and the backup node are switched, the host on the cloud updates the flow table of the host on the cloud and the ARP table of the L2GW network element, and the L2GW network element sends ARP information to refresh the ARP table of the host under the cloud.

[0043] In a third aspect, the present application provides a computer device, comprising: a memory and a processor, which are connected to each other in communication, and the memory stores computer instructions, and the processor executes the computer instructions to perform the cloud and under-cloud two-layer network intercommunication method of the first aspect or any of the corresponding embodiments thereof.

[0044] In a fourth aspect, the present application provides a computer readable storage medium, which stores computer instructions, and the computer instructions are used to make a computer perform the cloud and under-cloud two-layer network intercommunication method of the first aspect or any of the corresponding embodiments thereof.

[0045] In a fifth aspect, the present application provides a computer program product, which comprises computer instructions, and the computer instructions are used to make a computer perform the cloud and under-cloud two-layer network intercommunication method of the first aspect or any of the corresponding embodiments thereof.

[0046] The technical solution provided by the present application can include the following beneficial effects:

[0047] The cloud-on-cloud two-layer network intercommunication system is designed based on the L2GW network element, organically combines components such as a VPC, a tunnel, and an IDC, clearly plans the connection relationship and data flow direction among the components, and provides a reliable architecture reference for building an integrated cloud-on-cloud network for an enterprise. The L2GW network element allows direct connection of the cloud-on-cloud network at the data link layer, users can migrate the service of the IDC in the cloud to the cloud without changing the existing network configuration, while maintaining the continuity of the network and the consistency of the broadcast domain, eliminating the interruption in the migration process, reducing the complexity and cost of the migration, allowing users to seamlessly use the cloud resources and services, enhancing the flexibility and scalability of the cloud service, allowing wider network connection and resource sharing, and improving the efficiency and performance of the network.

[0048] The L2GW network element is deployed in a cluster mode, a plurality of L2GW network elements provide a virtual IP externally, improve the stability of the L2GW network element, the traffic is switched to the backup node when the master node fails or upgrades, and the ARP information synchronization mechanism is used to reduce the ARP information loss and packet loss in the master / backup switching process, and further enhance the high availability of the system at the two-layer communication level. The L2GW network element realizes subnet intercommunication at the data link layer, allows the cloud-on-cloud network segments to overlap, the user-side IDC does not need to modify the IP address, avoids the tedious IP address modification work, reduces the threshold for cloud migration, and improves the efficiency of network deployment and management. Based on the function of the L2GW network element, efficient two-layer communication of the cloud-on-cloud host is realized, the L2GW network element is responsible for ARP learning and information storage and maintenance, cooperates with the encapsulation and decapsulation mechanism of the data packet, and cooperates with the HAVIP service to ensure accurate forwarding of the data packet in the two-layer network, and improve the communication efficiency and quality. BRIEF DESCRIPTION OF DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the specific embodiments or the prior art, the drawings needed in the specific embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0050] Figure 1 is a structural schematic diagram of a cloud-on-cloud two-layer network intercommunication system according to an embodiment of the present application;

[0051] Figure 2 is a flowchart of a cloud-on-cloud two-layer network intercommunication method according to an embodiment of the present application;

[0052] Figure 3is a cloud-on-cloud host communication forwarding schematic diagram according to an embodiment of the present application;

[0053] Figure 4 is a hardware structure schematic diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0054] To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0055] It should be noted that the present embodiment designs a new gateway L2GW, and designs an L2-Connection port and a connection subnet for communicating and connecting between a subnet and the L2GW network element, and connects an Internet data center (IDC) under a user side cloud through a data center (DC) or a virtual private network (VPN) and the like laid VXLAN line, thereby solving the problem of data link layer subnet intercommunication between the cloud and the cloud under the user. The user does not have to care about the actual cloud or cloud under which the machine is located when performing any operation, and can allow the user to manage the machine on the cloud as in a traditional subnet, and can realize keepalived (a software tool for realizing high availability, which can realize functions such as fault switching between master and standby nodes) to build a high-availability cluster, and the master node is on the cloud, and the standby node is under the cloud. And the cloud and the cloud segment can overlap, and the Internet data center (IDC) under the user side cloud does not need to modify the IP address, and the user can migrate the data center or the private cloud host service part to the cloud without changing the subnet and IP planning, thereby expanding the broadcast domain. The cloud experience of the customer is greatly improved.

[0056] In the present embodiment, a cloud-on-cloud two-layer network intercommunication system is provided, Figure 1 is a structure schematic diagram of a cloud-on-cloud two-layer network intercommunication system according to an embodiment of the present application, as Figure 1 shown, the system comprises a cloud-on-VPC module and a cloud-under-IDC module connected through a tunnel module;

[0057] The cloud-on-VPC module comprises a cloud-on-subnet unit and an L2GW network element, and the cloud-on-subnet unit is configured to provide a cloud-on-network environment for a cloud-on-host in the cloud-on-VPC module;

[0058] The cloud IDC module comprises a cloud offline subnet unit, which is configured to provide a cloud offline network environment for cloud offline hosts in the cloud IDC module; and the cloud online subnet unit is connected with the cloud offline subnet unit through the tunnel module;

[0059] The L2GW network element is connected with the cloud online hosts in the cloud online VPC module through an L2-Connection port, and is configured to process a layer 2 communication event between the cloud online hosts and the cloud offline hosts.

[0060] In an optional embodiment, the cloud online subnet unit comprises a tunnel subnet and a first connection subnet, and the cloud online hosts are arranged in the first connection subnet;

[0061] The first connection subnet is configured to provide a connection network node for the cloud online hosts and other network devices, and the other network devices comprise the L2GW network element and the cloud offline hosts.

[0062] The tunnel subnet comprises an L2GW port, and is configured to carry the encapsulated data packets of the cloud online VPC module to realize layer 2 network intercommunication between the cloud online hosts and the cloud offline hosts.

[0063] One end of the L2GW network element is connected with the cloud online hosts in the first connection subnet through the L2GW port and the L2-Connection port in sequence, and the other end of the L2GW network element is connected with the tunnel module through a VTEP port.

[0064] In an optional embodiment, the tunnel module comprises a VXLAN tunnel, and the VXLAN tunnel comprises a DC dedicated line and a VPN virtual private network line.

[0065] The other end of the L2GW network element is connected with the cloud offline IDC module through the VTEP port and the DC dedicated line in sequence.

[0066] The other end of the cloud online VPC module is also connected with the cloud offline IDC module through the VTEP port and the VPN virtual private network line in sequence.

[0067] In an optional embodiment, the cloud offline IDC module further comprises a switch unit, and the cloud offline subnet unit comprises a second connection subnet.

[0068] The second connection subnet is configured to provide a connection network node for the cloud offline hosts and other network devices, and the other network devices comprise the L2GW network element and the cloud online hosts.

[0069] The other end of the L2GW network element is connected with one end of the switch unit through the VTEP port and the DC dedicated line in sequence.

[0070] The other end of the cloud VPC module is further connected with one end of the switch unit through the VTEP port, the VPN virtual private network line and the switch unit in sequence;

[0071] The other end of the switch unit accesses the second connection subnet.

[0072] In an optional embodiment, the L2GW network element is deployed in a cluster mode, and a plurality of the L2GW network elements share one virtual IP address.

[0073] Further, as shown in Figure 1 The system structure of the embodiment is implemented by referring to the classic computer network design idea of layered encapsulation to realize the layer 2 intercommunication between the cloud and the IDC, and the system is divided into three parts, a cloud VPC module, a tunnel module and a cloud IDC module. The cloud VPC module is composed of two parts, Figure 1 The left first part of the cloud VPC module is a cloud subnet unit, which is mainly composed of a tunnel subnet and a first connection subnet. The right part is an L2GW network element deployed on a host in the cloud. The cloud IDC module is a network on the user side, which is composed of various switches and a second connection subnet. The part connecting the cloud VPC module and the cloud IDC module is the tunnel module (i.e. the VXLAN tunnel), which is realized by a DC dedicated line or a VPN virtual private network line.

[0074] Further, the cloud VPC module (Virtual Private Cloud) is located in Figure 1The left side of the upper part of the figure is a cloud VPC module, and the network segment of the VPC is marked as 192.168.0.0 / 16. The cloud subnet unit of the cloud VPC module includes a first connection subnet and a tunnel subnet. The network segment of the first connection subnet is 192.168.2.0 / 24, which is used to connect the L2GW host and other components. The first connection subnet includes a plurality of cloud hosts and L2-Connection port ports, and the cloud hosts and the L2-Connection port ports are in one-to-one correspondence. The network segment of the tunnel subnet is 192.168.6.0 / 24, which is used for data transmission through a VXLAN tunnel (Virtual eXtensible Local Area Network). The tunnel subnet includes an L2GW port port. The right side of the cloud subnet unit is an L2gwmachine (L2GW host), that is, an L2GW network element, which is used to realize the connection between the cloud and the cloud in the data link layer. The L2GW network element is deployed on the cloud and is connected to the first connection subnet through the L2GW port port and the L2-Connection port in turn. The right side of the L2GW network element is a VGW (Virtual Gateway), which is used to connect the cloud host and the cloud host. The right side of the VGW is a VXLAN tunnel (Virtual Extensible LAN), which is used to establish a layer 2 network tunnel between the cloud VPC module and the cloud IDC module, and the tunnel is realized through DC (data center interconnection) or VPN (virtual private network). Figure 1 The rightmost side of the figure is a cloud IDC module (Internet Data Center), and the network segment is marked as 192.168.2.0 / 24. The cloud IDC module includes a VXLAN switch, a subnet switch, and a second connection subnet. The VXLAN switch is used to establish VXLAN tunnels in the cloud IDC module. These tunnels are connected to the VXLAN tunnels of the cloud VPC module through DC (data center interconnection) or VPN (virtual private network). The subnet switch is a core device in the cloud IDC network, which is used to connect and manage the communication between different subnets. The network segment of the second connection subnet is 192.168.2.0 / 24, which has the same IP address range as the second connection subnet of the cloud VPC module, so that the cloud and the cloud can have overlapping network segments.

[0075] Further, through such an architecture, the embodiment realizes the data link layer subnet interconnection between the cloud and the cloud, and has the advantages of network segment overlap, no need to modify the IP address, etc. It is convenient for users to migrate data center or private cloud host business to the cloud without changing the subnet and IP planning.

[0076] In summary, this embodiment presents a Layer 2 network interconnection system for cloud and on-premises networks designed based on L2GW network elements. It organically integrates cloud VPCs, tunnels, and on-premises IDCs, clearly defining the connection relationships and data flow between these components. This provides a reliable architectural reference for enterprises building integrated cloud and on-premises networks. L2GW network elements allow direct connectivity between cloud and on-premises networks at the data link layer. Users can migrate on-premises data center (IDC) services to the cloud without altering existing network configurations, while maintaining network continuity and broadcast domain consistency. This eliminates interruptions during migration, reduces migration complexity and cost, and allows users to seamlessly utilize cloud resources and services. It enhances the flexibility and scalability of on-premises services, allows for broader network connectivity and resource sharing, and improves network efficiency and performance.

[0077] In this embodiment, the L2GW network elements are deployed in a cluster. Multiple L2GW network elements provide a single virtual IP address, improving their stability. When the primary node fails or is upgraded, traffic switches to the backup node. Mechanisms such as ARP information synchronization reduce ARP information loss and packet loss during the switchover process, further enhancing the system's high availability at the Layer 2 communication layer. This embodiment achieves subnet interconnection at the data link layer using L2GW network elements, allowing overlapping of cloud and on-premises network segments. User-side IDCs do not need to modify IP addresses, avoiding cumbersome IP address modification work, lowering the barrier to cloud adoption, and improving network deployment and management efficiency. Based on the functionality of L2GW network elements, this embodiment achieves efficient Layer 2 communication between cloud and on-premises hosts. The L2GW network elements are responsible for ARP learning and information storage maintenance. Combined with packet encapsulation and decapsulation mechanisms, and collaboration with the HAVIP service, it ensures accurate packet forwarding in the Layer 2 network, improving communication efficiency and quality.

[0078] According to an embodiment of the present invention, a method for interoperability between cloud and on-premises Layer 2 networks is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0079] This embodiment provides a method for interoperability between cloud and on-premises Layer 2 networks, which can be applied to, for example... Figure 1 The above-cloud and on-premises two-layer network interconnection system shown is as follows: Figure 2 This is a flowchart of a method for interoperability between cloud and on-premises Layer 2 networks according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0080] In step S201, when communicating with the cloud host, the first data packet is sent to the L2GW network element. The first data packet includes the virtual IP address of the L2GW network element, the IP address of the cloud host, the MAC address of the cloud host, the IP address of the on-premises host, and the MAC address of the L2-Connection Port.

[0081] Furthermore, when a cloud host needs to communicate with an on-premises host, it constructs and sends a first data packet to the L2GW network element. This first data packet contains the following information: the virtual IP address of the L2GW network element, used to identify the initial sending point of the data packet; the IP address of the cloud host, used to identify the source of the data packet; the MAC address of the cloud host, used to identify the source hardware address of the data packet; the IP address of the on-premises host, used to identify the final destination of the data packet; and the MAC address of the L2-Connection Port, used to route the data packet within the cloud network. Since the cloud subnet unit includes multiple cloud hosts, and the on-premises subnet unit includes multiple on-premises hosts, the cloud host in step S201 can be any cloud host in the cloud subnet unit, and the on-premises host can be any on-premises host in the on-premises subnet unit.

[0082] Step S202: When the L2GW network element receives the first data packet, it adds the virtual IP address of the VGW virtual gateway, the VTEP port information of the on-premises host, and the tunnel subnet information to the first data packet to obtain the second data packet, and forwards the second data packet to the tunnel module.

[0083] Furthermore, after receiving the first data packet, the L2GW network element processes it to form a second data packet, which is then forwarded to the tunnel module. This processing includes adding the following information: the virtual IP address of the VGW (Virtual Gateway), used for routing within the on-premises network; the VTEP (VXLAN Tunnel Endpoint) port information of the on-premises host, identifying the endpoint of the VXLAN tunnel; and tunnel subnet information, used for routing data packets within the VXLAN tunnel.

[0084] Step S203: When the tunnel module receives the second data packet, it adds the VNI identifier information and VTEP port information of the user leased line to the second data packet, and after encapsulation, it obtains the third data packet. The third data packet is then processed by VXLAN tunnel parsing and transmitted to the host under the cloud.

[0085] Furthermore, after receiving the second data packet, the tunnel module processes it further, encapsulates it to obtain the third data packet, and then performs VXLAN tunnel parsing processing before transmitting it to the on-premises host through the VXLAN tunnel. This processing includes adding the following information: the VNI (VXLAN Network Identifier) ​​identifier information of the user's leased line, used to distinguish different VXLAN networks; and VTEP port information, used for VXLAN tunnel routing.

[0086] In step S204, when the host in the cloud receives the third data packet after VXLAN tunnel parsing, it sequentially performs the reverse decapsulation process on the third data packet after VXLAN tunnel parsing through the tunnel module and the L2GW network element, so that the host in the cloud obtains the decapsulated target data packet.

[0087] Furthermore, after the on-premises host receives the third data packet after VXLAN tunnel parsing, it will perform decapsulation processing. The cloud host then obtains the decapsulated target data packet, completing the Layer 2 network interconnection between the cloud and the on-premises host. The decapsulation process includes: removing the VXLAN tunnel encapsulation through the tunnel module to restore the original data packet; and further decapsulation through the L2GW network element to remove the virtual IP address, VTEP port information, and tunnel subnet information of the VGW virtual gateway.

[0088] In one alternative implementation, the decapsulation process of the reverse procedure includes:

[0089] The tunnel module removes the VNI identifier information and VTEP port information of the user's leased line from the third data packet after VXLAN tunnel parsing and processing, thus obtaining the fourth data packet.

[0090] The tunnel subnet information and the virtual IP address of the VGW virtual gateway in the fourth data packet are removed by the L2GW network element to obtain the target data packet, and the target data packet is sent to the cloud host.

[0091] Furthermore, when the on-premises host receives the third data packet transmitted through the VXLAN tunnel, the tunnel module first performs a decapsulation operation. The main purpose of this step is to remove the information added during data transmission through the VXLAN tunnel. The tunnel module needs to remove the VNI identifier information and VTEP port information of the user's leased line from the third data packet. The VNI identifier information is used to distinguish different virtual networks in the VXLAN tunnel, and this information is no longer needed after the data arrives at the on-premises host. The VTEP port information is used when processing data at the virtual tunnel endpoint, and it needs to be removed at the receiving end of the tunnel module. After the tunnel module removes this information, the third data packet becomes the fourth data packet. The fourth data packet obtained after decapsulation by the tunnel module still needs to be further decapsulated by the L2GW network element to restore the data originally sent from the cloud host. The L2GW network element needs to remove the tunnel subnet information and the virtual IP address of the VGW virtual gateway from the fourth data packet. The tunnel subnet information is added when the L2GW network element forwards data to the tunnel module, ensuring correct data transmission within the tunnel subnet. The virtual IP address of the VGW virtual gateway is added after the L2GW network element receives the first data packet, ensuring correct data routing to the VGW. This information needs to be removed when the data returns to the cloud host. After the L2GW network element removes this information, the fourth data packet becomes the target data packet. Finally, the L2GW network element sends the target data packet to the cloud host, completing the reverse decapsulation process of data transmission between the cloud and on-premises systems, enabling the cloud host to receive the original data. Through this decapsulation process, when data returns from the on-premises host to the cloud host, various network-related information added during transmission is sequentially removed, restoring the original data and ensuring the accuracy and integrity of data transmission between the cloud and on-premises Layer 2 networks.

[0092] For further details, please see Figure 3 The diagram illustrates cloud-to-on-premises host communication forwarding. This embodiment is built upon the L2GW network element to achieve cloud-to-on-premises host communication. Packets 1, 2, and 3 represent the cloud-to-on-premises packet encapsulation process, while packets 3, 4, and 5 represent the traditional VXLAN packet parsing process. Packets 6-10 represent the reverse process. Packet 1 primarily contains the virtual IP address of the L2GW network element cluster, the IP and MAC addresses of VM1 and VM2, and the transit port MAC (L2-connection port). After being sent to the L2GW network element, packet 1 becomes packet 2, adding VGW VIP, on-premises IDC VTEP information, tunnel subnet information, etc. Packet 3 adds user leased line VNI, VTEP, etc. Through this encapsulation and decapsulation process, the leased line completes the final layer of encapsulation, and in conjunction with the ARP information stored in the L2GW network element, cloud-to-on-premises interoperability is achieved. In other words,Figure 3 The cloud packet processing flow (including packets 1, 2, and 3) is as follows: Packet 1 mainly contains the virtual IP address of the L2GW network element cluster, the IP address and MAC address of the cloud host VM1, the IP address of the on-premises host VM2, and the transit port MAC address (L2-connection port). Packet 1 is the initial data packet sent from the cloud host VM1, carrying the necessary information to identify the source host, destination host, and transit port. When packet 1 is sent to the L2GW network element, it becomes packet 2. Packet 2 adds information such as the VGW (Virtual Gateway) VIP (Virtual IP address), the on-premises IDC module's VTEP (Virtual Tunnel Endpoint) information, and the tunnel subnet to packet 1. This added information allows the data packet to pass through the VGW and tunnel subnet, preparing it for entry into the VXLAN tunnel. Packet 2 is further processed into packet 3. Packet 3 adds information such as the user leased line VNI (Virtual Network Identifier) ​​and VTEP to packet 2. By adding this information, packet 3 can be transmitted through the VXLAN tunnel on the user leased line. Next, the traditional VXLAN packet parsing process (including packets 3, 4, and 5) begins. Packet 3, generated during the preceding cloud-based packet encapsulation process, contains all the information required for transmission through the VXLAN tunnel. Once packet 3 enters the VXLAN tunnel, it undergoes the traditional VXLAN packet parsing process, involving decapsulation and forwarding of the data packets within the VXLAN tunnel, transmitting the packets from the cloud host to the on-premises host. Finally, the reverse process (including packets 6-10) begins. Upon arrival at the on-premises host, a series of reverse operations are performed to restore the data packets to a format recognizable by the cloud host VM1 for communication. Packets 6-10 represent the reverse of the previous encapsulation process, involving the removal of user leased line VNI, VTEP information, tunnel subnet information, VGWVIP, etc., added during the cloud-based packet encapsulation process, ultimately restoring the original information of packet 1.

[0093] In one optional implementation, the L2GW network element is used to learn ARP information of cloud-based hosts and on-premises hosts, and the method further includes:

[0094] When the host under the cloud communicates with the host on the cloud, the host under the cloud sends the first ARP request to the L2GW network element;

[0095] After receiving the first ARP request, the L2GW network element performs a proxy response to the first ARP request and provides the MAC address of the cloud host to the on-premises host so that the on-premises host can communicate with the cloud host based on the MAC address of the cloud host.

[0096] When the cloud host communicates with the on-premises host, the cloud host sends a second ARP request to the L2GW network element; the source MAC address of the second ARP request is the MAC address of the L2-Connection port of the first connection subnet where the cloud host is located;

[0097] After receiving the second ARP request, if the L2GW network element does not have an ARP entry for the on-premises host corresponding to the second ARP request in its ARP table, then the L2GW network element will send the second ARP request to the on-premises host.

[0098] After receiving the second ARP request, the host under the cloud sends its MAC address to the L2GW network element so that the L2GW network element can learn it.

[0099] The L2GW network element will send the learned MAC address of the on-premises host to the cloud host, so that the cloud host can communicate with the on-premises host based on the MAC address of the on-premises host.

[0100] Furthermore, the L2GW network element in this embodiment is also used for ARP learning and ARP information storage and maintenance for cloud-based and on-premises hosts. For the on-premises host learning ARP from the cloud host, the on-premises host sends an ARP request to the L2GW network element to answer the MAC address of the default gateway of the cloud subnet. For the cloud host learning ARP from the on-premises machine, the cloud host sends an ARP packet with the MAC address of the L2-connection port in its subnet as the src to the L2GW network element. If the L2GW network element receives this packet and does not have a corresponding ARP entry, it sends an ARP request to the on-premises machine to learn its real MAC address. For stability and robustness, the L2GW network element is deployed in a cluster, with multiple L2GW network elements providing a single virtual IP address. An ARP request from an L2GW network element might originate from machine A, but the received ARP response might be from machine B, causing ARP learning failure. To address this, only one master node is normally used for external service; when the master node fails or is upgraded, traffic is switched to the backup node. To prevent packet loss during primary / standby failover in upgrade or failure scenarios, due to significant ARP loss or relearning, the primary node synchronizes previously learned ARPs to the standby node. Simultaneously, the L2GW network element also has the function of sending free ARPs from the on-premises network to the cloud, and vice versa. This lays the foundation for achieving a high-availability VIP cluster across both the cloud and on-premises networks. In this embodiment, when an on-premises host needs to learn the ARPs of a cloud host, the on-premises host sends a first ARP request. The L2GW network element acts as a proxy in this process, replying with the MAC address of the default gateway of the cloud subnet (i.e., the MAC address of the cloud host). This allows the on-premises host to communicate with the cloud host by obtaining the default gateway's MAC address. When the cloud host sends a second ARP request, the source (src) address of the second ARP request is the MAC address of the L2-connectionport port in the subnet, and the second ARP request is sent to the L2GW network element. If the L2GW network element does not have a corresponding ARP entry when it receives the second ARP request, the L2GW network element will send a second ARP request to the on-premises host in order to learn the real MAC address of the on-premises host.

[0101] To ensure network stability and robustness, this embodiment deploys L2GW network elements in a cluster, with multiple L2GW elements presenting a single virtual IP address to provide redundancy and load balancing. Normally, only one master node in the L2GW network element cluster provides services to the outside world. This avoids potential problems when multiple nodes handle ARP requests simultaneously, such as sending an ARP request from machine A but receiving an ARP response from machine B, leading to ARP learning failure. When the master node fails or needs upgrading, traffic switches to the backup node. This ensures network service continuity. During master-slave failover, to prevent packet loss due to large amounts of lost or relearned ARPs, the master node synchronizes previously learned ARP information to the backup node. Thus, when the backup node becomes the master, it already possesses the necessary ARP information and can seamlessly take over network services. The L2GW network elements also have the function of forwarding gratuitous ARPs, sending gratuitous ARPs from on-premises to the cloud and vice versa. Free ARP is mainly used for functions such as address conflict detection in the network. Through forwarding by L2GW network elements, it helps to achieve highly available VIP clusters in both cloud and on-premises environments.

[0102] In one optional implementation, the L2GW network element processes Layer 2 communication events between the cloud host and the on-premises host based on the HAVIP service. The method further includes:

[0103] When both the primary and backup nodes of the HAVIP service are deployed on the cloud VPC module, if a switch is performed between the primary and backup nodes, the local table of the L2GW network element will be updated through the controller in the cloud VPC module, and the ARP information synchronization operation of the host under the cloud will be triggered.

[0104] When both the primary node and the backup node are deployed on the on-premises IDC module, if a switch is performed between the primary and backup nodes, the on-premises host will send ARP information to the L2GW network element, and the cloud host will update the flow table of the cloud host and the local table of the L2GW network element.

[0105] When the primary node is deployed on the cloud VPC module and the backup node is deployed on the cloud IDC module, if a switch is performed between the primary and backup nodes, the cloud host will send ARP information to the L2GW network element to update the ARP table of the L2GW network element, and the cloud host will update the flow table of the cloud host and the local table of the L2GW network element.

[0106] When the primary node is deployed on the on-premises IDC module and the backup node is deployed on the cloud VPC module, if a switch is performed between the primary and backup nodes, the cloud host updates the flow table of the cloud host and the ARP table of the L2GW network element, and the L2GW network element sends ARP information to refresh the ARP table of the on-premises host.

[0107] Furthermore, the VIP implementation is based on the HAVIP service. The HAVIP service enables heartbeat communication between the two hosts via keepalive and manages them through HAVIP. When HAVIP receives a gratuitous ARP packet from the master node, it detects the packet and initiates a master-slave switchover, simultaneously recording the master node's MAC and IP information, performing ARP replies, and sending gratuitous ARP broadcasts to all nodes in the broadcast domain. Based on the HAVIP principle, L2GW achieves communication between on-premises and cloud hosts. HAVIP is deployed in four scenarios across the on-premises IDC module and the cloud VPC module. In scenarios where both the master and slave are in the cloud, the controller detects the switchover status during master-slave switchover and updates the L2GW local table. To synchronize ARP information to the on-premises environment, the on-premises environment actively initiates an ARP request with the local subnet gateway MAC address as the src, requesting the cloud MAC address. The reason the on-premises environment doesn't use its own host MAC address is to avoid refreshing the on-premises ARP in scenarios where both the master and slave are in the cloud during HAVIP switchover. In scenarios where both the primary and backup nodes are located on-premises, during a switchover, gratuitous ARP requests are sent to the cloud, and the L2GW network element refreshes its existing ARP table based on these gratuitous ARP requests. If the primary node is in the cloud and the backup node is on-premises, during a switchover, the on-premises node sends gratuitous ARP requests to update the L2GW ARP port, and simultaneously reports the primary / slave status to the control node. The cloud compute node updates its flow table and the L2GW local table. In scenarios where the primary node is on-premises and the backup node is in the cloud, during a switchover, the flow table and the L2GW network element's ARP table are updated, and the L2GW network element sends gratuitous ARP requests to refresh the on-premises host's ARP table.

[0108] In other words, the implementation of the VIP (Virtual IP Address) in this embodiment relies on the HAVIP service independently developed by China Telecom Cloud, which plays a crucial role in the entire network architecture. The HAVIP service achieves heartbeat communication between two hosts (cloud-based and on-premises hosts) through a keepalive mechanism. This means periodically sending signals to detect host liveness and ensure normal connection status between hosts. Simultaneously, the HAVIP service manages relevant hosts, enabling centralized management. When the HAVIP service receives a gratuitous ARP packet from the master node, it detects this and performs a master-slave switchover. During this process, the HAVIP service also records the master node's MAC address and IP information. The HAVIP service performs ARP replies and sends gratuitous ARP broadcasts to all nodes within the broadcast domain. This ensures that other nodes in the network can promptly obtain relevant information after the master-slave switchover, guaranteeing normal network communication. L2GW network elements utilize the principles of the HAVIP service to achieve interoperability between cloud-based and on-premises hosts. The deployment of the HAVIP service includes the following four scenarios:

[0109] The first scenario involves a HAVIP service where both the primary and backup servers are in the cloud. When a master-slave switch occurs, the controller detects this switch and updates the L2GW local table accordingly. To synchronize ARP information to the on-premises environment, the on-premises host actively initiates an ARP request. The source (src) address of the ARP request is the MAC address of the local subnet gateway, not the MAC address of the on-premises host. This ensures that, in a HAVIP service switch scenario where both the primary and backup servers are in the cloud, the on-premises ARP table does not need to be refreshed, reducing network fluctuations and unnecessary operations.

[0110] The second scenario involves HAVIP services where both the primary and backup servers are located on-premises. During primary / backup failover, gratuitous ARP information is sent to the cloud. The L2GW network element refreshes its existing ARP table based on the received gratuitous ARP information to ensure that the L2GW network element can update network information in a timely manner and maintain the accuracy of on-premises and cloud communication.

[0111] The third scenario involves the HAVIP service where the primary node is in the cloud and the backup node is on-premises. When a master-slave switch occurs, the on-premises node sends gratuitous ARP messages to update the L2GW ARP port. Simultaneously, the master-slave status needs to be reported to the control node so that the cloud compute nodes can update the flow tables and the L2GW-local table ports. This ensures accurate network information updates and normal communication in complex master-slave cross-cloud environments.

[0112] The fourth scenario is the HAVIP service where the primary host is on-premises and the backup host is in the cloud. When a master-slave switch occurs, the flow table needs to be updated, and the ARP table of the L2GW network element also needs to be updated. Furthermore, the L2GW network element will send gratuitous ARP messages to refresh the ARP table of the on-premises host. Through these operations, normal communication and information updates are ensured across different master-slave distribution scenarios.

[0113] In summary, this embodiment presents a Layer 2 network interconnection system for cloud and on-premises networks designed based on L2GW network elements. It organically integrates cloud VPCs, tunnels, and on-premises IDCs, clearly defining the connection relationships and data flow between these components. This provides a reliable architectural reference for enterprises building integrated cloud and on-premises networks. L2GW network elements allow direct connectivity between cloud and on-premises networks at the data link layer. Users can migrate on-premises data center (IDC) services to the cloud without altering existing network configurations, while maintaining network continuity and broadcast domain consistency. This eliminates interruptions during migration, reduces migration complexity and cost, and allows users to seamlessly utilize cloud resources and services. It enhances the flexibility and scalability of on-premises services, allows for broader network connectivity and resource sharing, and improves network efficiency and performance.

[0114] In this embodiment, the L2GW network elements are deployed in a cluster. Multiple L2GW network elements provide a single virtual IP address, improving their stability. When the primary node fails or is upgraded, traffic switches to the backup node. Mechanisms such as ARP information synchronization reduce ARP information loss and packet loss during the switchover process, further enhancing the system's high availability at the Layer 2 communication layer. This embodiment achieves subnet interconnection at the data link layer using L2GW network elements, allowing overlapping of cloud and on-premises network segments. User-side IDCs do not need to modify IP addresses, avoiding cumbersome IP address modification work, lowering the barrier to cloud adoption, and improving network deployment and management efficiency. Based on the functionality of L2GW network elements, this embodiment achieves efficient Layer 2 communication between cloud and on-premises hosts. The L2GW network elements are responsible for ARP learning and information storage maintenance. Combined with packet encapsulation and decapsulation mechanisms, and collaboration with the HAVIP service, it ensures accurate packet forwarding in the Layer 2 network, improving communication efficiency and quality.

[0115] This invention also provides a computer device; please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 4As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 4 Take a processor 10 as an example.

[0116] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GPA), or any combination thereof.

[0117] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

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

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

[0120] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0121] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0122] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0123] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the defined scope.

Claims

1. A cloud-based and on-premises two-layer network interconnection system, characterized in that, The system includes: a cloud-based VPC module and an on-premises IDC module connected via a tunnel module; The cloud-based VPC module includes a cloud subnet unit and an L2GW network element. The cloud subnet unit is used to provide a cloud network environment for the cloud hosts in the cloud VPC module. The on-premises IDC module includes an on-premises subnet unit, which provides an on-premises network environment for the on-premises hosts in the on-premises IDC module; the cloud subnet unit is connected to the on-premises subnet unit through the tunnel module. The L2GW network element establishes a connection with the cloud host in the cloud VPC module through the L2-Connection port. The L2GW network element is used to process Layer 2 communication events between the cloud host and the on-premises host. The L2GW network elements are deployed in a cluster, and multiple L2GW network elements share a single virtual IP address. When the on-premises host communicates with the cloud host, the on-premises host sends a first ARP request to the L2GW network element; After receiving the first ARP request, the L2GW network element performs a proxy response to the first ARP request and provides the MAC address of the cloud host to the on-premises host, so that the on-premises host can communicate with the cloud host based on the MAC address of the cloud host. When the cloud host communicates with the on-premises host, the cloud host sends a second ARP request to the L2GW network element; the source MAC address of the second ARP request is the MAC address of the L2-Connection port of the first connection subnet where the cloud host is located; After receiving the second ARP request, if the ARP table of the L2GW network element does not contain an entry for the on-premises host corresponding to the second ARP request, then the L2GW network element will send the second ARP request to the on-premises host. After receiving the second ARP request, the on-premises host sends its MAC address to the L2GW network element for the L2GW network element to learn. The L2GW network element sends the learned MAC address of the on-premises host to the cloud host, so that the cloud host can communicate with the on-premises host based on the MAC address of the on-premises host.

2. The system according to claim 1, characterized in that, The cloud subnet unit includes a tunnel subnet and a first connection subnet, and the cloud host is located in the first connection subnet; The first connection subnet is used to provide network nodes for connecting the cloud host to other network devices; the other network devices include L2GW network elements and the on-premises host; The tunnel subnet includes an L2GW port, which is used to carry data packets encapsulated by the cloud VPC module to enable Layer 2 network communication between the cloud host and the on-premises host. One end of the L2GW network element establishes a connection with the cloud host in the first connection subnet through the L2GW port and the L2-Connection port in sequence, and the other end of the L2GW network element connects to the tunnel module through the VTEP port.

3. The system according to claim 2, characterized in that, The tunnel module includes a VXLAN tunnel; the VXLAN tunnel includes a dedicated DC line and a VPN virtual private network line. The other end of the L2GW network element is connected to the on-premises IDC module via the VTEP port and the DC dedicated line in sequence. The other end of the cloud-based VPC module is connected to the on-premises IDC module via the VTEP port and the VPN virtual private network line.

4. The system according to claim 3, characterized in that, The on-premises IDC module also includes a switch unit, and the on-premises subnet unit includes a second connection subnet; The second connection subnet is used to provide network nodes for connecting the on-premises host to other network devices; the other network devices include L2GW network elements and the on-premises host; The other end of the L2GW network element is connected to one end of the switch unit in sequence through the VTEP port and the DC dedicated line; The other end of the cloud-based VPC module is also connected to one end of the switch unit via the VTEP port and the VPN virtual private network line in sequence. The other end of the switch unit is connected to the second connection subnet.

5. A method for interoperability between cloud and on-premises Layer 2 networks, characterized in that, The method is applied to a cloud-on-premises Layer 2 network interconnection system as described in any one of claims 1 to 4, and the method includes: When communicating with the host in the cloud, the first data packet is sent to the L2GW network element. The first data packet includes the virtual IP address of the L2GW network element, the IP address of the host in the cloud, the MAC address of the host in the cloud, the IP address of the host on the cloud, and the MAC address of the L2-Connection Port. When the L2GW network element receives the first data packet, it adds the virtual IP address of the VGW virtual gateway, the VTEP port information of the on-premises host, and the tunnel subnet information to the first data packet to obtain the second data packet, and forwards the second data packet to the tunnel module; When the tunnel module receives the second data packet, it adds the VNI identifier information and VTEP port information of the user leased line to the second data packet, and after encapsulation, it obtains the third data packet. The third data packet is then processed by VXLAN tunnel parsing and transmitted to the on-premises host. When the host in the cloud receives the third data packet after VXLAN tunnel parsing, it sequentially performs the reverse decapsulation process on the third data packet after VXLAN tunnel parsing through the tunnel module and the L2GW network element, so that the host in the cloud obtains the decapsulated target data packet.

6. The method according to claim 5, characterized in that, The decapsulation process of the reverse process includes: The fourth data packet is obtained by removing the VNI identifier information and VTEP port information of the user leased line from the third data packet after VXLAN tunnel parsing processing by the tunnel module; The target data packet is obtained by removing the tunnel subnet information and the virtual IP address of the VGW virtual gateway from the L2GW network element, and then the target data packet is sent to the cloud host.

7. The method according to claim 6, characterized in that, The L2GW network element processes Layer 2 communication events between the cloud host and the on-premises host based on the HAVIP service, and the method further includes: When both the primary and backup nodes of the HAVIP service are deployed on the cloud VPC module, if a switch between the primary and backup nodes is performed, the local table of the L2GW network element is updated through the controller in the cloud VPC module, and the ARP information synchronization operation of the on-premises host is triggered. When both the primary node and the backup node are deployed on the on-premises IDC module, if a switch is performed between the primary and backup nodes, the on-premises host will send ARP information to the L2GW network element, and the cloud host will update the flow table of the cloud host and the local table of the L2GW network element. When the primary node is deployed on the cloud VPC module and the backup node is deployed on the on-premises IDC module, if a switch is performed between the primary and backup nodes, the on-premises host will send ARP information to the L2GW network element to update the ARP table of the L2GW network element, and the cloud host will update the flow table of the cloud host and the local table of the L2GW network element. When the primary node is deployed on the on-premises IDC module and the backup node is deployed on the cloud VPC module, if a switch is performed between the primary and backup nodes, the cloud host updates the flow table of the cloud host and the ARP table of the L2GW network element, and causes the L2GW network element to send ARP information to refresh the ARP table of the on-premises host.

8. A computer device, characterized in that, include: The system includes a memory and a processor, which are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform a two-layer network interconnection method for cloud and on-premises networks as described in any one of claims 5 to 7.

Images