Cloud private line connectivity test method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a cloud private line connectivity test method and device, electronic equipment and a storage medium. A virtual switch is installed on a simulation node; constructing a first virtual network interface and a second virtual network interface for installing the virtual switch; creating a network namespace for simulating the network environment of the client side equipment at the simulation node; adding the second virtual network interface to the network namespace, and simulating the second virtual network interface to configure network information for the network namespace; adding the first virtual network interface to an integrated bridge, and creating a flow table on the integrated bridge; executing flow receiving and transmitting through the flow table, the network information and the network namespace, and generating flow receiving and transmitting state information; according to the method, the connectivity of the cloud private line between the cloud host and the network namespace is detected based on the traffic transceiving state information, the connectivity of the cloud private line is tested on the basis of not excessively depending on a test environment, the test cost is reduced, and the test efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud dedicated line connectivity testing, and in particular to a cloud dedicated line connectivity testing method, a cloud dedicated line connectivity testing device, an electronic device and a computer-readable storage medium. Background Art

[0002] In the traditional public cloud architecture, cloud dedicated lines are an important bridge connecting cloud resources and offline data centers. Through physical dedicated lines, hosts in the cloud and hosts in the client-side IDC can be interconnected to form a unified network environment.

[0003] However, cloud dedicated lines present significant technical challenges in the testing and maintenance process. Specifically, when cloud services are developed or iteratively updated, comprehensive testing and verification is required. Traditional testing methods usually rely on the test environment, but the resources of the test environment are limited and cannot fully simulate the complexity of the production environment. Especially when it comes to joint debugging with POP switches and client-side IDCs, it is necessary to configure complex network equipment, lay physical dedicated lines, and build a simulated client-side IDC environment. This testing method not only consumes a lot of manpower and material resources, but also has a long cycle and low efficiency, which greatly increases the cost and difficulty of testing. Summary of the invention

[0004] The embodiments of the present invention provide a cloud dedicated line connectivity testing method, device, electronic device and computer-readable storage medium to overcome the above problems or at least partially solve the above problems.

[0005] The embodiment of the present invention discloses a cloud dedicated line connectivity testing method, which is applied to a cloud host of a virtual private cloud network, and includes:

[0006] Select a simulation node, and install a virtual switch OVS on the simulation node; the virtual switch OVS is provided with an integrated bridge;

[0007] Constructing a first virtual network interface and a second virtual network interface for installing a virtual switch OVS;

[0008] Creating a network namespace for simulating a network environment of a client-side device at the simulation node;

[0009] Adding the second virtual network interface to the network namespace, and configuring network information for the second virtual network interface of the network namespace;

[0010] Adding the first virtual network interface to the integration bridge, and creating a flow table on the integration bridge;

[0011] Execute traffic sending and receiving through the flow table, the network information and the network namespace, and generate traffic sending and receiving state information;

[0012] The connectivity of the cloud dedicated line between the cloud host and the network namespace is detected based on the traffic receiving and sending status information.

[0013] The embodiment of the present invention further discloses a cloud dedicated line connectivity test device, which is applied to a cloud host of a virtual private cloud network, and includes:

[0014] A simulation node selection module, used for selecting a simulation node and installing a virtual switch OVS on the simulation node; the virtual switch OVS is provided with an integrated bridge;

[0015] A virtual network interface construction module, used to construct a first virtual network interface and a second virtual network interface for installing a virtual switch OVS;

[0016] A network namespace creation module, used to create a network namespace for simulating a network environment of a client-side device at the simulation node;

[0017] A network information configuration module, used to add the second virtual network interface to the network namespace and configure network information for the second virtual network interface of the network namespace;

[0018] A flow table creation module, used for adding the first virtual network interface to the integration bridge and creating a flow table on the integration bridge;

[0019] A flow receiving and sending state information generating module, used to perform flow receiving and sending through the flow table and the network information and the network namespace, and generate flow receiving and sending state information;

[0020] A connectivity testing module is used to detect the connectivity of the cloud dedicated line between the cloud host and the network namespace based on the traffic receiving and sending status information.

[0021] The embodiment of the present invention further discloses an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0022] The memory is used to store computer programs;

[0023] The processor is used to implement the method described in the embodiment of the present invention when executing the program stored in the memory.

[0024] The embodiment of the present invention further discloses a computer-readable storage medium having instructions stored thereon, which, when executed by one or more processors, enables the processors to execute the method described in the embodiment of the present invention.

[0025] The embodiments of the present invention include the following advantages:

[0026] In an embodiment of the present invention, a simulation node is selected, and a virtual switch OVS is installed on the simulation node; the virtual switch OVS is provided with an integrated bridge; a first virtual network interface and a second virtual network interface for installing the virtual switch OVS are constructed; a network namespace for simulating a network environment of a client-side device is created at the simulation node; the second virtual network interface is added to the network namespace, and network information is configured for the second virtual network interface of the network namespace; the first virtual network interface is added to the integrated bridge, and a flow table is created on the integrated bridge; traffic is sent and received with the network namespace through the flow table and the network information, and traffic sending and receiving status information is generated; and the connectivity of the cloud dedicated line between the cloud host and the network namespace is detected based on the traffic sending and receiving status information, thereby achieving the following beneficial effects:

[0027] Virtualization: Use virtualization technology to create multiple virtual network environments on physical machines to simulate real cloud dedicated line scenarios. Avoid building complex physical environments, including POP switches, physical dedicated lines, etc., and reduce dependence on the test environment.

[0028] Software-defined networking: Use OVS as a virtual switch to flexibly configure network traffic, achieve fine-grained control over the network, and avoid the difficulty of rapid adjustment and reuse of the test environment.

[0029] Automation: Automating the testing process through scripts or tools improves testing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 It is a flowchart of a method for testing cloud dedicated line connectivity provided in an embodiment of the present invention;

[0031] Figure 2 is a network topology diagram of a cloud resource pool provided in an embodiment of the present invention;

[0032] Figure 3 is another network topology diagram of a cloud resource pool provided in an embodiment of the present invention;

[0033] Figure 4 It is a structural block diagram of a cloud dedicated line connectivity testing device provided in an embodiment of the present invention;

[0034] Figure 5is a hardware structure block diagram of an electronic device provided in an embodiment of the present invention;

[0035] Figure 6 is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0036] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0037] In the current mainstream public cloud computing network, cloud dedicated lines are usually used to connect the resource pool within the cloud and the IDC on the customer side under the cloud. That is, a physical dedicated line is pulled between the two so that the host in the resource pool within the cloud and the host in the IDC on the customer side under the cloud can communicate with each other.

[0038] For the outbound traffic of the cloud resource pool, that is, when the cloud host in the cloud resource pool needs to access the host in the client-side IDC, the traffic of the cloud host is first sent to the tenant gateway corresponding to the cloud host in the cloud resource pool. There is a route on the tenant gateway, the destination address is the CIDR of the subnet where the host in the client-side IDC is located, and the next hop is a loop port address on the pop switch. Through this route, the tenant gateway can forward the traffic to the pop switch. There is also a route on the pop switch, the destination address is the CIDR of the subnet where the host in the client-side IDC is located, and the next hop is the loop port address of the network device in the client-side IDC. Through this route, the pop switch can forward the traffic to the client-side IDC through the physical dedicated line, and finally the network device in the client-side IDC forwards the traffic to the destination host 2.

[0039] For the inbound traffic of the cloud resource pool, that is, when the host in the client-side IDC needs to access the cloud host in the cloud resource pool, the host traffic is first sent to the network device in the client-side IDC, and the network device sends the traffic to the pop switch through a physical dedicated line. There is a route on the pop switch, the destination address is the CIDR of the subnet where the cloud host of the cloud resource pool is located, and the next hop is a loop port address on the tenant gateway. Through this route, the pop switch can forward the traffic to the tenant gateway corresponding to the cloud host 1 lock of the cloud resource pool. After receiving the traffic, the tenant gateway forwards the traffic to the cloud host.

[0040] At this point, the connectivity between the host in the cloud resource pool and the host in the client-side IDC under the cloud can be achieved.

[0041] However, in the development and maintenance of cloud dedicated lines, there are the following technical problems: high testing costs and difficulty. For example, after the development / iterative update of cloud dedicated line-related services is completed in the cloud resource pool, it can usually only be tested in the test environment, and the resources of the test environment are limited. When joint debugging with pop switches and customer IDCs is required, if the pop switches are configured, physical dedicated lines are pulled, and the customer-side IDC environment is deployed in the test environment like the online environment, it will cost a lot of manpower and material resources, consume high costs, and be difficult to implement.

[0042] In order to enable those skilled in the art to better understand the embodiments of the present invention, some technical names involved in the embodiments of the present invention are explained below.

[0043] VPC (Virtual Private Cloud): Virtual private cloud network is a network mode used to isolate cloud hosts of different tenants on the public cloud.

[0044] Tenant Gateway: One of the basic gateways in a cloud computing network. It is the default gateway for tenants and is used to forward service traffic in and out of the tenant VPC, enabling interconnection between the tenant VPC and other networks.

[0045] Cloud Private Line: used to build a high-speed, low-latency, stable and secure dedicated connection channel between the user's local data center and VPC.

[0046] POP switch: the switch in the cloud resource pool responsible for cloud dedicated line access.

[0047] OVS (OpenvSwitch): is a high-quality virtual switch that supports multi-layer data forwarding. It is mainly deployed on computer nodes to manage virtual machines on the computer nodes.

[0048] Reference Figure 1 , shows a flow chart of a method for testing cloud dedicated line connectivity provided in an embodiment of the present invention, which may specifically include the following steps:

[0049] Step 101, selecting a simulation node, and installing a virtual switch OVS on the simulation node; the virtual switch OVS is provided with an integrated bridge;

[0050] Step 102, constructing a first virtual network interface and a second virtual network interface for installing the virtual switch OVS;

[0051] Step 103, creating a network namespace for simulating a network environment of a client-side device at the simulation node;

[0052] Step 104, adding the second virtual network interface to the network namespace, and configuring network information for the second virtual network interface of the network namespace;

[0053] Step 105, adding the first virtual network interface to the integration bridge, and creating a flow table on the integration bridge;

[0054] Step 106, performing traffic transmission and reception through the flow table, the network information and the network namespace, and generating traffic transmission and reception state information;

[0055] Step 107 , detecting connectivity of the cloud dedicated line between the cloud host and the network namespace based on the traffic receiving and sending status information.

[0056] In a specific implementation, the embodiments of the present invention can be applied to a cloud host of a virtual private cloud network.

[0057] The embodiment of the present invention can select a simulation node and install a virtual switch OVS on the simulation node to build a test environment foundation. By selecting a computer as a simulation node, a basic platform is provided for subsequent network configuration. This computer will play the role of a POP switch. The introduction of the virtual switch OVS can be used as a powerful virtual switch to control data traffic in the simulation environment. The purpose of creating an integrated bridge is that the integrated bridge is a concept in OVS, which connects multiple ports together to form a switching network.

[0058] By installing a virtual switch configured with an integrated bridge, OVS provides a flexible and configurable test platform, providing a basis for subsequent network configuration.

[0059] In a specific implementation, an embodiment of the present invention can also construct a first virtual network interface and a second virtual network interface for installing a virtual switch OVS; an embodiment of the present invention can create a pair of vethpair type virtual network interfaces on the simulator, representing interfaces connecting the POP switch and the simulated client-side IDC respectively.

[0060] In actual applications, vethpair is a pair of special virtual network interfaces. When a data packet is sent from one veth interface, it will be immediately received from another veth interface. In the embodiment of the present invention, a pair of vethpair interfaces can be created on the simulator, named veth0_dc and veth1_dc, and the veth0_dc interface can be enabled to connect to the OVS bridge.

[0061] The embodiment of the present invention can also create a network namespace in the simulation node to simulate the network environment of the client-side device; the network namespace is an independent network environment, isolated from other network environments on the host. The embodiment of the present invention can create a network namespace named ns_dc to simulate the network environment of the client-side IDC.

[0062] By creating an independent network environment to simulate the client-side IDC, you can configure the network settings within the namespace independently without affecting other parts.

[0063] The embodiment of the present invention may also add the second virtual network interface to the network namespace, and configure network information for the second virtual network interface of the network namespace;

[0064] In a specific implementation, the embodiment of the present invention can add the veth1_dc interface to the ns_dc namespace, and set the IP address of veth1_dc to the loop port IP of the POP switch, namely, dst_loop_ip; configure an IP address for the loop port in the namespace, and this IP address belongs to the subnet of the client-side IDC; add a route in the namespace so that the traffic in the namespace can be forwarded to the tenant gateway, and configure the IP address and mask for the interface and loop port in the namespace, and add a route so that the traffic in the namespace can be forwarded to the tenant gateway.

[0065] For example:

[0066] Assuming that dst_loop_ip is 200.0.0.2, the client-side IDC subnet is 192.168.20.0 / 24, and the tenant gateway IP is 192.168.10.1, the configuration is as follows:

[0067] #Configure veth1_dc

[0068] ip netns exec ns_dc ip addr add200.0.0.2 / 30dev veth1_dc

[0069] #Configure the loop port

[0070] ip netns exec ns_dc ip addr add 192.168.20.20 / 24dev lo

[0071] #Add routes

[0072] ip netns exec ns_dc ip route add 192.168.10.0 / 24via 200.0.0.1devveth1_d

[0073] By associating a virtual network card with a namespace, the connection between the physical and virtual networks can be achieved. By configuring the IP address, subnet mask and other information for the interface in the namespace, the real network environment can be simulated, thereby establishing a connection between the simulated node and the namespace, providing a basis for network communication within the namespace.

[0074] Add the first virtual network interface to the integrated bridge, connect the virtual network card to the OVS bridge, form a switching network, realize the connection with the tenant gateway, and create a flow table on the integrated bridge to define the forwarding rules of the data packet on the OVS bridge, realize VXLAN encapsulation, decapsulation and other functions, thereby realizing the connection between the simulation node and the external network and controlling the flow of data packets in the network.

[0075] In the embodiment of the present invention, traffic is sent and received through the flow table, the network information and the network namespace.

[0076] For example, the veth0_dc interface can be added to the OVS bridge br-int, and the OVS flow table can be configured as follows:

[0077] Add flow table rules: Add flow table rules on the OVS bridge to implement VXLAN encapsulation and decapsulation.

[0078] Matching conditions: Match the VNI, source IP, destination IP and other fields of the VXLAN message.

[0079] Action: Execute corresponding actions based on the matching results, such as forwarding the packet to a specific port or performing VXLAN encapsulation / decapsulation.

[0080] For example:

[0081] ovs-ofctl add-flow br-int priority=2000, in_port=vxlan1, tun_id=320, actions=output: veth0_dc

[0082] ovs-ofctl add-flowbr-intpriority=2000,in_port=veth0_dc,actions=set_field:320->tun_id,set_field:22.22.22.22->tun_dst,output:vxlan1

[0083] The logical relationship between the above steps is as follows:

[0084] Simulate POP switch: provide a basic environment for subsequent network simulation.

[0085] Create a virtual network interface: Establish a channel connecting the OVS bridge and the namespace.

[0086] Create a network namespace: simulate the network environment of the client-side IDC.

[0087] Configure IP addresses and routes: Configure IP addresses for interfaces in the namespace and set routes so that traffic can be forwarded correctly.

[0088] Connect OVS Bridge: Connect the virtual network interface to the OVS bridge.

[0089] Configure the OVS flow table: define the forwarding rules for data packets on the OVS bridge to implement VXLAN encapsulation and decapsulation.

[0090] The embodiment of the present invention can generate traffic receiving and sending status information, and detect the connectivity of the cloud dedicated line between the cloud host and the network namespace based on the traffic receiving and sending status information;

[0091] Exemplarily, the connectivity of the cloud dedicated line can be tested in the following manner.

[0092] Send test traffic: Send the traffic to the namespace through the configured flow table.

[0093] Receive return traffic: Receive return traffic from the namespace.

[0094] Generate status information: Record the sending and receiving of traffic for analyzing network performance.

[0095] Analyze test results: Determine the connectivity of the cloud dedicated line based on the generated traffic status information to verify whether the cloud dedicated line is working properly.

[0096] In an embodiment of the present invention, a simulation node is selected, and a virtual switch OVS is installed on the simulation node; the virtual switch OVS is provided with an integrated bridge; a first virtual network interface and a second virtual network interface for installing the virtual switch OVS are constructed; a network namespace for simulating a network environment of a client-side device is created at the simulation node; the second virtual network interface is added to the network namespace, and network information is configured for the second virtual network interface of the network namespace; the first virtual network interface is added to the integrated bridge, and a flow table is created on the integrated bridge; traffic is sent and received with the network namespace through the flow table and the network information, and traffic sending and receiving status information is generated; and the connectivity of the cloud dedicated line between the cloud host and the network namespace is detected based on the traffic sending and receiving status information, thereby achieving the following beneficial effects:

[0097] Virtualization: Use virtualization technology to create multiple virtual network environments on physical machines to simulate real cloud dedicated line scenarios. Avoid building complex physical environments, including POP switches, physical dedicated lines, etc., and reduce dependence on the test environment.

[0098] Software-defined networking: Use OVS as a virtual switch to flexibly configure network traffic, achieve fine-grained control over the network, and avoid the difficulty of rapid adjustment and reuse of the test environment.

[0099] Automation: Automating the testing process through scripts or tools improves testing efficiency.

[0100] Based on the above embodiment, a variant embodiment of the above embodiment is proposed. It should be noted that in order to make the description concise, only the differences from the above embodiment are described in the variant embodiment.

[0101] In an optional embodiment of the present invention, before the step of selecting a simulation node and installing a virtual switch OVS on the simulation node; and providing the virtual switch OVS with an integrated bridge, the method further includes:

[0102] Obtain configuration information of the cloud dedicated line;

[0103] Based on the configuration information, determine the IP protocol type of the cloud dedicated line, the tunnel virtual network identifier, the tenant gateway, and the IP address of the tunnel endpoint of the POP switch, as well as the classless inter-domain routing of the cloud subnet and the client-side device subnet, the tenant gateway loopback interface and the tenant gateway IP address of the tenant gateway, and the POP switch loopback interface and the POP switch IP address of the POP switch.

[0104] In a specific implementation, the embodiment of the present invention may perform the following steps before performing the test.

[0105] Create tenant basic networks and resources.

[0106] The purpose is to provide a basic network environment for tenant devices, including VPC, subnets, and cloud hosts.

[0107] Importance: This is the foundation of the entire test scenario. The tenant gateway, VPC, subnet, and cloud host form a complete network topology, which provides a basis for the subsequent cloud dedicated line configuration.

[0108] Create a cloud dedicated line.

[0109] The purpose is to establish a dedicated line connection between the tenant's VPC and the client-side IDC.

[0110] Importance: Cloud dedicated line is the core of the entire test. Through cloud dedicated line, the tenant's cloud host can communicate with the client-side IDC host.

[0111] Obtain information about Cloud Direct.

[0112] The purpose is to collect detailed information about the cloud dedicated line configuration and provide input parameters for subsequent test scripts.

[0113] Specifically, an embodiment of the present invention can obtain relevant configuration information of the cloud dedicated line that has been created in the cloud resource pool, and the configuration information includes at least: the ip protocol type of the cloud dedicated line (i.e., ip_type, optional values ​​are ipv4 and ipv6), the tunnel vni value corresponding to the VPC (i.e., vxlan_tunnel_vni), the vtep ip address of the tenant gateway corresponding to the VPC (i.e., vpp_vtep_ip), the vtep ip address of the pop switch (i.e., pop_vtep_ip), the subnet CIDR in the cloud corresponding to the cloud dedicated line (i.e., src_cidr), the subnet CIDR in the customer IDC corresponding to the cloud dedicated line (i.e., dst_cidr), the IP address of the loop port corresponding to the cloud dedicated line on the tenant gateway (i.e., src_loop_ip), and the IP address of the loop port corresponding to the cloud dedicated line on the pop switch (i.e., dst_loop_ip).

[0114] VTEP IP is the IP address of the VXLAN (Virtual Extensible LAN) tunnel endpoint. In a VXLAN network, VTEP is a bridge connecting the physical network and the virtual network, responsible for the encapsulation and decapsulation of VXLAN packets.

[0115] CIDR is the abbreviation of Classless Inter-Domain Routing, which is translated into Chinese as “Classless Inter-Domain Routing”. It is an IP address classification method used to assign IP addresses to users and effectively route IP data packets on the Internet.

[0116] The role of CIDR in cloud subnets and client-side IDC subnets

[0117] IP address allocation: CIDR is used to divide the network and allocate continuous IP address blocks to the cloud subnet and the client-side IDC subnet.

[0118] Subnet mask: CIDR uses a variable-length subnet mask (VLSM), which allows network administrators to flexibly divide subnets according to actual needs and improve IP address utilization.

[0119] Routing: The router determines which network the data packet should be sent to based on CIDR information, thereby achieving efficient routing.

[0120] The reasons for using CIDR in the cloud subnet and the customer-side IDC subnet are:

[0121] Flexible allocation of IP addresses: CIDR can flexibly divide IP address blocks according to different network scales and requirements to avoid wasting IP addresses.

[0122] Simplified routing configuration: CIDR uses continuous IP address blocks, which simplifies routing table configuration and improves routing efficiency.

[0123] Support for large-scale networks: CIDR can support large-scale networks and meet the needs of modern data centers and cloud computing.

[0124] CIDR Notation

[0125] CIDR is usually expressed in the form of IP address / prefix length, for example:

[0126] 192.168.1.0 / 24: indicates that the network address is 192.168.1.0 and the subnet mask is 255.255.255.0. The network contains 254 available IP addresses.

[0127] 10.0.0.0 / 8: indicates that the network address is 10.0.0.0 and the subnet mask is 255.0.0.0. This network contains 16,777,214 available IP addresses.

[0128] Summarize

[0129] CIDR is a very important network concept, which is widely used in cloud subnets and client-side IDC subnets. By understanding CIDR, you can better understand the principles of IP address allocation and routing, and thus better manage and maintain the network.

[0130] Loop port, also known as loopback interface, is a virtual network interface that does not rely on any physical hardware. In simple terms, it is like a virtual network cable that connects the device itself.

[0131] The main functions of the loop port:

[0132] Device identification: Each device can be configured with a unique loop port IP address as the device identification. This IP address is usually used for communication between devices, such as the establishment of BGP protocol between routers.

[0133] Management interface: Many network devices use the loop port IP as the address of the management interface. Administrators can use this IP address to remotely log in to the device for configuration and management.

[0134] Routing protocol: The loop port can be used as the interface of the routing protocol and participate in the calculation of the routing protocol to ensure the stability of the network.

[0135] ip_type (IPv4 / IPv6): determines the protocol used for network communication.

[0136] When configuring the OVS flow table, you need to set different matching rules based on the IP type.

[0137] vxlan_tunnel_vni: VXLAN tunnel virtual network identifier.

[0138] In the OVS flow table, it is used to identify the traffic belonging to the cloud dedicated line.

[0139] vpp_vtep_ip, pop_vtep_ip: represent the VTEP IP addresses of the tenant gateway and POP switch, respectively.

[0140] In the OVS flow table, it is used to set the source and destination IP addresses of VXLAN packets.

[0141] src_cidr, dst_cidr: represent the CIDR of the cloud subnet and the client-side IDC subnet respectively.

[0142] In the OVS flow table, it is used to match the destination IP address and determine the forwarding path for the data packet.

[0143] src_loop_ip, dst_loop_ip: represent the loop port IP addresses on the tenant gateway and POP switch, respectively.

[0144] In the OVS flow table, it is used to set the source and destination IP addresses of IP tunnel encapsulation.

[0145] When creating a virtual interface on OVS and configuring the IP address, src_loop_ip and dst_loop_ip are used.

[0146] When creating a flow table, information such as vxlan_tunnel_vni, vpp_vtep_ip, pop_vtep_ip, src_cidr, and dst_cidr are used to define the matching rules and forwarding behavior of data packets.

[0147] When sending and receiving traffic, packets are encapsulated and decapsulated according to the configured flow table, and routing is performed based on src_cidr and dst_cidr.

[0148] When analyzing traffic receiving and sending status information, these values ​​are combined to determine the connectivity of the cloud dedicated line.

[0149] By obtaining the configuration information of the cloud dedicated line, we can build a simulation environment and perform the core configuration parameters for traffic sending and receiving. With these parameters, we can accurately simulate the network environment of the cloud dedicated line and evaluate the performance of the cloud dedicated line.

[0150] In an optional embodiment of the present invention, the step of selecting a simulation node and installing a virtual switch OVS on the simulation node includes:

[0151] The network card IP address of the computer used as the simulation node is set to the IP address of the tunnel endpoint of the POP switch, and a virtual switch OVS is installed on the computer.

[0152] The embodiment of the present invention provides a real network environment for subsequent testing by simulating the POP switch and client-side IDC environment of the cloud dedicated line. By modifying the VTEP IP address of a computer node to the VTEP IP address of the POP switch, the computer node can establish a VXLAN tunnel with the tenant gateway, thereby simulating data transmission on the cloud dedicated line.

[0153] Exemplarily, the simulation node may be selected and the virtual switch OVS may be installed in the following manner.

[0154] Select the computer node:

[0155] This computer node is usually a physical machine or virtual machine in the resource pool within the cloud.

[0156] It is required that OVS has been installed and configured on the node, and the basic network environment has been configured.

[0157] Modify the VTEP IP address:

[0158] Change the VTEP IP address of the computer node to pop_vtep_ip obtained from the configuration information, that is, 33.33.33.33.

[0159] The VTEP IP address is the IP address of the VXLAN tunnel endpoint and is used to identify the VXLAN tunnel.

[0160] Establish a VXLAN tunnel:

[0161] By configuring the OVS flow table, a VXLAN tunnel is established between the tenant gateway and the computer node.

[0162] The VNI value of the tunnel is the same as the vxlan_tunnel_vni obtained in the configuration information, that is, 320.

[0163] By setting the network card IP address of the computer used as the simulation node to the IP address of the tunnel endpoint of the POP switch and installing the virtual switch OVS on the computer, the following beneficial effects are achieved.

[0164] Simulating a real environment: By using a computer node as a POP switch, the process of connecting the cloud dedicated line to the POP switch and the tenant gateway is simulated.

[0165] Create a test environment: Provides a basic network environment for subsequent traffic testing.

[0166] Simplify the testing process: There is no need to build a real POP switch, which reduces the complexity and cost of testing.

[0167] In an optional embodiment of the present invention, the step of configuring network information for the second virtual network interface of the network namespace includes:

[0168] Determine the POP switch loopback interface IP address of the POP switch loopback interface;

[0169] Setting the IP address of the second virtual network interface to the IP address of the POP switch and the IP address of the loopback interface of the POP switch;

[0170] Based on the IP protocol type and the client-side device subnet, a subnet mask is set for the second virtual network interface.

[0171] In a specific implementation, the embodiment of the present invention can first find the veth1_dc interface, which is usually a virtual network card interface created in the network namespace ns_dc of the simulated client-side IDC. This interface is used to connect to the VXLAN tunnel.

[0172] Set IP address: Set the IP address of the veth1_dc interface to dst_loop_ip. This dst_loop_ip can be the loop port IP address on the POP switch obtained from the configuration information.

[0173] The purpose of setting the IP address is to enable the tenant gateway to find the simulated client-side IDC through the VXLAN tunnel.

[0174] Set subnet mask: Set the corresponding subnet mask for the veth1_dc interface according to ip_type (IPv4 or IPv6). The subnet mask is used to define the network part and the host part of the IP address, thereby determining the network on which the device is located.

[0175] By determining the POP switch loopback interface IP address of the POP switch loopback interface; setting the IP address of the second virtual network interface to the POP switch IP address and the POP switch loopback interface IP address; and setting the subnet mask for the second virtual network interface based on the IP protocol type and the client-side device subnet, the following beneficial effects are achieved:

[0176] Complete the simulation environment setup: By configuring the IP address for the simulated client-side IDC, the entire simulation environment is set up.

[0177] Prepare for traffic test: Provides an interface for sending and receiving data for subsequent traffic tests.

[0178] Simulate a real scenario: simulate the process of connecting the client-side IDC gateway device to the cloud dedicated line.

[0179] In the specific implementation, the IP address and mask can be set for the lo port in ns_dc according to the ip_type type and dst_cidr.

[0180] In an optional embodiment of the present invention, the network namespace is configured with a network namespace loopback interface, further comprising:

[0181] Setting a network namespace loopback interface IP address for the network namespace loopback interface;

[0182] Based on the IP protocol type and the client-side device subnet, a subnet mask is set for the network namespace loopback interface.

[0183] The Loopback (lo) interface, also known as the loopback interface, is a virtual network interface that does not rely on any physical hardware. You can think of it as a virtual network cable that connects the device itself.

[0184] In a specific implementation, the embodiment of the present invention can set the IP address and mask for the lo port in the ns_dc according to the ip_type type and dst_cidr.

[0185] Since the lo interface plays the role of a host in the mock client-side IDC, you need to set a common host IP address in the client-side IDC subnet for the lo interface, that is, assign it an IP address in dst_cidr (usually remove the first and last IP addresses in the cidr network segment and randomly select one in the middle range of cidr).

[0186] For example, this can be achieved through the following command:

[0187] #If it is ipv4 type, then:

[0188] ip netns exec ns_dc ip addr add 192.168.20.20 / 24dev lo

[0189] #If it is ipv6 type, then:

[0190] ip netns exec ns_dc ip-6addradd abcd:2::20 / 96dev lo

[0191] The purpose of the above command is to:

[0192] Enter the namespace: Run the ip netns exec ns_dc command to enter the network namespace of the simulated client-side IDC.

[0193] Configure the loopback interface:

[0194] IP address: According to ip_type and dst_cidr, an IP address is assigned to the loopback interface. This IP address should be within the subnet range represented by dst_cidr and should not be the start or end address of the network segment.

[0195] Subnet mask: Keep consistent with the subnet mask of dst_cidr.

[0196] For example, the example states:

[0197] IPv4 example:

[0198] ip netns exec ns_dc ip addr add 192.168.20.20 / 24dev lo

[0199] This command indicates that in the namespace ns_dc, the loopback interface lo is assigned an IP address of 192.168.20.20 with a subnet mask of 24. This IP address belongs to the network segment 192.168.20.0 / 24, which is consistent with the dst_cidr configured in step 3.

[0200] IPv6 example:

[0201] ip netns exec ns_dc ip-6addradd abcd:2::20 / 96dev lo

[0202] This command indicates that in the namespace ns_dc, the loopback interface lo is assigned an IPv6 address abcd:2::20 with a subnet mask of 96. This IP address belongs to the network segment abcd:2::0 / 96, which is consistent with the dst_cidr configured in step 3.

[0203] The purpose of configuring a loopback (lo) interface is to:

[0204] Simplified configuration: The loopback interface is a virtual network interface with simple configuration and does not require a physical network card.

[0205] Simulated host: The loopback interface can simulate a host to send and receive network traffic.

[0206] Isolation: The loopback interface is isolated from other interfaces and does not affect other network configurations.

[0207] In an optional embodiment of the present invention, it also includes:

[0208] Performing a network connectivity test based on the network namespace loopback interface IP address and generating a network connectivity test result;

[0209] The step of detecting the connectivity of the cloud dedicated line between the cloud host and the network namespace based on the traffic receiving and sending status information includes:

[0210] The connectivity of the cloud dedicated line between the cloud host and the network namespace is measured based on the network connectivity test result.

[0211] In practical applications, network connectivity test (ping test) is the most intuitive way to verify whether two hosts can communicate with each other, that is, whether they can send and receive data packets. The response result of the ping command (such as packet loss rate, delay, etc.) directly reflects the connectivity of the network.

[0212] In the specific implementation, the connectivity between the cloud host (VM1) and the IP address set on the lo port in ns_dc is tested in the cloud host (VM1) (such as ping test). If connectivity is achieved, it means that all business configurations are correct and the cloud dedicated line connectivity test has passed.

[0213] Verifying the connectivity between the cloud host and the virtual host in ns_dc through a ping test is a simple and effective way to verify whether the cloud dedicated line is configured correctly. If the ping test is successful, it means that the cloud dedicated line has been set up and can meet basic network communication requirements.

[0214] In order to enable those skilled in the art to better understand the embodiments of the present invention, a complete example is used below to illustrate the embodiments of the present invention.

[0215] Related technologies Before tenants create cloud dedicated lines, they need to create basic network resources in the cloud resource pool, including creating VPC and the corresponding subnet. The vni corresponding to the vpc is 320, and the subnet segment CIRD is 192.168.10.0 / 24. A cloud host 1 (i.e., a virtual machine) is created in the subnet. The IP address of cloud host 1 is 192.168.10.10. After the VPC is created, the cloud resource pool will allocate a tenant gateway for the VPC. All layer 3 traffic in and out of the VPC is forwarded by the tenant gateway. The vtep ip address of the tenant gateway is 22.22.22.22. Usually, the tenant gateway is two network element servers, which can provide traffic forwarding services for the VPC in a master-slave mode to improve the high availability of the service. The vtep ip address of the host machine where the cloud host is located is 11.11.11.11. There is a vxlan tunnel between the host machine and the tenant gateway, that is, a vxlan tunnel is established between the two vtep ip addresses 11.11.11.11 and 22.22.22.22, and the vni value of the vxlan tunnel is 320.

[0216] The tenant then creates a cloud dedicated line. When creating a cloud dedicated line, the subnet CIDR of the host in the client-side IDC that needs to communicate with the cloud resource pool is specified, that is, 192.168.20.0 / 24. In addition, the cloud resource pool will allocate a pair of loop IP addresses for the cloud dedicated line and send them to the tenant gateway and pop switch respectively. That is, the tenant gateway has a loop port with an IP address of loop_ip1, and the pop switch has a loop port with an IP address of loop_ip2. The vtep IP address of the pop switch is 33.33.33.33. There is a vxlan tunnel between the tenant gateway and the pop switch, that is, a vxlan tunnel is established between the two vtep IP addresses 22.22.22.22 and 33.33.33.33, and the vni value of the vxlan tunnel is 320. loop_ip1 and loop_ip2 can communicate with each other and are used to forward the service traffic of the cloud dedicated line. In addition, a new route will be added to the tenant gateway. The destination address of this route is the CIDR of the subnet in the client-side IDC, and the next hop is loop_ip2 on the pop switch, that is, 192.168.20.0 / 24via loop_ip2. This route is used to forward the traffic of the cloud dedicated line in the VPC to the pop switch. In addition, two new routes will be added to the pop switch. The destination address of one route is the CIDR of the subnet in the client-side IDC, and the next hop is loop_ip4 in the client-side IDC, that is, 192.168.20.0 / 24vialoop_ip4. The destination address of the other route is the CIDR of the subnet where the tenant cloud host 1 in the cloud resource pool is located, and the next hop is loop_ip1 on the tenant gateway, that is, 192.168.10.0 / 24vialoop_ip1. These two routes can be used to achieve intercommunication between the tenant gateway and the network devices in the customer IDC. The network configuration on the customer side needs to be configured offline by the customer. Here, only the relevant configuration in the cloud resource pool is explained, and the network configuration on the customer side is not detailed.

[0217] After creating the cloud dedicated line, the above configuration is issued and set to achieve connectivity between the subnet specified in the cloud resource pool and the subnet specified in the client-side IDC, that is, cloud host 1 (192.168.10.10) and host 2 (192.168.20.20) can communicate with each other.

[0218] However, in the daily development and testing of the cloud resource pool, usually only the test environment can be used, and the resources of the test environment are limited. If it is necessary to deploy a pop switch, a physical dedicated line, and a client-side IDC environment in the test environment, it will cost a lot of manpower and material resources, and the cost is high and the implementation is difficult. Therefore, the present invention provides a method and device for testing the connectivity of a cloud dedicated line, which can simulate a set of cloud dedicated line environments in the cloud resource pool environment without using a pop switch, without requiring a real physical dedicated line, and without requiring a real client-side IDC, and is used for mock testing the connectivity of the cloud dedicated line, so as to reduce the manpower and material cost during testing, reduce the difficulty of testing, and improve the efficiency of testing.

[0219] refer to Figure 2 and Figure 3 , Figure 2 is a network topology diagram of a cloud resource pool provided in an embodiment of the present invention; Figure 3 is another network topology diagram of a cloud resource pool provided in an embodiment of the present invention;

[0220] Figure 2 and Figure 3 They are respectively the network topology diagrams of the ipv4 type and the ipv6 type of the present invention. The network topology structures are the same and the implementation schemes are similar, so they are explained together.

[0221] The first step is to create the tenant's basic network and resources in advance, including creating the tenant gateway, the tenant's VPC, the subnet in the VPC, the cloud host in the subnet, etc. The cloud host can communicate with the tenant gateway.

[0222] In this step, you need to pre-create basic networks and resources such as tenant gateways, vpcs, subnets, and cloud hosts, including pre-creating a cloud host in the subnet for subsequent testing of connectivity with the host on the other end of the cloud dedicated line. For example, in the case of ipv4 type, the ip of the cloud host can be 192.168.10.10, and in the case of ipv6 type, the ip of the cloud host can be abcd:1::10.

[0223] The second step is to create a cloud dedicated line for the VPC of the above tenants.

[0224] After the cloud dedicated line is created, the basic cloud dedicated line configurations are configured on the tenant gateway: the loop port and IP address corresponding to the cloud dedicated line (i.e. src_loop_ip), the vxlan tunnel from the tenant gateway to the pop switch (i.e. the vxlan tunnel between 22.22.22.22 and 33.33.33.33), and the route to the customer subnet in the client IDC (i.e. 192.168.20.0 / 24 via 200.0.0.2 or abcd:2::0 / 96 via 200:0:0::2).

[0225] The third step is to obtain the relevant information of the cloud dedicated line created in the second step, including at least: the IP protocol type of the cloud dedicated line (i.e. ip_type, optional values ​​are ipv4 and ipv6), the tunnel vni value corresponding to the VPC (i.e. vxlan_tunnel_vni), the vtep ip address of the tenant gateway corresponding to the VPC (i.e. vpp_vtep_ip), the vtep ip address of the pop switch (i.e. pop_vtep_ip), the cloud subnet CIDR corresponding to the cloud dedicated line (i.e. src_cidr), the subnet CIDR in the customer IDC corresponding to the cloud dedicated line (i.e. dst_cidr), the IP address of the loop port corresponding to the cloud dedicated line on the tenant gateway (i.e. src_loop_ip), and the IP address of the loop port corresponding to the cloud dedicated line on the pop switch (i.e. dst_loop_ip).

[0226] like Figure 2 and Figure 3 , the vxlan_tunnel_vni value is 320, the vpp_vtep_ip is 22.22.22.22, and the pop_vtep_ip is 33.33.33.33.

[0227] for Figure 2 , ip_type value is ipv4, src_cidr is 192.168.10.0 / 24, dst_cidr is 192.168.20.0 / 24, src_loop_ip is 200.0.0.1, dst_loop_ip is 200.0.0.2.

[0228] for Figure 3 , ip_type value is ipv6, src_cidr is abcd:1::0 / 96, dst_cidr is abcd:2::0 / 96, src_loop_ip is 200:0:0::1, dst_loop_ip is 200:0:0::2.

[0229] Step 4: Select a computer node to mock the pop switch and client-side IDC environment corresponding to the cloud dedicated line. Change the vtep_ip address of the computer node to pop_vtep_ip.

[0230] like Figure 2 and Figure 3The selected computer node is usually also the host of various cloud hosts in the cloud resource pool. Basic network configurations such as OVS and vtep ip have been configured on the computer node. Change the vtep ip of the computer node to: 33.33.33.33. After the modification, the tenant gateway and the computer node can be connected through the vxlan tunnel. The vni value of the tunnel is the same as vxlan_tunnel_vni, that is, 320.

[0231] In the fifth step, a pair of vethpair type virtual network interfaces are created on the computer node, namely veth0_dc and veth1_dc, and the interface veth0_dc is enabled.

[0232] Use the following command:

[0233] ip link addveth0_dc type vethpeername veth1_dc

[0234] ip link set dev veth0_dc up

[0235] The vethpair type is used to connect the OVS br-int bridge to the created network namespace later.

[0236] Step 6: Create a network namespace on the computer node and name it ns_dc. Add the interface veth1_dc to the network namespace ns_dc, and enable the lo port and veth1_dc port in the network namespace ns_dc.

[0237] Use the following command:

[0238] ip netns addns_dc

[0239] ip link setveth1_dc netns ns_dc

[0240] ip netns exec ns_dc ip link set dev lo up

[0241] ip netns exec ns_dc ip link set devveth1_dc up

[0242] The interface lo is a loopback interface that is automatically created by default when the network namespace is created. After this step, there are two interfaces in the network namespace, the lo interface and the veth1_dc interface, and both interfaces are in the up state (i.e., enabled state).

[0243] Step 7. Set the IP address of the veth1_dc port in ns_dc to dst_loop_ip, and set the mask for the veth1_dc port according to the ip_type type.

[0244] Use the following command:

[0245] #If it is ipv4 type, then:

[0246] ip netns exec ns_dc ip addr add200.0.0.2 / 30dev veth1_dc

[0247] #If it is ipv6 type, then:

[0248] ip netns exec ns_dc ip-6addradd200:0:0::2 / 126dev veth1_dc

[0249] For ipv4-type cloud dedicated lines, the mask corresponding to dst_loop_ip is 30 bits, and for ipv6-type cloud dedicated lines, the mask corresponding to dst_loop_ip is 126 bits. The mask is made as large as possible to reduce the conflict between dst_loop_ip and other network segments.

[0250] Step 8. Set the IP address and mask for the lo port in ns_dc according to the ip_type type and dst_cidr.

[0251] Use the following command:

[0252] #If it is ipv4 type, then:

[0253] ip netns exec ns_dc ip addr add 192.168.20.20 / 24dev lo

[0254] #If it is ipv6 type, then:

[0255] ip netns exec ns_dc ip-6addradd abcd:2::20 / 96dev lo

[0256] Here, the role of interface lo is to mock the host in the client-side IDC, so you need to set a common host IP address in the client-side IDC subnet for interface lo, that is, assign it an IP address in dst_cidr (usually remove the first and last IP in the cidr network segment and randomly select one in the middle range of cidr). In this example, according to the different ip_type types, it is assigned 192.168.20.20 and abcd:2::20. The mask length is the same as the mask of dst_cidr. In this example, it is 24 and 96 respectively according to the different ip_type types.

[0257] Step 9. According to the ip_type type, add a route in ns_dc with the destination address src_cidr and the next hop address src_loop_ip.

[0258] Use the following command:

[0259] #If it is ipv4 type, then:

[0260] ip netns exec ns_dc ip route add 192.168.10.0 / 24via 200.0.0.1devveth1_dc

[0261] #If it is ipv6 type, then:

[0262] ip netns exec ns_dc ip-6route add abcd:1::0 / 96via200:0:0::1dev veth1_dc

[0263] After adding this route, if the destination address of the IP packet from the interface lo matches src_cidr, the traffic will be sent out from the veth1_dc port, and the next hop destination address will be src_loop_ip.

[0264] Step 10: Create a port named veth0_dc on the OVS br-int bridge of the computer node and activate the port.

[0265] Use the following command:

[0266] ovs-vsctl----if-exists del-port veth0_dc--add-port br-int veth0_dc--set Interface veth0_dc external-ids: iface-status=active

[0267] The --if-exists del-port veth0_dc command is used to avoid residual dirty data during repeated tests and to delete any residual dirty data that may exist.

[0268] In the eleventh step, a corresponding flow table is added to the OVS br-int bridge of the computer node so that the traffic in the network namespace ns_dc can be connected to the tenant gateway through the flow table.

[0269] 1.table=0, priority=2000, in_port=vxlan1, tun_id=320, tun_src=22.22.22.22actions=output: veth0_dc

[0270] 2.table=0, priority=2000, in_port=veth0_dc actions=set_field: 320->tun_id, set_field: 22.22.22.22->tun_dst, output: vxlan1

[0271] These two flow tables allow the traffic of the cloud dedicated line to be correctly forwarded between the vxlan1 port and the veth0_dc port of the br-int bridge. These two flow tables need to be set with a high priority value so that the test traffic of the cloud dedicated line is not interfered with by other traffic areas in the test environment. The priority is set to 2000 here, and other high priority values ​​can also be set according to the actual situation of the test environment.

[0272] Step 12: Test the connectivity between the cloud host (VM1) and the IP address set on the lo port in ns_dc (such as ping test) in the cloud host (VM1). If connectivity is achieved, it means that all business configurations are correct and the cloud dedicated line connectivity test has passed.

[0273] In summary, after the above eleven steps, cloud host 1 can communicate with the host in the client-side IDC. The following example uses ipv4 type traffic. The ipv6 type is similar and will not be repeated.

[0274] For the traffic in cloud host 1 that needs to access the host in the client-side IDC of the cloud dedicated line, that is, 192.168.10.10=>192.168.20.20 (original message 1), the traffic will initially be sent to the tenant gateway corresponding to the VPC. Since 192.168.10.10 and 192.168.20.20 are not IPs in the same subnet segment, the tenant gateway will find the corresponding route: 192.168.20.0 / 24via 200.0.0.2, which means that the message needs to be sent to 200.0.0.2. Since 200.0.0.2 is on the computer node, the tenant gateway will encapsulate the original message 1 through VXLAN and send it to the vxlan tunnel between the tenant gateway and the computer node. Figure 2 On the computer node shown. After the computer node is encapsulated by VXLAN, the vxlan1 port will be used by default to receive the message, that is, a data message 192.168.10.10=>192.168.20.20 (i.e. original message 1) comes from the vxlan1 port on OVS. After receiving the message, OVS finds that the message comes from the vxlan1 port, and the tunnel VNI is 320 and the tunnel source address is 22.22.22.22, so it will match the first flow table in step 11, and use the action of the flow table to send the message out from the veth0_dc port. Since the interface veth0_dc and the interface veth1_dc are a pair of vethpair type interfaces, veth1_dc will also receive the above original message 1. Since the veth1_dc port and the lo port are in the same network namespace, which is equivalent to being in the same local network, veth1_dc can clearly know that the address 192.168.20.20 is on the lo port, so veth1_dc will send the message to the lo port. At this point, the original message 1 (192.168.10.10=>192.168.20.20) has arrived at its target interface lo, that is, the mock simulates the message of cloud host 1 in the cloud resource pool and arrives at the host in the client-side IDC after passing through the cloud dedicated line. The following details the traffic path in the reverse direction.

[0275] For the traffic of cloud host 1 in the client-side IDC that needs to access the cloud dedicated line's peer cloud resource pool, that is, 192.168.20.20=>192.168.10.10 (original message 2), after the traffic comes out from the lo port, it will match the destination IP address and find this route in the network namespace: 192.168.10.0 / 24via 200.0.0.1dev veth1_dc, which means that the message needs to be sent from veth1_dc to 200.0.0.1. Thus, the original message 2 is sent out from the veth1_dc port, and the next hop destination address is 200.0.0.1. Since veth0_dc and veth1_dc are a pair of vethpair-type virtual network interfaces, the message will also come out from the veth0_dc port and reach the OVS br-int bridge. At this time, OVS will match the traffic and find that it is the traffic coming out of the veth0_dc port. It randomly matches the second flow table in the above eleventh step and executes the action corresponding to the flow table, that is, setting the vxlan tunnel vni value to 320 and the vxlan tunnel destination address to 22.22.22.22, and then sending it out from the vxlan1 port after vxlan encapsulation. The encapsulated message will reach the tenant gateway through the vxlan tunnel between the computer node and the tenant gateway, and the tenant gateway will perform vxlan decapsulation to obtain the original message 2 (192.168.20.20=>192.168.10.10). The tenant gateway, combined with the vni value of 320, can find the corresponding mac address and other data of the cloud host 1, so as to deliver the message to the cloud host 1 (the process of the tenant gateway sending the message to the cloud host does not belong to the focus and invention of the present invention, and will not be described in detail here). At this point, the original message 2 (192.168.20.20=>192.168.10.10) has reached its target host, that is, the mock simulates the message in the host in the client-side IDC and reaches the cloud host 1 in the cloud resource pool after passing through the cloud dedicated line.

[0276] At this point, a complete mock simulation of the traffic forwarding of the cloud dedicated line between the cloud resource pool and the customer-side IDC has been achieved. It can be used to test the connectivity of the cloud dedicated line in the test resource pool. There is no need to deploy pop switches, configure physical dedicated lines, or configure the customer IDC environment, which greatly reduces manpower and material costs and improves testing efficiency.

[0277] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0278] Reference Figure 4 , shows a structural block diagram of a cloud dedicated line connectivity test device provided in an embodiment of the present invention, which may specifically include the following modules:

[0279] The simulation node selection module 401 is used to select a simulation node and install a virtual switch OVS on the simulation node; the virtual switch OVS is provided with an integrated bridge;

[0280] A virtual network interface construction module 402 is used to construct a first virtual network interface and a second virtual network interface for installing a virtual switch OVS;

[0281] A network namespace creation module 403, used to create a network namespace for simulating a network environment of a client-side device at the simulation node;

[0282] A network information configuration module 404, configured to add the second virtual network interface to the network namespace and configure network information for the second virtual network interface of the network namespace;

[0283] A flow table creation module 405, configured to add the first virtual network interface to the integration bridge and create a flow table on the integration bridge;

[0284] A traffic transceiving state information generating module 406, configured to perform traffic transceiving through the flow table and the network information and the network namespace, and generate traffic transceiving state information;

[0285] The connectivity testing module 407 is used to detect the connectivity of the cloud dedicated line between the cloud host and the network namespace based on the traffic receiving and sending status information.

[0286] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0287] In addition, an embodiment of the present invention further provides an electronic device, such as Figure 5As shown, it includes a processor 501, a communication interface 502, a memory 503 and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504.

[0288] Memory 503, used for storing computer programs;

[0289] The processor 501 is configured to implement the cloud dedicated line connectivity testing method described in any one of the above embodiments when executing the program stored in the memory 503:

[0290] The communication bus mentioned in the above terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0291] The communication interface is used for communication between the above terminal and other devices.

[0292] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0293] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0294] like Figure 6As shown, in another embodiment provided by the present invention, a computer-readable storage medium 601 is also provided, in which instructions are stored. When the computer-readable storage medium 601 is run on a computer, the computer executes the cloud dedicated line connectivity test method described in the above embodiment.

[0295] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation modes, which are merely illustrative rather than restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are within the protection of the present invention.

[0296] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the embodiments of the present invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0297] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0298] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0299] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0300] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0301] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, ROM, RAM, magnetic disks, or optical disks.

[0302] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A cloud dedicated line connectivity testing method, characterized in that: The method is applied to a cloud host of a virtual private cloud network, and includes: Select a simulation node, and install a virtual switch OVS on the simulation node; the virtual switch OVS is provided with an integrated bridge; Constructing a first virtual network interface and a second virtual network interface for installing a virtual switch OVS; Creating a network namespace for simulating a network environment of a client-side device at the simulation node; Adding the second virtual network interface to the network namespace, and configuring network information for the second virtual network interface of the network namespace; Adding the first virtual network interface to the integration bridge, and creating a flow table on the integration bridge; Execute traffic sending and receiving through the flow table, the network information and the network namespace, and generate traffic sending and receiving state information; The connectivity of the cloud dedicated line between the cloud host and the network namespace is detected based on the traffic receiving and sending status information.

2. The method according to claim 1, characterized in that Before the step of selecting a simulation node and installing a virtual switch OVS on the simulation node; and providing an integration bridge on the virtual switch OVS, the method further includes: Obtain configuration information of the cloud dedicated line; Based on the configuration information, determine the IP protocol type of the cloud dedicated line, the tunnel virtual network identifier, the tenant gateway, and the IP address of the tunnel endpoint of the POP switch, as well as the classless inter-domain routing of the cloud subnet and the client-side device subnet, the tenant gateway loopback interface and the tenant gateway IP address of the tenant gateway, and the POP switch loopback interface and the POP switch IP address of the POP switch.

3. The method according to claim 2, characterized in that The steps of selecting a simulation node and installing a virtual switch OVS on the simulation node include: The network card IP address of the computer used as the simulation node is set to the IP address of the tunnel endpoint of the POP switch, and a virtual switch OVS is installed on the computer.

4. The method according to claim 3, characterized in that The step of configuring network information for the second virtual network interface of the network namespace comprises: Determine the POP switch loopback interface IP address of the POP switch loopback interface; The IP address of the second virtual network interface is set to the POP switch IP address and the POP switch loopback interface IP address.

5. The method according to claim 4, characterized in that Also includes: Based on the IP protocol type and the client-side device subnet, a subnet mask is set for the second virtual network interface.

6. The method according to claim 4, characterized in that The network namespace is configured with a network namespace loopback interface and further includes: Setting a network namespace loopback interface IP address for the network namespace loopback interface; Based on the IP protocol type and the client-side device subnet, a subnet mask is set for the network namespace loopback interface.

7. The method according to claim 6, characterized in that Also includes: Performing a network connectivity test based on the network namespace loopback interface IP address and generating a network connectivity test result; The step of detecting the connectivity of the cloud dedicated line between the cloud host and the network namespace based on the traffic receiving and sending status information includes: The connectivity of the cloud dedicated line between the cloud host and the network namespace is measured based on the network connectivity test result.

8. A cloud dedicated line connectivity testing device, characterized in that: The device is applied to a cloud host of a virtual private cloud network, and includes: A simulation node selection module, used for selecting a simulation node and installing a virtual switch OVS on the simulation node; the virtual switch OVS is provided with an integrated bridge; A virtual network interface construction module, used to construct a first virtual network interface and a second virtual network interface for installing a virtual switch OVS; A network namespace creation module, used to create a network namespace for simulating a network environment of a client-side device at the simulation node; A network information configuration module, used to add the second virtual network interface to the network namespace and configure network information for the second virtual network interface of the network namespace; A flow table creation module, used for adding the first virtual network interface to the integration bridge and creating a flow table on the integration bridge; A flow receiving and sending state information generating module, used to perform flow receiving and sending through the flow table and the network information and the network namespace, and generate flow receiving and sending state information; A connectivity testing module is used to detect the connectivity of the cloud dedicated line between the cloud host and the network namespace based on the traffic receiving and sending status information.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; The memory is used to store computer programs; The processor is used to implement the method according to any one of claims 1 to 7 when executing the program stored in the memory.

10. A computer-readable storage medium having instructions stored thereon, which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 7.

Images