Detailed Description
The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. Based on the embodiments of the present application, all other embodiments obtained by a person of ordinary skill in the art without making any inventive effort are within the scope of the present application.
It should be noted that in the description of the present application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. The terms "first," "second," and the like in this specification are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order.
The present application will be further described in detail below with reference to the drawings and detailed description for the purpose of enabling those skilled in the art to better understand the aspects of the present application.
The specific application environment architecture or specific hardware architecture upon which the execution of the network interworking method depends is described herein.
The method embodiments provided in the embodiments of the present application may be performed in a mobile terminal, a computer terminal or similar computing device. Taking a computer terminal as an example, fig. 1 is a block diagram of a hardware structure of a computer terminal of a network interworking method according to an embodiment of the present application. As shown in fig. 1, the computer terminal may include one or more (only one is shown in fig. 1) processors 102 (the processor 102 may include, but is not limited to, a microprocessor MCU or a processing device such as a programmable logic device FPGA) and a memory 104 for storing data, wherein the computer terminal may further include a transmission device 106 for communication functions and an input-output device 108. It will be appreciated by those skilled in the art that the configuration shown in fig. 1 is merely illustrative and is not intended to limit the configuration of the computer terminal described above. For example, the computer terminal may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.
The memory 104 may be used to store computer programs, such as software programs and modules of application software, such as computer programs corresponding to the network interworking method in the embodiment of the present application, and the processor 102 executes the computer programs stored in the memory 104 to perform various functional applications and data processing, that is, implement the method described above. Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory remotely located relative to the processor 102, which may be connected to the computer terminal via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The transmission device 106 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, simply referred to as a NIC) that can connect to other network devices through a base station to communicate with the internet. In one example, the transmission device 106 may be a Radio Frequency (RF) module, which is configured to communicate with the internet wirelessly.
Fig. 2 is a flowchart of a network interworking method according to an embodiment of the present application, applied to a computing node in a cloud computing environment. As shown in fig. 2, the process includes the steps of:
Step S202, in the case that a destination node of a first virtual machine flow is a physical server node, performing route matching on the first virtual machine flow through a route table corresponding to a first virtual route and a forwarding instance to obtain a second virtual machine flow, wherein a computing node comprises a virtual machine outputting the first virtual machine flow and the first virtual route and the forwarding instance, and route information of the physical server node is synchronized to the route table through a route reflector connected with the computing node;
it should be noted that, in the embodiment of the present application, the physical server node refers to a bare metal server (BareMetal, which may also be referred to as a bare metal node, a bare metal service, a bare metal, or a bare machine), which is generally used to indicate that no physical server of an operating system has been installed yet. It should be further noted that, in the field of cloud computing, a concept corresponding to a bare metal server in a cloud platform is a cloud physical machine, where the bare metal server in the cloud platform, in which an operating system has been installed, may be referred to as a cloud physical machine.
It should be noted that virtual routing and forwarding (Virtual Routing and Forwarding, abbreviated as VRF) is a technology that allows multiple virtual routing tables to coexist on the same router.
Step S204, sending the second virtual machine traffic to a target switch, and instructing the target switch to send the second virtual machine traffic to the physical server node, so that the virtual machine and the physical server node implement network intercommunication, where the target switch is connected to the physical server node, the route reflector, and the computing node, respectively.
According to the method, route matching is conducted on first virtual machine traffic which is output by a virtual machine in a computing node and is output by the virtual machine in the computing node and is of a physical server node by the aid of a route table corresponding to a first virtual route and a forwarding instance in the computing node, route information of the physical server node is synchronized to the route table by the aid of a route reflector connected with the computing node, the obtained second virtual machine traffic is sent to a target switch, the target switch is used for sending the second virtual machine traffic to the physical server node, and network intercommunication between the virtual machine and the physical server node is achieved, and the target switch is connected to the physical server node, the route reflector and the computing node respectively. Therefore, the method and the device can solve the technical problems that in the related technology, the soft gateway used between the virtual machine and the bare metal node in the computing node in the cloud computing environment has the defects of bandwidth forwarding bottleneck and high scheme cost, and further the network intercommunication effect between the virtual machine and the bare metal node is poor, so that the network intercommunication effect between the virtual machine and the bare metal node is improved.
The embodiment of the application provides a network intercommunication method, which is described in detail by combining the execution flow of the network intercommunication method.
In an exemplary embodiment, before performing route matching on the first virtual machine traffic through a routing table corresponding to a first virtual route and a forwarding instance to obtain a second virtual machine traffic, the method further includes acquiring, through a proxy component, an autonomous system number, a two-layer virtual network identifier and a three-layer virtual network identifier corresponding to the virtual machine from a control node connected with the computing node, and establishing a first preset protocol tunnel between the computing node and the route reflector through a free range routing instance according to the autonomous system number and a preset protocol.
It should be noted that the above-mentioned preset protocol is a border gateway protocol (Border Gateway Protocol, abbreviated AS BGP), a protocol for exchanging routing information between different autonomous systems (Autonomous System, abbreviated AS). The first preset protocol tunnel is a BGP tunnel established between the computing node and the route reflector, where the BGP tunnel specifically refers to a logical connection established through BGP protocol and is used to transfer routing information between different network nodes. Free range Routing (FREE RANGE Routing, FRR for short) is an open source internet protocol (Internet Protocol IP for short) Routing protocol suite for providing dynamic Routing functions for routers, supporting multiple Routing protocols including BGP.
In the embodiment of the application, how to effectively establish a network tunnel between a computing node and a routing reflector by interaction of a proxy component and a control node and by using a Free Range Routing (FRR) example and a preset protocol in a cloud computing environment, particularly in an application scene of a bare metal enhanced gateway (equivalent to the target switch), so as to realize accurate routing and efficient transmission of virtual machine traffic is described.
First, information is obtained from the control node through the proxy component. The agent component (e.g., ovn-bgp-agent) on the compute node plays a role in communicating with the control node. The control node is typically a central management platform in the cloud environment (e.g., a network service of Neutron, openStack) and is responsible for global network configuration and policies. When a virtual machine is created or the network configuration is changed, the proxy component obtains relevant network parameters from the control node, including an autonomous system number (such as bgas) corresponding to the virtual machine, a two-layer virtual network identifier (l 2 vni), and a three-layer virtual network identifier (l 3 vni).
Wherein the autonomous system number (bgas) is used in BGP protocol to identify an autonomous system on the internet. In a cloud environment, the autonomous system number is used for establishing a BGP tunnel between a computing node and a route reflector, so that network isolation and communication in a multi-tenant environment are realized.
Virtual network identifiers (Virtual Network Identifier, abbreviated as VNI) in l2 VNI and l3 vni: VXLAN (Virtual eXtensible Local Area Network), are used to identify different network spaces. l2 vni is used for the isolation of two-layer networks, while l3 vni is used for the routing isolation of three-layer networks. These VNIs a key identification to enable communication between different virtual machines or between virtual machines and bare metal in an overlay network.
Second, a tunnel is established using the FRR instance. At the compute node, the FRR instance is used to establish a first preset protocol tunnel between the compute node and the route reflector based on the bgas and preset protocols obtained from the proxy component. The tunnel is used for transmitting BGP Control plane information, such as route update, media Access Control (MAC) address, and the like, so that the virtual machine on the computing node and the bare metal server on the bare metal enhanced gateway side can share the route information, and the intercommunication of two layers and three layers is realized.
Finally, each VRF on a compute node is an independent routing and forwarding environment, with its own routing table. When the first virtual machine traffic reaches the computing node, three layers of route matching are performed based on the acquired l3 vni through the first virtual route and the route table of the forwarding instance, and a next hop destination is determined. The result of the route matching determines the subsequent flow direction of the traffic, e.g. sent to the bare metal enhanced gateway side or forwarded directly to the local network. The "second virtual machine traffic" actually refers to a state where the traffic is ready for being transmitted next after VRF routes through the computing nodes are matched, and is encapsulated or not encapsulated. If the traffic is destined for another virtual machine, it may need to be encapsulated again and sent out through VXLAN or other overlay technology, and if the destination is a resource within the same VRF, the traffic may be forwarded directly in two or three layers.
Through the steps, the embodiment of the application establishes the efficient and isolated network connection between the computing node and the route reflector by utilizing the mode of combining the preset protocol (such as BGP), the VRF instance and the VNI identifier, so that the virtual machine and the bare metal server can realize seamless and safe communication in a complex cloud environment, and simultaneously, the network performance and the resource utilization efficiency are optimized.
In one exemplary embodiment, obtaining, by a proxy component, an autonomous system number, a two-tier virtual network identifier, and a three-tier virtual network identifier corresponding to the virtual machine from a control node connected to the computing node includes monitoring, by the proxy component, a southbound database in the control node, and extracting, from an external identifier of a network port corresponding to the virtual machine, the autonomous system number, the two-tier virtual network identifier, and the three-tier virtual network identifier, where the autonomous system number, the two-tier virtual network identifier, and the three-tier virtual network identifier are added to the external identifier by a driver component in the control node if the network port is created.
It should be noted that, in a network controller of the cloud environment (such as a Neutron of OpenStack or a southbound database of an open virtual network (Open Virtual Network, abbreviated as OVN)), configuration information of all network ports (including network ports of resources such as virtual machines, bare metals, etc.) is stored. The configuration information includes external identifiers (external_ids) containing additional parameters associated with the network ports, such as autonomous system numbers, two-layer virtual network identifiers, three-layer virtual network identifiers, etc.
Embodiments of the present application continuously monitor a southbound database through a proxy component (e.g., ovn-bgp-agent) pre-deployed on a compute node to capture any changes related to virtual machine network port information. When a new virtual machine network port is created, a driver component (e.g., bgpvpn-ovn-driver) in the control node will add necessary network parameters including autonomous system number, two-layer virtual network identifier, three-layer virtual network identifier to the external identifier of the port. The proxy component, upon detecting that the external identifier of the virtual machine network port is synchronized to the southbound database, extracts the autonomous system number, the two-tier virtual network identifier, the three-tier virtual network identifier, etc. from the external identifier. The process is automatically carried out, so that the quick response and the accuracy of the network configuration of the virtual machine are ensured, and the delay and the error possibly caused by manual intervention are avoided.
In summary, the present embodiment constructs a dynamic and highly adaptive network environment through the real-time monitoring and automated parameter extraction capabilities of the proxy component. The mechanism ensures that even in a complex cloud architecture, network configuration changes can be responded rapidly and accurately, efficient and safe communication between the virtual machine and the bare metal server is realized, meanwhile, the workload of operation and maintenance personnel is reduced, and the automation level and management efficiency of the whole network are improved.
In one exemplary embodiment, after a first preset protocol tunnel between the computing node and the routing reflector is established according to the autonomous system number and a preset protocol through a free range routing instance, the method further includes synchronizing routing information of the virtual machine to the routing reflector through the first preset protocol tunnel to synchronize the routing information of the virtual machine to the target switch through the routing reflector, and synchronizing the routing information in the routing reflector to the routing table corresponding to the first virtual routing and forwarding instance through the first preset protocol tunnel, wherein the routing information in the routing reflector includes the routing information of the physical server node.
Under a cloud computing environment, particularly, a scene related to a bare metal enhanced gateway, ensuring that network information (such as routing information) is accurately and efficiently synchronized among different computing nodes, routing reflectors and target switches is a key for realizing seamless communication between a virtual machine and a bare metal server in an overlay network.
In the embodiment of the application, after the autonomous system number is acquired, the computing node establishes a first preset protocol tunnel from the computing node to the routing reflector through the FRR instance according to the acquired autonomous system number and a preset BGP protocol. Control plane information, such as route update, MAC address learning results, etc., can be transferred between the compute node and the route reflector through the first preset protocol tunnel.
Based on the first preset protocol tunnel, the computing node synchronizes routing information of the virtual machine, e.g., MAC of the virtual machine, VXLAN tunnel endpoint (VXLAN Tunnel Endpoint, abbreviated as VTEP) information, etc., to the routing reflector. After receiving the routing information of the virtual machine, the routing reflector reflects the routing information to other computing nodes and target switches (namely the bare metal enhanced gateway) connected with the routing reflector, so that network equipment of the whole cloud platform is ensured to have the latest routing information, and efficient data forwarding is supported.
The route reflector not only receives and reflects the route information of the virtual machine, but also collects and manages the route information of the physical server node (such as a bare metal server). The routing information of the physical servers is synchronized to a routing table corresponding to the first virtual routing and forwarding instance of the computing node through a preset first preset protocol tunnel.
According to the embodiment, network equipment (comprising the computing node, the routing reflector and the target switch) in the cloud environment can maintain a unified and updated routing information database, so that whether traffic is sent to the virtual machine or the bare metal server, the traffic can be forwarded along an optimal path, and bandwidth bottleneck and delay problems possibly caused by a traditional centralized gateway are avoided. Meanwhile, due to the adoption of the standardized BGP protocol, the scheme has good expandability and hardware compatibility, and can support the network intercommunication requirement in a large-scale cloud environment under the condition of not increasing complexity.
In an exemplary embodiment, after the autonomous system number, the two-layer virtual network identifier and the three-layer virtual network identifier corresponding to the virtual machine are acquired from the control node connected with the computing node through the proxy component, the method further comprises creating the first virtual routing and forwarding instance according to the three-layer virtual network identifier, establishing a virtual ethernet pair between a first bridge device and a second bridge device, wherein the first bridge device is a bridge device corresponding to the first virtual routing and forwarding instance, the second bridge device is a bridge device corresponding to an open virtual switch, and configuring a target component in the first virtual routing and forwarding instance through the two-layer virtual network identifier and the three-layer virtual network identifier, wherein the target component comprises two-layer ports and three-layer ports corresponding to the two-layer bridge device and the three-layer bridge device respectively, and the two-layer ports and the three-layer ports are used for transmitting traffic of the first virtual machine.
In an embodiment of the application, the computing node creates a first virtual routing and forwarding instance from the three-layer virtual network identifier obtained from the control node. A VRF instance may be understood as a network isolated environment that contains independent routing tables and forwarding tables, allowing multiple logical networks to be built on a physical network, each with its own routing policies and network resources.
On the computing node, a virtual ethernet pair between the first bridging device (br-VRF) and the second bridging device (br-int), i.e. the integrated bridge of Open vSwitch (abbreviated as OVS), is also established, through which direct communication between the two bridging devices is allowed, supporting transparent forwarding of traffic between VRF and OVS.
Further, in the computing node, corresponding two-layer bridging devices and three-layer bridging devices are configured in the created first virtual routing and forwarding instance according to the two-layer virtual network identifier and the three-layer virtual network identifier. Each bridging device has a corresponding port for receiving and transmitting traffic from the first virtual machine. Specifically, the two-layer port is responsible for processing the two-layer traffic, and the interoperability of the two-layer network is ensured by encapsulating and decapsulating the VXLAN through the l2 vni set in the first virtual routing and forwarding instance. And the three-layer port is responsible for routing and forwarding the three-layer traffic, performs VXLAN processing according to l3 vni, guides the traffic to the correct next hop, and supports the routing decision of the three-layer network.
In an exemplary embodiment, after configuring a target component in the first virtual routing and forwarding instance through the two-layer virtual network identifier and the three-layer virtual network identifier, the method further includes receiving physical server traffic sent by the physical server node through the first virtual routing and forwarding instance, sending the physical server traffic to the open virtual switch through the virtual ethernet pair, and sending the physical server traffic to the virtual machine through the open virtual switch if the destination node of the physical server traffic is determined to be the virtual machine.
In the case where the physical server node sends traffic to the virtual machine, the traffic starts from the physical server node and enters a first virtual routing and forwarding instance of the computing node. The virtual ethernet pair (veth pair) between the first virtual routing and forwarding instance and the OVS acts as a bridge between the two, so that traffic can be transferred seamlessly between the VRF environment and the OVS. After the physical server traffic is received and processed by the first virtual routing and forwarding instance, the traffic is sent to the OVS over the virtual ethernet pair. Once the physical server traffic reaches the OVS, the OVS checks the destination node of the traffic according to the flow table rules. If it is determined that the destination of this traffic is a virtual machine, the OVS will follow the corresponding forwarding logic, delivering the traffic directly to the target virtual machine. By the method, the physical server flow can quickly pass through forwarding rules of the OVS to directly reach the target virtual machine, unnecessary network paths and processing delays are avoided, and more efficient and direct data packet transmission is realized.
In one exemplary embodiment, after sending the second virtual machine traffic to a target switch and instructing the target switch to send the second virtual machine traffic to the physical server node to enable the virtual machine to network interworking with the physical server node, the method further includes sending the second virtual machine traffic to the target switch through the first virtual routing and forwarding instance and instructing the target switch to send the second virtual machine traffic to the physical server node through a second virtual routing and forwarding instance in the target switch to enable the virtual machine to network interworking with the physical server node.
In the embodiment of the application, when the computing node receives the traffic sent by the first virtual machine and the destination node is identified as the physical server, the traffic is processed through the first virtual routing and forwarding instance of the computing node. The first virtual route and forwarding routing table already contains the routing information of the physical server node, which is synchronized by a route reflector (router-reflector) connected to the computing node. And then through route matching in the first virtual route and the forwarding instance, the first virtual machine traffic is converted into the second virtual machine traffic, and the process comprises VXLAN encapsulation of the traffic so as to adapt to the transmission requirement of the overlay network.
The computing node sends the second virtual machine traffic to the target switch through the first virtual routing and forwarding instance. The target switch in this scenario plays the role of an enhanced gateway for connecting the physical server node and the compute node (including the virtual machine). The target switch is connected with the computing node, the physical server node and the route reflector, so that the target switch can not only receive the traffic from the computing node, but also acquire the route information through the route reflector, and has the capability of directly communicating with the physical server node.
It should be noted that, in all embodiments of the present application, the connection (such as the connection between the target switch and any one of the computing node, the route reflector, and the physical server node, the connection between the route reflector and the computing node, and the connection between the computing node and the control node) includes a physical connection and a communication connection.
After receiving the second virtual machine traffic, the target switch processes the second virtual machine traffic through its internal second virtual routing and forwarding instance, which may include VXLAN decapsulation and destination address-based two-layer or three-layer routing decisions. And the second virtual routing and forwarding instance sends the processed second virtual machine traffic to the physical server node, so that the network intercommunication between the virtual machine and the physical server is realized. The process ensures the safety of the traffic, simultaneously utilizes the characteristic of hardware acceleration, improves the forwarding efficiency, optimizes the traffic management in the overlay network, thereby realizing the efficient network intercommunication between the virtual machine and the physical server node, and simultaneously ensuring the safety and the stability of the network.
In one exemplary embodiment, the method for directing the target switch to send the second virtual machine traffic to the physical server node through a second virtual route and forwarding instance in the target switch comprises directing the target switch to parse a target virtual network identifier corresponding to the second virtual machine traffic, wherein the target virtual network identifier comprises one of a two-layer virtual network identifier corresponding to the virtual machine and a three-layer virtual network identifier corresponding to the virtual machine, directing the second virtual route and forwarding instance to determine a tenant network identifier corresponding to the physical server node based on the target virtual network identifier, and directing the second virtual route and forwarding instance to send the second virtual machine traffic to the physical server node through the tenant network identifier.
In the embodiment of the present application, when the second virtual machine traffic arrives at the target switch, the first step is to parse the target virtual network identifier carried by the second virtual machine traffic, where the identifier may be a two-layer virtual network identifier or a three-layer virtual network identifier, depending on the nature of the traffic (i.e. whether the second-layer traffic or the three-layer traffic). The identification of the target virtual network identifier is the basis for subsequent traffic handling and routing decisions, which directs the target switch how to decapsulate, identify and further process the traffic, ensuring that the traffic can enter the correct VRF instance and be sent to the correct destination.
The second virtual routing and forwarding instance determines a tenant network identity associated with the physical server node based on the parsed target virtual network identifier. This step is based on configuration of the switches and mapping rules defining correspondence between different virtual network identifiers and specific tenant networks. The method and the system ensure that the flow only flows in the correct network environment, effectively avoid the mistransmission of the flow across tenants and improve the safety and the efficiency of the network.
And the second virtual routing and forwarding instance sends the second virtual machine traffic to the corresponding physical server node by using the determined tenant network identification. This process may involve decapsulation of the VXLAN and further forwarding decisions based on MAC addresses (two-layer traffic) or IP addresses (three-layer traffic). And then through the accurate processing of the second virtual routing and forwarding instance, the traffic can reach the physical server node efficiently and without error, and the network intercommunication between the virtual machine and the physical server is realized.
Through a series of operations of the second virtual routing and forwarding instance in the target switch, including resolution of the target virtual network identifier, determination of the tenant network identity, and final forwarding of traffic, an accurate transmission path from the virtual machine to the physical server is constructed. The mechanism not only ensures the high-efficiency and safe processing and forwarding of the traffic in the overlay network environment, but also maintains the network isolation among different tenants, and improves the network performance and the security of the whole cloud computing platform.
In an exemplary embodiment, before route matching is performed on the first virtual machine traffic through a routing table corresponding to a first virtual route and a forwarding instance to obtain second virtual machine traffic, the method further includes instructing the target switch to create the second virtual route and the forwarding instance, instructing the target switch to create a second preset protocol tunnel between the target switch and the route reflector through the second virtual route and the forwarding instance and a preset protocol, and instructing the target switch to perform route information synchronization with the route reflector through the second preset protocol tunnel.
It should be noted that, in this embodiment, the preset protocol is BGP protocol, and the second preset protocol tunnel is a BGP tunnel established between the target switch and the route reflector. And the target switch synchronizes the route information of the physical server node to the route reflector through the second preset protocol tunnel, and acquires the route information of the route reflector from the route reflector, wherein the route information of the route reflector comprises the route information of the virtual machine.
In summary, by creating the second virtual routing and forwarding instance on the target switch in advance, and establishing the preset protocol tunnel of the target switch and the routing reflector, and continuous routing information synchronization, the embodiment shows how to optimize network interconnection in the cloud computing environment, and provides a solid technical foundation for network interworking between the virtual machine and the physical server.
In order to better understand the process of the network interworking method, the implementation flow of the network interworking method is described below in conjunction with the optional embodiment, but the implementation flow is not limited to the technical solution of the embodiment of the present application.
The centralized gateway and the distributed gateway scheme used by the current bare metal node have defects, and the enhanced gateway forwarded by the switch can be used for solving the bandwidth forwarding bottleneck problem of the centralized gateway, and meanwhile, the switch is adopted to replace the intelligent network card so as to solve the cost and threshold problem of the intelligent network card.
The bare metal (i.e., bare metal node) of the enhanced gateway forwards traffic through a Top-of-Rack switch (TOR). The application provides a bare metal enhanced gateway based on a hardware switch, which can realize interconnection of two layers and three layers under the networking of bare metal and a virtual machine overlay in a cloud platform.
The bare metal enhanced gateway can solve the problem of overlay network intercommunication between the virtual machine and the bare metal in the cloud computing environment computing node. In a cloud computing scenario, bare metal is generally provided to tenant users independently, and VXLAN encapsulation cannot be performed on the bare metal under overlay networking. Therefore, the enhanced gateway is adopted to realize the scene, in the process of two-layer and three-layer intercommunication of the bare metal and the virtual machine, the fact that how the bare metal and the virtual machine are coplanar, how the bare metal on the computing node side virtual machine and the enhanced gateway exchanger side are opened in two layers, how the MAC address of the virtual machine on the computing node side can enable the bare metal on the enhanced gateway side to learn, and how the flow from the computing node virtual machine side is sent to the bare metal on the enhanced gateway side are needed to be considered.
Optionally, for the above-mentioned problem to be considered, as shown in fig. 3, the present application adopts a route reflector (router-reflector) to solve the coplanar problem of the bare metal on the compute node side and the enhanced gateway (i.e. the target switch), the virtual machine on the compute node establishes a border gateway protocol BGP tunnel (corresponding to the first preset protocol tunnel in the above-mentioned embodiment) with the router-reflector through the compute node, and synchronizes the MAC and VTEP information of the virtual machine to the router-reflector through the FRR service pulled by the ovn-BGP-agent of the compute node, so that the route currently existing in the router-reflector can also be learned and generated into the route table of the virtual route and forwarding VRF. Similarly, the enhanced gateway and the router-reflector also establish BGP links (corresponding to the second preset protocol tunnel in the above embodiment), so that the MAC of the bare metal on the enhanced gateway side and the VTEP configured by the switch can be synchronized to the router-reflector through BGP links, and all the route information currently received by the router-reflector is also received.
Technical terms used in the above are explained as follows:
1) An overlay network is a virtual network layer built on top of an underlying physical network. It allows logical connections to be established between devices in a network without being limited by the underlying physical topology or network address. Such a network architecture is well suited to multi-tenant environments, such as cloud platforms, because it can provide independent, isolated network space for each tenant, even though they share the same physical infrastructure.
3) Media access control MAC, hardware address of the network device, unique identification for network communication.
4) Route reflector-reflector in BGP protocol, route reflector is a mechanism for reducing the number of BGP sessions within an autonomous system. By reflecting the routing information to other BGP neighbors, the need for interconnection between all BGP routers is avoided.
5) And the vxlan tunnel endpoint is a terminal of the vxlan and is used for encapsulating and decapsulating network data packets.
In connection with fig. 3, the traffic of the virtual machine in the computing node (corresponding to the first virtual machine traffic in the above embodiment) will first enter the integrated bridge (INTEGRATED BRIDGE OF OPEN VSWITCH, abbreviated as br-int) of the OVS, then the decision is made by the flow table rule added by ovn-bgp-agent, if it is the traffic destined for the bare metal, the traffic will be sent to the VRF (i.e. the first virtual routing and forwarding instance in the above embodiment) by the flow table rule, and route matching is performed in the VRF (because the routing of the bare metal has been synchronized to the VRF of the computing node by the router-reflector), and the traffic destined for the bare metal of the virtual machine will be encapsulated in the VRF of the computing node (the traffic after route matching or the traffic after encapsulation corresponds to the second virtual machine traffic in the above embodiment), and then the traffic is sent to the VTEP of the enhanced gateway. After the traffic arrives at the enhanced gateway, VXLAN decapsulation is performed, and a corresponding VLAN is found according to the VNI value of the virtual network identifier of VXLAN (corresponding to the target virtual network identifier in the above embodiment), so that the traffic is sent to the bare metal according to the MAC address.
Further, as shown in fig. 4, a specific implementation scheme of the enhanced gateway and a specific implementation scheme of two-three layer overlay network interworking between the bare metal and the virtual machine in combination with the enhanced gateway are as follows:
First, control panel flow design for compute node side:
Network services (Neutron), ovn-nb, ovsb, and Neutron's OVN plug-ins bgpvpn-ovn-driver plug-ins are deployed at the control nodes. Ovn-bgp-agent and ovn-controller components are deployed at the compute nodes. (where north databases ovn-nb correspond to ovn-nb-db in FIG. 4, and south databases ovn-sb correspond to ovn-sb-db in FIG. 4). Specifically, the method is realized by the following steps 31 to 35.
In step 31, in the process of creating a network port of a Virtual Machine (VM), bgpvpn-ovn-driver adds auxiliary information such as bgas, l2 vni, l3 vni and the like to an external identifier (External Identifiers, external_ids) of the Virtual Machine port, and writes the auxiliary information into ovn-nb. The data is then synchronized from ovn-nb to ovn-sb.
Step 32, running ovn-bgp-agent on the computing node, when the neutron port data of the virtual machine is synchronized from ovn-nb to ovn-sb, ovn-bgp-agent can capture the action, and extracting bgas, l2 vni and l3 vni in the port from port information of ovn-sb. Writing to local memory, wherein the attribute information in the external_ids of the port is transferred to the computing node where the virtual machine is located by the Neutron control node.
Step 33, the ovn-BGP-agent configures EVPN BGP (wherein, an enhanced virtual private network (Enhanced Virtual Private Network, abbreviated as EVPN)) according to the bgas information extracted in step 32 through frr vtysh, establishes a BGP link to a router-reflector, creates a VM route, synchronizes the route to the router-reflector through EVPN BGP protocol, and synchronizes other route information in the router-reflector to VRF.
Step 34, for the l2 vni and the l3 vni extracted by ovn-bgp-agent, creating VRF according to the l3 vni and designating VRF table as the l3 vni. Creating br-OVS, br-VRF VETH PAIR (equivalent to virtual Ethernet pair in the above embodiment), accessing OVS traffic to VRF, creating linux bridge in VRF according to l2 VNI, l3 VNI, hanging br-VRF on br-l2, l2 VNI being the VNI value of tunnel, l3 VNI being evpn l VNI and tenant binding one-to-one. VXLAN ports are created on br-l2, br-l3, respectively, with VNIs of l2 VNI and l3 VNI, respectively.
Step 35. The ovn-bgp-agent will add a high priority flow table to the OVS. For a port (baremetal port refers to a network port connected with a bare metal server) with a port type of bare metal (baremetal), the outgoing traffic skips the geneve encapsulation flow, is introduced into the VRF, is differentiated into two layers and three layers in the VRF, and is sent out from a corresponding l2-br vxlan port or l3 vxlan port respectively. Also for incoming VXLAN traffic, the core is decapsulated and then jumped to the corresponding openflow table via the br-ovs high priority flow table.
Technical terms in the above steps 31 to 35 are explained below.
1) Neutron, in the OpenStack cloud infrastructure, neutron is a service that provides cloud environment network functionality, supporting the creation and management of various virtual network resources, including but not limited to networks, subnets, routers, firewalls, load balancers, and the like. The network topology management method is a key component used for defining and managing network topology in OpenStack, and allows a user to customize a complex network structure to meet network requirements of resources such as virtual machines and containers.
2) Ovn-nb-db, is a database in the OVN architecture for storing network topology information including networks, ports, routes, etc. The northbound database is where data is exchanged between the controller and the network application for the logical network state of the control plane. ovn-sb-db, another database in OVN, is used primarily to store state information related to the data plane, such as flow table rules. The southbound database is where data is exchanged between the controller and the network device (e.g., OVS switch) to reflect the status of the actual network device.
3) Bgpvpn-ovn-driver an open virtual network virtual private network driver (BGP-based Virtual Private Network for Open Virtual Network Driver, abbreviated as bgpvpn-ovn-driver) based on border gateway protocol. This Neutron plug-in is used to implement bgpvpn and OVN integration in the OpenStack environment, which allows users to define and manage bgpvpn services and synchronize the parameters of the services to ovn-nb-db, thus automatically configuring OVN the network to support bgpvpn.
4) Ovn-BGP-agent, an open virtual network border gateway protocol agent, is a component running on a computing node and is responsible for exchanging routing information with a Router-Reflector through a BGP protocol, so that the computing node can know the reachability of other nodes in the network and synchronize the information such as the MAC address, VTEP and the like of the virtual machine to the Router-Reflector.
5) Ovn-controller, which is a core component in OVN architecture, is responsible for processing requests from the northbound database and issuing instructions to the southbound database, ultimately affecting the behavior of the data plane. ovn controller is the core that controls network policies and flow table rules, ensuring proper configuration of the network and proper handling of traffic.
6) Neutron Port, i.e., network Port. In the Neutron network service of OpenStack, a network port represents a connection point of a network resource, and may be attached to a virtual machine, a bare metal server, or other network resources. Neutron Port is a basic unit that defines a network connection, and contains an IP address, a MAC address, a security group, and other network attributes.
7) External_ids in ovn-nb-db, external_ids is a set of key-value pairs for storing information that does not belong to the standard OVN database model, e.g., external_ids can be used to store additional metadata such as associated bgas numbers, l2 vni, and l3 vni values when virtual machine ports are created.
8) FRR vtysh is a Command Line Interface (CLI) tool in the FRR software suite for configuring and managing routing protocols, allowing administrators to make detailed configuration and status queries for routing devices via the command line interface. FRR is an open source software package for routing functions that supports multiple routing protocols, such as BGP, OSPF, RIP, etc.
9) The two-layer bridge device br-l2 and the three-layer bridge devices br-l3, br-l2 and br-l3 represent bridge devices that handle two-layer and three-layer traffic, respectively. In the VXLAN and EVPN architectures, br-l2 is used to handle two layers of VXLAN traffic, while br-l3 handles three layers of routing information and traffic associated with EVPN.
10 Veth pair-virtual ethernet pairs. veth pair is a virtual network device provided by a Linux kernel that allows a pair of full duplex virtual ethernet devices to be created in the kernel, typically for establishing connections between different network namespaces, enabling forwarding of traffic. In the present application veth pair is used to connect br-OVS and br-VRF, ensuring that traffic can properly enter the VRF environment from the OVS bridge device.
11 Geneve general encapsulation protocol (Generic Network Encapsulation, abbreviated Geneve). Geneve is a network encapsulation protocol, which is mainly used for constructing an overlay network in a data center. The data packet encapsulation method can encapsulate the data packet of the two-layer network and transmit the data packet through the three-layer network, and simultaneously provides high efficiency, flexible header formats and various encapsulation options.
12 OpenFlow Table: "OpenFlow Table"). In Open VSwitch (OVS) or any network device implementing the OpenFlow protocol, a Flow table (Flow Tables) is where Flow Rules (Flow Rules) are stored. The flow rules define how data packets are handled and forwarded in the device. Each flow entry contains a matching condition and an action to be performed. When a packet arrives at the OpenFlow switch, it is checked to determine if a rule in the flow table is met. If there is a match, the packet will be processed in the manner specified by the rule, such as forwarded to a particular port, performing certain network operations, or being discarded. If no matching flow entry is found, the packet may be sent to the controller for further processing. In OVS, the flow table is located within a bridge device (bridge), which is a core part of the OpenFlow architecture, for filtering and forwarding network packets according to predefined rules. The controller, such as ovn-controller, may remotely modify these flow tables to accommodate changes in the network or policy updates to ensure proper packet processing and routing behavior.
Secondly, designing a control panel flow aiming at the switch logic test.
Specifically, the steps 41 to 45 are as follows.
Step 41, uniformly planning ACCESS VLAN switch ports accessed by the address of the computing node vtep ip, and creating VLAN if (VLAN INTERFACE, which refers to a virtual interface associated with a specific VLAN) corresponding to the VLAN. Vtep ip is arranged on the vlan if as vtep ip on the bare side. Thus, the bare computer can be ensured to be interconnected and intercommunicated with all the computing nodes VTEP through the switch. As shown in FIG. 4 of the present application, 192.168.122.0/24 is planned as a VTEP network, and VLAN is planned to be 88, wherein VTEP ip of the computing node is 192.168.122.8, VTEP of the enhanced gateway is 192.168.122.6, and the enhanced gateway falls on VLAN if of VLAN 88 of the switch, router-reflector node is configured 192.168.122.4, and the VTEP network BGP is guaranteed to be interoperable.
Step 42, creating ACCESS VLAN of the tenant at the bare metal access side, evpn l vni vlan of the tenant and l2 vni of the tunnel. Creating a tenant VRF (corresponding to the second virtual routing and forwarding instance in the above embodiment), and binding ACCESS VLAN, evpn l, 3 vni vlan, i 2 vni of tunnel to VRF.
Step 43, configuring the switch to establish BGP, and activating neighbor router-reflector in address-family 2vpn evpn to announce advertisement-all-vni. The tunnel uses the router bgas instance to interact, passing evpn type type3 messages.
And 44, configuring EVPN release type-5 route in the corresponding VRF of the switch, wherein the release type-5 route can be released by using commands network and redistribute connected, and realizing route release and learning between the switch and the router-reflector through the step 43 and the step 44, wherein the learned route can be synchronized to the corresponding VRF.
Step 45, configuring the switch l3 evpn tunnel. Creating an l3 evpn tunnel, designating ACCESS VLAN IF of the VTEP as a source ip address of the overlay-evpn, and configuring a mapping relationship between the VRF and the VNI (corresponding to the target virtual network identifier in the above embodiment) and a mapping relationship between the bare metal access side TENANT VLAN (corresponding to the tenant network identifier in the above embodiment) and the VNI in the l3 evpn tunnel.
Combining the control surface flow designs of the computing node side and the computing bare metal node side, the data surface flow transmission scheme of the virtual machine and the bare metal node in the computing node is as follows:
1) The virtual machine flows to two layers and three layers of bare machines.
After the control rule is matched, if the destination port is a bare metal port, the flow entry ovs openflow table of the virtual machine matches the flow control rule with high priority and enters the VRF through br-ovs. In the VRF, the two-layer and three-layer route matching is performed on the destination IP address, and if the current flow is the two-layer flow, the l2 vni is packaged according to the control rule of the EVPN, and if the current flow is the 3-layer flow, the package EVPN l3 vni sends out the message. After the message reaches the VTEP of the corresponding bare metal switch, the switch performs the decapsulation of the VTEP, maps to the corresponding VLAN and VRF through the VNI of the VXLAN, and sends to the corresponding bare metal through the searching route.
2) The bare engine flows to two and three layers of the virtual machine side.
Similarly, the flow of the bare computer is matched to a corresponding VRF through an accessed ACCESS VLAN, after entering the VRF, the flow is matched to a corresponding routing rule through a destination IP to carry out VXLAN encapsulation, then the VXLAN encapsulation is sent to a corresponding computation node VXLAN vtep port, after the VXLAN encapsulation, the flow of the VRF is accessed to an OVS through br-VRF and br-OVS veth pair, and a high-priority flow control rule is issued to a corresponding table through ovn-bgp-agent to carry out processing.
In summary, the bare metal enhanced gateway is used as a network optimization scheme in a cloud computing scene, and mainly has the following beneficial effects:
1) High performance and low latency.
The enhanced gateway performs VXLAN encapsulation/decapsulation through the TOR (top of rack switch) of the multiplexed bare metal, the data surface is completely processed by hardware equipment, the participation of a software gateway is not needed, and the performance loss of the traditional virtualization layer is avoided.
Supporting the same network bandwidth as the physical machine. The end-to-end path is directly completed by hardware equipment, intermediate forwarding links are reduced, and the method is suitable for high-throughput scenes such as high-performance computing (High Performance Computing, HPC for short), a core database and the like. In addition, the network traffic with higher density can be borne by the acceleration of the hardware of the switch, so that the requirements of enterprise-level application on stability and instantaneity are met.
2) The cost effectiveness is remarkable.
The existing switch is directly utilized to realize functions without additionally purchasing an intelligent network card or special gateway equipment, so that the hardware input cost is greatly reduced. Compared with the intelligent network card scheme, the deployment cost of the enhanced gateway is lower, the enhanced gateway is compatible with multi-manufacturer equipment, and ecology is more open. And moreover, standardized switch hardware is adopted, so that upgrade complexity and operation and maintenance risks caused by tight coupling of the intelligent network card and the cloud platform are avoided.
3) The safety and stability are enhanced.
The bare metal server provides physical level isolation, the enhanced gateway realizes VPC network encapsulation through hardware equipment, data transmission safety is further ensured, and potential attack of a virtualization layer is avoided.
From the description of the above embodiments, it will be clear to a person skilled in the art that the method according to the above embodiments may be implemented by means of software plus the necessary general hardware platform, but of course also by means of hardware, but in many cases the former is a preferred embodiment.
The present embodiment also provides a network interworking device, which is used to implement the foregoing embodiments and preferred embodiments, and is not described in detail. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. While the means described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.
Fig. 5 is a diagram of an architecture of a network interworking system according to an embodiment of the present application, as shown in fig. 5, the system comprising:
A compute node 52, a route reflector 54, a target switch 56, a physical server node 58;
The computing node is used for carrying out route matching on the first virtual machine flow through a routing table corresponding to a first virtual route and a forwarding instance under the condition that a destination node of the first virtual machine flow is a physical server node, obtaining a second virtual machine flow and sending the second virtual machine flow to a target switch, wherein the computing node comprises a virtual machine outputting the first virtual machine flow and the first virtual route and the forwarding instance, and route information of the physical server node is synchronized to the routing table through a route reflector connected with the computing node;
the target switch is respectively connected with the physical server node, the route reflector and the computing node and is used for sending the second virtual machine flow to the physical server node.
According to the system, for the first virtual machine flow which is output by the virtual machine in the computing node and is of which the destination node is the physical server node, route matching is conducted on the first virtual machine flow through the routing table corresponding to the first virtual route and the forwarding instance in the computing node, route information of the physical server node is synchronized to the routing table through the route reflector connected with the computing node, the obtained second virtual machine flow is sent to the target switch, so that the target switch sends the second virtual machine flow to the physical server node, and network intercommunication between the virtual machine and the physical server node is achieved, and the target switch is connected to the physical server node, the route reflector and the computing node respectively. Therefore, the method and the device can solve the technical problems that in the related technology, the soft gateway used between the virtual machine and the bare metal node in the computing node in the cloud computing environment has the defects of bandwidth forwarding bottleneck and high scheme cost, and further the network intercommunication effect between the virtual machine and the bare metal node is poor, so that the network intercommunication effect between the virtual machine and the bare metal node is improved.
In an exemplary embodiment, the system further comprises a control node connected with the computing node, the computing node further comprises a proxy component and a free range routing instance, the proxy component is used for acquiring an autonomous system number, a two-layer virtual network identifier and a three-layer virtual network identifier corresponding to the virtual machine from the control node, and the free range routing instance is used for establishing a first preset protocol tunnel between the computing node and the route reflector according to the autonomous system number and a preset protocol.
In an exemplary embodiment, the control node further comprises a southbound database and a driving component, wherein the driving component is used for adding the autonomous system number, the two-layer virtual network identifier and the three-layer virtual network identifier to an external identifier of a network port when the network port corresponding to the virtual machine is created, and the proxy component is further used for monitoring the southbound database in the control node and extracting the autonomous system number, the two-layer virtual network identifier and the three-layer virtual network identifier from the external identifier when the external identifier is detected to be synchronized to the southbound database.
In an exemplary embodiment, the computing node is further configured to synchronize routing information of the virtual machine to the routing reflector through the first preset protocol tunnel, the routing reflector is configured to synchronize the routing information of the virtual machine to the target switch, and the computing node is further configured to synchronize the routing information in the routing reflector to the routing table corresponding to the first virtual routing and forwarding instance through the first preset protocol tunnel, wherein the routing information in the routing reflector includes routing information of the physical server node.
In an exemplary embodiment, the computing node further comprises a first virtual routing and forwarding instance created according to the three-layer virtual network identifier, and a virtual Ethernet pair established between a first bridging device and a second bridging device, wherein the first bridging device is a bridging device corresponding to the first virtual routing and forwarding instance, and the second bridging device is a bridging device corresponding to an open virtual switch, and the first virtual routing and forwarding instance comprises a target component comprising a two-layer port and a three-layer port respectively corresponding to the two-layer bridging device and the three-layer bridging device, wherein the target component is configured in the first virtual routing and forwarding instance through the two-layer virtual network identifier and the three-layer virtual network identifier, and the two-layer port and the three-layer port are used for transmitting the first virtual machine traffic.
In an exemplary embodiment, the computing node is further configured to receive, through the first virtual routing and forwarding instance, physical server traffic sent by the physical server node, the computing node is further configured to send the physical server traffic to the open virtual switch through the virtual ethernet pair, and the computing node is further configured to send, through the open virtual switch, the physical server traffic to the virtual machine if it is determined that the destination node of the physical server traffic is the virtual machine.
In an exemplary embodiment, the computing node is further configured to send the second virtual machine traffic to the target switch through the first virtual routing and forwarding instance, and the target switch further includes a second virtual routing and forwarding instance configured to send the second virtual machine traffic to the physical server node to enable the virtual machine to communicate with the physical server node over a network.
In an exemplary embodiment, the target switch is further configured to parse a target virtual network identifier corresponding to the second virtual machine traffic, where the target virtual network identifier includes one of a two-layer virtual network identifier corresponding to the virtual machine and a three-layer virtual network identifier corresponding to the virtual machine, the second virtual routing and forwarding instance is further configured to determine a tenant network identifier corresponding to the physical server node based on the target virtual network identifier, and send the second virtual machine traffic to the physical server node through the tenant network identifier.
The description of the features in the embodiments corresponding to the network interworking system may refer to the related description of the embodiments corresponding to the network interworking method, which is not described in detail herein.
The embodiment of the application also provides an electronic device comprising a memory having stored therein a computer program and a processor arranged to run the computer program to perform the steps of any of the network interworking method embodiments described above.
Embodiments of the present application also provide a computer readable storage medium having a computer program stored therein, wherein the computer program is configured to perform the steps of any of the network interworking method embodiments described above when run.
In an exemplary embodiment, the computer readable storage medium may include, but is not limited to, a U disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a removable hard disk, a magnetic disk, or an optical disk, etc. various media in which a computer program may be stored.
Embodiments of the present application also provide a computer program product comprising a computer program which, when executed by a processor, implements the steps of any of the network interworking method embodiments described above.
Embodiments of the present application also provide another computer program product comprising a non-volatile computer readable storage medium storing a computer program which when executed by a processor implements the steps of any of the network interworking method embodiments described above.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The above describes a network interworking provided by the present application in detail. The principles and embodiments of the present application have been described herein with reference to specific examples, the description of which is intended only to facilitate an understanding of the method of the present application and its core ideas. It should be noted that it will be apparent to those skilled in the art that various modifications and adaptations of the application can be made without departing from the principles of the application and these modifications and adaptations are intended to be within the scope of the application as defined in the following claims.