Device testing method, system, electronic device, and computer-readable storage medium

Abstract

The application relates to the technical field of industrial automation, and provides a device testing method and system, an electronic device and a computer readable storage medium, the method comprises the following steps: being applied to a device testing system, the device testing system comprises a plurality of devices to be tested, each device to be tested is connected with a physical port of a switch, the switch is connected with a test server, a structured configuration file is analyzed to obtain a device mapping relationship. Based on the device mapping relationship, a plurality of virtual network interfaces are created, and a corresponding network protocol address is allocated to each virtual network interface. An independent routing table is established for each virtual network interface, and a source network protocol address of the virtual network interface is bound to the routing table. Address resolution protocol response control parameters are set for each virtual network interface. A plurality of logically isolated virtual network interfaces can be automatically created, an automatic configuration driven testing environment can be built, and the testing efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of industrial automation technology, and in particular to a device testing method, system, electronic device, and computer-readable storage medium. Background Technology

[0002] In power automation, industrial IoT and large-scale equipment testing scenarios, it is often necessary to connect a central server with dozens to hundreds of industrial devices (such as relay protection devices and smart meters) that have the same default IP address through a network in order to achieve centralized monitoring and batch testing.

[0003] Traditional batch testing solutions mainly include VLAN-based network isolation, single routing table forwarding, and standard ARP processing mechanisms. However, these solutions have significant drawbacks when faced with a large number of devices sharing the same IP address: First, they suffer from redundant configurations and poor scalability. Manually creating virtual interfaces and assigning IPs to each device is prone to errors, and the lack of a unified physical and network resource mapping model makes maintenance difficult. Second, they lack sufficient communication path control. Sharing a single routing table across multiple interfaces prevents differentiated routing based on source IP or ingress interface, easily leading to routing conflicts and logical interference. Third, standard ARP policies can trigger cross-interface responses in multi-interface environments, causing ARP table corruption and IP conflicts. Fourth, they cannot distinguish between multiple devices with the same target IP address; the server can only communicate with one of them, making large-scale parallel testing impossible.

[0004] Traditional batch testing solutions suffer from significant problems in this scenario, including low automation, poor isolation, uncontrollable paths, and the inability of devices with the same IP address to coexist. Summary of the Invention

[0005] This application provides a device testing method, system, electronic device, and computer-readable storage medium that can automatically create multiple logically isolated virtual network interfaces, realize configuration-driven automated test environment construction, and improve testing efficiency.

[0006] Firstly, this application provides a device testing method applied to a device testing system. The device testing system includes multiple devices under test (DUTs), each DUT connected to a physical port of a switch. The switch is connected to a test server. The method includes: parsing a structured configuration file to obtain device mapping relationships, which include a one-to-one correspondence between multiple DUTs and multiple network identifiers; creating multiple virtual network interfaces based on the device mapping relationships, with each virtual network interface corresponding to one of the multiple DUTs, and assigning a corresponding network protocol address to each virtual network interface; establishing an independent routing table for each virtual network interface and binding the source network protocol address of the virtual network interface to the routing table, so that data packets sent from the virtual network interface are forwarded only in the routing table it is bound to; and setting address resolution protocol response control parameters for each virtual network interface to restrict each virtual network interface to only responding to address resolution requests where the destination address matches its own address.

[0007] In some implementations, the structured configuration file is an Extensible Markup Language (EXPLAIN) format file. The device mapping also includes a one-to-one correspondence between multiple devices under test and multiple device location identifiers.

[0008] In some implementations, the Address Resolution Protocol (ARP) response control parameters are the ARP filtering parameters of the Linux kernel. An automated script batch configures the ARP filtering parameter value of each virtual network interface to 1, ensuring that each virtual network interface only responds when both conditions are met: the target address of the address resolution request matches the network protocol address of its own interface, and the address resolution request packet was received from the interface itself.

[0009] In some implementations, the source network protocol address of the virtual network interface is bound to the routing table, including: assigning a routing table identifier to each virtual network interface; adding a default route or specified route entry corresponding to the virtual network interface to a separate routing table; and using policy routing rules to force packets whose source network protocol address is the network protocol address of the virtual network interface to be routed to the routing table corresponding to that interface for forwarding decisions.

[0010] In some implementations, the method is applied to centralized testing scenarios of industrial equipment where multiple devices under test (DUTs) have the same static default network protocol address. By assigning different virtual LAN identifiers, different virtual network interface network protocol addresses, and different independent routing tables to each DUT with the same network protocol address, isolated communication paths can be established simultaneously with multiple DUTs having the same target network protocol address under the same test server.

[0011] In some implementations, the method further includes: when communication is required with a target device under test (DUT) among multiple DUTs having the same target network protocol address, the test program on the test server side actively binds to the source network protocol address of the virtual network interface corresponding to the DUT and initiates a connection. Based on the source network protocol address, data packets are directed to the corresponding independent routing table and virtual network interface, thereby distinguishing and forwarding data streams with the same target network protocol address but belonging to different DUTs.

[0012] In some implementations, the method further includes: an enable flag in the structured configuration file. When the enable flag is true, the corresponding network instance is automatically created. When the enable flag is false, the creation of the network instance is skipped, and the configuration entry is retained for later enabling.

[0013] Secondly, this application provides a device testing system, which includes multiple devices under test (DUTs), each DUT connected to a physical port of a switch, and the switch connected to a test server; the system also includes: Configuration Management Unit: Used to parse structured configuration files to obtain device mapping relationships, which include a one-to-one correspondence between multiple devices under test and multiple network identifiers.

[0014] Network instance generation unit: connected to the configuration management unit, used to create multiple virtual network interfaces based on device mapping relationships. Each virtual network interface corresponds to one of the multiple devices under test, and a corresponding network protocol address is assigned to each virtual network interface.

[0015] Policy routing control unit: Connected to the network instance generation unit, it is used to establish an independent routing table for each virtual network interface and bind the source network protocol address of the virtual network interface to the routing table, so that data packets sent from the virtual network interface are forwarded only in the routing table bound to it.

[0016] Address resolution control unit: Connected to the network instance generation unit, it is used to set address resolution protocol response control parameters for each virtual network interface, restricting each virtual network interface to only respond to address resolution requests whose target address matches its own address.

[0017] Thirdly, this application provides a device testing apparatus, including: a parsing module and a processing module.

[0018] The parsing module is used to parse the structured configuration file to obtain the device mapping relationship, which includes a one-to-one correspondence between multiple devices under test and multiple network identifiers.

[0019] The processing module is used to create multiple virtual network interfaces based on the device mapping relationship. Each virtual network interface corresponds to one of the multiple devices under test, and a corresponding network protocol address is assigned to each virtual network interface.

[0020] The processing module is also used to establish an independent routing table for each virtual network interface and bind the source network protocol address of the virtual network interface to the routing table, so that data packets sent from the virtual network interface are forwarded only in the routing table to which they are bound.

[0021] The processing module is also used to set address resolution protocol response control parameters for each virtual network interface, restricting each virtual network interface to only respond to address resolution requests whose target address matches its own address.

[0022] Fourthly, this application provides a chip for performing the method as described in the first aspect above.

[0023] Fifthly, this application provides an electronic device including a processor and a memory, the processor being configured to execute a computer program stored in the memory to implement the method described in the first aspect above. Alternatively, Electronic devices include chips, as described in the fourth aspect.

[0024] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0025] In a seventh aspect, this application provides a computer program product that stores a computer program, which, when executed by a processor, implements the method described in the first aspect above.

[0026] The technical solution provided in this application automatically generates a mapping relationship between devices and network identifiers by parsing structured configuration files, and creates one-to-one corresponding virtual network interfaces and assigns IP addresses based on this mapping relationship in batches. This realizes the transformation from tedious manual configuration to configuration-driven automation, significantly reducing the configuration complexity and error rate in large-scale device testing scenarios, and improving system scalability and maintainability. Secondly, by establishing an independent routing table for each virtual network interface and binding the source IP address to the routing table, data packets sent from each virtual interface are forwarded only in their respective bound routing tables. This achieves precise control and strong isolation of communication paths when multiple devices and instances communicate concurrently, effectively solving the problems of routing conflicts, path interleaving, and the inability of the server to distinguish and allow parallel communication of multiple devices with the same IP address caused by sharing a single routing table in existing technologies. By setting ARP response control parameters for each virtual interface, it restricts it to only responding to ARP requests that match its own IP address, avoiding address conflicts and communication anomalies caused by cross-interface ARP responses, and improving the stability and determinism of the system in a large-scale virtual interface coexistence environment. The technical solutions provided in this application embodiment achieve beneficial technical effects such as high automation, strong isolation, high scalability, and high reliability in the scenario of centralized testing of industrial equipment. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of a test scenario provided in an embodiment of this application; Figure 2 This is a schematic diagram of the architecture of a device testing system provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the interaction between configuration driver and routing traffic splitting strategy provided in an embodiment of this application; Figure 4 This is a schematic diagram of the equipment testing process of an equipment testing method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a device testing apparatus provided in an embodiment of this application; Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0030] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0031] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0032] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0033] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0034] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0035] In the fields of power automation, industrial IoT and large-scale equipment testing, it is necessary to connect a central server (or test platform, monitoring system) with dozens or even hundreds of industrial devices (such as relay protection devices, smart meters, etc.) to achieve centralized monitoring, batch testing or data collection.

[0036] Figure 1 This is a schematic diagram of a test scenario provided for an embodiment of this application. Figure 1 As shown, a common industrial testing scenario includes a server, an industrial switch, and a large number of devices under test (DUTs) connected to the switch (DUT 1, DUT 2, ..., DUT N). These DUTs are typically configured with the same default IP address at the time of manufacture, and the number of devices is quite large. How to achieve isolated and controllable network communication between the server and multiple devices is a crucial problem that urgently needs to be solved in the field of industrial testing.

[0037] To achieve network communication in the aforementioned centralized testing scenarios, traditional technical solutions mainly include the following: First, VLAN-based network isolation. This method configures multiple VLANs (Virtual Local Area Networks) on the physical switch, dividing different devices into different broadcast domains to achieve logical isolation. The server communicates with each device by binding virtual network interfaces tagged with VLANs.

[0038] Second, there is the scheme based on a single routing table for forwarding. In traditional Linux / Unix server network configurations, multiple network interfaces (including physical and virtual interfaces) share the system's default routing table. Packet forwarding relies entirely on the destination IP address matching the routing entry, and all outgoing interface traffic follows the same routing policy.

[0039] Third, the standard ARP handling mechanism. This method uses the Open Address Resolution Protocol (ARP) response strategy by default in the operating system. That is, when a network interface receives an ARP request, it will respond as long as the local machine possesses the requested target IP address, regardless of which network interface that IP address is configured on.

[0040] While the above technical solutions can function normally in their respective applicable scenarios, they exhibit significant technical drawbacks when a single server connects dozens or even hundreds of industrial devices with the same default IP address, including: Poor configuration redundancy and scalability. Traditional technical solutions heavily rely on manual operation or simple, fixed scripts. Administrators need to manually create VLAN sub-interfaces, assign IP addresses, and configure routes for each device under test. When the number of devices reaches dozens or hundreds, the configuration work becomes extremely tedious, repetitive, and error-prone (such as VLAN ID conflicts and incorrect IP assignments). Furthermore, due to the lack of a unified mapping model between device physical locations (such as rack port numbers) and network resources (VLAN / IP / routing tables), the entire network configuration is difficult to trace and maintain when device topology changes.

[0041] Insufficient control over communication paths can easily lead to logical interference. Under the default single routing table architecture, all virtual network interfaces share a single routing policy. When the server needs to send data to different devices under test, the outgoing interface selection of the data packet depends solely on the destination IP address, failing to differentiate routing based on the source IP address or the incoming interface. This mechanism of multiple interfaces sharing a single routing table is highly prone to routing conflicts or path crossovers when multiple network instances communicate concurrently, causing data packets to be sent to the wrong interface, which cannot meet the stringent requirements of industrial-grade scenarios demanding communication isolation.

[0042] ARP interference and IP conflicts in multi-interface environments. When using standard ARP policies, if multiple virtual interfaces are configured with IP addresses from different network segments, but the target IP of an ARP request happens to match one of these interfaces, the system will respond even if the request originates from an unrelated interface. This cross-interface response leads to ARP table confusion, causing IP address conflicts, intermittent communication, or even complete outages, seriously threatening the stability of high-reliability scenarios such as power systems.

[0043] Communication conflicts arise from the homogenization of IP addresses across multiple devices. Many industrial devices (such as protection devices and smart meters) typically have the same default IP address when shipped (e.g., 192.168.253.3 / 24). In traditional network architectures, a single physical network interface card (NIC) on a server cannot simultaneously maintain two routing paths pointing to the exact same destination IP address. Because routing tables are based on destination IP lookups, when multiple devices under test have the same IP address, the server cannot distinguish between them, resulting in communication only with one device and preventing the others from connecting, thus hindering large-scale parallel testing.

[0044] In summary, existing technologies suffer from significant drawbacks in large-scale, highly isolated industrial equipment testing scenarios with coexisting devices sharing the same IP address, including low automation, poor isolation, uncontrollable paths, and the inability of devices with the same IP address to coexist.

[0045] In view of this, embodiments of this application provide a device testing method that can automatically create multiple logically isolated virtual network interfaces, realize configuration-driven automated test environment construction, and improve testing efficiency.

[0046] Figure 2 This is a schematic diagram of the architecture of a device testing system provided in an embodiment of this application. Figure 2 As shown, the device testing system includes: multiple devices under test (the illustration uses devices 1 to 4 as an example, but in actual application scenarios, it can include N devices), an industrial switch, and a test server (server / monitoring system). Each device under test has the same static default IP address (e.g., 192.168.253.3 / 24). Each device under test is connected to one end of the industrial switch via a physical port, and the other end of the industrial switch is connected to the test server. The test server has a single physical network interface card (e.g., eth1).

[0047] The test server dynamically creates multiple virtual network sub-interfaces with VLAN tags using a single physical network interface card (NIC) based on VLAN technology. Each virtual network sub-interface corresponds to a unique VLAN ID and forms an independent communication channel with a device under test (DUT). Specifically: the virtual NIC corresponding to VLAN 101 is eth1_101, configured with IP address 192.168.1.31 / 24, corresponding to device 1 in area A; the virtual NIC corresponding to VLAN 201 is eth1_201, configured with IP address 192.168.1.74 / 24, corresponding to device 2 in area B; the virtual NIC corresponding to VLAN 301 is eth1_301, configured with IP address 192.168.1.117 / 24, corresponding to device 3 in area C; and the virtual NIC corresponding to VLAN 401 is eth1_401, configured with IP address 192.168.1.160 / 24, corresponding to device 4 in area D.

[0048] Figure 3 This is a schematic diagram illustrating the interaction between a configuration driver and a routing traffic splitting strategy, provided as an embodiment of this application. Figure 3 As shown, the method flow of this application embodiment includes the following steps: The configuration management unit reads and parses XML configuration files to extract the mapping relationships between device locations, VLAN numbers, and IP addresses. After parsing, these mapping relationships are passed to the network instance generation unit.

[0049] After receiving the mapping relationship, the network instance generation unit performs the following operations: First, it creates VLAN virtual interfaces (such as eth1_101, eth1_102, etc.) on the physical network card; then, it configures the corresponding IP address for each virtual interface; finally, it sets the ARP filtering parameters. This transforms the abstract configuration data into actual, usable network interfaces.

[0050] After the virtual interface is created, the policy routing control unit generates an independent routing table (assigning a unique Table ID) for each VLAN and adds policy routing rules to establish a binding relationship from the source IP address to the corresponding routing table.

[0051] Ultimately, each configuration file entry evolves into a complete communication loop, which includes: a virtual network interface, an independent routing table, and a policy binding relationship between the source address and the routing table. This abstracts the originally complex and cumbersome sequence of network commands into concise, structured data, enabling the system to maintain the logical independence of each communication path while supporting large-scale (hundreds of instances) concurrent communication, and simultaneously achieving efficient reuse of hardware resources.

[0052] The following is combined Figure 3 The device testing method of the embodiments of this application will be described in detail.

[0053] Figure 4 This is a schematic diagram of the device testing process for a device testing method provided in an embodiment of this application. Figure 4 As shown, it includes the following four steps: Step S401: Parse the structured configuration file to obtain the device mapping relationship, which includes a one-to-one correspondence between multiple devices under test and multiple network identifiers.

[0054] The device testing method provided in this application can be applied to a device testing system. For example, such as... Figure 2 As shown, the device testing system includes multiple devices under test (DUTs), each of which is connected to a physical port of a switch, and the switch is connected to a test server.

[0055] The test server first reads and parses the structured configuration file to extract the device mapping relationship. This mapping relationship defines the mapping relationship between the location information of multiple devices under test and network parameters, including: device location identifier, network identifier, and address resource information.

[0056] Step S402: Based on the device mapping relationship, create multiple virtual network interfaces, each corresponding to one of the multiple devices under test, and assign a corresponding network protocol address to each virtual network interface.

[0057] After obtaining the device mapping relationship, the test server creates multiple virtual network interfaces based on the mapping relationship to ensure that there is a one-to-one correspondence between the virtual interfaces and the device under test, and assigns a corresponding network protocol address to each virtual interface.

[0058] like Figure 3As shown, the network instance generation unit automatically generates multiple virtual network interfaces on a single physical network card of the test server based on the mapping relationship. This embodiment uses VLAN technology to achieve this, dynamically creating virtual sub-interfaces with VLAN tags through Linux system commands.

[0059] Each virtual sub-interface has a unique VLAN ID and is bound to a specific device under test. For example, virtual interface eth1.101 corresponds to VLAN 101 and serves device 1 connected to physical port A01_1 of the switch.

[0060] Step S403: Establish an independent routing table for each virtual network interface and bind the source network protocol address of the virtual network interface to the routing table, so that data packets sent from the virtual network interface are forwarded only in the routing table to which they are bound.

[0061] The test server establishes an independent routing table for each virtual network interface and binds the source network protocol address of the interface to its corresponding routing table, ensuring that data packets sent from the interface are only looked up and forwarded in the routing table bound to them.

[0062] like Figure 3 As shown, the policy routing control unit is used to perform this step. The specific operation consists of three sub-steps: Step 1: Assign a routing table identifier to each virtual network interface.

[0063] In this embodiment, VLAN ID can be used as the routing table identifier (Table ID), or a separate independent numerical number can be assigned.

[0064] Step 2: Add the route entry corresponding to the virtual interface to each independent routing table.

[0065] Routing entries can be either default routes or routes for specific network segments.

[0066] Step 3: Using policy routing rules, force data packets whose source IP address points to a specific virtual interface to be routed to the routing table corresponding to that interface.

[0067] After completing the above configuration, data packets originating from any virtual network interface will only be forwarded in their dedicated routing table.

[0068] For example, taking eth1.101 as an example: packets originating from this interface (source IP 192.168.1.31) are routed to Table 101 according to the policy rule "from 192.168.1.31 lookup 101"; the default route in Table 101 then sends the packet out from the eth1.101 interface. Thus, data flows between different virtual interfaces are completely isolated at the routing level.

[0069] Step S404: Set address resolution protocol response control parameters for each virtual network interface to restrict each virtual network interface to only respond to address resolution requests where the target address matches its own address.

[0070] The test server sets address resolution protocol response control parameters for each virtual network interface, limiting the response range of each interface to address resolution requests that only match its own target address.

[0071] For example, such as Figure 3 As shown, the ARP control unit is used to execute the configuration process. In this embodiment, the control parameter adopts the arp_filter parameter of the Linux kernel, and the parameter value of each virtual interface is set to 1 in batches through an automated script.

[0072] For example, the configuration arp_filter=1 means that each virtual network interface will only respond to ARP requests if both of the following conditions are met simultaneously: (1) The target address requested is the same as the IP address of this interface.

[0073] (2) The request message was received from this interface itself.

[0074] With this configuration, each virtual network interface only responds to ARP requests that match its own IP address, avoiding cross-interface ARP responses.

[0075] For example, an ARP request querying the IP address 192.168.1.31 will be handled normally if it originates from the eth1.101 interface. However, if the request originates from the eth1.201 interface, even if the target IP is also 192.168.1.31, eth1.101 will not respond. This interface-level ARP isolation mechanism effectively resolves common ARP conflicts when large-scale virtual interfaces coexist.

[0076] The device testing method provided in this application automatically generates a mapping relationship between devices and network identifiers by parsing structured configuration files, and creates one-to-one corresponding virtual network interfaces and assigns IP addresses based on this mapping relationship in batches. This realizes the transformation from tedious manual configuration to configuration-driven automation, significantly reducing the configuration complexity and error rate in large-scale device testing scenarios, and improving system scalability and maintainability. Secondly, by establishing an independent routing table for each virtual network interface and binding the source IP address to the routing table, data packets sent from each virtual interface are forwarded only in their respective bound routing tables. This achieves precise control and strong isolation of communication paths when multiple devices and instances communicate concurrently, effectively solving the problems of routing conflicts, path interleaving, and the inability of the server to distinguish and allow parallel communication of multiple devices with the same IP address caused by sharing a single routing table in existing technologies. By setting ARP response control parameters for each virtual interface, it restricts it to responding only to ARP requests that match its own IP address, avoiding address conflicts and communication anomalies caused by cross-interface ARP responses, and improving the stability and determinism of the system in a large-scale virtual interface coexistence environment. The technical solutions provided in this application embodiment achieve beneficial technical effects such as high automation, strong isolation, high scalability, and high reliability in the scenario of centralized testing of industrial equipment.

[0077] The method proposed in this application can be applied to industrial centralized testing scenarios where multiple devices under test have the same static default IP address.

[0078] Assume that devices 1, 2, and 3 are all configured with the same default IP address, 192.168.253.3 / 24. Following steps S401 to S404 above, assign each device under test a different VLAN ID (e.g., 101, 201, 301), a different server-side virtual interface IP address (e.g., 192.168.1.31, 192.168.1.74, 192.168.1.117), and a different independent routing table (Table 101, Table 201, Table 301). Under the same test server, isolated communication paths can be established simultaneously with multiple devices under test sharing the same target IP address.

[0079] When the test server needs to communicate with one of these devices with the same IP address (e.g., device 1), the test program on the server side will actively bind to the source IP address of the virtual interface corresponding to that device (i.e., 192.168.1.31) to initiate a connection. Based on this source IP address, the policy routing rules direct the data packet to the corresponding independent routing table (Table 101) and virtual interface (eth1.101). After the data packet is sent from eth1.101, it is tagged with VLAN 101 as it passes through the switch. The switch forwards the data packet to the physical port connected to device 1 based on the tag, ultimately delivering it to device 1. When communicating with device 2, the test program binds to the source IP address 192.168.1.74, and the data packet reaches device 2 through the eth1.201 interface and the VLAN 201 channel.

[0080] Through the above mechanism, this application achieves accurate differentiation and targeted forwarding of data streams with the same target IP address but belonging to different devices under test, solving the problem that devices with the same IP cannot access in parallel in traditional solutions.

[0081] In some embodiments, each device under test may be equipped with an independent physical network card and network cable.

[0082] In some embodiments, a separate virtual machine or container may be created for each device under test.

[0083] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the system embodiments of this application. For details on their specific functions and technical effects, please refer to the system embodiments section, and they will not be repeated here.

[0084] It should be understood that, provided there are no logical conflicts, the above-described embodiments can be combined and implemented to adapt to actual application needs. These combined embodiments or implementation schemes are still within the scope of protection of this application.

[0085] Corresponding to the device testing method in the above embodiments, this application provides a device testing apparatus 50. The device testing apparatus 50 can be implemented as part or all of a computer device by software, hardware or a combination of both, and is used to execute the steps in the device testing method in the above embodiments.

[0086] Figure 5 This document shows a schematic diagram of a device testing apparatus 50 provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0087] Reference Figure 5 The testing device 50 includes an analysis module 510 and a processing module 520.

[0088] The parsing module 510 is used to parse the structured configuration file to obtain the device mapping relationship, which includes a one-to-one correspondence between multiple devices under test and multiple network identifiers.

[0089] The processing module 520 is used to create multiple virtual network interfaces based on the device mapping relationship. Each virtual network interface corresponds to one of the multiple devices under test, and a corresponding network protocol address is assigned to each virtual network interface.

[0090] The processing module 520 is also used to establish an independent routing table for each virtual network interface and bind the source network protocol address of the virtual network interface to the routing table, so that data packets sent from the virtual network interface are forwarded only in the routing table to which they are bound.

[0091] The processing module 520 is also used to set address resolution protocol response control parameters for each virtual network interface, restricting each virtual network interface to only respond to address resolution requests whose target address matches its own address.

[0092] In some embodiments, the structured configuration file is an Extensible Markup Language (EXPLAIN) format file. The device mapping also includes a one-to-one correspondence between multiple devices under test and multiple device location identifiers.

[0093] In some embodiments, the Address Resolution Protocol (ARP) response control parameter is the Linux kernel's ARP filtering parameter. An automated script batch configures the ARP filtering parameter value of each virtual network interface to 1, ensuring that each virtual network interface only responds when both conditions are met: the target address of the address resolution request matches the network protocol address of its own interface, and the address resolution request message was received from the interface itself.

[0094] In some embodiments, the processing module 520 is specifically configured to: allocate a routing table identifier for each virtual network interface; add a default route or specified route entry corresponding to the virtual network interface to a separate routing table; and, through policy routing rules, force packets whose source network protocol address is the network protocol address of the virtual network interface to be routed to the routing table corresponding to that interface for forwarding decisions.

[0095] In some embodiments, the device testing apparatus 50 can be applied to a centralized testing scenario of industrial equipment where multiple devices under test (DUTs) have the same static default network protocol address. By assigning different virtual LAN identifiers, different virtual network interface network protocol addresses, and different independent routing tables to each DUT with the same network protocol address, isolated communication paths can be established simultaneously with multiple DUTs having the same target network protocol address under the same test server.

[0096] In some embodiments, the processing module 520 is further configured to: when communication is required with a target device under test among multiple devices under test having the same target network protocol address, the test program on the test server side actively binds to the source network protocol address of the virtual network interface corresponding to the device under test to initiate a connection. Based on the source network protocol address, data packets are directed to the corresponding independent routing table and virtual network interface, thereby distinguishing and forwarding data streams with the same target network protocol address but belonging to different devices under test.

[0097] In some embodiments, the processing module 520 is further configured to: include an enable flag in the structured configuration file. When the enable flag is true, the corresponding network instance is automatically created. When the enable flag is false, the creation of the network instance is skipped, and the configuration entry is retained for later enabling.

[0098] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0099] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0100] Based on the same inventive concept, embodiments of this application also provide an electronic device.

[0101] Figure 6 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 6 As shown, the electronic device 60 of this embodiment includes: at least one processor 610 ( Figure 6 Only one is shown in the diagram), memory 620, and communication module 630. Memory 620 stores a computer program 640 that may run on processor 610. When processor 610 executes computer program 640, it implements the steps in the above-described device testing method embodiments. Alternatively, when processor 610 executes computer program 640, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 5 The functions of the parsing module 510 to the processing module 520 are shown. The communication module 630 is an independent communication unit used to communicate with external servers or terminal devices.

[0102] Electronic device 60 may include, but is not limited to, a processor 610 and a memory 620. Those skilled in the art will understand that... Figure 6This is merely an example of electronic device 60 and does not constitute a limitation on electronic device 60. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 60 may also include input transmitting devices, network access devices, buses, etc.

[0103] The processor 610 can be a central processing unit (CPU), or other general-purpose processors, 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, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0104] In some embodiments, memory 620 may be an internal storage unit of electronic device 60, such as a hard disk or memory of electronic device 60. Memory 620 may also be an external storage device of electronic device 60, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on electronic device 60. Memory 620 may also include both internal and external storage units of electronic device 60. Memory 620 is used to store operating system, applications, bootloader, data, and other programs, such as the program code of computer program 640. Memory 620 may also be used for temporary storage of data that has been sent or will be sent.

[0105] Furthermore, those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. In the various embodiments of this application, each functional unit 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0106] This application provides a computer-readable storage medium storing a computer program that, when run on an electronic device, causes the electronic device to perform the steps described in the various method embodiments above.

[0107] This application provides a chip, which includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the steps in the various method embodiments described above.

[0108] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the steps described in the various method embodiments above.

[0109] It should be understood that the processor mentioned in the embodiments of this application can be a Central Processing Unit (CPU), or other general-purpose processors, 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, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0110] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0111] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0112] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0113] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein 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 implementation should not be considered beyond the scope of this application.

[0114] 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 system embodiments described above are merely illustrative. For instance, the division of modules or 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 an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

[0116] Furthermore, the functional units in the various embodiments of this application 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0117] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a large-screen device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0118] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A device testing method, characterized in that, The method is applied to a device testing system, which includes multiple devices under test (DUTs), each DUT connected to a physical port of a switch, and the switch connected to a test server. The structured configuration file is parsed to obtain the device mapping relationship, which includes a one-to-one correspondence between the multiple devices under test and multiple network identifiers; Based on the device mapping relationship, multiple virtual network interfaces are created, and each of the multiple virtual network interfaces corresponds one-to-one with the multiple devices under test. A corresponding network protocol address is assigned to each virtual network interface. An independent routing table is created for each virtual network interface, and the source network protocol address of the virtual network interface is bound to the routing table, so that data packets sent from the virtual network interface are forwarded only in the routing table to which they are bound. Configure address resolution protocol response control parameters for each virtual network interface to restrict each virtual network interface to only respond to address resolution requests whose target address matches its own address.

2. The equipment testing method according to claim 1, characterized in that, The structured configuration file is an Extensible Markup Language (EXPLAIN) format file; the device mapping relationship also includes a one-to-one correspondence between multiple devices under test and multiple device location identifiers.

3. The equipment testing method according to claim 1, characterized in that, The address resolution protocol response control parameters are the address resolution protocol filtering parameters of the Linux kernel; By using automated scripts to batch configure the address resolution protocol filtering parameter value of each virtual network interface to 1, each virtual network interface will only respond when both of the following conditions are met: the target address of the address resolution request is consistent with the network protocol address of this interface, and the address resolution request message is received from this interface itself.

4. The equipment testing method according to claim 1, characterized in that, The step of binding the source network protocol address of the virtual network interface to the routing table includes: Assign a routing table identifier to each virtual network interface; Add a default route or a specified route entry corresponding to the virtual network interface to the independent routing table; By using policy-based routing rules, data packets whose source network protocol address is the network protocol address of the virtual network interface are forcibly routed to the routing table corresponding to that interface for forwarding decisions.

5. The equipment testing method according to claim 1, characterized in that, The method is applied to a centralized testing scenario of industrial equipment where multiple devices under test have the same static default network protocol address. By assigning different virtual LAN identifiers, different virtual network interface network protocol addresses, and different independent routing tables to each device under test with the same network protocol address, isolated communication paths can be established simultaneously with multiple devices under test with the same target network protocol address under the same test server.

6. The equipment testing method according to claim 5, characterized in that, The method further includes: When it is necessary to communicate with a target device under test among multiple devices under test that have the same target network protocol address, the test program on the test server side actively binds to the source network protocol address of the virtual network interface corresponding to the device under test and initiates a connection. Based on the source network protocol address, the data packets are directed to the corresponding independent routing table and virtual network interface, thereby distinguishing and forwarding data streams that have the same target network protocol address but belong to different devices under test.

7. The equipment testing method according to any one of claims 1 to 6, characterized in that, The method further includes: The structured configuration file contains an enable flag; When the enable flag is true, the corresponding network instance is automatically created; When the enable flag is false, the creation of the network instance is skipped, and the configuration entry is retained for later enabling.

8. A device testing system, characterized in that, The device testing system includes multiple devices under test (DUTs), each DUT connected to a physical port of a switch, and the switch connected to a test server; the system also includes: Configuration Management Unit: Used to parse structured configuration files to obtain device mapping relationships, which include a one-to-one correspondence between the multiple devices under test and multiple network identifiers; Network instance generation unit: connected to the configuration management unit, used to create multiple virtual network interfaces based on the device mapping relationship, wherein each virtual network interface corresponds one-to-one with the multiple devices under test, and a corresponding network protocol address is assigned to each virtual network interface; Policy routing control unit: connected to the network instance generation unit, used to establish an independent routing table for each virtual network interface, and bind the source network protocol address of the virtual network interface to the routing table, so that data packets sent from the virtual network interface are forwarded only in the routing table bound to them; Address resolution control unit: connected to the network instance generation unit, used to set address resolution protocol response control parameters for each virtual network interface, restricting each virtual network interface to only respond to address resolution requests where the target address matches its own address.

9. An electronic device, characterized in that, It includes a processor and a memory, the processor being configured to execute a computer program stored in the memory to implement the device testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the device testing method as described in any one of claims 1 to 7.

Images