Methods, apparatus, equipment and storage media for testing link jitter in network devices

Abstract

This invention discloses a method, apparatus, device, and storage medium for testing link jitter in network devices. The method includes: acquiring test configuration information, including jitter parameters, monitoring objects, and event triggering conditions; injecting link state change events into the target port of the device under test based on the jitter parameters; during the injection of link state change events, collecting multi-dimensional state data of the device under test according to the monitoring objects; when a state change of the device under test is detected based on the multi-dimensional state data and meets the event triggering conditions, acquiring a snapshot of the multi-dimensional state data within a target time window; and performing correlation analysis between the multi-dimensional state data snapshot and the link state change events to generate test results. Compared with existing technologies, this invention not only automates the entire testing process but also improves the comprehensiveness of test coverage and the accuracy of fault location, thereby enhancing the reliability of link jitter test results.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a method, apparatus, device, and storage medium for testing link jitter in network devices. Background Technology

[0002] In the field of network communication, the stability of network device port link states is fundamental to ensuring reliable data transmission. Link jitter refers to the phenomenon where a physical port frequently switches between Up and Down states within a short period of time, which can be caused by factors such as physical media failure, optical module aging, and electromagnetic interference. Accurately assessing the behavior and response of devices under link jitter conditions is of great significance for the design verification, selection and evaluation of network devices, and current network operation and maintenance.

[0003] Currently, testing methods for network device port link jitter have the following main shortcomings: First, limited test coverage. Most existing solutions are limited to the physical or link layer, failing to comprehensively assess the chain reaction of jitter propagating from the physical layer upwards to the hardware forwarding layer (e.g., equal-cost multipath entry pruning) and the control layer (e.g., routing protocol oscillation). This makes it difficult to detect hidden dangers where the internal state of the device is abnormal while the external appearance appears normal. Second, difficulty in fault location. When a brief network outage or routing oscillation occurs, traditional methods cannot accurately determine whether the root cause is physical layer jitter, hardware entry switching, or routing protocol recalculation. Events at different layers are isolated, resulting in low troubleshooting efficiency. Furthermore, existing testing processes heavily rely on manual operation, which not only lacks timeliness and struggles to capture instantaneous changes in millisecond-level jitter, but also results in fragmented data from different dimensions, failing to form systematic test conclusions and ultimately leading to insufficient reliability of link jitter test results.

[0004] Therefore, there is an urgent need for a link jitter testing method for network devices that can improve the reliability of link jitter test results. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for testing link jitter in network devices, aiming to solve the technical problems of insufficient test coverage, difficulty in fault location, and reliance on manual testing in existing technologies, which lead to insufficient reliability of link jitter test results.

[0006] To achieve the above objectives, the present invention provides a method for testing link jitter in network devices, the method comprising the following steps: Obtain test configuration information, which includes jitter parameters, monitoring objects, and event triggering conditions; Based on the jitter parameters, a link state change event is injected into the target port of the device under test; During the injection of the link state change event, multi-dimensional state data of the device under test are collected according to the monitoring object; When the state change of the device under test is detected to meet the event triggering condition based on the multi-dimensional state data, a snapshot of the multi-dimensional state data within the target time window is obtained. The multi-dimensional state data snapshots are correlated with the link state change events to generate test results.

[0007] Optionally, the step of obtaining a snapshot of the multi-dimensional state data within a target time window when the state change of the device under test is detected to meet the event triggering condition based on the multi-dimensional state data includes: The system analyzes the multi-dimensional status data in real time. When it detects a change in the hardware forwarding plane table entry of the device under test, a change in the routing protocol adjacency relationship status, or a service traffic quality index exceeding a preset threshold, it determines that the status change of the device under test meets the event triggering condition and records the event triggering time corresponding to the status change. Based on the event trigger time, obtain a multi-dimensional state data snapshot within the target time window.

[0008] Optionally, the step of obtaining a multi-dimensional state data snapshot within the target time window based on the event trigger time includes: A snapshot acquisition instruction is generated based on the event trigger time, and the snapshot acquisition instruction is sent to the corresponding functional module; Receive the target hardware forwarding plane data, target control plane protocol data and target service traffic quality data within the target time window, which are transmitted back by each of the functional modules according to the snapshot acquisition instruction; The target hardware forwarding plane data, the target control plane protocol data, and the target service traffic quality data are aligned and stored according to timestamps to generate a multi-dimensional state data snapshot.

[0009] Optionally, the step of injecting link state change events into the target port of the device under test based on the jitter parameters includes: A fault injection instruction is generated based on the jitter parameters, and the fault injection instruction includes the link state change mode and the state maintenance duration; The fault injection command is used to control the physical link of the target port to switch between connected and disconnected states.

[0010] Optionally, the step of collecting multi-dimensional status data of the device under test according to the monitoring object during the injection of the link status change event includes: Based on the first monitoring dimension of the monitored object, during the injection of the link status change event, the internal hardware table status and hardware counter of the device under test are queried through the management interface in the first collection cycle to obtain hardware forwarding plane status data. Based on the second monitoring dimension of the monitored object, during the injection of the link state change event, the routing protocol adjacency status, routing table information and system log of the device under test are obtained through the management interface in the second collection cycle to obtain control plane protocol data; Based on the third monitoring dimension of the monitored object, during the injection of the link status change event, the throughput, latency and packet loss rate of the service traffic of the tested device are statistically analyzed through the service monitoring interface in the third collection cycle to obtain service traffic quality data; The hardware forwarding plane status data, the control plane protocol data, and the service traffic quality data are used as multi-dimensional status data.

[0011] Optionally, the step of performing correlation analysis between the multi-dimensional state data snapshot and the link state change event to generate test results includes: Based on the timestamp information in the multi-dimensional state data snapshot and the time information of the link state change event, the link state change event is aligned with the multi-dimensional state data snapshot on the time axis. Based on the alignment results, the causal relationship between the link state change event and changes in hardware forwarding plane entries, control plane protocol state, and service traffic quality is determined. A visual test report containing time series information is generated based on the causal relationship, and the visual test report is used as the test result.

[0012] Optionally, after the step of performing correlation analysis between the multi-dimensional state data snapshot and the link state change event to generate test results, the method further includes: Stop injecting the link state change event into the target port and restore the link state of the target port to a stable connectivity state; After stopping the injection of the link state change event, continue to collect multi-dimensional state data of the device under test to obtain monitoring information of the state recovery process; Based on the monitoring information of the state recovery process, the internal hardware entry recovery delay and routing protocol convergence delay of the device under test are determined.

[0013] Furthermore, to achieve the above objectives, the present invention also proposes a link jitter testing device for network devices, the device comprising: The information acquisition module is used to acquire test configuration information, which includes jitter parameters, monitoring objects, and event triggering conditions. The fault injection module is used to inject link state change events into the target port of the device under test based on the jitter parameters. The data acquisition module is used to collect multi-dimensional status data of the device under test according to the monitoring object during the injection of the link status change event; The snapshot acquisition module is used to acquire a snapshot of the multi-dimensional state data within a target time window when the state change of the device under test is detected to meet the event triggering condition based on the multi-dimensional state data. The correlation analysis module is used to perform correlation analysis between the multi-dimensional state data snapshot and the link state change event to generate test results.

[0014] Furthermore, to achieve the above objectives, the present invention also proposes a link jitter testing device for network devices, the device comprising: a memory, a processor, and a link jitter testing program for network devices stored in the memory and executable on the processor, the link jitter testing program for network devices being configured to implement the steps of the link jitter testing method for network devices as described above.

[0015] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a link jitter test program for a network device, wherein when the link jitter test program for the network device is executed by a processor, the link jitter test program for the network device implements the steps of the link jitter test method for the network device as described above.

[0016] This invention discloses a method for acquiring test configuration information, including jitter parameters, monitoring objects, and event triggering conditions. Based on the jitter parameters, a link state change event is injected into the target port of the device under test (DUT). During the injection of the link state change event, multi-dimensional state data of the DUT is collected according to the monitoring objects. When a state change of the DUT is detected based on the multi-dimensional state data and meets the event triggering conditions, a snapshot of the multi-dimensional state data within a target time window is obtained. The multi-dimensional state data snapshot is correlated with the link state change event to generate test results. Because this invention collects multi-dimensional state data during jitter injection, obtains a data snapshot within a target time window through an event triggering mechanism, and finally correlates the data snapshot with the link jitter event, compared to existing technologies, this invention not only automates the entire testing process but also improves the comprehensiveness of test coverage and the accuracy of fault location, thereby enhancing the reliability of link jitter test results. Attached Figure Description

[0017] Figure 1This is a flowchart illustrating the first embodiment of the link jitter testing method for network devices according to the present invention; Figure 2 This is a schematic diagram illustrating the module relationship structure of the test system in the link jitter test method for network devices of the present invention; Figure 3 This is a flowchart illustrating the second embodiment of the link jitter testing method for network devices according to the present invention; Figure 4 This is a flowchart illustrating the third embodiment of the link jitter testing method for network devices of the present invention; Figure 5 This is a structural block diagram of the first embodiment of the link jitter testing device for network equipment of the present invention; Figure 6 This is a schematic diagram of the structure of a link jitter testing device for a network device in the hardware operating environment involved in the embodiments of the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0020] This invention provides a method for testing link jitter in network devices, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the link jitter testing method for network devices according to the present invention.

[0021] In this embodiment, the link jitter testing method for the network device includes steps S10 to S50: Step S10: Obtain test configuration information, which includes jitter parameters, monitoring objects, and event triggering conditions.

[0022] It should be noted that the executing entity in this embodiment can be a computer server device with data processing, network communication, and program execution functions applied in a link jitter testing scenario, such as a server, tablet computer, or personal computer, or an electronic device capable of performing the above functions (such as a link jitter testing device for network devices). The following uses a test system (hereinafter referred to as the system) that includes a link jitter testing device for network devices as an example to illustrate this embodiment and the following embodiments.

[0023] It should be explained that the aforementioned test configuration information refers to the set of parameters defined by the test system for performing a single link jitter test, used to guide the behavior of the entire test process. The jitter parameters can be a set of quantitative indicators describing the pattern of link state changes, such as jitter frequency (number of flips per second), duty cycle (the ratio of up state to down state time), duration of a single jitter, and total number of jitters. The monitoring objects can be the range of data that the test system needs to collect and monitor, including internal entries at the hardware forwarding layer (such as the WCMP group membership table), routing protocol states at the control layer (such as OSPF neighbor relationships, BGP routing tables), and traffic quality indicators at the service layer (such as packet loss rate, latency). The event triggering conditions can be a preset judgment rule. When the state change of the device under test meets this rule, the test system will trigger additional data snapshot collection actions, such as "WCMP group membership changes from 4 to 3" or "service traffic packet loss rate exceeds 0.1%".

[0024] In its implementation, before executing any link jitter test, the system first obtains all the configuration information required for the test. The system can obtain this test configuration information by reading locally stored configuration files, parsing parameters entered by the user through a graphical interface, or receiving instructions from automated test scripts.

[0025] It should be noted that the above test configuration information specifically includes three parts: first, jitter parameters, which define the type of jitter behavior injected into the network link of the device under test; second, monitoring objects, which specify which dimensions of status data of the device under test need to be collected during the test; and third, event triggering conditions, which set the specific criteria for triggering additional data snapshot collection. After obtaining the above test configuration information, the system will store it in its internal memory for subsequent test steps to access.

[0026] To facilitate understanding, the following example illustrates the concept, but does not impose specific limitations on this embodiment. For instance, suppose a tester wants to test the pruning behavior of a network device's WCMP group member table entries when a port experiences continuous rapid jitter. The tester configures the following test configuration information through the test system's graphical interface: the jitter parameter is set to "the port remains in the Up state for 10 milliseconds, then switches to the Down state and remains in the Down state for 10 milliseconds, repeating this 10 times"; the monitoring objects are set to "member table entries of WCMP group 1, the number of link state changes in the hardware counter, and OSPF neighbor status"; and the event trigger condition is set to "the number of WCMP group members changes". After the system reads the above configuration, it completes the acquisition of the test configuration information.

[0027] Step S20: Based on the jitter parameters, inject a link state change event into the target port of the device under test.

[0028] It should be understood that the aforementioned device under test can refer to network devices undergoing link jitter testing, such as core switches or routers supporting WCMP (Weighted Equal Cost Multipath) functionality. The aforementioned target port can refer to the specific physical interface on the aforementioned device under test designated for injecting link state change events, such as the Gigabit Ethernet interface GigabitEthernet0 / 1 or the 10 Gigabit Ethernet interface TenGigabitEthernet1 / 1.

[0029] It should be noted that the aforementioned link state change event can refer to a sequence of events in which the target port of the device under test switches between a physical connected state and a physical disconnected state. For example, the port changes from an Up (connected) state to a Down (disconnected) state, or from a Down state to an Up state. Each switch constitutes a link state change event.

[0030] In its implementation, after acquiring test configuration information containing jitter parameters, the system injects link state change events into the target port of the device under test (DUT) according to these jitter parameters. The system first reads the specific values ​​of the jitter parameters from the stored test configuration information, such as the jitter frequency, the duration of each Up or Down state, and the total number of jitters. Then, based on the read jitter parameters, the system applies a series of continuous link state changes to the target port via the physical medium connected to it. Specifically, the system controls the physical link of the target port to repeatedly switch between connected and disconnected states according to the time pattern specified by the jitter parameters; each switch constitutes an injected link state change event. Simultaneously with the injection, the system records the absolute timestamp of the injection start for later timeline alignment with other data. The system continues to execute the injection until all the required number or duration of link state change events specified by the jitter parameters are completed.

[0031] For example, suppose the jitter parameter is "10 consecutive flips, Up state duration 10 milliseconds, Down state duration 10 milliseconds". After reading this jitter parameter, the system identifies the target port to be injected as the GigabitEthernet0 / 1 interface on the device under test. The system, through a connected physical layer fault injection module (e.g., a programmable network tester), controls the physical link of this interface to first switch to the Down state and maintain it for 10 milliseconds, then switch to the Up state and maintain it for 10 milliseconds, repeating this process 10 times, thus completing the operation of injecting a link state change event into the target port.

[0032] It should be noted that, in order to achieve precise and programmable control of jitter parameters, the step of injecting link state change events into the target port of the device under test based on the jitter parameters includes: generating a fault injection instruction based on the jitter parameters, wherein the fault injection instruction includes a link state change mode and a state maintenance duration; and using the fault injection instruction to control the physical link of the target port to switch between a connected state and a disconnected state.

[0033] It should be understood that the aforementioned fault injection command can refer to the command data packet issued by the test system to the physical layer fault injection module for precisely controlling the link state change behavior. The aforementioned link state change mode can refer to the way the physical link switches between connected and disconnected states, such as a continuous flip mode (repeatedly performing Up-Down switching at fixed time intervals), a random interval jitter mode (the time interval between two adjacent switches conforms to a certain random distribution), or a burst jitter mode (intensively performing multiple switches within a short period). The aforementioned state maintenance duration can refer to the duration for which the physical link remains in a specific state (connected or disconnected) each time, such as maintaining the Up state for 10 milliseconds or the Down state for 20 milliseconds.

[0034] In its implementation, after acquiring jitter parameters, the system generates fault injection commands based on these parameters. The system first parses the acquired jitter parameters, extracting key information describing link behavior, including but not limited to the required link state change mode and the duration of each state switch. Next, the system encapsulates the link state change mode and the state maintenance duration into one or more fault injection commands according to a preset command format. The system then sends these fault injection commands to the physical layer fault injection module connected to the target port of the device under test via the management network. Upon receiving the fault injection commands, the physical layer fault injection module controls the physical link of the target port to repeatedly switch between connected and disconnected states according to the specified link state change mode and state maintenance duration. The system can send a fault injection command containing a complete switching sequence at once, or it can send single switching commands multiple times in chronological order.

[0035] Understandably, a fault injection command containing link state change patterns and state duration is generated based on jitter parameters, and this command is used to control the physical link of the target port to switch between connected and disconnected states. This feature achieves precise programmatic control of the physical layer link switching process by parsing abstract jitter parameters into fault injection commands with clear timing characteristics and state maintenance rules, replacing the traditional operation method that relies on manual cable plugging and unplugging or discrete scripts. Since the fault injection command directly acts on the physical link of the target port, the switching between connected and disconnected states can be strictly executed according to the preset timing pattern, ensuring that the duration and timing of each state change event are highly controllable and consistent.

[0036] Furthermore, when collecting multi-dimensional status data of the device under test in the subsequent process, it is possible to establish an accurate time correspondence between physical layer jitter and changes in hardware forwarding plane, control plane protocols and service traffic quality based on precise and controllable link status change events. This effectively avoids inaccurate event correlation caused by delays in manual operation or timing deviations, thus providing a reliable data foundation for quantitative analysis of jitter impact and root cause localization, and significantly improving the accuracy and reproducibility of test results.

[0037] Step S30: During the injection of the link state change event, collect multi-dimensional state data of the device under test according to the monitoring object.

[0038] It should be explained that the aforementioned multi-dimensional state data refers to a set of state information collected by the test system from the device under test, covering different functional levels. This multi-dimensional state data can include hardware forwarding layer state data (i.e., hardware forwarding plane state data, such as WCMP group membership entries, next-hop tables, and port hardware counter values ​​within the forwarding chip), control layer state data (i.e., control plane protocol data, such as routing protocol adjacency status, routing table entries, and system logs), and service layer quality data (i.e., service traffic quality data, such as service traffic throughput, latency, and packet loss rate).

[0039] It should be understood that the aforementioned multi-dimensional status data can be used to comprehensively assess the actual impact of link jitter events on various functional aspects of the device under test.

[0040] In its implementation, the system continuously collects multi-dimensional status data of the device under test (DUT) throughout the entire period of injecting link status change events into the target port of the DUT. The system first reads the specific content of the monitoring objects from the stored test configuration information, which specifies which dimensions of status data need to be collected and which specific items or indicators need to be monitored. Next, the system initiates collection channels with various data sources, including establishing connections with the DUT through the management interface and with the traffic analysis device through the service monitoring interface. During the process of the physical layer fault injection module injecting the link status change event, the system sends status query commands to the DUT according to a preset collection cycle and receives hardware forwarding plane data, control plane protocol data, and system logs returned by the DUT. Simultaneously, the system receives real-time statistical service traffic quality data from the service traffic monitoring module. The system timestamps all collected data according to the collection time and stores it in an internal database or cache in time-series format, forming multi-dimensional status data. The system continues to execute the above collection actions until the link status change event injection is completed or the tester manually stops the collection.

[0041] For example, suppose the monitoring targets are set as "WCMP group 1 member entries, link state change counts in hardware counters, OSPF neighbor status, and packet loss rate of service traffic". During the process of injecting continuous link jitter into the GigabitEthernet0 / 1 port of the device under test, the system logs into the device under test via SSH every 10 milliseconds and executes the command "show hardwareinternal wcmp group 1" to obtain WCMP group member entries. Simultaneously, it obtains the port hardware counter values ​​every 10 milliseconds, retrieves neighbor state change events from the OSPF protocol emulator every 5 milliseconds, and obtains the current packet loss rate from the traffic analyzer every 1 millisecond. The system records all collected data sequentially according to timestamps.

[0042] Step S40: When the state change of the device under test is detected based on the multi-dimensional state data and meets the event triggering condition, a snapshot of the multi-dimensional state data within the target time window is obtained.

[0043] Understandably, the aforementioned target time window can refer to a time range formed by extending a preset duration forward and backward from the moment a detected event occurs, such as a time interval of 200 milliseconds, based on the moment the event occurs, extending forward by 100 milliseconds and backward by 100 milliseconds.

[0044] It should be explained that the aforementioned multi-dimensional state data snapshot can refer to a data set that the test system collects within the target time window, containing state information of multiple functional levels of the device under test. This data set is continuous on the time axis and can reflect the dynamic changes in the state of the device under test before and after the event occurs.

[0045] In its implementation, the system continuously collects multi-dimensional status data of the device under test (DUT) and analyzes each piece of data in real time. The system compares the currently collected multi-dimensional status data with pre-defined event triggering conditions. When the system detects that a change in the DUT's status meets the event triggering conditions based on the multi-dimensional status data, it immediately executes the action of acquiring a multi-dimensional status data snapshot. Specifically, the system first determines the specific moment corresponding to the fulfillment of the event triggering conditions and uses this moment as the reference point for subsequent time windows. Next, the system determines the start and end times of the target time window based on preset time window parameters (e.g., window width, forward extension length, backward extension length). The system extracts all data entries whose timestamps fall within the aforementioned target time window range from the stored multi-dimensional status data sequence. The system packages and organizes these extracted data entries in chronological order to form a complete multi-dimensional status data snapshot. The system stores this multi-dimensional status data snapshot in internal memory or a database for use in subsequent correlation analysis steps.

[0046] To facilitate understanding, the following example illustrates the concept, but does not impose specific limitations on this embodiment. For instance, suppose the event trigger condition is set to "the number of WCMP group members changes," and the target time window is set to "100 milliseconds before and after the event trigger time." During continuous monitoring of multi-dimensional state data, the system detects that the number of members in WCMP group 1 has changed from 4 to 3, a change that satisfies the preset event trigger condition. The system records the moment T_event when this change is detected. Next, the system filters all data from all internally stored multi-dimensional state data, selecting all data with timestamps within the range [T_event-100 milliseconds, T_event+100 milliseconds]. The system then packages all the selected data in chronological order, forming a complete data snapshot for this WCMP member change event.

[0047] It should be noted that the step of obtaining a snapshot of multi-dimensional state data within a target time window when the state change of the device under test is detected to meet the event triggering condition based on the multi-dimensional state data may include: real-time analysis of the multi-dimensional state data; when a change in the hardware forwarding plane table entry of the device under test, a change in the routing protocol adjacency relationship state, or a service traffic quality indicator exceeding a preset threshold is detected, determining that the state change of the device under test meets the event triggering condition, and recording the event triggering time corresponding to the state change; and obtaining a snapshot of multi-dimensional state data within a target time window based on the event triggering time.

[0048] It should be understood that by binding the triggering conditions to specific indicator types in multi-dimensional state data, the testing system can accurately identify abnormal events truly caused by link jitter in massive real-time monitoring data, avoiding the waste of storage resources and processing overhead caused by indiscriminate snapshot collection, and achieving the precision, standardization and full-stack coverage of the test triggering mechanism.

[0049] Furthermore, since the event trigger moment is accurately recorded, the target time window acquired subsequently can be extended forward and backward with that moment as the anchor point, thereby ensuring that the snapshot data fully covers the critical transition interval before and after the fault occurs, avoiding the problem of missing key data due to reaction lag in traditional manual collection, and realizing the automation and precision of fault capture.

[0050] It should be explained that the aforementioned hardware forwarding plane entries can refer to the table information stored inside the forwarding chip of the device under test, which is used to determine the forwarding path of data packets, such as WCMP (Weighted Equal Cost Multipath) group membership entries, next-hop entries, and routing forwarding table entries (FIB).

[0051] The aforementioned routing protocol adjacency state can refer to the current state of the neighbor relationship established between the device under test and its neighboring routers when running routing protocols, such as the Full state and 2-Way state in the OSPF protocol, or the Established state and Idle state in the BGP protocol.

[0052] The aforementioned service traffic quality indicators can refer to quantifiable parameters used to measure the transmission quality of service flows forwarded by the device under test, such as throughput, end-to-end latency, latency jitter, and packet loss rate. The aforementioned preset thresholds can refer to pre-set critical values ​​used to determine whether service traffic quality indicators are abnormal, such as setting the packet loss rate threshold to 0.1% and the latency threshold to 10 milliseconds.

[0053] It is understandable that the aforementioned event triggering time can refer to the specific time point when the test system detects that the state change of the device under test meets the event triggering conditions. This time point is used as a benchmark reference point for the target time window.

[0054] It should be understood that when the system detects any one of the following three situations: a change in a hardware forwarding plane entry, a change in the state of a routing protocol adjacency, or a service traffic quality indicator exceeding a preset threshold, the system determines that the state change of the device under test meets the event triggering conditions.

[0055] To address the shortcomings of existing solutions, such as inconsistent time bases for multi-source data and difficulties in correlated analysis due to fragmented events, the step of obtaining a multi-dimensional state data snapshot within a target time window based on the event trigger time may include: generating a snapshot acquisition instruction based on the event trigger time and sending the snapshot acquisition instruction to the corresponding functional modules; receiving the target hardware forwarding plane data, target control plane protocol data, and target service traffic quality data within the target time window returned by each functional module according to the snapshot acquisition instruction; and aligning and storing the target hardware forwarding plane data, the target control plane protocol data, and the target service traffic quality data according to timestamps to generate a multi-dimensional state data snapshot.

[0056] It should be explained that the aforementioned snapshot acquisition command can refer to a command issued by the test system to each functional module, instructing each module to return status data within a specified time window. The corresponding functional modules can refer to various independent functional units in the test system that participate in multi-dimensional status data acquisition, such as the physical layer fault injection module, the device status comprehensive acquisition module, and the protocol simulation monitoring module.

[0057] It should be noted that the aforementioned target hardware forwarding plane data can refer to the hardware table entry status data and hardware counter data of the forwarding chip inside the device under test within the target time window, such as snapshot values ​​of WCMP group membership entries and differences in port CRC error counters. The aforementioned target control plane protocol data can refer to routing protocol state change records and system logs of the device under test within the target time window, such as OSPF neighbor state transition logs and BGP route update message summaries. The aforementioned target service traffic quality data can refer to the statistical values ​​of quality indicators such as throughput, latency, and packet loss rate of service flows within the target time window.

[0058] It should be understood that the above-mentioned aligned storage may refer to aligning multi-source data from different functional modules on the timeline according to their respective timestamps, and storing the aligned data as a whole in the storage medium.

[0059] In its implementation, after recording the event trigger time, the system generates a snapshot acquisition command based on that event trigger time. The system first determines the range of the target time window, for example, 100 milliseconds before and after the event trigger time. Then, following a preset command format, the system generates a snapshot acquisition command containing the start and end times of the target time window. The system distributes these snapshot acquisition commands to the corresponding functional modules via the management network. These modules include, but are not limited to, the physical layer fault injection module responsible for recording link state change events, the device state comprehensive acquisition module responsible for collecting the internal state of the device under test, and the protocol simulation monitoring module responsible for monitoring protocol interactions and service traffic. Upon receiving the snapshot acquisition command, each functional module extracts data within the specified target time window from its locally stored historical data and sends the extracted data back to the system. The system receives the data returned by each functional module, including target hardware forwarding plane data, target control plane protocol data, and target service traffic quality data. Subsequently, the system parses the timestamp information carried in each data set and aligns all data records from different modules whose timestamps fall within the target time window according to their chronological order. The system encapsulates the aligned data into a complete data packet and stores the data packet in an internal database or file system, thereby generating a multi-dimensional state data snapshot.

[0060] Step S50: Perform correlation analysis between the multi-dimensional state data snapshot and the link state change event to generate test results.

[0061] It should be explained that the above-mentioned correlation analysis can refer to the process of comparing and logically associating two types of data—multi-dimensional state data snapshots and link state change events—on a time axis to determine the causal relationship between link state change events and internal state changes of the device under test.

[0062] It should be understood that the above test results can refer to comprehensive conclusions that are output after correlation analysis and can reflect the impact of link jitter on various levels of the device under test. For example, they can describe the causal chain of how physical layer events lead to changes in hardware entries and how changes in hardware entries trigger routing protocol oscillations.

[0063] In its implementation, after acquiring a multi-dimensional state data snapshot, the system correlates this snapshot with previously recorded link state change events and generates test results. The system first reads the multi-dimensional state data snapshot from the storage medium, simultaneously reading the timestamp and event type (Up switch or Down switch) of each link state change event recorded throughout the test. Next, the system compares the timestamps of various data types (including hardware forwarding plane data, control plane protocol data, and service traffic quality data) in the multi-dimensional state data snapshot with the timestamps of the link state change events to determine whether the state data of each dimension of the device under test has changed before and after each link state change event. Based on preset analysis rules, the system determines whether there is a temporal sequence and logical triggering relationship between link state change events and changes in hardware forwarding plane entries, whether there is a correlation between changes in hardware forwarding plane entries and changes in routing protocol state, and whether there is a correspondence between the frequency of link jitter and the degree of service traffic quality degradation. The system then organizes these analysis results to form structured test results. The test results can include root cause analysis, time-series relationships of events at different levels, and statistical values ​​of quantitative indicators. The system stores the generated test results in its internal memory and can further use them to generate test reports.

[0064] For example, suppose a multi-dimensional state data snapshot records the following information: a link down event occurred at timestamp T1; the number of WCMP group members changed from 4 to 3 at timestamp T1+2; the OSPF neighbor state changed from Full to Down at timestamp T1+5; and the packet loss rate of service traffic reached 5% between timestamp T1+3 and timestamp T1+10. The test system analyzed the correlation between this data and the link state change event, determining that the link down event triggered WCMP group pruning. WCMP group pruning further led to route recalculation and OSPF neighbor interruption, ultimately causing significant packet loss in service traffic. Based on this, the test system generated the test result: "Link jitter triggered the WCMP pruning threshold, causing route oscillation and service interruption."

[0065] To improve the readability and reproducibility of test results, the step of performing correlation analysis between the multi-dimensional state data snapshot and the link state change event to generate test results includes: aligning the link state change event with the multi-dimensional state data snapshot on a timeline based on the timestamp information in the multi-dimensional state data snapshot and the time information of the link state change event; determining the causal relationship between the link state change event and changes in hardware forwarding plane entries, control plane protocol state, and service traffic quality based on the alignment result; generating a visual test report containing time series information based on the causal relationship, and using the visual test report as the test result.

[0066] Understandably, the aforementioned timeline alignment refers to the process of arranging and matching event data from different sources according to their respective timestamp information on the same time coordinate system. For example, placing the timestamps of physical layer link state change events, hardware forwarding plane entry change records, control plane protocol state change records, and service traffic quality data on the same timeline allows for comparison and viewing of state changes at each layer at any given moment.

[0067] It should be explained that the aforementioned causal relationship refers to the logical triggering and being triggered relationship between a link state change event as the cause and changes in hardware forwarding plane entries, control plane protocol state, and service traffic quality as the results. For example, a link down event causes WCMP group members to be pruned, which in turn triggers routing protocol recalculation and causes neighbor relationship oscillation, ultimately resulting in an increase in service traffic packet loss rate. The dependencies between the various links in this chain constitute the causal relationship.

[0068] Understandably, the aforementioned visual test report can refer to a document that presents test results graphically, such as a PDF file or HTML page containing visualization elements such as timeline charts, event annotations, and indicator curves. The aforementioned time series information can refer to a sequence of events and state changes arranged chronologically, such as a chain of information arranged in chronological order like "Link Down at time T1 → WCMP Members Decrease at time T2 → Routing Convergence Begins at time T3 → Packet Loss Rate Increases at time T4".

[0069] It should be understood that by introducing a timestamp-based timeline alignment mechanism, link state change events and multi-dimensional state data snapshots can be accurately mapped within a unified time coordinate system. This allows for the deduction of causal relationships between link state change events and changes in hardware forwarding plane entries, control plane protocol states, and service traffic quality based on the chronological order of state changes and response timing. This avoids the risk of misjudging by simply equating temporal sequence with causal relationship. Based on this, a visualized test report containing time-series information is generated, improving the readability and reproducibility of test results. This enables testers to quickly locate the network layer where the root cause of the fault lies without having to sift through a large amount of raw logs.

[0070] It should be added that the testing system can be composed of five core modules: an intelligent correlation and diagnostic engine, a test control and orchestration module, a physical layer fault injection module, a device status comprehensive acquisition module, and a protocol simulation and monitoring module. The test control and orchestration module acts as the central controller, issuing commands to other modules through the management network and receiving status data and monitoring results from each module. The physical layer fault injection module is connected in series on the data path, applying precise and controllable link jitter to the target port of the device under test (DUT). The device status comprehensive acquisition module polls the status information of each plane within the DUT at high frequency through the management interface. The protocol simulation and monitoring module simulates protocol interactions and service traffic in a real network, sensing changes in network quality. The intelligent correlation and diagnostic engine is responsible for real-time analysis of multi-source data, triggering event snapshots when an anomaly is detected, and storing all information in a correlated manner, ultimately generating a comprehensive test report.

[0071] For example, refer to Figure 2 , Figure 2This diagram illustrates the module relationships within the test system of the link jitter testing method for network devices according to the present invention. Based on the intelligent association and diagnostic engine, the system first issues test control and orchestration commands to drive the device under test (DUT) to inject link state changes. Simultaneously, it coordinates the device state comprehensive acquisition module, protocol simulation monitoring module, traffic generator, and traffic analyzer to collect multi-dimensional data on hardware forwarding plane, control plane protocols, and service traffic quality. During testing, the physical layer fault injection module responds to control commands by applying link disturbance events to the DUT's input interface. Simultaneously, it continuously acquires internal device table status, routing protocol adjacency changes, system logs, and metrics such as service throughput, latency, and packet loss rate through the management interface and service monitoring interface. When the collected multi-dimensional state data meets preset event triggering conditions (such as hardware table changes, protocol state anomalies, or service quality degradation), the system automatically generates a snapshot command, which is then sent to each functional module to capture a snapshot of the multi-dimensional state data within the target time window. Subsequently, the intelligent correlation and diagnosis engine performs timeline alignment and causal correlation analysis on link events and state snapshots to identify the temporal relationship between jitter events and device responses, thereby generating test results that include hardware response latency, protocol convergence latency, and business impact assessment, realizing a closed-loop test and intelligent diagnosis process from event injection to root cause localization.

[0072] This embodiment discloses the acquisition of test configuration information, including jitter parameters, monitoring objects, and event triggering conditions. Based on the jitter parameters, a link state change event is injected into the target port of the device under test. During the injection of the link state change event, multi-dimensional state data of the device under test is collected according to the monitoring objects. When a state change of the device under test is detected based on the multi-dimensional state data and meets the event triggering conditions, a snapshot of the multi-dimensional state data within a target time window is obtained. The multi-dimensional state data snapshot is correlated with the link state change event to generate test results. Because this embodiment collects multi-dimensional state data during jitter injection, obtains a data snapshot within a target time window through an event triggering mechanism, and finally correlates the data snapshot with the link jitter event, compared to existing technologies, this embodiment not only automates the entire testing process but also improves the comprehensiveness of test coverage and the accuracy of fault location, thereby improving the reliability of the link jitter test results.

[0073] refer to Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the link jitter testing method for network devices according to the present invention.

[0074] Based on the first embodiment described above, in this embodiment, step S30 includes steps S301 to S304: Step S301: Based on the first monitoring dimension of the monitored object, during the injection of the link status change event, query the internal hardware table status and hardware counter of the device under test through the management interface in the first collection cycle to obtain hardware forwarding plane status data.

[0075] Step S302: Based on the second monitoring dimension of the monitored object, during the injection of the link state change event, the routing protocol adjacency status, routing table information and system log of the device under test are obtained through the management interface in the second collection cycle to obtain control plane protocol data.

[0076] Step S303: Based on the third monitoring dimension of the monitored object, during the injection of the link status change event, the throughput, latency and packet loss rate of the service traffic of the device under test are statistically analyzed through the service monitoring interface in the third collection cycle to obtain service traffic quality data.

[0077] Step S304: Use the hardware forwarding plane state data, the control plane protocol data, and the service traffic quality data as multi-dimensional state data.

[0078] It should be noted that the aforementioned first monitoring dimension may refer to the first type of monitoring scope included in the monitoring object in the test configuration information, used to instruct the test system to collect status data at the hardware forwarding layer of the device under test. The aforementioned second monitoring dimension may refer to the second type of monitoring scope included in the monitoring object in the test configuration information, used to instruct the test system to collect protocol status data at the control layer of the device under test. The aforementioned third monitoring dimension may refer to the third type of monitoring scope included in the monitoring object in the test configuration information, used to instruct the test system to collect quality data at the service traffic layer of the device under test.

[0079] It should be explained that the aforementioned management interface can refer to the communication interface provided by the device under test (DUT) for outputting the device's internal status and receiving management commands, such as a Console serial port or an MGMT Ethernet management port, supporting protocols such as CLI, SNMP, or Netconf. The aforementioned service monitoring interface can refer to an interface in the test system specifically used to receive service traffic quality statistics, such as a data interface or API interface connected to a traffic analyzer.

[0080] Understandably, the first collection period mentioned above can refer to the time interval at which the test system performs collection operations on hardware forwarding plane data, for example, set to collect data once every 10 milliseconds. The second collection period mentioned above can refer to the time interval at which the test system performs collection operations on control plane protocol data, for example, set to collect data once every 5 milliseconds. The third collection period mentioned above can refer to the time interval at which the test system collects or receives statistical information on service traffic quality data, for example, set to obtain statistical values ​​once every 1 millisecond.

[0081] It should be noted that the aforementioned internal hardware table status can refer to the current content of various forwarding-related tables stored internally in the forwarding chip of the device under test, such as WCMP group membership entries, next-hop entries, and equal-cost multipath entries. The aforementioned hardware counters can refer to register values ​​maintained internally by the port or forwarding chip of the device under test to count the number of various events, such as link state change counters, CRC error counters, and packet loss counters.

[0082] The aforementioned routing protocol adjacency state can refer to the current state value of the neighbor relationships established between the device under test and neighboring devices when the device is running a routing protocol (such as OSPF, BGP, IS-IS), for example, the Full, Down, and Init states of OSPF. The aforementioned routing table information can refer to the set of routing entries stored in the device under test that guide packet forwarding, including fields such as destination network, next-hop address, and outgoing interface. The aforementioned system logs can refer to text records automatically generated by the device under test during operation to record system events and fault information, such as interface status change logs and neighbor relationship change logs.

[0083] Understandably, during the injection of link state change events, the system employs different collection strategies to acquire three types of state data based on the different monitoring dimensions defined in the monitored object. The system first reads the specific content of the monitored object from the stored test configuration information and identifies the specific data items that need to be collected for each of the first, second, and third monitoring dimensions.

[0084] To facilitate understanding, the following examples are provided for illustration, but do not impose specific limitations on this embodiment. For instance, suppose that in a test, the first monitoring dimension of the monitored object specifies the collection of WCMP group 1 member entries and the link state change counters of port GigabitEthernet0 / 1, with the first collection period set to 10 milliseconds; the second monitoring dimension specifies the collection of OSPF neighbor status and routing information to the 192.168.1.0 / 24 network segment, with the second collection period set to 5 milliseconds; the third monitoring dimension specifies the collection of service flow throughput and packet loss rate, with the third collection period set to 1 millisecond. During the process of injecting link jitter into the device under test, the system executes "show hardwareinternal wcmp group 1" and "show interface gigabitethernet0 / 1 counters" via SSH every 10 milliseconds, recording the results of each query. Simultaneously, it executes "show ip ospf neighbor" and "show ip route 192.168.1.0" every 5 milliseconds and captures the system logs in real time. Also, it queries the traffic analyzer for the current service traffic throughput and packet loss rate every 1 millisecond. The system stores all collected data by timestamp, which together constitute multi-dimensional status data.

[0085] It should be noted that, since the three monitoring dimensions correspond to the physical / link layer (hardware forwarding plane), network / control layer (control plane protocol), and application / service layer (service traffic quality), respectively, and are collected independently through management or service monitoring interfaces, the data for each dimension is physically isolated at the source of collection, avoiding data loss or latency distortion caused by congestion of a single interface. Furthermore, by setting differentiated parameters for the first, second, and third collection cycles (e.g., millisecond-level high-frequency polling for the hardware forwarding plane to capture transient changes in entries, second-level cycles for the control plane to match protocol convergence granularity, and sub-second cycles for service quality to balance accuracy and overhead), the collection frequency of each dimension's data matches the response characteristics of its corresponding network layer. This allows for precise alignment of state transition events at different layers based on their respective timestamps during subsequent correlation analysis.

[0086] This embodiment discloses that, based on a first monitoring dimension of the monitored object, during the injection of the link state change event, the internal hardware table status and hardware counter of the device under test are queried via a management interface at a first collection cycle to obtain hardware forwarding plane status data; based on a second monitoring dimension of the monitored object, during the injection of the link state change event, the routing protocol adjacency status, routing table information, and system logs of the device under test are obtained via the management interface at a second collection cycle to obtain control plane protocol data; based on a third monitoring dimension of the monitored object, during the injection of the link state change event, the throughput, latency, and packet loss rate of the service traffic of the device under test are statistically analyzed via a service monitoring interface at a third collection cycle to obtain service traffic quality data; and the hardware forwarding plane status data, the control plane protocol data, and the service traffic quality data are used as multi-dimensional status data. Because this embodiment distinguishes between the first, second, and third monitoring dimensions and collects hardware forwarding plane, control plane, and service traffic quality data respectively, it forms a full-dimensional status monitoring covering both the internal and external aspects of the device. Compared with the prior art, this embodiment avoids the blind spots of single-level testing and provides a complete data foundation for subsequent cross-level correlation analysis, thereby improving the systematicness and accuracy of link jitter testing.

[0087] refer to Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the link jitter testing method for network devices according to the present invention.

[0088] Based on the above embodiments, in this embodiment, after step S50, steps S60 to S80 are further included: Step S60: Stop injecting the link state change event into the target port and restore the link state of the target port to a stable connectivity state.

[0089] Step S70: After stopping the injection of the link state change event, continue to collect multi-dimensional state data of the device under test to obtain monitoring information of the state recovery process.

[0090] Step S80: Based on the monitoring information of the state recovery process, determine the internal hardware entry recovery delay and routing protocol convergence delay of the device under test.

[0091] It should be understood that the aforementioned stable connectivity state can refer to the physical link of the target port of the device under test being in a state of continuous and effective data transmission capability, that is, the normal working mode in which the port remains in the Up state and no longer experiences link state flipping.

[0092] It should be noted that the monitoring information of the above-mentioned state recovery process can refer to the data set obtained by the test system over a period of time after stopping the injection of link state change events and continuing to collect multi-dimensional state data of the device under test. This data set reflects the state changes of the device under test at various levels during the transition from the end of jitter to the return to normal operation.

[0093] It should be explained that the aforementioned internal hardware entry recovery latency can refer to the time elapsed from the moment the test system stops injecting link state change events until the internal hardware forwarding plane entries of the device under test (e.g., pruned WCMP group members) are fully restored to their normal state before the jitter occurred. The aforementioned routing protocol convergence latency can refer to the time elapsed from the moment the test system stops injecting link state change events until the routing protocol adjacency relationships of the device under test are restored to a stable state (e.g., OSPF neighbors are restored to a Full state) and the routing table achieves global consistency again.

[0094] In its implementation, after executing all preset link state change event injection operations and completing correlation analysis to generate test results, the aforementioned test system performs the state recovery phase test steps. First, the test system sends a stop injection command to the physical layer fault injection module, instructing it to cease applying any link state change events to the target port of the device under test. Next, the test system restores the link state of the target port to a stable connectivity state, ensuring that the physical link of the target port is set to a continuously up state and no further active link flipping occurs. The test system can achieve this recovery operation by sending a port enable command or resetting the output state of the fault injection module.

[0095] After ceasing the injection of link state change events, the aforementioned test system continues to collect multi-dimensional state data of the device under test (DUT) to obtain monitoring information for the state recovery process. Following the same collection strategy as during the test, the test system continues to acquire hardware forwarding plane state data (e.g., WCMP group membership entries), control plane protocol data (e.g., routing protocol adjacency status, routing table information, system logs), and service traffic quality data of the DUT through the management interface at a preset collection cycle. The test system uses the moment the injection stopped as the starting reference point for the recovery process, continuously collecting and recording the state changes of the DUT at various levels over a subsequent period until all state indicators stabilize within the normal range. All the data obtained through this continuous collection constitutes the monitoring information for the state recovery process.

[0096] Then, based on the monitoring information of the state recovery process, the aforementioned test system determines the internal hardware entry recovery delay and routing protocol convergence delay of the device under test. The test system extracts the timestamp of the injection stop time from the monitoring information of the state recovery process and identifies the precise time point when the internal hardware entry (e.g., the number of WCMP group members) recovers from an abnormal state (e.g., a missing member state) to a normal state (e.g., a complete member state), calculating the time difference between the two time points as the internal hardware entry recovery delay. Simultaneously, the test system identifies the time point when the routing protocol adjacency state (e.g., OSPF neighbors) recovers from an interrupted state to a stable Full state, and the time point when the affected routing entries in the routing table reappear and remain stable, calculating the time difference from the injection stop time to the recovery time as the routing protocol convergence delay. The test system stores the determined recovery delay and convergence delay in the test results to evaluate the self-healing capability and recovery performance of the device under test.

[0097] It should be noted that by continuously monitoring the device under test after link jitter stops, the internal hardware table recovery latency and routing protocol convergence latency required for the device to recover from a fault state to a normal stable state can be accurately quantified. This allows for a comprehensive evaluation of the network device's self-healing capability and recovery performance after link jitter is eliminated. This overcomes the shortcomings of existing testing methods that only focus on the device's performance at the moment of the fault or during the fault period, providing network operations personnel with quantitative data on the complete recovery cycle of the device. Furthermore, it provides a more comprehensive and accurate testing basis for optimizing network fault tolerance parameters, evaluating device selection, and designing network reliability.

[0098] This embodiment discloses a method to stop injecting the link state change event into the target port and restore the link state of the target port to a stable connectivity state. After stopping the injection of the link state change event, multi-dimensional state data of the device under test (DUT) is continuously collected to obtain monitoring information of the state recovery process. Based on the monitoring information of the state recovery process, the internal hardware table entry recovery delay and routing protocol convergence delay of the DUT are determined. Compared with existing technologies, this embodiment achieves quantitative performance evaluation during the fault recovery period by continuously collecting multi-dimensional state data and determining the internal hardware table entry recovery delay and routing protocol convergence delay after stopping the injection of link state change events, forming a closed-loop test process and improving test completeness.

[0099] Furthermore, this embodiment of the invention also proposes a storage medium storing a link jitter test program for a network device. When the link jitter test program for the network device is executed by a processor, it implements the steps of the link jitter test method for the network device as described above.

[0100] Reference Figure 5 , Figure 5 This is a structural block diagram of the first embodiment of the link jitter testing device for network equipment of the present invention.

[0101] like Figure 5 As shown, the link jitter testing device for network devices proposed in this embodiment of the invention includes: an information acquisition module 601, a fault injection module 602, a data acquisition module 603, a snapshot acquisition module 604, and a correlation analysis module 605.

[0102] The information acquisition module 601 is used to acquire test configuration information, which includes jitter parameters, monitoring objects, and event triggering conditions.

[0103] The fault injection module 602 is used to inject link state change events into the target port of the device under test based on the jitter parameters.

[0104] The data acquisition module 603 is used to collect multi-dimensional status data of the device under test according to the monitoring object during the injection of the link status change event.

[0105] The snapshot acquisition module 604 is used to acquire a snapshot of multi-dimensional state data within a target time window when the state change of the device under test is detected to meet the event triggering condition based on the multi-dimensional state data.

[0106] The correlation analysis module 605 is used to perform correlation analysis between the multi-dimensional state data snapshot and the link state change event to generate test results.

[0107] The fault injection module 602 is further configured to generate a fault injection instruction based on the jitter parameters, the fault injection instruction including a link state change mode and a state maintenance duration; and to control the physical link of the target port to switch between a connected state and a disconnected state using the fault injection instruction.

[0108] The snapshot acquisition module 604 is also used to analyze the multi-dimensional state data in real time. When it detects that the hardware forwarding plane table entry of the device under test changes, the routing protocol adjacency relationship status changes, or the service traffic quality index exceeds a preset threshold, it determines that the state change of the device under test meets the event triggering condition and records the event triggering time corresponding to the state change; based on the event triggering time, it acquires a multi-dimensional state data snapshot within the target time window.

[0109] The snapshot acquisition module 604 is further configured to generate a snapshot acquisition instruction based on the event trigger time, and send the snapshot acquisition instruction to the corresponding functional module; receive the target hardware forwarding plane data, target control plane protocol data, and target service traffic quality data within the target time window transmitted back by each of the functional modules according to the snapshot acquisition instruction; and align and store the target hardware forwarding plane data, the target control plane protocol data, and the target service traffic quality data according to timestamps to generate a multi-dimensional state data snapshot.

[0110] The correlation analysis module 605 is further configured to align the link state change event with the multi-dimensional state data snapshot based on the timestamp information in the multi-dimensional state data snapshot and the time information of the link state change event; determine the causal relationship between the link state change event and changes in hardware forwarding plane entries, changes in control plane protocol state, and changes in service traffic quality based on the alignment result; generate a visual test report containing time series information based on the causal relationship, and use the visual test report as the test result.

[0111] This device embodiment discloses the acquisition of test configuration information, including jitter parameters, monitoring objects, and event triggering conditions. Based on the jitter parameters, a link state change event is injected into the target port of the device under test. During the injection of the link state change event, multi-dimensional state data of the device under test is collected according to the monitoring objects. When a state change of the device under test is detected based on the multi-dimensional state data and meets the event triggering conditions, a snapshot of the multi-dimensional state data within a target time window is obtained. The multi-dimensional state data snapshot is correlated with the link state change event to generate test results. Because this device embodiment collects multi-dimensional state data during jitter injection, obtains a data snapshot within a target time window through an event triggering mechanism, and finally correlates the data snapshot with the link jitter event, compared with the prior art, this device embodiment not only automates the entire testing process but also improves the comprehensiveness of test coverage and the accuracy of fault location, thereby improving the reliability of link jitter test results.

[0112] Based on the first embodiment of the link jitter testing device for network devices of the present invention, a second embodiment of the link jitter testing device for network devices of the present invention is proposed.

[0113] In this embodiment, the data acquisition module 603 is further configured to, based on the first monitoring dimension of the monitored object, during the injection of the link state change event, query the internal hardware table status and hardware counter of the device under test via the management interface at a first acquisition cycle to obtain hardware forwarding plane status data; based on the second monitoring dimension of the monitored object, during the injection of the link state change event, acquire the routing protocol adjacency status, routing table information, and system logs of the device under test via the management interface at a second acquisition cycle to obtain control plane protocol data; based on the third monitoring dimension of the monitored object, during the injection of the link state change event, statistically analyze the throughput, latency, and packet loss rate of the service traffic of the device under test via the service monitoring interface at a third acquisition cycle to obtain service traffic quality data; and use the hardware forwarding plane status data, the control plane protocol data, and the service traffic quality data as multi-dimensional status data.

[0114] Other embodiments or specific implementations of the link jitter testing device for network devices of the present invention can be found in the above-described method embodiments, and will not be repeated here.

[0115] This application provides a link jitter testing device for a network device. The link jitter testing device for a network device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the link jitter testing method for the network device in the above embodiment 1.

[0116] The following is for reference. Figure 6 This document illustrates a schematic diagram of a link jitter testing device suitable for implementing network devices according to embodiments of this application. The link jitter testing device for network devices in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The link jitter test device for network devices shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0117] like Figure 6As shown, the link jitter testing device for network devices may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the link jitter testing device for network devices. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the link jitter testing device for network devices to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a link jitter testing device for network devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0118] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0119] The link jitter testing device for network devices provided in this application, employing the link jitter testing method for network devices described in the above embodiments, can solve the technical problems of insufficient test coverage, difficulty in fault location, and reliance on manual testing in existing technologies, leading to insufficient reliability of link jitter test results. Compared with the prior art, the beneficial effects of the link jitter testing device for network devices provided in this application are the same as those of the link jitter testing method for network devices provided in the above embodiments, and other technical features of this link jitter testing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0120] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0121] 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 that can be easily conceived by those skilled in the art within the scope of the technology 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.

[0122] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0123] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0125] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for link jitter test of a network device, the method comprising: The method includes: Obtain test configuration information, which includes jitter parameters, monitoring objects, and event triggering conditions; Based on the jitter parameters, a link state change event is injected into the target port of the device under test; During the injection of the link state change event, multi-dimensional state data of the device under test are collected according to the monitoring object; When the state change of the device under test is detected to meet the event triggering condition based on the multi-dimensional state data, a snapshot of the multi-dimensional state data within the target time window is obtained. The multi-dimensional state data snapshots are correlated with the link state change events to generate test results.

2. The method of claim 1, wherein the network device is a router. The step of obtaining a snapshot of the multi-dimensional state data within a target time window when the state change of the device under test is detected to meet the event triggering condition based on the multi-dimensional state data includes: The system analyzes the multi-dimensional state data in real time. When it detects that the hardware forwarding plane table entry of the device under test has changed, the routing protocol adjacency relationship status has changed, or the service traffic quality index has exceeded the preset threshold, it determines that the state change of the device under test meets the event triggering condition and records the event triggering time corresponding to the state change. Based on the event trigger time, obtain a multi-dimensional state data snapshot within the target time window.

3. The method of claim 2, wherein the network device is a router. The step of obtaining a multi-dimensional state data snapshot within a target time window based on the event trigger time includes: A snapshot acquisition instruction is generated based on the event trigger time, and the snapshot acquisition instruction is sent to the corresponding functional module; Receive the target hardware forwarding plane data, target control plane protocol data and target service traffic quality data within the target time window, which are transmitted back by each of the functional modules according to the snapshot acquisition instruction; The target hardware forwarding plane data, the target control plane protocol data, and the target service traffic quality data are aligned and stored according to timestamps to generate a multi-dimensional state data snapshot.

4. The method of claim 1, wherein the network device is a router. The step of injecting link state change events into the target port of the device under test based on the jitter parameters includes: A fault injection instruction is generated based on the jitter parameters, and the fault injection instruction includes the link state change mode and the state maintenance duration; The fault injection command is used to control the physical link of the target port to switch between connected and disconnected states.

5. The link jitter testing method for network devices as described in claim 1, characterized in that, The step of collecting multi-dimensional status data of the device under test according to the monitoring object during the injection of the link status change event includes: Based on the first monitoring dimension of the monitored object, during the injection of the link status change event, the internal hardware table status and hardware counter of the device under test are queried through the management interface in the first collection cycle to obtain hardware forwarding plane status data. Based on the second monitoring dimension of the monitored object, during the injection of the link state change event, the routing protocol adjacency status, routing table information and system log of the device under test are obtained through the management interface in the second collection cycle to obtain control plane protocol data; Based on the third monitoring dimension of the monitored object, during the injection of the link status change event, the throughput, latency and packet loss rate of the service traffic of the tested device are statistically analyzed through the service monitoring interface in the third collection cycle to obtain service traffic quality data; The hardware forwarding plane status data, the control plane protocol data, and the service traffic quality data are used as multi-dimensional status data.

6. The link jitter testing method for network devices as described in claim 1, characterized in that, The step of correlating and analyzing the multi-dimensional state data snapshots with the link state change events to generate test results includes: Based on the timestamp information in the multi-dimensional state data snapshot and the time information of the link state change event, the link state change event is aligned with the multi-dimensional state data snapshot on the time axis. Based on the alignment results, the causal relationship between the link state change event and changes in hardware forwarding plane entries, control plane protocol state, and service traffic quality is determined. A visual test report containing time series information is generated based on the causal relationship, and the visual test report is used as the test result.

7. The link jitter testing method for network devices as described in claim 1, characterized in that, After the step of correlating and analyzing the multi-dimensional state data snapshots with the link state change events to generate test results, the method further includes: Stop injecting the link state change event into the target port and restore the link state of the target port to a stable connectivity state; After stopping the injection of the link state change event, continue to collect multi-dimensional state data of the device under test to obtain monitoring information of the state recovery process; Based on the monitoring information of the state recovery process, the internal hardware entry recovery delay and routing protocol convergence delay of the device under test are determined.

8. A link jitter testing device for network equipment, characterized in that, The device includes: The information acquisition module is used to acquire test configuration information, which includes jitter parameters, monitoring objects, and event triggering conditions. The fault injection module is used to inject link state change events into the target port of the device under test based on the jitter parameters. The data acquisition module is used to collect multi-dimensional status data of the device under test according to the monitoring object during the injection of the link status change event; The snapshot acquisition module is used to acquire a snapshot of the multi-dimensional state data within a target time window when the state change of the device under test is detected to meet the event triggering condition based on the multi-dimensional state data. The correlation analysis module is used to perform correlation analysis between the multi-dimensional state data snapshot and the link state change event to generate test results.

9. A link jitter testing device for network equipment, characterized in that, The device includes: a memory, a processor, and a link jitter test program for a network device stored in the memory and executable on the processor, the link jitter test program for the network device being configured to implement the steps of the link jitter test method for a network device as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a link jitter test program for a network device, which, when executed by a processor, implements the steps of the link jitter test method for a network device as described in any one of claims 1 to 7.

Images