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

Abstract

Embodiments of the present application provide a cloud private line connectivity test method and device, electronic equipment and storage medium, a virtual switch is installed on a simulation node; a first virtual network interface and a second virtual network interface are constructed for the installed virtual switch; a network namespace is created on the simulation node to simulate a network environment of a customer-side device; the second virtual network interface is added to the network namespace, and the network namespace is simulated with the second virtual network interface to configure network information; the first virtual network interface is added to an integrated bridge, and a flow table is created on the integrated bridge; traffic transmission and reception are performed with the flow table and the network information and the network namespace, and traffic transmission and reception state information is generated; and connectivity of a cloud private line between a cloud host and the network namespace is detected based on the traffic transmission and reception state information, so that the connectivity of the cloud private line is tested without excessive dependence on a test environment, test cost is reduced, and test efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud private line connectivity testing, in particular to a cloud private line connectivity testing method, a cloud private line connectivity testing device, an electronic device and a computer readable storage medium. BACKGROUND

[0002] In a traditional public cloud architecture, a cloud private line is an important bridge connecting resources in the cloud and data centers offline. Through a physical private line, the host in the cloud and the host in the customer-side IDC can realize interconnection and intercommunication, forming a unified network environment.

[0003] However, there are significant technical challenges in testing and maintaining the cloud private line. Specifically, when the cloud business is developed or iteratively updated, comprehensive testing and verification are required. Traditional testing methods usually rely on testing environments, but the resources of testing environments are limited and cannot fully simulate the complexity of the production environment. Especially when it comes to joint debugging with POP switches and customer-side IDCs, complex network equipment needs to be configured, physical private lines need to be set up, and simulated customer-side IDC environments need to be built. This testing method not only consumes a lot of manpower and resources, but also has a long cycle and low efficiency, greatly increasing the testing cost and difficulty. SUMMARY

[0004] The embodiments of the present application provide a cloud private 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 embodiments of the present application disclose a cloud private line connectivity testing method, which is applied to a cloud host of a virtual private cloud network, and includes:

[0006] Selecting a simulation node and installing a virtual switch OVS on the simulation node; the virtual switch OVS is provided with an integrated bridge;

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

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

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

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

[0011] Traffic transmission and reception are performed using the flow table and the network information in the network namespace, and traffic transmission and reception status information is generated.

[0012] The connectivity of the cloud private line between the cloud host and the network namespace is detected based on the traffic transmission and reception status information.

[0013] This invention also discloses a cloud private line connectivity testing device, which is applied to cloud hosts in a virtual private cloud network and includes:

[0014] The simulated node selection module is used to select simulated nodes and install virtual switches (OVS) on the simulated nodes; the virtual switches (OVS) are equipped with integrated bridges.

[0015] The virtual network interface construction module is used to build the first and second virtual network interfaces for installing the OVS virtual switch.

[0016] The network namespace creation module is used to create a network namespace on the simulated node for simulating the network environment of the client-side device.

[0017] The network information configuration module is used to add the second virtual network interface to the network namespace and configure network information for the second virtual network interface in the network namespace.

[0018] The flow table creation module is used to add the first virtual network interface to the integration bridge and create a flow table on the integration bridge;

[0019] The traffic transmission and reception status information generation module is used to perform traffic transmission and reception with the network namespace through the flow table and the network information, and generate traffic transmission and reception status information;

[0020] The connectivity testing module is used to detect the connectivity of the cloud private line between the cloud host and the network namespace based on the traffic transmission and reception status information.

[0021] This invention also discloses an electronic device, including 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;

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

[0023] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0024] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

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

[0026] In this embodiment of the invention, by selecting a simulated node and installing a Virtual Switch (OVS) on the simulated node; the OVS is equipped with an integrated bridge; a first virtual network interface and a second virtual network interface are constructed for the installed OVS; a network namespace is created on the simulated node to simulate the network environment of the client-side device; the second virtual network interface is added to the network namespace, and network information is configured for the second virtual network interface in 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; the connectivity of the cloud private line between the cloud host and the network namespace is detected based on the traffic sending and receiving status information, achieving the following beneficial effects:

[0027] Virtualization: By using virtualization technology, multiple virtual network environments can be created on physical machines to simulate real cloud private line scenarios, avoiding the need to build complex physical environments, including POP switches, physical private lines, etc., and reducing dependence on the test environment.

[0028] Software-defined networking: Using OVS as a virtual switch, network traffic can be flexibly configured to achieve fine-grained control over the network and avoid the difficulty of quickly adjusting and reusing the test environment.

[0029] Automation: Improving testing efficiency by automating the testing process through scripts or tools. Attached Figure Description

[0030] Figure 1 This is a flowchart of the steps of a cloud private line connectivity testing method provided in an embodiment of the present invention;

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

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

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

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

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

[0036] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0037] In current mainstream public cloud computing networks, cloud dedicated lines are typically used to connect the cloud resource pool with the on-premises customer data center (IDC). This involves laying a physical dedicated line between the two, enabling the hosts in the cloud resource pool to communicate with the hosts in the on-premises customer data center.

[0038] For outbound traffic from the cloud resource pool—that is, when a cloud host in the cloud resource pool needs to access a host in the customer's data center—the cloud host's traffic is first sent to the tenant gateway corresponding to that cloud host within the cloud resource pool. The tenant gateway has a route whose destination address is the CIDR of the subnet where the host in the customer's data center resides, and the next hop is a loop port address on a POP switch. Through this route, the tenant gateway can forward the traffic to the POP switch. The POP switch also has a route whose destination address is the CIDR of the subnet where the host in the customer's data center resides, and the next hop is the loop port address of a network device within the customer's data center. Through this route, the POP switch can forward the traffic to the customer's data center via a physical leased line, and finally, the network device within the customer's data center forwards the traffic to destination host 2.

[0039] For inbound traffic to the cloud resource pool—that is, when a host in the customer-side IDC needs to access a cloud host in the cloud resource pool—the host's traffic is first sent to the network device in the customer-side IDC. This network device then forwards the traffic to the POP switch via a physical leased line. The POP switch has a route whose destination address is the CIDR of the subnet where the cloud host in the cloud resource pool resides, and the next hop is a loopback address on the tenant gateway. Through this route, the POP switch can forward the traffic to the tenant gateway corresponding to cloud host 1 in the cloud resource pool. The tenant gateway then receives the traffic and forwards it to the cloud host.

[0040] This enables connectivity between hosts in the cloud resource pool and hosts in the on-premises customer data center.

[0041] However, the development and maintenance of cloud dedicated lines present the following technical challenges: high testing costs and difficulties. For example, after completing the development / iterative updates of cloud dedicated line-related services within the cloud resource pool, testing is typically only possible in a test environment. However, the resources of the test environment are limited. When it is necessary to perform joint debugging with POP switches and customer IDCs, configuring POP switches, setting up physical dedicated lines, and deploying customer-side IDC environments in the test environment as in the production environment would require significant manpower and resources, resulting in high costs and implementation difficulties.

[0042] To enable those skilled in the art to better understand the embodiments of the present invention, some of the technical names involved in the embodiments of the present invention will be described below.

[0043] VPC (Virtual Private Cloud): A network model used to isolate cloud hosts from each other in a 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 business traffic entering and leaving 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: A switch within the cloud resource pool responsible for accessing cloud dedicated lines.

[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 those computer nodes.

[0048] Reference Figure 1 The diagram illustrates a flowchart of a cloud private line connectivity testing method provided in an embodiment of the present invention, which may specifically include the following steps:

[0049] Step 101: Select a simulated node and install a virtual switch (OVS) on the simulated node; the virtual switch (OVS) is equipped with an integrated bridge.

[0050] Step 102: Construct the first and second virtual network interfaces for the OVS virtual switch.

[0051] Step 103: Create a network namespace on the simulated node to simulate the network environment of the client-side device;

[0052] Step 104: Add the second virtual network interface to the network namespace, and configure network information for the second virtual network interface in the network namespace;

[0053] Step 105: Add the first virtual network interface to the integration bridge and create a flow table on the integration bridge;

[0054] Step 106: Perform traffic sending and receiving with the network namespace using the flow table and the network information, and generate traffic sending and receiving status information;

[0055] Step 107: Select the connectivity of the cloud private line between the cloud host and the network namespace based on the traffic transmission and reception status information.

[0056] In specific implementations, embodiments of the present invention can be applied to cloud hosts in virtual private cloud networks.

[0057] In this embodiment of the invention, a simulated node can be selected, and a virtual switch (OVS) can be installed on the simulated node to establish the foundation for the test environment. By selecting a computer as the simulated node, a basic platform is provided for subsequent network configuration; this computer will act as a POP switch. Introducing the virtual switch (OVS) allows it to function as a powerful virtual switch used to control data traffic in the simulated environment. The purpose of creating an integrated bridge is that an integrated bridge, a concept in OVS, connects multiple ports together to form a switching network.

[0058] Installing and configuring an OVS virtual switch with integrated bridges provides a flexible and configurable testing platform, laying the foundation for subsequent network configuration.

[0059] In specific implementations, embodiments of the present invention can also construct a first virtual network interface and a second virtual network interface for installing the virtual switch OVS; embodiments 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 practical applications, a vethpair is a pair of special virtual network interfaces. When a data packet is sent out from one veth interface, it is immediately received from the other veth interface. This embodiment of the invention can create a pair of vethpair interfaces on the simulator, named veth0_dc and veth1_dc, and enable the veth0_dc interface for connection to the OVS bridge.

[0061] This embodiment of the invention can also create a network namespace on the simulated 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. This embodiment of the 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 that simulates a client-side data center, network settings within the namespace can be configured independently without affecting other parts.

[0063] In this embodiment of the invention, the second virtual network interface can also be added to the network namespace, and network information can be configured for the second virtual network interface in the network namespace;

[0064] In a specific implementation, this embodiment of the 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, i.e., dst_loop_ip; configure an IP address for the loop port in the namespace, which belongs to the subnet of the customer-side IDC; add a route in the namespace so that traffic in the namespace can be forwarded to the tenant gateway. By configuring IP addresses and subnet masks for the interfaces and loop ports in the namespace and adding a route, traffic in the namespace can be forwarded to the tenant gateway.

[0065] For example:

[0066] Assuming dst_loop_ip is 200.0.0.2, the customer-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 loop port

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

[0071] #Add route

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

[0073] By associating virtual network interface cards with namespaces, the connection between physical and virtual networks can be achieved. By configuring IP addresses, subnet masks, and other information for interfaces within the namespace, a real network environment can be simulated, thus establishing a connection between simulated nodes and the namespace and providing a foundation for network communication within the namespace.

[0074] The first virtual network interface is added to the integrated bridge, and the virtual network card is connected to the OVS bridge to form a switching network, realizing the connection with the tenant gateway. A flow table is created on the integrated bridge to define the forwarding rules of data packets on the OVS bridge, and to realize VXLAN encapsulation and decapsulation functions, thereby realizing the connection between the simulated node and the external network and controlling the flow of data packets in the network.

[0075] In this embodiment of the invention, traffic sending and receiving are performed using 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 to the OVS bridge to implement VXLAN encapsulation and decapsulation.

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

[0079] Action: Based on the matching result, perform the corresponding action, 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 relationships between the above steps are as follows:

[0084] Simulated POP switch: Provides 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 within the namespace and set routes to ensure that traffic can be forwarded correctly.

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

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

[0090] The embodiments of the present invention can generate traffic transmission and reception status information, and detect the connectivity of the cloud private line between the cloud host and the network namespace based on the traffic transmission and reception status information;

[0091] For example, the connectivity of a cloud private line can be tested in the following way.

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

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

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

[0095] Analyze the test results: Based on the generated traffic status information, determine the connectivity of the cloud private line to verify whether the cloud private line is working properly.

[0096] In this embodiment of the invention, by selecting a simulated node and installing a Virtual Switch (OVS) on the simulated node; the OVS is equipped with an integrated bridge; a first virtual network interface and a second virtual network interface are constructed for the installed OVS; a network namespace is created on the simulated node to simulate the network environment of the client-side device; the second virtual network interface is added to the network namespace, and network information is configured for the second virtual network interface in 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; the connectivity of the cloud private line between the cloud host and the network namespace is detected based on the traffic sending and receiving status information, achieving the following beneficial effects:

[0097] Virtualization: By using virtualization technology, multiple virtual network environments can be created on physical machines to simulate real cloud private line scenarios, avoiding the need to build complex physical environments, including POP switches, physical private lines, etc., and reducing dependence on the test environment.

[0098] Software-defined networking: Using OVS as a virtual switch, network traffic can be flexibly configured to achieve fine-grained control over the network and avoid the difficulty of quickly adjusting and reusing the test environment.

[0099] Automation: Improving testing efficiency by automating the testing process through scripts or tools.

[0100] Based on the above embodiments, modified embodiments of the above embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in the modified embodiments.

[0101] In an optional embodiment of the present invention, prior to the steps of selecting a simulated node and installing a virtual switch (OVS) on the simulated node, and the virtual switch (OVS) being configured with an integrated bridge, the method further includes:

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

[0103] Based on the configuration information, determine the IP protocol type of the cloud private line, the tunnel virtual network identifier, the tenant gateway, the IP address of the tunnel endpoint of the POP switch, the classless inter-domain routing of the cloud subnet and the customer-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 embodiments of the present invention may perform the following steps before executing the test.

[0105] Create tenant-based networks and resources.

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

[0107] Importance: This is the foundation of the entire test scenario. The tenant gateway, VPC, subnet, and cloud hosts constitute a complete network topology, providing a basis for subsequent cloud leased line configuration.

[0108] Create a cloud private line.

[0109] The goal is to establish a dedicated line connection between the tenant's VPC and the customer's IDC.

[0110] Importance: The cloud leased line is the core of the entire test. Through the cloud leased line, the tenant's cloud server can communicate with the server in the customer's data center.

[0111] Obtain information related to cloud private lines.

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

[0113] Specifically, embodiments of the present invention can obtain relevant configuration information of cloud private lines created in the cloud resource pool. The configuration information includes at least: the IP protocol type of the cloud private line (i.e., ip_type, with optional values ​​of 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 CIDR of the cloud subnet corresponding to the cloud private line (i.e., src_cidr), the CIDR of the subnet within the customer's IDC corresponding to the cloud private line (i.e., dst_cidr), the IP address of the loop port corresponding to the cloud private line on the tenant gateway (i.e., src_loop_ip), and the IP address of the loop port corresponding to the cloud private line on the POP switch (i.e., dst_loop_ip).

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

[0115] CIDR is an abbreviation for Classless Inter-Domain Routing. It is an IP address classification method used to assign IP addresses to users and to efficiently route IP packets across the Internet.

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

[0117] IP address allocation: CIDR is used to divide the network and allocate contiguous blocks of IP addresses to cloud subnets and customer-side IDC subnets.

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

[0119] Routing: Routers use CIDR information to determine which network a data packet should be sent to, thereby achieving efficient routing.

[0120] The reason for using CIDR in cloud subnets and customer-side IDC subnets is:

[0121] Flexible IP address allocation: CIDR can flexibly divide IP address blocks according to different network sizes and needs, avoiding the waste of IP addresses.

[0122] Simplified routing configuration: CIDR uses contiguous blocks of IP addresses, which simplifies routing table configuration and improves routing efficiency.

[0123] Supports large-scale networks: CIDR can support large-scale networks, meeting the needs of modern data centers and cloud computing.

[0124] CIDR representation

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

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

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

[0128] Summarize

[0129] CIDR is a very important network concept, widely used in cloud subnets and customer-side IDC subnets. Understanding CIDR allows for a better understanding of the principles of IP address allocation and routing, leading to better network management and maintenance.

[0130] The Loop port, also known as the loopback interface, is a virtual network interface that does not depend on any physical hardware. Simply put, it's like a virtual network cable that connects to the device itself.

[0131] The main function of the Loop port:

[0132] Device Identifier: Each device can be configured with a unique Loop port IP address as its identifier. This IP address is typically used for communication between devices, such as establishing BGP protocol connections between routers.

[0133] Management interface: Many network devices use the Loop port IP as the address of the management interface. Administrators can remotely log in to the device through this IP address to configure and manage it.

[0134] Routing Protocol: The Loop port can serve as an interface for routing protocols, participating in the calculation of routing protocols to ensure network stability.

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

[0136] When configuring OVS flow tables, different matching rules need to be set according to IP type.

[0137] vxlan_tunnel_vni: VXLAN tunnel virtual network identifier.

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

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

[0140] In the OVS flow table, the source and destination IP addresses of VXLAN packets are set.

[0141] src_cidr and 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 of the data packet.

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

[0144] The OVS flow table is used to set the source and destination IP addresses for IP tunnel encapsulation.

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

[0146] When creating flow tables, information such as vxlan_tunnel_vni, vpp_vtep_ip, pop_vtep_ip, src_cidr, and dst_cidr are used to define packet matching rules and forwarding behavior.

[0147] When sending and receiving traffic, the system encapsulates and decapsulates data packets according to the configured flow table, and performs route selection based on src_cidr and dst_cidr.

[0148] When analyzing traffic transmission and reception status information, these values ​​are used to determine the connectivity of the cloud private line.

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

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

[0151] Set the network card IP address of the computer used as the simulated node to the IP address of the tunnel endpoint of the POP switch, and install the virtual switch OVS on the computer.

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

[0153] For example, a simulated node can be selected and a virtual switch (OVS) can be installed in the following manner.

[0154] Select computer node:

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

[0156] The node must have OVS installed and configured, and a basic network environment must be configured.

[0157] Modify VTEP IP address:

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

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

[0160] Establish a VXLAN tunnel:

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

[0162] The VNI value of this tunnel is the same as the vxlan_tunnel_vni obtained from the configuration information, which is 320.

[0163] By setting the network card IP address of the computer used as the simulated 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] Simulate a real-world environment: By using a computer node as a POP switch, the process of connecting the cloud private line to the POP switch and the tenant gateway is simulated.

[0165] Creating a test environment: This provides the basic network environment for subsequent traffic testing.

[0166] Simplified testing process: No need to set up a real POP switch, reducing 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 IP address of the POP switch loopback interface;

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

[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, embodiments of the present invention can first locate the veth1_dc interface. veth1_dc is typically a virtual network interface card (NIC) created in the simulated client-side IDC's network namespace ns_dc. This interface is used to connect to the VXLAN tunnel.

[0172] Set the 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 the subnet mask: Set the appropriate subnet mask for the veth1_dc interface based on the ip_type (IPv4 or IPv6). The subnet mask is used to define the network portion and host portion of the IP address, thereby determining the network in which the device belongs.

[0175] By determining the POP switch loopback interface IP address; 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] The simulation environment setup was completed by configuring IP addresses for the simulated client-side IDC.

[0177] Preparing for traffic testing: Provides interfaces for sending and receiving data for subsequent traffic tests.

[0178] Simulates a real-world scenario: Simulates the process of connecting the gateway device of the customer-side IDC to the cloud private line.

[0179] In the actual implementation, the IP address and subnet mask of the LO interface in ns_dc can be set according to the ip_type and dst_cidr.

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

[0181] Configure the network namespace loopback interface IP address;

[0182] Based on the IP protocol type and the client-side device subnet, set the subnet mask 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 depend on any physical hardware. You can think of it as a virtual network cable connecting the device itself.

[0184] In a specific implementation, embodiments of the present invention can set the IP address and subnet mask for the LO interface within ns_dc based on the ip_type and dst_cidr.

[0185] Since the lo interface acts as a mock host within the client-side IDC, it is necessary to assign an IP address to the lo interface from a regular host within the subnet of the client-side IDC. This means assigning an IP address to it within dst_cidr (usually by removing the first and last IP addresses from the cidr network segment and then randomly selecting one from the middle range of cidr).

[0186] For example, this can be achieved using 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:

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

[0193] Configure the loopback interface:

[0194] IP Address: Assign an IP address to the loopback interface based on ip_type and dst_cidr. This IP address should be within the subnet represented by dst_cidr and should not be the start or end address of the network segment.

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

[0196] For example, example description:

[0197] IPv4 example:

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

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

[0200] IPv6 example:

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

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

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

[0204] Simplified configuration: The loopback interface is a virtual network interface, which is easy to configure and does not require a physical network card.

[0205] Simulated host: The loopback interface can simulate a host for sending and receiving network traffic.

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

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

[0208] Perform network connectivity testing based on the IP address of the loopback interface in the network namespace, and generate network connectivity test results;

[0209] The step of detecting the connectivity of the cloud private line between the cloud host and the network namespace based on the traffic transmission and reception status information includes:

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

[0211] In practical applications, network connectivity testing (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 results of the ping command (such as packet loss rate, latency, etc.) directly reflect the network connectivity.

[0212] In practice, the connectivity between the cloud host (VM1) and the IP address set on the lo port in ns_dc is tested (e.g., ping test). If the connectivity is successful, it means that all service configurations are correct and the cloud private line connectivity test is passed.

[0213] Verifying connectivity between the cloud server and the virtual hosts within the ns_dc is a simple and effective way to check if the cloud leased line is configured correctly. A successful ping test indicates that the cloud leased line has been successfully established and can meet basic network communication needs.

[0214] 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] Before a tenant creates a cloud private line, they need to create basic network resources in the cloud resource pool, including creating a VPC and its corresponding subnet. The VNI for the VPC is 320, and the CIRD for the subnet segment is 192.168.10.0 / 24. A cloud host 1 (i.e., a virtual machine) is created within this subnet, with the IP address 192.168.10.10. After creating the VPC, the cloud resource pool will assign a tenant gateway to it. All Layer 3 traffic entering and leaving the VPC is forwarded by this tenant gateway, whose VTEP IP address is 22.22.22.22. Typically, the tenant gateway consists of two network element servers, which can provide traffic forwarding services to the VPC in a primary / backup configuration to improve service high availability. The VTEP IP address of the host machine where the cloud host resides 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 private line. During creation, the CIDR of the subnet within the customer's data center that needs to communicate with the cloud resource pool is specified, namely 192.168.20.0 / 24. The cloud resource pool allocates a pair of loop IP addresses to this private line, one on the tenant gateway and one on the pop-up switch. The tenant gateway has one loop port with IP address loop_ip1, and the pop-up switch has one loop port with IP address loop_ip2. The VTEP IP address of the pop-up switch is 33.33.33.33. A VXLAN tunnel exists between the tenant gateway and the pop-up switch, specifically between the two VTEP IP addresses 22.22.22.22 and 33.33.33.33, with a VNI value of 320. Loop_ip1 and loop_ip2 can communicate with each other to forward the service traffic of the cloud private line. Furthermore, a new route will be added to the tenant gateway. The destination address of this route is the CIDR of the subnet within the customer's IDC, and the next hop is loop_ip2 on the POP switch, i.e., 192.168.20.0 / 24 via loop_ip2. This route is used to forward traffic from this cloud private line within the VPC to the POP switch. Two new routes will also be added to the POP switch. One route's destination address is the CIDR of the subnet within the customer's IDC, and the next hop is loop_ip4 within the customer's IDC, i.e., 192.168.20.0 / 24 via loop_ip4. The other route's destination address is the CIDR of the subnet where tenant cloud host 1 resides within the cloud resource pool, and the next hop is loop_ip1 on the tenant gateway, i.e., 192.168.10.0 / 24 via loop_ip1. These two routes enable communication between the tenant gateway and the network devices within the customer's IDC. The customer's network configuration needs to be configured offline; this section only describes the relevant configurations within the cloud resource pool and will not elaborate on the customer's network configuration.

[0217] After creating a cloud private line, and following the above configuration and settings, connectivity can be established between the specified subnet in the cloud resource pool and the specified subnet in the customer-side IDC. That is, cloud host 1 (192.168.10.10) and host 2 (192.168.20.20) can communicate and access each other.

[0218] However, during routine development and testing of cloud resource pools, only test environments are typically available, and these environments have limited resources. Deploying POP switches, physical leased lines, and customer-side IDC environments within the test environment would require significant manpower and resources, resulting in high costs and implementation difficulties. Therefore, this invention provides a method and apparatus for testing cloud leased line connectivity. This method and apparatus can simulate a cloud leased line environment within a cloud resource pool environment without requiring POP switches, real physical leased lines, or real customer-side IDCs. This allows for mock testing of cloud leased line connectivity, reducing manpower and resource costs, lowering testing difficulty, and improving testing efficiency.

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

[0220] Figure 2 and Figure 3 These are network topology diagrams for IPv4 and IPv6 types of the present invention, respectively. The network topology structures are the same and the implementation schemes are similar, so they are described together.

[0221] The first step is to pre-create the tenant's basic network and resources, including creating the tenant gateway, the tenant's VPC, subnets within the VPC, and cloud servers within the subnets. The cloud servers must be able to communicate with the tenant gateway.

[0222] This step requires pre-creating basic network and resources such as tenant gateways, VPCs, subnets, and cloud servers. This includes pre-creating a cloud server within the subnet for later testing of connectivity with the host on the cloud leased line. For example, in IPv4, the cloud server's IP address could be 192.168.10.10; in IPv6, the cloud server's IP address could be abcd:1::10.

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

[0224] After the cloud private line is created, the tenant gateway will be configured with the basic cloud private line related configurations: the loop port and IP address corresponding to the cloud private 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 within the client's 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 private line created in the second step, including at least: the IP protocol type of the cloud private line (i.e., ip_type, with optional values ​​of 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 CIDR of the cloud subnet corresponding to the cloud private line (i.e., src_cidr), the CIDR of the subnet within the customer's IDC corresponding to the cloud private line (i.e., dst_cidr), the IP address of the loop port corresponding to the cloud private line on the tenant gateway (i.e., src_loop_ip), and the IP address of the loop port corresponding to the cloud private line on the POP switch (i.e., dst_loop_ip).

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

[0227] for Figure 2 The 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, and dst_loop_ip is 200.0.0.2.

[0228] for Figure 3 The 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, and dst_loop_ip is 200:0:0::2.

[0229] Fourth, select a computer node to be used for the POP switch and customer-side IDC environment corresponding to the mock cloud leased line. Modify the vtep_ip address of this computer node to pop_vtep_ip.

[0230] like Figure 2 and Figure 3The selected computer node is typically the host machine for various cloud servers within the cloud resource pool, and basic network configurations such as OVS and VTEP IP are already configured on this computer node. Modify the VTEP IP of this computer node to 33.33.33.33. After the modification, the tenant gateway and this computer node can communicate via a VXLAN tunnel, and the VNI value of this tunnel is the same as vxlan_tunnel_vni, which is 320.

[0231] Fifth, create a pair of virtual network interfaces of type vethpair on the computer node, namely veth0_dc and veth1_dc, and enable interface veth0_dc.

[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 named ns_dc on the computer node. 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 `lo` interface 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, both of which are in the `up` state (i.e., enabled).

[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.

[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 cloud leased lines, the subnet mask for dst_loop_ip is 30 bits, while for IPv6 cloud leased lines, it is 126 bits. Making the subnet mask as large as possible reduces conflicts between dst_loop_ip and other network segments.

[0250] Step 8: Based on the ip_type and dst_cidr, set the IP address and subnet mask for the lo interface in ns_dc.

[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 interface `lo` acts as a mock host within the client-side IDC. Therefore, it needs to be assigned a regular host IP address from a subnet within the client-side IDC. This is done by assigning an IP address to `dst_cidr` (usually a random IP address within the middle range of the `cidr` subnet after removing the first and last IP addresses). In this example, based on the `ip_type`, it is assigned the addresses 192.168.20.20 and abcd:2::20. The subnet mask length is the same as the `dst_cidr` subnet mask; in this example, it is 24 and 96 respectively, depending on the `ip_type`.

[0257] Step 9: Based on the ip_type, add a route in ns_dc with a destination address of src_cidr and a next-hop address of 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, traffic coming from interface lo will be sent out through veth1_dc if the destination address of the IP packet matches src_cidr, 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 use of `--if-exists del-port veth0_dc` is to avoid residual dirty data during repeated testing, and is used to delete any potentially existing residual dirty data.

[0268] Step 11: Add the corresponding flow table to the OVS br-int bridge on the computer node so that traffic in the network namespace ns_dc can connect 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 ensure that traffic for this cloud private line is correctly forwarded between the vxlan1 and veth0_dc interfaces of the br-int bridge. These two flow tables need to be set with a high priority value to prevent test traffic from being interfered with by other traffic areas in the test environment. Here, the priority is set to 2000, but other high priority values ​​can be set according to the actual test environment.

[0272] Step 12: Test the connectivity between the cloud host (VM1) and the IP address configured on the LO port in ns_dc (e.g., ping test). If the connectivity is successful, it means that all service configurations are correct and the cloud private line connectivity test is passed.

[0273] In summary, after the above eleven steps, cloud host 1 can communicate with the host in the customer's IDC. The following example uses IPv4 traffic; IPv6 is similar and will not be described in detail.

[0274] For the traffic from cloud host 1 that needs to access a host within the client's IDC on the cloud leased line, i.e., 192.168.10.10 => 192.168.20.20 (original packet 1), this traffic will initially be sent to the tenant gateway corresponding to this VPC. Since 192.168.10.10 and 192.168.20.20 are not IPs in the same subnet, the tenant gateway will find the corresponding route: 192.168.20.0 / 24 via 200.0.0.2, meaning that the packet 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 packet 1 using VXLAN and then send it through the VXLAN tunnel between the tenant gateway and the computer node. Figure 2 On the computer node shown, after VXLAN encapsulation, the computer node will by default use the vxlan1 port to receive the packet. That is, a data packet 192.168.10.10 => 192.168.20.20 (i.e., original packet 1) arrives on the vxlan1 port of OVS. After receiving the packet, OVS finds that the packet came from the vxlan1 port, and the tunnel VNI is 320 and the tunnel source address is 22.22.22.22. Therefore, it will match the first flow table entry in step eleven, and use the action of the flow table to send the packet out from the veth0_dc port. Since the interfaces veth0_dc and veth1_dc are a vethpair type interface, veth1_dc will also receive the above original packet 1. Since the veth1_dc interface and the lo interface 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 interface. Therefore, veth1_dc will send the packet to the lo interface. Thus, the original packet 1 (192.168.10.10 => 192.168.20.20) has reached its target interface lo. In other words, this mocks a packet from cloud host 1 in the cloud resource pool, which then travels through the cloud dedicated line to the host within the customer's IDC. The reverse traffic path will be explained in detail below.

[0275] For traffic from a host within the customer's IDC that needs to access cloud host 1 in the cloud resource pool on the cloud private line, i.e., 192.168.20.20 => 192.168.10.10 (original packet 2), after this traffic exits from the LO interface, matching the destination IP address will find this route in the network namespace: 192.168.10.0 / 24 via 200.0.0.1dev veth1_dc, indicating that the packet needs to be sent from veth1_dc to 200.0.0.1. Thus, original packet 2 is sent out from the veth1_dc interface, with the next-hop destination address being 200.0.0.1. Since veth0_dc and veth1_dc are a pair of vethpair type virtual network interfaces, the packet will also exit from the veth0_dc interface, thus reaching the OVS br-int bridge. At this point, OVS matches the traffic and finds that it originates from the veth0_dc port. It randomly matches the second flow table entry from step eleven above and executes the corresponding action: setting the VXLAN tunnel VNI value to 320 and the VXLAN tunnel destination address to 22.22.22.22. After VXLAN encapsulation, the packet is sent out through the VXLAN1 port. This encapsulated packet travels through the VXLAN tunnel between the computer node and the tenant gateway to reach the tenant gateway, where it undergoes VXLAN decapsulation to obtain the original packet 2 (192.168.20.20 => 192.168.10.10). The tenant gateway, combined with the VNI value of 320, can then find the MAC address and other data of the corresponding cloud host 1, and deliver the packet to cloud host 1 (the process of the tenant gateway delivering the packet to the cloud host is not the focus or inventive point of this invention and will not be detailed here). At this point, the original message 2 (192.168.20.20 => 192.168.10.10) has reached its target host. In other words, the mock simulates a message from a host in the client's IDC reaching cloud host 1 in the cloud resource pool after passing through the cloud dedicated line.

[0276] This completes the mock simulation of traffic forwarding between the cloud resource pool and the customer's IDC. It can be used to test the connectivity of the cloud private line in the test resource pool without deploying a POP switch, configuring a physical private line, or configuring the customer's 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 all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

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

[0279] The simulated node selection module 401 is used to select a simulated node and install a virtual switch (OVS) on the simulated node; the virtual switch (OVS) is equipped with an integrated bridge.

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

[0281] The network namespace creation module 403 is used to create a network namespace on the simulated node for simulating the network environment of the client-side device.

[0282] The network information configuration module 404 is used to add the second virtual network interface to the network namespace and configure network information for the second virtual network interface in the network namespace.

[0283] The flow table creation module 405 is used to add the first virtual network interface to the integration bridge and create a flow table on the integration bridge;

[0284] The traffic transmission and reception status information generation module 406 is used to perform traffic transmission and reception with the network namespace through the flow table and the network information, and generate traffic transmission and reception status information;

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

[0286] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0287] In addition, embodiments of the present invention also provide 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 is used to store computer programs;

[0289] When the processor 501 executes the program stored in the memory 503, it implements any of the cloud private line connectivity testing methods described in the above embodiments:

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

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

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

[0293] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0294] like Figure 6As shown, in another embodiment of the present invention, a computer-readable storage medium 601 is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the cloud private line connectivity testing method described in the above embodiment.

[0295] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

[0296] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

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

[0298] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

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

[0301] If the aforementioned functions are implemented as 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 this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0302] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A cloud dedicated line connectivity test method, characterized by, The method is applied to a cloud host of a virtual private cloud network, and comprises the following steps: selecting a simulation node and installing 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 the installed virtual switch OVS; creating a network namespace for simulating a network environment of a customer-side device on the simulation node; adding the second virtual network interface to the network namespace and configuring network information of the second virtual network interface of the network namespace; adding the first virtual network interface to the integrated bridge and creating a flow table on the integrated bridge; performing traffic transceiving with the network namespace through the flow table and the network information and generating traffic transceiving state information; detecting the connectivity of a cloud private line between the cloud host and the network namespace based on the traffic transceiving state information.

2. The method of claim 1, wherein, Before the step of selecting a simulation node and installing a virtual switch OVS on the simulation node; the virtual switch OVS is provided with an integrated bridge, further comprising the following steps: obtaining configuration information of the cloud private line; determining, based on the configuration information, an IP protocol type, a tunnel virtual network identifier, a tenant gateway, and an IP address of a tunnel endpoint of a POP switch of the cloud private line, as well as a classless inter-domain routing of a customer-side device subnet and an in-cloud subnet, and a tenant gateway loopback interface and a tenant gateway IP address of the tenant gateway, and a POP switch loopback interface and a POP switch IP address of the POP switch.

3. The method of claim 2, wherein, The step of selecting a simulation node and installing a virtual switch OVS on the simulation node comprises the following steps: setting an IP address of a network card of a computer serving as the simulation node as the IP address of the tunnel endpoint of the POP switch, and installing a virtual switch OVS on the computer.

4. The method of claim 3, wherein, The step of configuring network information of the second virtual network interface of the network namespace comprises the following steps: determining a POP switch loopback interface IP address of the POP switch loopback interface; setting an IP address of the second virtual network interface as the POP switch IP address and the POP switch loopback interface IP address.

5. The method of claim 4, wherein, Further comprising the following steps: based on the IP protocol type and the customer-side device subnet, setting a subnet mask for the second virtual network interface.

6. The method of claim 4, wherein, The network namespace is provided with a network namespace loopback interface, and further comprising the following steps: setting a network namespace loopback interface IP address for the network namespace loopback interface; based on the IP protocol type and the customer-side device subnet, setting a subnet mask for the network namespace loopback interface.

7. The method of claim 6, wherein, Further comprising the following steps: 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 a cloud private line between the cloud host and the network namespace based on the traffic transceiving state information comprises the following steps: based on the network connectivity test result, detecting the connectivity of a cloud private line between the cloud host and the network namespace.

8. A cloud wire connectivity testing apparatus, comprising: The device is applied to a cloud host of a virtual private cloud network, and comprises: an analog node selection module configured to select an analog node and install a virtual switch OVS on the analog node, wherein the virtual switch OVS is provided with an integrated bridge; a virtual network interface construction module configured to construct a first virtual network interface and a second virtual network interface for the installed virtual switch OVS; a network namespace creation module configured to create a network namespace for simulating a network environment of a customer-side device on the analog node; a network information configuration module configured to add the second virtual network interface to the network namespace and configure network information of the second virtual network interface of the network namespace; a flow table creation module configured to add the first virtual network interface to the integrated bridge and create a flow table on the integrated bridge; a traffic transceiving state information generation module configured to perform traffic transceiving with the network namespace through the flow table and the network information and generate traffic transceiving state information; a connectivity test module configured to detect connectivity of a cloud private line between the cloud host and the network namespace based on the traffic transceiving state information.

9. An electronic device, comprising: The device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete communication with each other through the communication bus. The memory is used to store a computer program. The processor is used to execute the program stored on the memory, and implement the method of any one of claims 1-7. 10.A computer readable storage medium having instructions stored thereon, the instructions, when executed by one or more processors, cause the processors to perform the method of any one of claims 1-7.

Images