On-cloud and under-cloud two-layer network intercommunication system and method
By introducing L2GW network elements and tunnel modules into the cloud-up and down-cloud network interoperability system, the problems of network segment restrictions and inflexible host interactions in the traditional three-layer connection method are solved, and direct connectivity and efficient interoperability of the cloud-up and down-cloud network are realized, improving the flexibility and scalability of the network.
Patent Information
- Application Number
- CN202411731472.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-28
- Publication Date
- 2025-04-15
- Estimated Expiration
- 2044-11-28
AI Technical Summary
The traditional method of establishing a layer three connection through VPN or DC has problems such as network segment restrictions and inflexible host interactions, which leads to inconvenience in network interoperability and difficulty in ensuring high availability during the cloud.
A layer two-layer network interoperability system on the cloud and under the cloud is designed. Through the combination of L2GW network elements and tunnel modules, on-cloud VPC modules and down-cloud IDC modules, the layer two-layer networks on-cloud are realized, eliminating the overlapping restrictions of network segments, and supporting the flexible deployment of primary and secondary nodes.
It realizes seamless interoperability between cloud and cloud networks, reduces migration complexity and cost, enhances the flexibility and scalability of cloud services, improves network efficiency and performance, and improves the high availability of the system.
Smart Images

Figure CN119835112A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of network communication technologies, and in particular to a system and method for interconnecting two-layer networks on a cloud and off a cloud. Background Art
[0002] With the development of cloud computing technology, more and more companies are choosing to migrate their businesses to the cloud. However, before considering moving to the cloud, many companies have already established their own IDC (Internet Data Center) facilities locally to provide services. When companies want to migrate part of their businesses to the cloud, they are faced with the problem of how to achieve interoperability between the local IDC and the VPC (Virtual Private Cloud) on the cloud.
[0003] The traditional interconnection method is to build a VPN (virtual private network) or DC (data center) between the user's off-cloud IDC subnet and the on-cloud VPC subnet to establish a three-layer connection. This three-layer connection method solves the need for on-cloud and off-cloud interconnection to a certain extent. The three-layer access method is based on IP address addressing, which requires that the subnet segments of the off-cloud IDC subnet and the on-cloud VPC subnet cannot overlap. If the segments overlap, a lot of manpower is required to physically transform the IP addresses, delaying the user's progress on the cloud. In addition, with the traditional three-layer connection method, the hosts on and off the cloud cannot achieve seamless interaction, that is, the primary and backup nodes can only be located on or off the cloud at the same time, and it is impossible to achieve a more flexible deployment method where the primary node is on the cloud and the backup node is off the cloud. This limits the choice of enterprises when building high-availability services, which may lead to the inability to effectively protect the business in the face of certain specific failure scenarios, affecting user experience and business stability.
[0004] In the above solution, although the traditional method of establishing a three-layer connection through VPN or DC can achieve basic cloud-to-cloud connectivity, it has problems such as network segment restrictions and inflexible host interaction, which brings many inconveniences to enterprise users in cloud computing. Summary of the invention
[0005] In view of this, the present invention provides a cloud-based and off-cloud Layer 2 network interconnection system and method to solve the problems of network segment limitations and inflexible host interaction in the traditional method of establishing a Layer 3 connection through VPN or DC, which brings many inconveniences to enterprise users in going to the cloud.
[0006] In a first aspect, the present invention provides a cloud-based and cloud-based Layer 2 network interconnection system, the system comprising: a cloud-based VPC module and a cloud-based IDC module connected by a tunnel module;
[0007] The cloud VPC module includes 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 off-cloud IDC module includes an off-cloud subnet unit, and the off-cloud subnet unit is used to provide an off-cloud network environment for the off-cloud host in the off-cloud IDC module; the on-cloud subnet unit is connected to the off-cloud subnet unit through the tunnel module;
[0009] The L2GW network element establishes a connection with the cloud host in the cloud VPC module through the L2-Connection port, and the L2GW network element is used to handle the Layer 2 communication events between the cloud host and the off-cloud host.
[0010] In an optional implementation, the cloud subnet unit includes a tunnel subnet and a first connection subnet, and the cloud host is set in the first connection subnet;
[0011] The first connection subnet is used to provide a connection network node for the host on the cloud and other network devices; the other network devices include L2GW network elements and the host under the cloud;
[0012] The tunnel subnet includes an L2GW port, and the tunnel subnet is used to carry the data packets encapsulated by the VPC module on the cloud to achieve Layer 2 network interconnection between the host on the cloud and the host off the cloud;
[0013] 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 accesses the tunnel module through the VTEP port.
[0014] In an optional implementation, the tunnel module includes a VXLAN tunnel; the VXLAN tunnel includes a DC dedicated line and a VPN virtual private network line;
[0015] The other end of the L2GW network element is connected to the IDC module under the cloud through the VTEP port and the DC dedicated line in sequence;
[0016] The other end of the VPC module on the cloud is also connected to the IDC module under the cloud through the VTEP port and the VPN virtual private network line in sequence.
[0017] In an optional implementation, the under-cloud IDC module further includes a switch unit, and the under-cloud subnet unit includes a second connection subnet;
[0018] The second connection subnet is used to provide a connection network node for the host under the cloud and other network devices; the other network devices include L2GW network elements and the host on the cloud;
[0019] The other 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] The other end of the VPC module on the cloud is also connected to one end of the switch unit through the VTEP port and the VPN virtual private network line in sequence;
[0021] The other end of the switch unit is connected to the second connection subnet.
[0022] In an optional implementation, the L2GW network elements are deployed in a cluster manner, and multiple L2GW network elements share a virtual IP address.
[0023] In a second aspect, the present invention provides a method for interconnecting two-layer networks on a cloud and off a cloud. The method is applied to a system for interconnecting two-layer networks on a cloud and off a cloud as described above. The method includes:
[0024] When the host on the cloud communicates, a first data packet is sent to the L2GW network element, where the first data packet includes the virtual IP address of the L2GW network element, the IP address of the host on the cloud, the MAC address of the host on the cloud, the IP address of the host off the cloud, and the MAC address of the L2-Connection Port.
[0025] When the L2GW network element receives the first data packet, the virtual IP address of the VGW virtual gateway, the VTEP port information of the host under the cloud, and the tunnel subnet information are added to the first data packet to obtain a second data packet, and the second data packet is forwarded to the 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, a third data packet is obtained after encapsulation, and the third data packet is parsed and processed by the VXLAN tunnel and transmitted to the off-cloud host;
[0027] When the host under the cloud receives the third data packet after the VXLAN tunnel parsing process, the third data packet after the VXLAN tunnel parsing process is decapsulated in reverse process through the tunnel module and the L2GW network element in sequence, so that the host on the cloud obtains the decapsulated target data packet.
[0028] In an optional implementation, the decapsulation process of the reverse process includes:
[0029] Removing the VNI identifier information and the VTEP port information of the user dedicated line in the third data packet after the VXLAN tunnel parsing process by the tunnel module, obtaining a fourth data packet;
[0030] The tunnel subnet information of the fourth data packet and the virtual IP address of the VGW virtual gateway are removed by the L2GW network element to obtain the target data packet, and the target data packet is sent to the cloud host.
[0031] In an optional implementation, the L2GW network element is used to learn ARP information of the host on the cloud and the host off the cloud, and the method further includes:
[0032] When the off-cloud host communicates with the on-cloud host, the off-cloud 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 processing on the first ARP request, and provides the MAC address of the cloud host to the off-cloud host, so that the off-cloud host communicates with the cloud host based on the MAC address of the cloud host;
[0034] When the host on the cloud communicates with the host off the cloud, the host on the cloud 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 host on the cloud is located;
[0035] After receiving the second ARP request, if the ARP table of the L2GW network element does not contain an ARP entry of the host under the cloud corresponding to the second ARP request, the L2GW network element sends the second ARP request to the host under the cloud;
[0036] After receiving the second ARP request, the host under the cloud sends the MAC address of the host under the cloud to the L2GW network element for the L2GW network element to learn;
[0037] The L2GW network element sends the learned MAC address of the off-cloud host to the on-cloud host, so that the on-cloud host communicates with the off-cloud host based on the MAC address of the off-cloud host.
[0038] In an optional implementation, the L2GW network element processes a layer 2 communication event between the host on the cloud and the host off the cloud based on the HAVIP service, and the method further includes:
[0039] When the master node and the standby node of the HAVIP service are both deployed on the VPC module on the cloud, if the master node and the standby node are switched, the local table of the L2GW network element is updated by the controller in the VPC module on the cloud, and the ARP information synchronization operation of the host under the cloud is triggered;
[0040] When the master node and the standby node are both deployed on the off-cloud IDC module, if the master node and the standby node are switched, the off-cloud host sends ARP information to the L2GW network element, and the on-cloud host updates the flow table of the on-cloud host 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 standby node is deployed on the IDC module off the cloud, if the master node and the standby node are switched, the host off 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 standby node is deployed on the VPC module on the cloud, if the master node and the standby 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 causes the L2GW network element to send ARP information to refresh the ARP table of the host under the cloud.
[0043] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes a method for cloud-to-cloud layer 2 network intercommunication according to the first aspect or any corresponding embodiment thereof by executing the computer instructions.
[0044] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute a method for intercommunication between cloud-based and cloud-based Layer 2 networks according to the first aspect or any corresponding embodiment thereof.
[0045] In a fifth aspect, the present invention provides a computer program product, including computer instructions, which are used to enable a computer to execute a method for cloud-to-cloud layer 2 network interconnection according to the above-mentioned first aspect or any corresponding embodiment.
[0046] The technical solution provided by the present invention may include the following beneficial effects:
[0047] The present invention designs a two-layer network interconnection system on the cloud and off the cloud based on the L2GW network element, which organically combines components such as VPC on the cloud, tunnel, and IDC off the cloud, clearly plans the connection relationship and data flow between the components, and provides a reliable architectural reference for enterprises to build an integrated network on the cloud and off the cloud. The L2GW network element allows direct connectivity between the network on the cloud and the network off the cloud at the data link layer. Users can migrate the business of the data center (IDC) off 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 interruptions during the migration process, reducing the complexity and cost of migration, and users can seamlessly use resources and services on the cloud, enhancing the flexibility and scalability of off-cloud business, allowing a wider range of network connections and resource sharing, and improving the efficiency and performance of the network.
[0048] The L2GW network element of the present invention is deployed in a cluster manner, and multiple L2GW network elements provide a virtual IP to the outside world, which improves its own stability. When the master node fails or is upgraded, the traffic is switched to the standby node, and through mechanisms such as ARP information synchronization, the ARP information loss and packet loss problems in the master-standby switching process are reduced, further enhancing the high availability of the system at the layer 2 communication level. The present invention realizes subnet intercommunication at the data link layer through the L2GW network element, allowing the network segments on the cloud and off the cloud to overlap. The user-side IDC does not need to modify the IP address, avoiding tedious IP address transformation work, lowering the threshold for cloud access, and improving the efficiency of network deployment and management. Based on the function of the L2GW network element, the present invention realizes efficient layer 2 communication between hosts on and off the cloud. The L2GW network element is responsible for ARP learning and information storage and maintenance, cooperates with the mechanism of encapsulating and decapsulating data packets, and works in collaboration with the HAVIP service to ensure the accurate forwarding of data packets in the layer 2 network and improve communication efficiency and quality. BRIEF DESCRIPTION OF THE DRAWINGS
[0049] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0050] Figure 1 2. It is a structural diagram of a cloud-on-cloud-off-cloud Layer 2 network interconnection system according to an embodiment of the present invention;
[0051] Figure 2 This is a flow chart of a method for intercommunication between cloud-based and cloud-based Layer 2 networks according to an embodiment of the present invention;
[0052] Figure 32. It is a schematic diagram of on-cloud and off-cloud host communication forwarding according to an embodiment of the present invention;
[0053] Figure 4 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION
[0054] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.
[0055] It should be noted that this embodiment designs a new type of gateway L2GW. In order to communicate the connection between the subnet and the L2GW network element, an L2-Connection port and a connection subnet are designed, and the Internet data center (IDC) under the cloud on the user side is connected through a VXLAN line laid out by a data center (DC) or a virtual private network (VPN), etc., which solves the problem of intercommunication between the data link layer subnets on the cloud and under the cloud. Users do not have to care about whether the machine is actually on the cloud or under the cloud when performing any operation. Users can manage machines on the cloud and under the cloud like in a traditional subnet. Keepalived (a software tool for achieving high availability that can achieve functions such as fault switching between master and standby nodes) can be implemented to build a high-availability cluster, with the master node on the cloud and the standby node under the cloud. In addition, the network segments on the cloud and under the cloud can overlap, and the Internet data center (IDC) under the cloud on the user side does not need to modify the IP address. Users can migrate part of the data center or private cloud host business to the cloud without changing the subnet and IP planning, thereby expanding the broadcast domain. The cloud experience of customers is greatly improved.
[0056] In this embodiment, a two-layer network interconnection system between cloud and off-cloud is provided. Figure 1 is a structural diagram of a cloud-on-cloud-off-cloud layer 2 network interconnection system according to an embodiment of the present invention, such as Figure 1 As shown, the system includes: an on-cloud VPC module and an off-cloud IDC module connected via a tunnel module;
[0057] The cloud 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 host in the cloud VPC module;
[0058] The off-cloud IDC module includes an off-cloud subnet unit, which is used to provide an off-cloud network environment for an off-cloud host in the off-cloud IDC module; the on-cloud subnet unit is connected to the off-cloud subnet unit through the tunnel module;
[0059] 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 handle the Layer 2 communication events between the cloud host and the cloud host.
[0060] In an optional implementation, the cloud subnet unit includes a tunnel subnet and a first connection subnet, and the cloud host is arranged in the first connection subnet;
[0061] The first connection subnet is used to provide a connection network node for the host on the cloud and other network devices; the other network devices include an L2GW network element and the host under the cloud;
[0062] The tunnel subnet includes an L2GW port, which is used to carry data packets encapsulated by the VPC module on the cloud to achieve Layer 2 network interconnection between the host on the cloud and the host off the cloud;
[0063] 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 accesses the tunnel module through the VTEP port.
[0064] In an optional implementation, the tunnel module includes a VXLAN tunnel; the VXLAN tunnel includes a DC dedicated line and a VPN virtual private network line;
[0065] The other end of the L2GW network element is connected to the IDC module under the cloud through the VTEP port and the DC dedicated line in sequence;
[0066] The other end of the VPC module on the cloud is also connected to the IDC module under the cloud through the VTEP port and the VPN virtual private network line in sequence.
[0067] In an optional implementation, the under-cloud IDC module further includes a switch unit, and the under-cloud subnet unit includes a second connection subnet;
[0068] The second connection subnet is used to provide a connection network node for the host under the cloud and other network devices; the other network devices include the L2GW network element and the host on the cloud;
[0069] The other 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;
[0070] The other end of the VPC module on the cloud is also connected to one end of the switch unit through the VTEP port and the VPN virtual private network line in sequence;
[0071] The other end of the switch unit is connected to the second connection subnet.
[0072] In an optional implementation manner, the L2GW network element is deployed in a cluster manner, and multiple L2GW network elements share a virtual IP address.
[0073] Further, such as Figure 1 As shown, the system structure of this embodiment draws on the classic computer network design concept of layered encapsulation to achieve two-layer interconnection between the cloud and the cloud. The overall system is divided into three parts: the cloud VPC module, the tunnel module, and the cloud IDC module. The cloud VPC module consists of two parts: Figure 1 The first part on the left is the cloud subnet unit, which is mainly composed of the tunnel subnet and the first connection subnet. The right side is the L2GW network element deployed on the cloud host. The off-cloud IDC module is the user-side network, which is composed of various switches and the second connection subnet. The part that connects the on-cloud VPC module and the off-cloud IDC module is the tunnel module (i.e., VXLAN tunnel), which is implemented by a DC dedicated line or a VPN virtual private network line.
[0074] Furthermore, the VPC module (Virtual Private Cloud) on the cloud is located at Figure 1On the upper left side, the network segment of VPC is marked as 192.168.0.0 / 16. The cloud subnet unit of the cloud VPC module includes the first connection subnet and the 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 multiple cloud hosts and L2-Connection ports. The cloud hosts correspond to the L2-Connection ports one by one. The network segment of the tunnel subnet is 192.168.6.0 / 24, which is used for data transmission through the VXLAN tunnel (Virtual eXtensible Local Area Network). The tunnel subnet includes the L2GW port. On the right side of the cloud subnet unit is L2gwmachine (L2GW host), that is, L2GW network element, which is used to achieve connectivity between the cloud and the cloud at 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 and the L2-Connection port in turn. On the right side of the L2GW network element is VGW (Virtual Gateway), which is used to connect the cloud host and the cloud host. On the right side of VGW is 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, which is implemented through DC (Data Center Interconnect) or VPN (Virtual Private Network). Figure 1 The far right side is the off-cloud IDC module (Internet Data Center), with the network segment marked as 192.168.2.0 / 24. The off-cloud IDC module includes a VXLAN switch, a subnet switch, and a second connection subnet. The VXLAN switch is used to establish VXLAN tunnels inside the off-cloud IDC module, which are connected to the VXLAN tunnels of the on-cloud VPC module through DC (Data Center Interconnect) or VPN (Virtual Private Network); the subnet switch is the core device in the off-cloud IDC network, used to connect and manage communications 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 on-cloud VPC module, so that there can be overlapping network segments on and off the cloud.
[0075] Furthermore, this embodiment realizes the interconnection of data link layer subnets on and off the cloud through such an architecture, and has the advantages of overlapping network segments and no need to modify IP addresses, making it convenient for users to migrate data center or private cloud host services to the cloud without changing subnet and IP planning.
[0076] In summary, this embodiment designs a two-layer network interconnection system between the cloud and the off-cloud based on the L2GW network element, which organically combines components such as the on-cloud VPC, tunnel, and off-cloud IDC, clearly plans the connection relationship and data flow between the components, and provides a reliable architectural reference for enterprises to build an integrated network on the cloud and off-cloud. The L2GW network element allows direct connectivity between the on-cloud network and the off-cloud network at the data link layer. Users can migrate the services of the off-cloud data center (IDC) to the cloud without changing the existing network configuration, while maintaining the continuity of the network and the consistency of the broadcast domain, eliminating interruptions during the migration process, reducing the complexity and cost of migration, and allowing users to seamlessly use on-cloud resources and services, enhancing the flexibility and scalability of off-cloud services, allowing for more extensive network connections and resource sharing, and improving network efficiency and performance.
[0077] The L2GW network elements of this embodiment are deployed in a cluster manner, and multiple L2GW network elements provide a virtual IP to the outside world, which improves its own stability. When the master node fails or is upgraded, the traffic is switched to the standby node, and through mechanisms such as ARP information synchronization, the ARP information loss and packet loss problems in the master-standby switching process are reduced, further enhancing the high availability of the system at the layer 2 communication level. This embodiment uses the L2GW network element to achieve subnet intercommunication at the data link layer, allowing the cloud and off-cloud network segments to overlap. The user-side IDC does not need to modify the IP address, avoiding tedious IP address transformation work, lowering the threshold for cloud access, and improving the efficiency of network deployment and management. Based on the functions of the L2GW network element, this embodiment realizes efficient layer 2 communication between hosts on and off the cloud. The L2GW network element is responsible for ARP learning and information storage and maintenance, cooperates with the mechanism of encapsulating and decapsulating data packets, and works in collaboration with the HAVIP service to ensure the accurate forwarding of data packets in the layer 2 network and improve communication efficiency and quality.
[0078] According to an embodiment of the present invention, an embodiment of a method for interconnecting a layer 2 network between a cloud and an off-cloud 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, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.
[0079] In this embodiment, a method for interconnecting two-layer networks on the cloud and off the cloud is provided, which can be applied to Figure 1 In the above-cloud and below-cloud two-layer network interconnection system shown, Figure 2 is a flow chart of a method for intercommunication between cloud-based and cloud-based Layer 2 networks according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:
[0080] Step S201, when the host on the cloud communicates, a first data packet is sent to the L2GW network element, and the first data packet includes the virtual IP address of the L2GW network element, the IP address of the host on the cloud, the MAC address of the host on the cloud, the IP address of the host off the cloud, and the MAC address of the L2-Connection Port.
[0081] Furthermore, when the host on the cloud needs to communicate with the host off the cloud, it will construct and send a first data packet to the L2GW network element. The 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 host on the cloud, used to identify the source of the data packet; the MAC address of the host on the cloud, used to identify the source hardware address of the data packet; the IP address of the host off the cloud, used to identify the final destination of the data packet. The MAC address of the L2-Connection Port is used to route data packets within the cloud network. Since the cloud subnet unit includes multiple cloud hosts and the cloud subnet unit includes multiple cloud hosts, the cloud host in step S201 can be any cloud host in the cloud subnet unit, and the cloud host can be any cloud host in the cloud subnet unit.
[0082] Step S202, when the L2GW network element receives the first data packet, the virtual IP address of the VGW virtual gateway, the VTEP port information of the host under the cloud and the tunnel subnet information are added to the first data packet to obtain a second data packet, and the second data packet is forwarded to the tunnel module.
[0083] Furthermore, after receiving the first data packet, the L2GW network element processes it to form a second data packet, and then forwards it to the tunnel module. The processing includes adding the following information: the virtual IP address of the VGW (Virtual Gateway) virtual gateway, which is used for routing the network under the cloud; the VTEP (VXLAN Tunnel Endpoint) port information of the host under the cloud, which identifies the end point of the VXLAN tunnel. Tunnel subnet information is used to route data packets in the VXLAN tunnel.
[0084] Step S203, when the tunnel module receives the second data packet, the VNI identifier information and VTEP port information of the user dedicated line are added to the second data packet, and a third data packet is obtained after encapsulation, and the third data packet is parsed and processed through the VXLAN tunnel and transmitted to the host under the cloud.
[0085] Furthermore, after receiving the second data packet, the tunnel module will further process it, encapsulate it to obtain the third data packet, and then perform VXLAN tunnel parsing and transmission to the cloud host through the VXLAN tunnel. The processing includes adding the following information: VNI (VXLAN Network Identifier) identifier information of the user dedicated line, which is used to distinguish different VXLAN networks; VTEP port information, which is used for VXLAN tunnel routing.
[0086] Step S204, when the host under the cloud receives the third data packet after the VXLAN tunnel parsing process, the third data packet after the VXLAN tunnel parsing process is decapsulated in reverse process through the tunnel module and the L2GW network element in sequence, so that the host on the cloud obtains the decapsulated target data packet.
[0087] Furthermore, after receiving the third data packet after the VXLAN tunnel is parsed, the host under the cloud will perform decapsulation processing, and the host on the cloud will obtain the decapsulated target data packet, completing the on-cloud and off-cloud Layer 2 network interconnection. The decapsulation process includes: removing the encapsulation of the VXLAN tunnel through the tunnel module, restoring the original data packet, and further decapsulating through the L2GW network element to remove the virtual IP address of the VGW virtual gateway, VTEP port information, and tunnel subnet information.
[0088] In an optional implementation, the decapsulation process of the reverse process includes:
[0089] Remove the VNI identifier information and VTEP port information of the user dedicated line in the third data packet after the VXLAN tunnel parsing process by the tunnel module, and obtain a fourth data packet;
[0090] The tunnel subnet information of the fourth data packet and the virtual IP address of the VGW virtual gateway are removed through 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 host under the cloud 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 relevant information for tunnel transmission added when the data is transmitted through the VXLAN tunnel. The tunnel module needs to remove the VNI identifier information and VTEP port information of the user dedicated line in the third data packet. The VNI identifier information is used to distinguish different virtual networks in the VXLAN tunnel. After the data reaches the host under the cloud, this information is no longer needed; the VTEP port information is the information used for data processing at the endpoint of the virtual tunnel, and it needs to be removed at the tunnel module at the receiving end. After the tunnel module removes this information, the third data packet becomes the fourth data packet. The fourth data packet obtained by decapsulation by the tunnel module needs to be further decapsulated by the L2GW network element to restore the data originally sent from the host on the cloud. The L2GW network element needs to remove the tunnel subnet information and the virtual IP address of the VGW virtual gateway in the fourth data packet. The tunnel subnet information is added when the L2GW network element forwards the data to the tunnel module, and is used to correctly transmit data in the tunnel subnet; the virtual IP address of the VGW virtual gateway is added after the L2GW network element receives the first data packet, and is used to correctly route the data to the VGW. When the data returns to the cloud host, all this information needs to be removed. 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 process of decapsulation of the entire on-cloud and off-cloud data transmission, so that the cloud host can receive the original data. Through such a decapsulation process, when the data returns from the off-cloud host to the cloud host, the various network-related information added during the transmission process can be removed in turn to restore the original data, ensuring the accuracy and integrity of the on-cloud and off-cloud Layer 2 network intercommunication data transmission.
[0092] For further information, see Figure 3 The schematic diagram of host communication forwarding between the cloud and the off-cloud is shown. This embodiment is built on the basis of the L2GW network element and realizes host communication between the cloud and the off-cloud. Packets 1, 2, and 3 are the cloud packet encapsulation process, and packets 3, 4, and 5 are the traditional vxlan data packet parsing process. Packets 6-10 are the reverse process. Packet 1 mainly contains the virtual IP address of the L2GW network element cluster, the IP address and MAC address of VM1, and the IP address of VM2, and the transit port Mac (L2-connection port). After packet 1 is sent to the L2GW network element, it becomes packet 2, adding VGW VIP, vtep information of the off-cloud IDC, tunnel subnet and other information. Packet 3 adds user dedicated line vni, vtep and other information. By encapsulating and decapsulating in this way, the dedicated line completes the last layer of encapsulation, and cooperates with the ARP and other information stored in the L2GW network element to realize off-cloud intercommunication. In other words, Figure 3 The cloud packet encapsulation process (including 1, 2, and 3 packets), where 1 packet 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 cloud host VM2, and the transit port Mac port (L2-connection port). Packet 1 is the initial data packet sent from the cloud host VM1, carrying the necessary information for identifying the source host, the target host, and the transit port. When packet 1 is sent to the L2GW network element, it becomes 2 packets. Packet 2 adds VGW (virtual gateway) VIP (virtual IP address), vtep (virtual tunnel endpoint) information of the cloud IDC module, tunnel subnet and other information on the basis of packet 1. These newly added information enable the data packet to pass through the VGW and tunnel subnet and prepare for entering the VXLAN tunnel. Packet 2 is further processed to become 3 packets. Packet 3 adds user dedicated line vni (virtual network identifier), vtep and other information on the basis of packet 2. By adding this information, packet 3 can be transmitted through the VXLAN tunnel on the user dedicated line. Next, the traditional VXLAN packet parsing process (including packets 3, 4, and 5) is entered. Packets 3 have been generated in the previous cloud packet encapsulation process, which contains all the information required for transmission through the VXLAN tunnel. After the 3 packets enter the VXLAN tunnel, they will be processed according to the traditional VXLAN packet parsing process. This process involves the decapsulation and forwarding operations of the VXLAN tunnel on the data packet, and the data packet is transmitted from the cloud host to the cloud host through the VXLAN tunnel. Finally, the reverse process (including packets 6-10) is entered. When the data packet arrives at the cloud, it needs to go through a series of reverse process operations to restore the data packet to a format that can be recognized by the cloud host VM1 for communication. Packets 6-10 are a decapsulation process opposite to the previous packet encapsulation process. The user dedicated line vni, vtep information, tunnel subnet information, VGWVIP, etc. added in the cloud packet encapsulation process are removed in sequence, and the original information of packet 1 is finally restored.
[0093] In an optional implementation, the L2GW network element is used to learn ARP information of the host on the cloud and the host off the cloud, and the method further includes:
[0094] When the off-cloud host communicates with the on-cloud host, the off-cloud host sends a first ARP request to the L2GW network element;
[0095] After receiving the first ARP request, the L2GW network element performs a proxy processing on the first ARP request, and provides the MAC address of the cloud host to the off-cloud host, so that the off-cloud host communicates with the cloud host based on the MAC address of the cloud host;
[0096] When the host on the cloud communicates with the host off the cloud, the host on the cloud 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 host on the cloud is located;
[0097] After receiving the second ARP request, if the ARP table of the L2GW network element does not contain an ARP entry of the cloud host corresponding to the second ARP request, the L2GW network element sends the second ARP request to the cloud host;
[0098] After receiving the second ARP request, the host under the cloud sends the MAC address of the host under the cloud to the L2GW network element for the L2GW network element to learn;
[0099] The L2GW network element sends the learned MAC address of the off-cloud host to the on-cloud host, so that the on-cloud host communicates with the off-cloud host based on the MAC address of the off-cloud host.
[0100] Furthermore, the L2GW network element of this embodiment is also used for ARP learning of the cloud host and the cloud host, as well as ARP information storage and maintenance. For the ARP process of the cloud host learning the cloud host, the cloud 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 the ARP of the cloud machine, the cloud host sends an ARP with the src of the mac address of the L2-connection port in this subnet to the L2GW network element. After receiving the packet, if there is no corresponding ARP table entry, the L2GW network element sends an ARP request to the cloud to learn the real MAC address of the corresponding cloud machine. For stability and robustness, the L2GW network element is deployed in a cluster, and multiple L2GW network elements provide a virtual IP to the outside. The ARP request of the L2GW network element may be sent by machine A, but the received ARP reply packet is for machine B, resulting in ARP learning failure. In order to solve this situation, usually only one master node is fixed to provide external services. When the master node fails or is upgraded, the traffic is switched to the backup. In order to prevent the problem of packet loss caused by a large number of ARPs being lost or relearned during the master-slave switching process due to upgrade or failure scenarios, the master node synchronizes the previously learned ARP to the standby. At the same time, the L2GW network element also has the function of sending free ARPs under the cloud to the cloud, and free ARPs on the cloud to the cloud. Lay the foundation for realizing high-availability VIP clusters on and off the cloud. That is to say, in this embodiment, when the host under the cloud needs to learn the ARP of the host on the cloud, the host under the cloud will send a first ARP request. The L2GW network element plays a role of answering in this process, and the L2GW network element will reply to the MAC address of the default gateway of the cloud subnet (that is, the MAC address of the host on the cloud). In this way, the host under the cloud can communicate with the host on the cloud by obtaining the MAC address of the default gateway. When the host on the cloud 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 table entry when receiving the second ARP request, the L2GW network element will further send a second ARP request to the host under the cloud, thereby learning the real MAC address of the host under the cloud.
[0101] In order to ensure the stability and robustness of the network, the L2GW network elements are deployed in a cluster in this embodiment, and multiple L2GW network elements present a virtual IP address to the outside to provide redundancy and load balancing functions. In the cluster, usually only one master node in the L2GW network element cluster provides services to the outside to avoid problems that may occur when multiple nodes process ARP requests at the same time, such as sending an ARP request from machine A, but receiving an ARP reply packet from machine B, resulting in ARP learning failure. When the master node fails or needs to be upgraded, the traffic will be switched to the standby node. This can ensure the continuity of network services. During the master-standby switching process, in order to prevent packet loss caused by a large number of ARPs being lost or relearned, the master node will synchronize the previously learned ARP information to the standby node. In this way, when the standby node switches to the master node, it already has the necessary ARP information and can seamlessly take over the network service. The L2GW network element also has the function of forwarding free ARPs, which can send free ARPs under the cloud to the cloud, and send free ARPs on the cloud to the cloud. Free ARP is mainly used for functions such as address conflict detection in the network. Through the forwarding of L2GW network elements, it helps to realize high-availability VIP clusters on and off the cloud.
[0102] In an optional implementation, the L2GW network element processes a layer 2 communication event between the host on the cloud and the host under the cloud based on the HAVIP service, and the method further includes:
[0103] When the primary node and the backup node of the HAVIP service are both deployed on the VPC module on the cloud, if the primary node and the backup node are switched, the local table of the L2GW network element is updated through the controller in the VPC module on the cloud, and the ARP information synchronization operation of the host under the cloud is triggered;
[0104] 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;
[0105] When the master node is deployed on the VPC module on the cloud, and the standby node is deployed on the IDC module under the cloud, if the master node and the standby 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;
[0106] When the master node is deployed on the IDC module under the cloud and the standby node is deployed on the VPC module on the cloud, if the master node and the standby 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 causes the L2GW network element to send ARP information to refresh the ARP table of the host under the cloud.
[0107] Furthermore, the implementation of VIP is based on the HAVIP service. The HAVIP service implements heartbeat communication between two hosts through keepalive and is managed through HAVIP. When HAVIP receives a free ARP message from the master node, HAVIP will detect the message and perform master-slave switching. At the same time, it will record the MAC and IP information of the master node, perform ARP proxy reply, and send free ARP broadcasts to all nodes in the broadcast domain. Based on the HAVIP principle, L2GW implements the intercommunication between hosts on and off the cloud. The IDC module and VPC module on the cloud deployed locally by HAVIP are divided into four scenarios. For the scenario where both the master and the standby are on the cloud, the controller senses the switching status during the master-slave switching and updates the L2GW local table. In order to synchronize the ARP information to the cloud, the cloud actively initiates an ARP request with the src of the local subnet gateway MAC to request the cloud MAC. The reason why the cloud does not use its own host MAC is to facilitate the scenario where both the master and the standby are on the cloud and HAVIP switch does not refresh the cloud ARP. For scenarios where both the master and backup are in the cloud, free ARP is sent to the cloud when the master and backup switch, and the L2GW network element refreshes its existing ARP based on the free ARP. For scenarios where the master is in the cloud and the backup is in the cloud, when a master-slave switch occurs, the cloud sends a free ARP to update the L2GW ARP port, and the master-slave status needs to be reported to the control node. The cloud computing node updates the flow table and the L2GW local table. For scenarios where the master is in the cloud and the backup is in the cloud, when the master-slave switch occurs, the flow table is updated, the ARP table of the L2GW network element is updated, and the L2GW network element sends a free ARP to refresh the offline host ARP table.
[0108] That is to say, the implementation of VIP (virtual IP address) in this embodiment depends on the HAVIP service independently developed by Tianyi Cloud, and the HAVIP service plays an important role in the entire network architecture. The HAVIP service realizes the heartbeat interconnection between the two hosts (the host on the cloud and the host under the cloud) through the keepalive mechanism, which means that by periodically sending signals to detect whether the host is alive, the connection status between the hosts is ensured to be normal. At the same time, the relevant hosts are managed through the HAVIP service, that is, the hosts are centrally managed. When the HAVIP service receives a free ARP message from the master node, it will detect this situation and perform the master-slave switching operation. In this process, the HAVIP service will also record the MAC address and IP information of the master node. The HAVIP service will perform ARP replies and send free ARP broadcasts to all nodes in the broadcast domain. In this way, it is ensured that other nodes in the network can obtain relevant information after the master-slave switching in time to ensure the normal operation of network communication. The L2GW network element uses the principle of HAVIP service to realize the interconnection between hosts on and off the cloud. The deployment of HAVIP service includes the following four scenarios:
[0109] The first type: In the scenario where the primary and backup HAVIP services are both in the cloud, when the primary and backup switch occurs, the controller can sense this switch state and update the L2GW local table accordingly. In order to synchronize the ARP information to the cloud, the host in the cloud will actively initiate 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 host in the cloud, so that in the switching scenario of the HAVIP service where both the primary and backup are in the cloud, there is no need to refresh the ARP table in the cloud, reducing network fluctuations and unnecessary operations.
[0110] The second type: When the primary and backup HAVIP services are both in the cloud, free ARP information will be sent to the cloud when the primary and backup switch occurs. The L2GW network element refreshes its existing ARP table based on the received free ARP information to ensure that the L2GW network element can update network information in a timely manner and maintain the accuracy of on-cloud and off-cloud communications.
[0111] The third scenario: The master of the HAVIP service is on the cloud and the backup is off the cloud. When the master-slave switch occurs, the off-cloud will send free ARP information to update the L2GW ARP port. At the same time, the master-slave status needs to be reported to the control node so that the computing node on the cloud can update the flow table and update the L2GW-local table port, ensuring accurate update of network information and normal communication in a complex master-slave cross-cloud environment.
[0112] The fourth type: In the scenario where the master of the HAVIP service is in the cloud and the backup is in the cloud, when the master-slave switch occurs, the flow table needs to be updated, and the ARP table of the L2GW network element needs to be updated at the same time. In addition, the L2GW network element will send free ARP information to refresh the ARP table of the offline host (host in the cloud). Through these operations, normal communication and information update of the network in different master-slave distribution scenarios are guaranteed.
[0113] In summary, this embodiment designs a two-layer network interconnection system between the cloud and the off-cloud based on the L2GW network element, which organically combines components such as the on-cloud VPC, tunnel, and off-cloud IDC, clearly plans the connection relationship and data flow between the components, and provides a reliable architectural reference for enterprises to build an integrated network on the cloud and off-cloud. The L2GW network element allows direct connectivity between the on-cloud network and the off-cloud network at the data link layer. Users can migrate the services of the off-cloud data center (IDC) to the cloud without changing the existing network configuration, while maintaining the continuity of the network and the consistency of the broadcast domain, eliminating interruptions during the migration process, reducing the complexity and cost of migration, and allowing users to seamlessly use on-cloud resources and services, enhancing the flexibility and scalability of off-cloud services, allowing for more extensive network connections and resource sharing, and improving network efficiency and performance.
[0114] The L2GW network elements of this embodiment are deployed in a cluster manner, and multiple L2GW network elements provide a virtual IP to the outside world, which improves its own stability. When the master node fails or is upgraded, the traffic is switched to the standby node, and through mechanisms such as ARP information synchronization, the ARP information loss and packet loss problems in the master-standby switching process are reduced, further enhancing the high availability of the system at the layer 2 communication level. This embodiment uses the L2GW network element to achieve subnet intercommunication at the data link layer, allowing the cloud and off-cloud network segments to overlap. The user-side IDC does not need to modify the IP address, avoiding tedious IP address transformation work, lowering the threshold for cloud access, and improving the efficiency of network deployment and management. Based on the functions of the L2GW network element, this embodiment realizes efficient layer 2 communication between hosts on and off the cloud. The L2GW network element is responsible for ARP learning and information storage and maintenance, cooperates with the mechanism of encapsulating and decapsulating data packets, and works in collaboration with the HAVIP service to ensure the accurate forwarding of data packets in the layer 2 network and improve communication efficiency and quality.
[0115] The embodiment of the present invention also provides a computer device, see Figure 4 , Figure 4 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 4As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 4 A processor 10 is taken as an example.
[0116] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.
[0117] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.
[0118] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0119] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.
[0120] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.
[0121] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.
[0122] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.
[0123] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the defined scope.
Claims
1. A cloud-based and cloud-based two-layer network interconnection system, characterized in that: The system includes: an on-cloud VPC module and an off-cloud IDC module connected via a tunnel module; The cloud VPC module includes 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; The off-cloud IDC module includes an off-cloud subnet unit, and the off-cloud subnet unit is used to provide an off-cloud network environment for the off-cloud host in the off-cloud IDC module; the on-cloud subnet unit is connected to the off-cloud 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, and the L2GW network element is used to handle the Layer 2 communication events between the cloud host and the off-cloud 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 set in the first connection subnet; The first connection subnet is used to provide a connection network node for the host on the cloud and other network devices; the other network devices include L2GW network elements and the host under the cloud; The tunnel subnet includes an L2GW port, and the tunnel subnet is used to carry the data packets encapsulated by the VPC module on the cloud to achieve Layer 2 network interconnection between the host on the cloud and the host off the cloud; 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 accesses 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 DC dedicated line and a VPN virtual private network line; The other end of the L2GW network element is connected to the IDC module under the cloud through the VTEP port and the DC dedicated line in sequence; The other end of the VPC module on the cloud is also connected to the IDC module under the cloud through the VTEP port and the VPN virtual private network line in sequence.
4. The system according to claim 3, characterized in that The off-cloud IDC module further includes a switch unit, and the off-cloud subnet unit includes a second connection subnet; The second connection subnet is used to provide a connection network node for the host under the cloud and other network devices; the other network devices include L2GW network elements and the host on the cloud; The other 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; The other end of the VPC module on the cloud is also connected to one end of the switch unit through 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. The system according to claim 1, characterized in that The L2GW network elements are deployed in a cluster manner, and a plurality of the L2GW network elements share a virtual IP address.
6. A method for interconnecting two-layer networks on and off the cloud, characterized in that: The method is applied to a cloud-on-cloud-off-cloud Layer 2 network intercommunication system according to any one of claims 1 to 5, and the method comprises: When the host on the cloud communicates, a first data packet is sent to the L2GW network element, where the first data packet includes the virtual IP address of the L2GW network element, the IP address of the host on the cloud, the MAC address of the host on the cloud, the IP address of the host off the cloud, and the MAC address of the L2-Connection Port. When the L2GW network element receives the first data packet, the virtual IP address of the VGW virtual gateway, the VTEP port information of the host under the cloud, and the tunnel subnet information are added to the first data packet to obtain a second data packet, and the second data packet is forwarded to the tunnel module; 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, a third data packet is obtained after encapsulation, and the third data packet is parsed and processed by the VXLAN tunnel and transmitted to the off-cloud host; When the host under the cloud receives the third data packet after the VXLAN tunnel parsing process, the third data packet after the VXLAN tunnel parsing process is decapsulated in reverse process through the tunnel module and the L2GW network element in sequence, so that the host on the cloud obtains the decapsulated target data packet.
7. The method according to claim 6, characterized in that The decapsulation process of the reverse process includes: Removing the VNI identifier information and the VTEP port information of the user dedicated line in the third data packet after the VXLAN tunnel parsing process by the tunnel module, obtaining a fourth data packet; The tunnel subnet information of the fourth data packet and the virtual IP address of the VGW virtual gateway are removed by the L2GW network element to obtain the target data packet, and the target data packet is sent to the cloud host.
8. The method according to claim 6, characterized in that The L2GW network element is used to learn ARP information of the host on the cloud and the host off the cloud, and the method further includes: When the off-cloud host communicates with the on-cloud host, the off-cloud host sends a first ARP request to the L2GW network element; After receiving the first ARP request, the L2GW network element performs a proxy processing on the first ARP request, and provides the MAC address of the cloud host to the off-cloud host, so that the off-cloud host communicates with the cloud host based on the MAC address of the cloud host; When the host on the cloud communicates with the host off the cloud, the host on the cloud 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 host on the cloud is located; After receiving the second ARP request, if the ARP table of the L2GW network element does not contain an ARP entry of the host under the cloud corresponding to the second ARP request, the L2GW network element sends the second ARP request to the host under the cloud; After receiving the second ARP request, the host under the cloud sends the MAC address of the host under the cloud to the L2GW network element for the L2GW network element to learn; The L2GW network element sends the learned MAC address of the off-cloud host to the on-cloud host, so that the on-cloud host communicates with the off-cloud host based on the MAC address of the off-cloud host.
9. The method according to claim 8, characterized in that The L2GW network element processes a layer 2 communication event between the host on the cloud and the host off the cloud based on the HAVIP service, and the method further includes: When the master node and the standby node of the HAVIP service are both deployed on the VPC module on the cloud, if the master node and the standby node are switched, the local table of the L2GW network element is updated by the controller in the VPC module on the cloud, and the ARP information synchronization operation of the host under the cloud is triggered; When the master node and the standby node are both deployed on the off-cloud IDC module, if the master node and the standby node are switched, the off-cloud host sends ARP information to the L2GW network element, and the on-cloud host updates the flow table of the on-cloud host and the local table of the L2GW network element; When the master node is deployed on the VPC module on the cloud, and the standby node is deployed on the IDC module off the cloud, if the master node and the standby node are switched, the host off 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; When the master node is deployed on the IDC module under the cloud and the standby node is deployed on the VPC module on the cloud, if the master node and the standby 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 causes the L2GW network element to send ARP information to refresh the ARP table of the host under the cloud.
10. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the on-cloud and off-cloud layer two network intercommunication method described in any one of claims 6 to 9 by executing the computer instructions.
Citation Information
Patent Citations
Internet element and network intercommunication method, system and device, and computer medium
CN110868474A
Data forwarding method and device under virtual network and computer program product
CN115225634A
Cloud network system and interaction method of cloud network system
CN116996343A
Intelligent service layer for separating application from physical networks and extending service layer intelligence over IP across the internet, cloud, and edge networks
US20210168125A1
Cited By
Cloud private line arrangement management method and device, electronic equipment and medium
CN121691431A
Cloud dedicated line orchestration and management methods, devices, electronic equipment and media
CN121691431B