WO2018032910A1 - Procédé et appareil de communication inter-réseaux - Google Patents
Procédé et appareil de communication inter-réseaux Download PDFInfo
- Publication number
- WO2018032910A1 WO2018032910A1 PCT/CN2017/092526 CN2017092526W WO2018032910A1 WO 2018032910 A1 WO2018032910 A1 WO 2018032910A1 CN 2017092526 W CN2017092526 W CN 2017092526W WO 2018032910 A1 WO2018032910 A1 WO 2018032910A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data packet
- vlan
- host
- virtual machine
- vni
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/58—Association of routers
- H04L45/586—Association of routers of virtual routers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/66—Layer 2 routing, e.g. in Ethernet based MAN's
Definitions
- the present invention relates to the field of wireless communication technologies, and in particular, to a method and device for communicating across a network.
- Heterogeneous cloud network means that two or more private clouds use different access technologies, or private clouds that use the same wireless access technology but belong to different wireless carriers are intelligently integrated through inter-system convergence. Together, a variety of different types of private clouds are provided to provide users with wireless access anytime, anywhere, thereby forming a heterogeneous cloud network.
- VMs virtual machines
- VLAN Virtual Local Area Network
- IP Internet Protocol
- VXLAN Virtual eXtensible Local Area Network
- GRE Generic Routing Encapsulation
- VPN Virtual Private Network
- the present invention provides a method and a device for communicating across a network, so as to solve the problem that the network security of the agent needs to be deployed in the VM and the additional network card is virtualized when the communication between different Layer 2 networks is implemented.
- a method for communicating across a network is provided.
- the method can be applied to communication between a first virtual machine VM and a second VM.
- the first VM is located at the first host Host, and the second VM is located at the second host.
- a routing virtual machine is created in a host, and the method may include:
- the routing virtual machine receives the first vlan data packet sent by the first virtual switch in the first host, and the first vlan data packet is encapsulated by the Ethernet data packet sent by the first VM, where the first vlan data packet includes: The vlan identifier of the first vlan port corresponding to the VM and the address information of the second VM, and the first vlan data packet is encapsulated into a first VNI including a coverage domain for identifying a layer 2 network where the first VM is located After the VXLAN data packet, sending the first VXLAN data packet to the second Host, so that the second Host is based on the address information of the second VM, And the first VNI, the first VXLAN packet is processed and sent to the second VM.
- routing virtual machine is an element capable of realizing communication across the network based on the description of the present invention, and is merely for convenience of describing the solution provided by the present invention, and does not indicate or imply that the component must be named thereby.
- the routing switch may be named as an OVS-vAPP virtual machine, and may also be named as a virtual machine of another name, and thus cannot be construed as limiting the present invention.
- the routing virtual machine intercepts the data packet sent by the VM, encapsulates the data packet sent by the VM into a three-layer VXLAN data packet, and sends the encapsulated VXLAN data packet to the VM in the other private cloud through the three-layer tunnel technology.
- the interworking between different Layer 2 networks is realized, and the problem of reducing the security caused by deploying agents in the VM and virtualizing additional network cards is avoided.
- the routing virtual machine can receive the first vlan packet sent by the first virtual switch by using the following implementation manner:
- the second vlan port can be created on the first switch, the second vlan port and the first vlan port have the same vlan identifier, and the second vlan port and the route
- the second virtual switch in the virtual machine is connected to the first virtual switch that is sent by the first virtual switch in the first host, and the routing virtual machine may include:
- the second virtual switch in the routing virtual machine receives the first vlan data packet sent by the first virtual switch through the second vlan port;
- the routing virtual machine encapsulating the first vlan data packet into the first VXLAN data packet may include:
- the second virtual switch in the routing virtual machine encapsulates the first vlan data packet into the first VXLAN data packet.
- a trunk trunk port may be created on the first switch, the routing virtual machine includes a second virtual switch, and the third virtual switch has a third vlan port.
- the trunk port is connected to the third vlan port, and the third vlan port has the same vlan identifier as the first vlan port; the routing virtual machine receives the first vlan data packet sent by the first virtual switch in the first host, including:
- the routing virtual machine receives the first vlan data packet sent by the first virtual switch in the first host through the trunk port;
- the routing virtual machine sends the first vlan data packet to the second virtual switch by using the vlan identifier in the first vlan data packet through the third vlan port corresponding to the vlan identifier.
- the routing virtual machine encapsulates the first vlan data packet into the first VXLAN data packet, including:
- the second virtual switch in the routing virtual machine encapsulates the first vlan data packet into the first VXLAN data packet.
- the routing virtual machine can intercept the traffic sent by the VM in the Host for subsequent processing and send it to the peer VM.
- the first Host may be located in the first private cloud, and the second Host may be located in the second private cloud, the first The private cloud includes a first Layer 2 gateway, and the second private cloud includes a second Layer 2 gateway; the routing virtual machine sending the first VXLAN packet to the second Host may include:
- the routing virtual machine sends the first VXLAN data packet to the first layer 2 gateway, and the first layer 2 gateway receives the first VNI in the first VXLAN data packet according to the preset correspondence between the first VNI and the second VNI. Modifying to the second VNI, and passing the first VXLAN packet including the second VNI through the first Layer 2 gateway and the second Layer 2 gateway The VXLAN tunnel is sent to the second layer 2 gateway, and the second layer 2 gateway changes the second VNI in the received first VXLAN packet to the first according to the preset correspondence between the first VNI and the second VNI. VNI, and sends the first VXLAN data packet to the second Host according to the first VNI.
- the VXLAN packet encapsulated by the routing virtual machine can be sent to the Layer 2 gateway in the other private cloud through the tunnel technology through the Layer 2 gateway in the private cloud, and processed by the Layer 2 gateway in the other private cloud, and then sent to the Layer 2 gateway in the other private cloud.
- the OVS-vApp virtual machine may be added only in one Host, and all VMs in any other Host may be implemented by the OVS-vApp virtual machine.
- the communication between itself and other VMs that is, in another implementation manner of the first aspect, in combination with the first aspect or any one of the first aspects, the present invention can also implement the third method by the following method. Communication between the VM and the second VM, the third VM is located in the third host, the first Host and the third Host are located in the first private cloud, the first private cloud further includes: a physical switch, and the OVS-vApp is not deployed in the third Host virtual machine:
- the routing virtual machine receives the third vlan data packet sent by the physical switch and sent by the virtual switch in the third host to the physical switch, and the third vlan data packet is encapsulated by the Ethernet data packet sent by the third VM, and the Ethernet data packet is formed.
- the third vlan data packet includes: a vlan identifier of the fourth vlan port corresponding to the third VM, and address information of the second VM, and the routing virtual machine encapsulates the third vlan data packet into a second VXLAN packet, and sending a second VXLAN packet to the second host, so that the second Host processes the second VXLAN packet and sends the packet to the second VM according to the address information of the second VM and the second VNI.
- the second VNI is used to identify the coverage area of the Layer 2 network where the third VM is located.
- the routing virtual machine is not deployed in the host, the data packet sent by the VM in the host is encapsulated in the VXLAN by the routing virtual machine in the other host, and the encapsulated VXLAN data packet is sent by the routing virtual machine to the routing virtual machine.
- a second aspect provides a routing virtual machine, including a sending unit, a packaging unit, and a receiving unit;
- a receiving unit configured to receive a first vlan data packet sent by the first virtual switch in the first host
- a packaging unit configured to encapsulate the first vlan data packet received by the receiving unit into a first VXLAN data packet
- the sending unit is further configured to send, to the second host, the first VXLAN data package encapsulated by the unit.
- the specific implementation manner of the second aspect may refer to the behavior of the virtual machine in the cross-network communication method provided by the first aspect or the possible implementation manner of the first aspect. Therefore, the routing virtual machine provided by the second aspect may reach The same benefits as the first aspect.
- a route virtual machine including a processor and a transceiver;
- a transceiver configured to receive a first vlan data packet sent by the first virtual switch in the first host
- a processor configured to encapsulate the first vlan data packet received by the transceiver into a first VXLAN data packet
- the processor is further configured to send the first VXLAN data package after the processor is encapsulated to the second host.
- the specific implementation manner of the third aspect may refer to the behavior of the virtual machine in the method for cross-network communication provided by the first aspect or the possible implementation manner of the first aspect. Therefore, the routing virtual machine provided by the third aspect may reach The same benefits as the first aspect.
- a non-transitory computer readable storage medium storing one or more programs, the instructions comprising instructions, when included in the second aspect or the third aspect or any of the above, Implementation When the routing virtual machine executes, the routing virtual machine performs the following events:
- the specific implementation manner of the fourth aspect may refer to the behavior of the virtual machine in the cross-network communication method provided by the first aspect or the possible implementation manner of the first aspect. Therefore, the routing virtual machine provided by the fourth aspect may reach The same benefits as the first aspect.
- FIG. 1 is a schematic diagram of an architecture of a heterogeneous cloud network
- FIG. 2 is a schematic structural diagram of a heterogeneous cloud network according to an embodiment of the present invention.
- FIG. 3 is a schematic structural diagram of a physical host according to an embodiment of the present disclosure.
- FIG. 4 is a flowchart of a method for communicating across a network according to an embodiment of the present invention
- FIG. 5 is a structural diagram of a host machine according to an embodiment of the present invention.
- FIG. 5B is a structural diagram of still another host machine according to an embodiment of the present invention.
- FIG. 6 is a schematic diagram of a process of communicating across a network according to an embodiment of the present invention.
- FIG. 7 is a schematic diagram of a process of communicating across a network according to an embodiment of the present invention.
- FIG. 8 is a schematic structural diagram of an OVS-vAPP virtual machine according to an embodiment of the present disclosure.
- FIG. 9 is a schematic structural diagram of an OVS-vAPP virtual machine according to an embodiment of the present invention.
- the principle of the present invention is: adding a routing virtual machine in the host where the VM is located, the routing virtual machine intercepts the data packet sent by the VM, encapsulates the data packet sent by the VM into a VXLAN data packet, and encapsulates the VXLAN packet.
- the data packets are sent to the VMs in other private clouds through the overlay network technology, so as to achieve interworking between different Layer 2 networks, avoiding the deployment of agents in the VM and virtualizing additional network cards.
- the routing virtual machine is an element capable of realizing communication across the network based on the description of the present invention, and is merely for convenience of describing the solution provided by the present invention, and does not indicate or imply that the component must be named thereby. Therefore, the limitation of the present invention is not limited.
- the routing switch may be named as an OVS-vAPP virtual machine, and may also be named as a virtual machine of another name.
- the newly added “routing virtual machine” may be named “OVS-vAPP virtual machine” to describe the method and device for heterogeneous cloud network communication provided by the present invention.
- the method for cross-network communication according to the present invention can be applied to a heterogeneous cloud network to implement communication between VMs in different Layer 2 networks in a heterogeneous cloud network.
- the embodiment of the present invention uses only the heterogeneous cloud network shown in FIG. 1 as an example to describe the method and device for heterogeneous cloud network communication provided by the present invention.
- the VMs in different Layer 2 networks refer to: A VM that is in a different virtual local area network.
- the Layer 2 network can be a Layer 2 virtual network or a Layer 2 physical network.
- the heterogeneous cloud network may include: a cloud manager, and at least one private cloud.
- the cloud management system is composed of multiple servers, and is mainly used for uniformly managing resources (such as computing, network, and storage resources) in a private cloud in a heterogeneous cloud network, and can use IP addresses in the same subnet in different private groups.
- VMs are deployed on the cloud, that is, VMs in different private clouds are assigned IP addresses in the same subnet.
- Different private clouds can be in the same Layer 2 network or not in the same Layer 2 network.
- the same private cloud (referred to as: Cloud) can include Network Server, Layer 2 Gateway (L2G), and Virtual Switch.
- L2G Layer 2 Gateway
- Virtual Switch Virtual Switch
- vSwitch dynamic host configuration protocol
- DCHP dynamic host configuration protocol
- the vSwitch is used to implement data transmission between hosts. Different vlan ports can be deployed in the private network. The vlan ports can be used to isolate packets sent by different VMs through the vlan port.
- the vSwitch and Host can run on the hardware layer of the physical host (not shown in Figure 1) in the private cloud. Each Host can contain multiple VMs. It should be noted that FIG.
- FIG. 1 is only a schematic diagram, and the private cloud, the host machine, and the VM shown in FIG. 1 are only examples, and the number thereof does not limit the solution of the present invention.
- the heterogeneous cloud network can be deployed. Different from the multiple components shown in Figure 1.
- the present invention adds an OVS-vAPP virtual machine to the host of the private cloud, and the VSwitch (ovs) can also be deployed in the OVS-vAPP virtual machine.
- a vlan port with the same function as the vlan port can be created on the OVS-vAPP virtual machine, and the vlan created in the OVS-vAPP virtual machine will be created.
- the port is added to the ovs, so that the traffic sent by the VM passes through the vSwitch in the host, and then flows into the ovs in the OVS-vAPP virtual machine, and all traffic sent by the VM is intercepted by the OVS-vAPP virtual machine, and OVS-vAPP is used.
- the virtual machine processes the intercepted traffic (for example, encapsulated into a VXLAN packet), it is sent to the VMs in other private clouds through the tunnel between the private clouds to implement VM interworking between different networks.
- the OVS-vAPP virtual machine 1041 runs on the Host 104, which runs on the hardware layer of the physical host 10, and the hardware layer may include a Remote Direct Memory Access (RDMA) network card 103.
- the hardware layer may further include at least one processor 102 and a memory 101, and the devices are connected and communicated with each other through a communication bus or a direct connection.
- the Host 104 may further include a plurality of VMs 1042 and vSwitch 1043 in addition to the OVS-vAPP virtual machine 1041.
- Host104 is used as the management layer to manage and allocate hardware resources, and presents a virtual hardware platform for the internal virtual machine.
- the virtual hardware platform runs on each virtual machine (such as: OVS-vAPP virtual machine 1041, VM1042). And vSwitch1043) provides various hardware resources, such as providing virtual processors (VCPUs), virtual memory, virtual disks, virtual network cards, and so on.
- VCPUs virtual processors
- VCPUs virtual memory
- virtual disks virtual disks
- virtual network cards virtual network cards
- the OVS-vAPP virtual machine 1041, VM1042, and vSwitch 1043 work like a real computer.
- the OVS-vAPP virtual machine 1041, VM 1042, and vSwitch 1043 can be installed with operating systems and applications, the OVS-vAPP virtual machine 1041, VM 1042, and The vSwitch1043 also has access to network resources.
- the RDMA network card 103 in the hardware layer may be various network cards supporting the RDMA function, for example, an InfiniBand card or an RDMA over Converged Ethernet (RoCE) card.
- an InfiniBand card or an RDMA over Converged Ethernet (RoCE) card.
- RoCE RDMA over Converged Ethernet
- the processor 102 can be a Central Processing Unit (CPU), or an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.
- CPU Central Processing Unit
- ASIC Application Specific Integrated Circuit
- Memory 101 can include random access memory and provides instructions and data to processor 102.
- the following embodiments show and describe in detail the process of cross-network communication provided by the present invention in the form of steps, wherein the steps shown may be performed in addition to being executed in the OVS-vAPP virtual machine. Executed in a computer system that executes instructions. Moreover, although logical sequences are shown in the figures, in some cases the steps shown or described may be performed in a different order than the ones described herein.
- FIG. 4 is a flowchart of a method for communicating across a network according to an embodiment of the present invention, which may be executed by the OVS-vAPP virtual machine shown in FIG. 2 and FIG. 3, for implementing communication between a first VM and a second VM.
- the first VM is located in the first Host
- the second VM is located in the second Host
- the OVS-vAPP virtual machine is located in the first Host.
- the method may include the following steps:
- the OVS-vAPP virtual machine receives the first vlan data packet sent by the first virtual switch in the first host, where the first vlan data packet is encapsulated by an Ethernet data packet sent by the first VM, and the Ethernet data packet is encapsulated.
- the first vlan data packet includes: a vlan identifier of the first vlan port corresponding to the first VM, and address information of the second VM.
- the first VM may be any VM in the first Host, and the Ethernet data packet sent by the first VM may include, but is not limited to, the following types of data packets: media access control for requesting acquisition of the first VM (Media) An Address Resolution Protocol (ARP) of an Access Control (MAC) address, a data packet for requesting acquisition of an IP address of a first VM, and a data packet for requesting service data.
- media access control for requesting acquisition of the first VM
- ARP Address Resolution Protocol
- MAC Access Control
- the vlan identifier is used to identify the first vlan port, and the first vlan port can be deployed on the first virtual switch and connected to the first VM.
- the address information of the second VM may be the IP address of the second VM or the MAC address of the second VM.
- the first VM may send the Ethernet packet sent by itself to the first virtual switch by using the first vlan port connected to the first VM, where the first virtual switch is from the first vlan.
- the port After receiving the Ethernet data packet, the port generates the first vlan data packet by encapsulating the Ethernet data packet with the vlan identifier of the first vlan port according to the vlan identifier of the first vlan port, for example, the head of the Ethernet data packet. Add the vlan ID of the first vlan port. It should be noted that, in the process of generating the first vlan data packet, including but not limited to adding the vlan identifier only on the Ethernet data packet, in addition, you can add: Layer Ethernet header, inner IP header, and other payloads.
- the OVS-vAPP virtual machine can receive the first vlan data packet sent by the first virtual switch in the following two manners:
- Manner 1 The second vlan port is created on the first switch, the second vlan port has the same vlan identifier as the first vlan port, and the second vlan port is connected to the second virtual switch in the OVS-vAPP virtual machine.
- the first virtual switch may search for the first vlan port after the first vlan port corresponding to the first vlan identifier according to the first vlan identifier in the encapsulated first vlan data packet, and the encapsulated first vlan data packet. Sended through the second vlan port;
- the second virtual switch in the OVS-vAPP virtual machine can receive the first vlan packet sent by the first virtual switch from the second vlan port.
- the second vlan port and the first vlan port have the same vlan identifier, and the second vlan port and the first vlan port have the same function, and the second vlan port supports transmitting the data packet sent from the first vlan port.
- the first vlan port and the second vlan port may be named by the same name, or may be named by different names, which is not limited by the embodiment of the present invention.
- VM1 and VM2 two virtual machines are included in Host1: VM1 and VM2, VM1 is connected to vlan1 port on vSwtich1, and VM2 is connected to vlan2 port on vSwtich1.
- vlan1 can be added to vSwtich1.
- a port with the same function as the vlan port and the vlan port with the same function as the vlan2 port, and the vlan port with the same function as the vlan1 port and the vlan port with the same function as the vlan2 port are connected to the ovs (as shown in the virtual box in Figure 5A).
- vSwtich1 After receiving the Ethernet packet sent by VM1 through the vlan1 port, vSwtich1 encapsulates the Ethernet packet into a vlan packet and sends it to the ovs through the vlan port in the virtual box that has the same function as the vlan1 port. .
- Manner 2 Create a trunk port on the first switch, create a third vlan port on the second virtual switch in the OVS-vAPP virtual machine, connect the trunk port to the third vlan port, and connect the third vlan port with The first vlan port has the same vlan identifier;
- the first virtual switch can send the encapsulated first vlan packet through the trunk port;
- the OVS-vAPP virtual machine can receive the first vlan data packet sent from the trunk port, according to the first vlan identifier in the first vlan data packet, and pass the first vlan data packet to the third vlan port with the first vlan identifier. Send to the second virtual switch in the OVS-vAPP virtual machine.
- the third vlan port and the first vlan port have the same vlan identifier, and the third vlan port and the first vlan port have the same function, and the third vlan port supports transmitting the data packet sent from the first vlan port.
- the first vlan port and the third vlan port may be named by the same name, or may be named by different names, which is not limited in this embodiment of the present invention.
- VM1, VM2, VM1 and vSwtich1 are included in Host1: VM1, VM2, VM1 and vSwtich1.
- the VM2 is connected to the vlan2 port on the vSwtich1, and the trunk port is created on the vSwtich1.
- the vlan port with the same function as the vlan1 port and the vlan port with the same function as the vlan2 port are created on the ovs (as shown in Figure 5B).
- the trunk port is connected to the vlan port on the ovs.
- the vSwtich1 can encapsulate the Ethernet packet into the first vlan packet after receiving the Ethernet packet sent by the VM1 through the vlan1 port.
- the OVS-vAPP virtual machine receives the first vlan data packet through the trunk port in the virtual box, and sends the first vlan data packet according to the vlan identifier in the first vlan data packet, and sends the vlan with the same function as the vlan1 port.
- the OVS-vAPP virtual machine encapsulates the first vlan data packet into the first VXLAN data packet, and sends the first VXLAN data packet to the second host, so that the second host sends the first VXLAN data packet to the first The second VM, wherein the first VXLAN data packet includes: a first virtual extended local area network identifier VNI.
- VNI VXLAN Network Identifier
- the OVS-vAPP virtual machine encapsulates the first vlan data packet into the first VXLAN data packet, which may include:
- the vlan identifier in the first vlan packet is removed, and the first VNI is encapsulated.
- the original Ethernet data packet with the vlan identifier removed may be encapsulated: outer layer Ethernet header, outer IP header, User Datagram Protocol (UDP) header, VXLAN tag, and some reserved fields.
- UDP User Datagram Protocol
- the Layer 2 Ethernet data packet can be encapsulated by the Layer 3 protocol to implement the extension of the Layer 2 network in the Layer 3 network, and the VMs in different Layer 2 networks can communicate through the Layer 3 interworking technology.
- the first host when the cross-network communication is performed in the heterogeneous cloud network, the first host may be located in the first private cloud, the second host may be located in the second private cloud, and the first private cloud may include the first second-layer gateway.
- the second private cloud may include a second layer 2 gateway.
- the OVS-vAPP virtual machine sends the first VXLAN data packet to the second host, which may include:
- the OVS-vAPP virtual machine sends the first VXLAN data packet to the first layer 2 gateway;
- the first layer 2 gateway modifies the first VNI in the received first VXLAN data packet to the second VNI according to the preset correspondence between the first VNI and the second VNI, and the first VXLAN including the second VNI
- the data packet is sent to the second layer 2 gateway through the VXLAN tunnel between the first layer 2 gateway and the second layer 2 gateway.
- the second layer 2 gateway modifies the received second VNI in the first VXLAN data packet to the first VNI according to the preset correspondence between the first VNI and the second VNI, and the first VXLAN according to the first VNI
- the data packet is sent to the vSwitch in the second host where the second VM is located;
- the vSwitch in the second Host After receiving the first VXLAN data packet, the vSwitch in the second Host converts the first VXLAN data packet into the second vlan data packet according to the address information of the second VM in the first VXLAN data packet, and removes the second vlan identifier.
- the vlan port corresponding to the vlan identifier is sent to the second VM, where the second vlan data includes the second vlan identifier, and the second vlan identifier is used to identify the vlan port connected to the second VM.
- the cloud management system in the heterogeneous cloud network may pre-configure the VNIs of the first VM and the second VM in different networks, configure the VNIs of the two as the first VNI, and pre-configure the first VNI and the second VNI.
- the first layer 2 gateway and the second layer 2 gateway can obtain the correspondence between the first VNI and the second VNI from the cloud management system, and perform VNI modification according to the correspondence between the first VNI and the second VNI
- Two VNI can Any VNI configured for the first Layer 2 gateway for the cloud management system.
- the cloud management system can configure at least one VNI for the first Layer 2 gateway.
- VM1 is in private cloud 1
- VM2 is in private cloud 2
- L2GW1 in private cloud 1 and L2GW2 in private cloud 2 are interoperable through VXLAN tunnel technology
- VM1 and VM2 have VNIs of 5000
- cloud management system is VNI configured for L2GW1.
- the range is 7000 ⁇ 8999.
- the cloud management system can select unused VNIs from 7000 to 8999, such as 7000, to map VMNIs to VM1 and VM2, and map them. It is delivered to L2GW1 and L2GW2.
- L2GW1 receives the VXLAN packet containing 5000
- the 5000 is modified to 7000
- L2GW2 After receiving the VXLAN packet containing 7000, L2GW2 sends the 7000 modified 5000 to The vSwitch in the Host.
- VM1 is in vlan1 in private cloud 1
- VM2 is in vlan2 in private cloud 2.
- Vlan1 and vlan2 are different virtual local area networks, where the IP addresses of VM1 and VM2 are 10.0.0.100 and 10.0.0.101, respectively:
- 1VM1 finds that the IP address (10.0.0.101) of VM2 to be accessed is in the same network, and sends an ARP packet for obtaining the MAC address corresponding to 10.0.0.101 to vSwitch1 through vlan1.
- the ARP packet contains : The IP address of VM2; after receiving the packet, vSwitch1 adds the identifier of vlan1 to the vlan packet. After that, vSwitch1 sends the vlan packet to the same vlan1 port as vlan1. At this time, the vlan packet enters the ovs in the OVS-vApp virtual switch. After receiving the vlan packet, ovs first removes the vlan identifier and corresponds to VM1. VNI, the vlan packet is converted to a VXLAN packet and forwarded to the L2GW1 in the private cloud 1 through the public port vlan0 of the vSwitch1.
- L2GW1 in the private cloud 1 modifies the VNI in the received VXLAN packet, and the modified VXLAN packet arrives at the L2GW2 in the private cloud 2 through the VXLAN.
- the L2GW2 in the private cloud 2 modifies the VNI in the received VXLAN packet to the VNI of the VM2, and sends the modified VXLAN packet to the vSwitch2 in the Host2 where the VM2 is located according to the VNI of the VM2, after which the vSwitch2 is based on VM2's IP address, remove the VNI in the received VXLAN packet, convert the vlan2 ID corresponding to VM2 into a vlan packet, and then remove the vlan flag to become an ARP packet and enter VM2 through vlan2.
- VM2 receives the After the ARP packet, it will directly reply to VM1 with its own MAC address.
- the foregoing describes only the communication between the VM in one Host and the VM in the other Host. If the VM of any other Host needs to communicate with the VM in the other Host, the The OVS-vApp virtual machine is added to the host, and the VMs are interoperable through the above methods. That is, the OVS-vApp virtual machine can be added to each Host, and the VM and other VMs in the Host can be realized by the OVS-vApp virtual machine. Communication between VMs in the Host.
- the OVS-vApp virtual machine may be added only in one Host, and all VMs in any other Host may be implemented by the OVS-vApp virtual machine.
- the communication between the third VM and the second VM is implemented in the embodiment of the present invention.
- the third VM is located in the third host, and the third host is located in the first private cloud.
- a private cloud further includes: a physical switch, and the OVS-vApp virtual machine is not deployed in the third host;
- the OVS-vAPP virtual machine receives the third vlan sent by the physical switch through the virtual switch in the first Host.
- a data packet the third vlan data packet is sent by the virtual switch in the third host to the physical switch, and the third vlan data packet is encapsulated by an Ethernet data packet sent by the third VM, and the Ethernet data packet is sent.
- a data packet to the second VM the third vlan data packet includes: a vlan identifier of the fourth vlan port corresponding to the third VM, and address information of the second VM;
- the OVS-vAPP virtual machine encapsulates the third vlan data packet into a second VXLAN data packet, and sends a second VXLAN data packet to the second host, so that the second host sends the second VXLAN data packet to the second VM.
- the second VXLAN data packet includes: a second virtual VNI, where the second VNI is used to identify a coverage area of the Layer 2 network where the third VM is located.
- the physical switch can be configured with a first trunk port corresponding to the third host and a second trunk port corresponding to the first host, and the virtual switch in the third host can use the trunk port to send the third vlan packet.
- the physical switch can send the third vlan packet to the vSwitch in the first host through the second trunk port, and the vlan receives the received third vlan packet to the OVS-vAPP virtual machine, where OVS A vlan port with the same function as the vlan port connected to the third VM is created on the -vAPP virtual machine.
- the process of sending the second VXLAN data packet to the second host by the OVS-vAPP virtual machine is the same as the process of sending the first VXLAN data packet to the second host by the OVS-vAPP virtual machine, and details are not described herein again.
- VM3 is in vlan3 in private cloud 1
- VM2 is in vlan2 in private cloud 2.
- Vlan3 and vlan2 are different virtual local area networks, wherein the IP addresses of VM3 and VM2 are 10.0.0.102 and 10.0.0.101, respectively:
- 1VM3 finds that the IP address (10.0.0.101) of VM2 to be accessed is in the same network, and sends an ARP packet for obtaining the MAC address corresponding to 10.0.0.101 to vSwitch3 through vlan3.
- the ARP packet contains : The IP address of VM2; after receiving the packet, vSwitch3 adds the identifier of vlan3 to the vlan packet. After that, vSwitch3 sends the vlan packet to the physical switch through the trunk2 port. The physical switch sends the received vlan packet to vSwitch1 in Host1 through the trunk1 port. vSwitch1 sends the vlan packet through the same vlan port as vlan1.
- the ovs When the vlan packet enters the ovs in the OVS-vApp virtual switch, the ovs first removes the vlan identifier after receiving the vlan packet, and puts the VNI corresponding to the VM3, and converts the vlan packet into a VXLAN packet through the public port of the vSwitch1. Vlan0 is forwarded to L2GW1 in private cloud 1.
- L2GW1 in the private cloud 1 modifies the VNI in the received VXLAN packet, and the modified VXLAN packet arrives at the L2GW2 in the private cloud 2 through the VXLAN.
- the L2GW2 in the private cloud 2 modifies the VNI in the received VXLAN packet to the VNI of the VM2, and sends the modified VXLAN packet to the vSwitch2 in the Host2 where the VM2 is located according to the VNI of the VM2, after which the vSwitch2 is based on VM2's IP address, remove the VNI in the received VXLAN packet, convert the vlan2 ID corresponding to VM2 into a vlan packet, and then remove the vlan flag and change the ARP packet to vm2 through vlan2.
- vm2 receives the IP address. After the ARP packet, it will directly reply to VM3 with its own MAC address.
- the embodiment of the present invention provides a method for communicating across a network.
- the OVS-vAPP virtual machine receives the first vlan data packet sent by the first virtual switch in the first host, and encapsulates the first vlan data packet into the first packet. VXLAN And transmitting the first VXLAN data packet to the second host, so that the second host processes the first VXLAN data packet and sends the data to the second VM.
- the communication between the VMs is realized by the OVS-vAPP virtual machine, and there is no need to deploy the agent in the VM and virtualize the additional network card, thereby avoiding the need to deploy the agent in the VM when implementing communication between different Layer 2 networks. And the problem of reduced network security caused by virtualizing additional network cards.
- the above-mentioned scheme for cross-network communication provided by the embodiment of the present invention is mainly introduced from the perspective of the OVS-vAPP virtual machine.
- the OVS-vAPP virtual machine includes corresponding hardware structures and/or software modules for performing various functions in order to implement the above functions.
- the present invention can be implemented in a combination of hardware or hardware and computer software in combination with the elements and algorithm steps of the various examples described in the embodiments disclosed herein. Whether a function is implemented in hardware or computer software to drive hardware depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods for implementing the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the present invention.
- the embodiment of the present invention may divide the function module of the OVS-vAPP virtual machine according to the foregoing method example.
- each function module may be divided according to each function, or two or more functions may be integrated into one processor.
- the above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of the module in the embodiment of the present invention is schematic, and is only a logical function division, and the actual implementation may have another division manner.
- FIG. 8 is a schematic diagram showing a possible structure of the OVS-vAPP virtual machine involved in the foregoing embodiment.
- the OVS-vAPP virtual machine is shown in FIG. 20 may include a receiving unit 201, a packaging unit 202, and a transmitting unit 203.
- the receiving unit 201 is configured to support the OVS-vAPP virtual machine to execute the process S101 in FIG. 4, and the encapsulating unit 202 and the sending unit 203 are used to jointly support the OVS-vAPP virtual machine to execute the process S102 in FIG. 4. All the related content of the steps involved in the foregoing method embodiments may be referred to the functional descriptions of the corresponding functional modules, and details are not described herein again.
- FIG. 9 shows a possible structural diagram of the OVS-vAPP virtual machine involved in the above embodiment.
- the OVS-vAPP virtual machine 300 includes a processor 3011, a memory 3012, a transceiver 3013, and a communication bus 3014.
- the processor 3011, the memory 3012, and the transceiver 3013 are connected to each other through a communication bus 3014.
- the communication bus 3014 may be a peripheral component interconnection.
- PCI Peripheral Component Interconnect
- EISA Extended Industry Standard Architecture
- the bus can be divided into an address bus, a data bus, a control bus, and the like.
- the processor 3011 may be a processor or a controller, and may be, for example, a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), and an application specific integrated circuit (Application-Specific). Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) or other programmable logic device, transistor logic device, hardware component, or any combination thereof. It is possible to implement or carry out the various illustrative logical blocks, modules and circuits described in connection with the present disclosure.
- CPU central processing unit
- DSP digital signal processor
- ASIC Application-Specific
- FPGA Field Programmable Gate Array
- the processor may also be a combination of computing functions, for example, including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc., for controlling and managing the actions of the OVS-vAPP virtual machine, for example,
- the processor 3011 is configured to support the encapsulation process in S102 in FIG. 4,
- the transceiver 3013 may be a transceiver circuit or a communication interface or the like for performing the process S101 in FIG. 4 and the transmitting process in the process S102 in FIG.
- the disclosed system, apparatus, and method may be implemented in other manners.
- the device embodiments described above are merely illustrative.
- the division of the unit is only a logical function division.
- there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
- the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some port, device or unit, and may be electrical or otherwise.
- the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network devices. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
- each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each functional unit may exist independently, or two or more units may be integrated into one unit.
- the above integrated unit can be implemented in the form of hardware or in the form of hardware plus software functional units.
- the above-described integrated unit implemented in the form of a software functional unit can be stored in a computer readable storage medium.
- the software functional units described above are stored in a storage medium and include instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform portions of the steps of the methods described in various embodiments of the present invention.
- the foregoing storage medium includes: Universal Serial Bus (USB) flash drive (English: USB flash drive), mobile hard disk, read-only memory (English: read-only memory, ROM), random access
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
La présente invention se rapporte au domaine technique des communications sans fil et concerne un procédé et un appareil de communication inter-réseaux, utilisés pour résoudre le problème existant de sécurité de réseau réduite provoquée par le déploiement d'un agent dans une machine virtuelle (VM, "virtual machine") et par la virtualisation d'une carte de réseau supplémentaire, tout en mettant en oeuvre une communication entre différents réseaux à deux couches. Le procédé comprend les étapes suivantes : une machine virtuelle de routage reçoit un premier paquet de données VLAN envoyé par un premier commutateur virtuel dans un premier hôte, encapsule le premier paquet de données VLAN en un premier paquet de données VXLAN, et envoie le premier paquet de données VXLAN à un second hôte, de telle sorte que le second hôte envoie le premier paquet VXLAN à une seconde VM après traitement.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610698154.1A CN107770064A (zh) | 2016-08-19 | 2016-08-19 | 一种跨网络通信的方法、设备 |
| CN201610698154.1 | 2016-08-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2018032910A1 true WO2018032910A1 (fr) | 2018-02-22 |
Family
ID=61196278
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2017/092526 Ceased WO2018032910A1 (fr) | 2016-08-19 | 2017-07-11 | Procédé et appareil de communication inter-réseaux |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN107770064A (fr) |
| WO (1) | WO2018032910A1 (fr) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111225071A (zh) * | 2018-11-23 | 2020-06-02 | 深信服科技股份有限公司 | 一种云平台及跨云平台网络互通系统、方法 |
| CN113381920A (zh) * | 2020-03-09 | 2021-09-10 | 中国移动通信有限公司研究院 | 一种数据传输方法、节点和存储介质 |
| CN113783765A (zh) * | 2021-08-10 | 2021-12-10 | 济南浪潮数据技术有限公司 | 一种实现云内网和云外网互通的方法、系统、设备和介质 |
| CN114285661A (zh) * | 2021-12-28 | 2022-04-05 | 中国银联股份有限公司 | 一种私有网络接入方法、装置、设备及存储介质 |
| CN114356493A (zh) * | 2021-11-26 | 2022-04-15 | 阿里巴巴新加坡控股有限公司 | 跨云服务器的虚拟机实例之间的通信方法、装置及处理器 |
| CN114500162A (zh) * | 2020-10-23 | 2022-05-13 | 中国移动通信有限公司研究院 | Sd-wan系统和数据转发方法 |
| CN116132221A (zh) * | 2023-04-04 | 2023-05-16 | 鹏城实验室 | 网络靶场平台的虚实互联方法、装置、设备及存储介质 |
| CN116800486A (zh) * | 2023-06-13 | 2023-09-22 | 中科驭数(北京)科技有限公司 | 云网络通信方法及系统 |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108833545A (zh) * | 2018-06-19 | 2018-11-16 | 福建江夏学院 | 一种解决平滑迁移中心间主机跨overlay三层互访的方法 |
| CN109194640A (zh) * | 2018-08-27 | 2019-01-11 | 北京安数云信息技术有限公司 | 一种虚拟化平台东西向流量隔离防护方法 |
| CN109525477A (zh) * | 2018-09-30 | 2019-03-26 | 华为技术有限公司 | 数据中心中虚拟机之间的通信方法、装置和系统 |
| CN111262771B (zh) * | 2018-11-30 | 2021-06-22 | 北京金山云网络技术有限公司 | 虚拟私有云通信系统、系统配置方法及控制器 |
| CN110233750B (zh) * | 2019-05-15 | 2023-04-07 | 咪咕文化科技有限公司 | 私有云管理系统及方法 |
| CN113176928B (zh) * | 2021-04-27 | 2022-08-30 | 深圳市研唐科技有限公司 | 一种异构虚拟机的运行方法和装置 |
| CN113630275B (zh) * | 2021-08-13 | 2024-03-19 | 华云数据控股集团有限公司 | 虚拟机管理器集群的网络互通方法、计算设备和存储介质 |
| CN114051246B (zh) * | 2021-11-16 | 2024-02-20 | 酒泉钢铁(集团)有限责任公司 | 基于sdn+vxlan网络与企业5g网络融合的方法 |
| CN115189920A (zh) * | 2022-06-16 | 2022-10-14 | 阿里巴巴(中国)有限公司 | 跨网络域通信方法和相关装置 |
| CN115208888B (zh) * | 2022-09-13 | 2022-12-27 | 杭州优云科技有限公司 | 云实例跨可用区的通信方法及装置和电子设备 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103095546A (zh) * | 2013-01-28 | 2013-05-08 | 华为技术有限公司 | 一种处理报文的方法、装置及数据中心网络 |
| US20140201733A1 (en) * | 2013-01-15 | 2014-07-17 | International Business Machines Corporation | Scalable network overlay virtualization using conventional virtual switches |
| CN104486192A (zh) * | 2014-12-05 | 2015-04-01 | 国云科技股份有限公司 | 一种虚拟网络隔离方法 |
| WO2016127909A1 (fr) * | 2015-02-11 | 2016-08-18 | Hangzhou H3C Technologies Co., Ltd. | Transmission de paquets |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9210079B2 (en) * | 2012-08-14 | 2015-12-08 | Vmware, Inc. | Method and system for virtual and physical network integration |
| WO2015180084A1 (fr) * | 2014-05-29 | 2015-12-03 | 华为技术有限公司 | Procédé de transfert de paquets, et passerelle vxlan |
-
2016
- 2016-08-19 CN CN201610698154.1A patent/CN107770064A/zh active Pending
-
2017
- 2017-07-11 WO PCT/CN2017/092526 patent/WO2018032910A1/fr not_active Ceased
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140201733A1 (en) * | 2013-01-15 | 2014-07-17 | International Business Machines Corporation | Scalable network overlay virtualization using conventional virtual switches |
| CN103095546A (zh) * | 2013-01-28 | 2013-05-08 | 华为技术有限公司 | 一种处理报文的方法、装置及数据中心网络 |
| CN104486192A (zh) * | 2014-12-05 | 2015-04-01 | 国云科技股份有限公司 | 一种虚拟网络隔离方法 |
| WO2016127909A1 (fr) * | 2015-02-11 | 2016-08-18 | Hangzhou H3C Technologies Co., Ltd. | Transmission de paquets |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111225071B (zh) * | 2018-11-23 | 2022-11-22 | 深信服科技股份有限公司 | 一种云平台及跨云平台网络互通系统、方法 |
| CN111225071A (zh) * | 2018-11-23 | 2020-06-02 | 深信服科技股份有限公司 | 一种云平台及跨云平台网络互通系统、方法 |
| CN113381920A (zh) * | 2020-03-09 | 2021-09-10 | 中国移动通信有限公司研究院 | 一种数据传输方法、节点和存储介质 |
| CN113381920B (zh) * | 2020-03-09 | 2022-11-22 | 中国移动通信有限公司研究院 | 一种数据传输方法、节点和存储介质 |
| CN114500162A (zh) * | 2020-10-23 | 2022-05-13 | 中国移动通信有限公司研究院 | Sd-wan系统和数据转发方法 |
| CN113783765A (zh) * | 2021-08-10 | 2021-12-10 | 济南浪潮数据技术有限公司 | 一种实现云内网和云外网互通的方法、系统、设备和介质 |
| CN114356493A (zh) * | 2021-11-26 | 2022-04-15 | 阿里巴巴新加坡控股有限公司 | 跨云服务器的虚拟机实例之间的通信方法、装置及处理器 |
| CN114285661A (zh) * | 2021-12-28 | 2022-04-05 | 中国银联股份有限公司 | 一种私有网络接入方法、装置、设备及存储介质 |
| CN114285661B (zh) * | 2021-12-28 | 2023-06-30 | 中国银联股份有限公司 | 一种私有网络接入方法、装置、设备及存储介质 |
| CN116132221A (zh) * | 2023-04-04 | 2023-05-16 | 鹏城实验室 | 网络靶场平台的虚实互联方法、装置、设备及存储介质 |
| CN116132221B (zh) * | 2023-04-04 | 2023-08-25 | 鹏城实验室 | 网络靶场平台的虚实互联方法、装置、设备及存储介质 |
| CN116800486A (zh) * | 2023-06-13 | 2023-09-22 | 中科驭数(北京)科技有限公司 | 云网络通信方法及系统 |
| CN116800486B (zh) * | 2023-06-13 | 2024-06-07 | 中科驭数(北京)科技有限公司 | 云网络通信方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107770064A (zh) | 2018-03-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2018032910A1 (fr) | Procédé et appareil de communication inter-réseaux | |
| US12143353B2 (en) | Dynamically learning media access control and internet protocol addresses | |
| CN111885075B (zh) | 容器通信方法、装置、网络设备及存储介质 | |
| US11171830B2 (en) | Multiple networks for virtual execution elements | |
| CN112702252B (zh) | 一种报文处理方法、系统及相关设备 | |
| US10778532B2 (en) | Overlay network movement operations | |
| US10708082B1 (en) | Unified control plane for nested clusters in a virtualized computing infrastructure | |
| US9042384B2 (en) | Distributed routing domains in multi-tenant datacenter virtual networks | |
| EP4307115A1 (fr) | Support d'interface de réseau virtuel multiple pour éléments d'exécution virtuels | |
| CN114338606B (zh) | 一种公有云的网络配置方法及相关设备 | |
| US8725898B1 (en) | Scalable port address translations | |
| CN103369027B (zh) | 混合云环境中的位置感知虚拟服务配备 | |
| US20150124823A1 (en) | Tenant dhcp in an overlay network | |
| JP2022541381A (ja) | ハイブリッドクラウド環境における通信方法、ゲートウェイ、並びに管理方法及び装置 | |
| US11671358B2 (en) | Disambiguating traffic in networking environments with multiple virtual routing and forwarding (VRF) logical routers | |
| WO2020135542A1 (fr) | Système de centre de données d'informatique en nuage, passerelle, serveur et procédé de traitement de message | |
| WO2018137369A1 (fr) | Procédé, dispositif et appareil informatique de gestion de nuage hybride | |
| WO2016173271A1 (fr) | Procédé, dispositif et système de traitement de messages | |
| CN105591820A (zh) | 一种高可扩展的容器网络管理系统和方法 | |
| CN111404797B (zh) | 控制方法、sdn控制器、sdn接入点、sdn网关及ce | |
| CN104579898A (zh) | 一种租户隔离方法及系统 | |
| WO2015113410A1 (fr) | Procédé et appareil de traitement de paquets de données | |
| CN113726915B (zh) | 网络系统及其中的报文传输方法和相关装置 | |
| US11469958B1 (en) | Network controller deployment | |
| CN111294268B (zh) | 避免ip地址冲突的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 17840885 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 17840885 Country of ref document: EP Kind code of ref document: A1 |