Test methods, apparatuses, systems, storage media, and program products

Abstract

The application discloses a test method, device, system, storage medium and program product, relates to the technical field of communication, and is used for improving the flexibility and efficiency of SRv6 TE Policy path connectivity test. The method comprises the following steps: in response to receiving a probe packet from a device under test, determining a packet encapsulation mode of a backhaul packet based on mode configuration information; the packet encapsulation mode comprises an IP mode and one or more tunnel modes; when the packet encapsulation mode is the IP mode, the backhaul packet is transmitted through a routing mode; when the packet encapsulation mode is the one or more tunnel modes, the backhaul packet is transmitted through a preset tunnel; based on the packet encapsulation mode, a backhaul packet is constructed and sent to the device under test; the backhaul packet carries a backhaul path; based on whether the device under test successfully receives the backhaul packet, a test result is determined; the test result comprises the connectivity of the probe path and the backhaul path.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a test method, apparatus, system, storage medium, and program product. Background Technology

[0002] SRv6-based traffic engineering policies (SRv6 TE policies) are a strategy that easily translates network intents into programmable SRv6 TE policy paths (segment lists) and automatically directs traffic along these paths. Due to its ease of deployment and high flexibility in path adjustment, it has rapidly become a core technology for traffic scheduling. However, before deploying an SRv6 TE policy, testing is necessary to ensure the connectivity of the paths within the policy.

[0003] In related technologies, testing SRv6 TE Policy paths typically requires constructing a complete network topology, including multiple SRv6-enabled intermediate forwarding devices (such as SRv6-enabled routers or switches), to simulate path orchestration and forwarding behavior in a real network. However, this approach is not only costly in terms of hardware and time-consuming in terms of test topology construction, but also has significant limitations in terms of test scale, diversity of test scenarios, and scalability, making it difficult to meet the needs of large-scale, high-performance SRv6 TE Policy path connectivity testing. Summary of the Invention

[0004] This application discloses a testing method, apparatus, system, storage medium, and program product for improving the flexibility and efficiency of SRv6 TEPolicy path connectivity testing.

[0005] Firstly, this application provides a testing method that can be applied to a testing device. The testing device is communicatively connected to the device under test. By simulating multiple virtual nodes that support SRv6 using the testing device, a large number of hardware devices that support SRv6 are not required. This reduces hardware costs and simplifies the network topology setup process, thereby greatly improving testing efficiency.

[0006] When testing with the aforementioned testing device, the device under test (DUT) sends probe messages to the testing device. Upon receiving the probe messages, the testing device determines the message encapsulation mode of the return message based on the mode configuration information, constructs the return message according to the message encapsulation mode, and sends the return message to the DUT. The connectivity between the probe path and the return path is determined by monitoring whether the DUT receives the return message. The intermediate and final points of the probe path, as well as the starting and intermediate points of the return path, all utilize virtual nodes on the testing device. This not only eliminates the additional overhead of deploying hardware and improves testing efficiency, but also allows for simultaneous verification of the connectivity between the probe path and the return path through a single interaction of probe and return messages, ensuring that the test results comprehensively cover the bidirectional traffic transmission link.

[0007] Messages are encapsulated according to different message encapsulation modes. In IP mode, return messages are transmitted via routing; in one or more tunnel modes, return messages are transmitted through a preset tunnel. This approach allows for differentiated selection and flexible adaptation of message encapsulation modes, meeting the diverse needs of various SRv6 testing scenarios and thus improving the flexibility of the testing method.

[0008] In summary, the testing method proposed in this application replaces hardware deployment with virtual node simulation, verifies bidirectional paths through single-interaction, and flexibly adapts to multiple encapsulation modes. This significantly reduces the hardware cost and topology construction complexity of SRv6 path testing while maintaining both testing flexibility and efficiency.

[0009] As a first possible implementation of the first aspect, one or more tunneling modes include an insertion tunneling mode and an encapsulation tunneling mode; wherein, when the packet encapsulation mode is the insertion tunneling mode, an SRH corresponding to the return path is inserted before the original segment routing header (SRH) of the probe packet to obtain a return packet; or, when the packet encapsulation mode is the encapsulation tunneling mode, an outer IPv6 header containing a return SRH is added before the IPv6 header of the probe packet to obtain a return packet; or, when the packet encapsulation mode is the IP mode, the SRH in the probe packet is removed, and the destination address in the probe packet is modified to the source address of the probe packet to obtain a return packet.

[0010] It should be understood that by supporting flexible configuration of three backhaul packet construction modes—insert tunnel mode, encapsulated tunnel mode, and IP mode—it is possible to simulate the forwarding behavior of router forwarding chips that construct backhaul packets in Insert mode, the forwarding behavior of router forwarding chips that construct backhaul packets in Encap mode, and test scenarios where the backhaul path needs to go through IP routing forwarding, thereby covering the processing logic of different forwarding chips in the SRv6 network.

[0011] As a second possible implementation of the first aspect, the return message includes: the number of remaining segments. The number of remaining segments represents the number of SRv6-supporting virtual nodes remaining to be traversed in the return message; wherein the number of remaining segments is determined by the return parameter configuration information.

[0012] It should be understood that by setting the number of remaining segments, the hop-by-hop forwarding logic of return packets can be precisely controlled, flexibly simulating packet forwarding scenarios at different locations in a real network.

[0013] As a third possible implementation of the first aspect, the test device and the device under test establish communication through a bidirectional forwarding detection (BFD) session, so that probe messages and return messages are transmitted based on the BFD protocol.

[0014] It should be understood that BFD sessions support millisecond-level message interaction cycles and timeout determination mechanisms. This application uses BFD sessions for communication, which can significantly shorten the detection latency of path connectivity and improve detection efficiency.

[0015] As a fourth possible implementation of the first aspect, the probe message further includes: a first reverse binding identifier; the first reverse binding identifier indicates that it is used to bind a return path; constructing and sending a return message to the device under test based on the message encapsulation mode includes: constructing and sending a return message to the device under test based on the message encapsulation mode when the first reverse binding identifier is consistent with the preset reverse binding identifier; the preset reverse binding identifier is configured by the test device when establishing a BFD session.

[0016] It should be understood that when the device under test constructs a BFD probe message, it will fill the first reverse binding identifier into the SRH[1] position in the probe message. After receiving the probe message, the test device will parse the value of the SRH[1] position. If the value of the SRH[1] position is inconsistent with the value configured in the local BFD session, it will be determined that the return mode configuration and the packet receiving structure do not match. It may be that the probe message has taken the wrong path or the configuration is incorrect. At this time, the test device will not respond, thereby avoiding invalid return messages from interfering with the test.

[0017] As a fifth possible implementation of the first aspect, in response to receiving a probe packet from the device under test, the packet encapsulation mode of the return packet is determined based on mode configuration information, including: filtering and preprocessing the probe packet based on whether it carries a double-layer IPv6 header to obtain a preprocessed packet; the preprocessing includes: for probe packets with a double-layer IPv6 header, removing the outer IPv6 header and retaining the inner IPv6 header. The message header serves as the preprocessed message. Based on the presence or absence of an SRH header in the preprocessed message, the preprocessed message is filtered to obtain the first message. The first message represents the preprocessed message containing an SRH header. Based on the matching result between the interface configuration information of the BFD session in the first message and the preset interface configuration information, the first message is filtered to obtain the second message. The second message represents the first message that conforms to the preset interface configuration information. The interface configuration information includes: Media Access Control MAC address, Virtual LAN VLAN tag, User Datagram Protocol (UDP) port number or interface IP address. In response to receiving the probe message corresponding to the second message, the message encapsulation mode of the return message is determined based on the mode configuration information.

[0018] It should be understood that by preprocessing the probe packets' double-layer IPv6 headers, checking for the presence of an SRH header, and verifying whether the interface configuration information matches the preset interface configuration information, illegal and invalid traffic can be filtered out, ensuring that the test packets are probe packets associated with the current BFD test session.

[0019] As a sixth possible implementation of the first aspect, before determining the packet encapsulation mode of the return packet based on the mode configuration information in response to receiving a probe packet from the device under test, the method further includes: sending path information of the test device to the device under test so that the device under test generates a probe packet based on the path information; the path information is determined based on configuration information input by the user and / or traffic engineering policy information based on SRv6; the traffic engineering policy information based on SRv6 is used to guide traffic transmission on the probe path; wherein the path information includes: a probe path and a first reverse binding identifier, the first reverse binding identifier indicating that it is used to bind the return path.

[0020] It should be understood that determining path information based on user-input configuration information and / or SRv6-based traffic engineering policy information, and then sending the path information to the device under test, not only enables flexibility in determining the test path, but also allows the device under test to generate a probe path based on the path information, ensuring the authenticity of the test results.

[0021] As a seventh possible implementation of the first aspect, before sending the path information of the test device to the device under test, the method further includes: sending virtual topology data generated by the test device simulation to the device under test, so that the device under test generates a probe message based on the virtual topology data and the path information, wherein the virtual topology data includes graph information between multiple virtual nodes supporting SRv6.

[0022] It should be understood that by sending virtual topology data to the device under test, the authenticity of the test results is ensured by ensuring that the probe messages generated by the device under test match the virtual topology of the test device.

[0023] As an eighth possible implementation of the first aspect, the device under test includes a first port, and the testing device includes a second port and a processor; the first port of the device under test and the second port of the testing device are connected via a communication link, and the processor includes multiple CPU cores; the method further includes: binding a BFD process to a target CPU core among the multiple CPU cores, so that one BFD process exclusively occupies the computing resources of one target CPU core; the BFD process is used to maintain a BFD session, and to receive probe messages and construct and send return messages based on the BFD session; the BFD process is run based on the target CPU core to execute the testing method.

[0024] It should be understood that the target CPU core being bound only carries all business operations of the corresponding BFD process, including parsing probe packets, verifying reverse binding identifiers, constructing and encapsulating return packets, and sending return packets. Since the target CPU core is not interfered with by other tasks, it only executes the test method in the above embodiments. The execution of the BFD process does not need to wait for the release of computing power, thereby shortening the latency of packet processing and improving the timeliness and accuracy of test results.

[0025] As a ninth possible implementation of the first aspect, the number of first ports is one or more, the number of BFD processes and the number of target CPU cores are the same as the number of first ports, and there is a one-to-one correspondence between the first ports, BFD processes and target CPU cores.

[0026] It should be understood that each first port corresponds to an independent BFD process, and this process is uniquely bound to a target CPU core. Based on this mapping relationship, all BFD sessions and message processing tasks under a single first port are completed independently by the corresponding target CPU core, and will not compete for computing power with BFD tasks of other ports, ensuring that the BFD service processing latency of each port can be guaranteed during multi-port parallel testing.

[0027] As a tenth possible implementation of the first aspect, the above-described method of executing a test method based on a target CPU core by running a BFD process includes: in response to receiving a configuration operation from a user on a display interface of the test device, running a BFD process based on the target CPU core to execute the test method.

[0028] It should be understood that by triggering the BFD process based on the target CPU core through the user's configuration operation, it is possible to determine whether to run the BFD process based on the target CPU core according to the user's needs, thereby realizing the on-demand allocation of computing resources of the test device. This ensures the high-performance processing capability of the test device while avoiding the waste of computing resources, thereby improving the flexibility of the test method.

[0029] As the eleventh possible implementation of the first aspect, the number of virtual nodes supporting SRv6, graph information, probe path, first reverse binding identifier, probe message reception and filtering strategy, and remaining segment count are all obtained based on the configuration information entered by the user on the display interface of the test device.

[0030] It should be understood that users can customize the input configuration information to specify relevant parameters for the test process. The test device automatically generates corresponding virtual topology data, path information and other parameters based on the configuration information, and then automatically executes the test process, which improves the convenience and flexibility of the test plan.

[0031] As a twelfth possible implementation of the first aspect, the testing apparatus further includes: a hardware processing circuit; before running the BFD process based on the target CPU core to execute the testing method, the method further includes: the hardware processing circuit parsing the probe message to obtain characteristic parameters; the characteristic parameters are used to distinguish whether the probe message is an SRv6 message of a BFD session; the hardware processing circuit distributes the probe message to the corresponding target CPU core for processing based on the characteristic parameters.

[0032] It should be understood that parsing and distributing probe messages through hardware processing circuits can prevent non-BFD messages from entering the target CPU core and consuming computing power, thereby ensuring the low-latency processing capability of the BFD process.

[0033] In a second aspect, this application provides a testing apparatus, comprising: a processor and a memory; the memory being used to store processor-executable instructions; wherein the processor is configured to execute the instructions to implement the methods of the first aspect and any of the first to eleventh possible implementations of the first aspect.

[0034] In one possible implementation, the testing apparatus further includes a hardware processing circuit; wherein the hardware processing circuit is used to implement the method of the twelfth possible implementation of the first aspect.

[0035] Thirdly, this application provides a testing system, including: a device under test and a testing apparatus, the testing apparatus being used to perform the method described in the first aspect and any of its possible implementations.

[0036] Fourthly, this application provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables a test apparatus to perform the methods of the first aspect and any of the first to eleventh possible implementations of the first aspect.

[0037] Fifthly, this application provides a computer program product including computer instructions that, when executed on an electronic device, cause a testing device to perform the method described in the first aspect and any of the first to eleventh possible implementations of the first aspect. Attached Figure Description

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

[0039] Figure 1 A schematic diagram illustrating the construction of an SRv6 TE Policy path, provided for an embodiment of this application;

[0040] Figure 2 This is a schematic diagram of the structure of a testing system provided in an embodiment of this application;

[0041] Figure 3 This is a schematic diagram of a testing system provided in an embodiment of this application;

[0042] Figure 4 A schematic diagram of the functional modules of a testing device provided in an embodiment of this application;

[0043] Figure 5 This is a schematic diagram of the structure of a testing device provided in an embodiment of this application;

[0044] Figure 6 A flowchart illustrating a testing method provided in an embodiment of this application;

[0045] Figure 7 A schematic diagram illustrating a Segment List configuration for a return path provided in an embodiment of this application;

[0046] Figure 8A flowchart illustrating the process of determining the return mode, as provided in an embodiment of this application;

[0047] Figure 9 A schematic diagram illustrating the process of encapsulating a return message in Insert mode, as provided in an embodiment of this application;

[0048] Figure 10 A schematic diagram illustrating the process of encapsulating a return message in Encap mode, as provided in an embodiment of this application;

[0049] Figure 11 A flowchart illustrating the encapsulation of a return message in IP mode, provided as an embodiment of this application;

[0050] Figure 12 A flowchart illustrating another testing method provided in an embodiment of this application;

[0051] Figure 13 A flowchart illustrating another testing method provided in an embodiment of this application;

[0052] Figure 14 This is a schematic diagram illustrating a path information delivery method provided in an embodiment of this application.

[0053] Figure 15 This application provides a topology diagram of the relationship between the device under test and the tail end.

[0054] Figure 16 A schematic diagram of a network topology simulated by a testing device provided in an embodiment of this application;

[0055] Figure 17 A flowchart illustrating another testing method provided in an embodiment of this application;

[0056] Figure 18 This is a schematic diagram of another testing device provided in an embodiment of this application.

[0057] Explanation of reference numerals in the attached figures:

[0058] 201 - Device under test;

[0059] 2011 - First Port;

[0060] 202 - Test apparatus;

[0061] 2021 - Topology Simulation Module; 2022 - Tunnel Distribution Module; 2023 - Packet Receiving Module; 2024 - Packet Sending Module;

[0062] 2111 - Second port; 2112 - Processor; 2113 - Hardware processing circuit;

[0063] 21121-CPU core. Detailed Implementation

[0064] In some embodiments, the Segment Routing IPv6 Traffic Engineering Policy (SRv6 TE Policy) is a traffic engineering scheme based on IPv6 segment routing technology. Its core is to transform the network administrator's traffic scheduling intentions into programmable path instructions (i.e., SegmentList), and force traffic to be transmitted along a preset path through the extended field of the IPv6 packet header (Segment Routing Header SRH), thereby achieving fine-grained control of network resources and flexible scheduling of traffic paths.

[0065] The specific implementation process includes: (1) Path intent conversion. The network administrator defines path constraints according to business requirements, including latency limits, bandwidth requirements, path priorities, etc. The processor calculates the optimal path that meets the path constraints based on the network topology and link status, and converts the optimal path into a segment list. The segment list consists of a string of segment identifiers (SIDs) in IPv6 address format. Each SID corresponds to a forwarding instruction of a node or link in the network.

[0066] (2) Perform message path encapsulation.

[0067] When service traffic enters the network ingress node, which is the starting point of the path, the ingress node will insert an SRH segment routing header into the IPv6 packet header according to the SRv6 TEPolicy, write the segment list into the SRH, and set the remaining segment number (Segment Left) to the total number of SIDs in the segment list.

[0068] (3) Segment-by-segment forwarding execution. During the transmission process, each time the message passes through a network node, the node will read the remaining number of segments in the SRH and the SID to be executed. 1) Execute the forwarding action corresponding to the SID (such as forwarding to the next node); 2) Decrement the remaining number of segments by 1; 3) When the remaining number of segments is 0, forward the message to the final destination address.

[0069] The following example illustrates this point. Figure 1 As shown, there are a total of 4 nodes: A, B, C, and D. Each node has an IPv6 address and an SRv6 SID.

[0070] Node A (Headend): Loopback interface: A:1:11::1 / 128, End Segment Identifier (End SID): A:1:1::1, Node A is the starting point of the SRv6 TE Policy and is responsible for encapsulating and initiating traffic.

[0071] Nodes B and C (intermediate nodes): End SID: B: A:1:2::1, C: A:1:3::1.

[0072] Node D (Endpoint): Loopback interface: A:1:44::1 / 128, End SID: A:1:4::1, Node D is the endpoint of the SRv6 TE Policy.

[0073] Main parameters:

[0074] Endpoint: A:1:44::1, this is the final destination of the policy, i.e., the address of node D.

[0075] Segment List: (A:1:2::1, A:1:3::1, A:1:4::1). Defines the path that traffic must take: A → B → C → D, where each segment is the End SID of the corresponding node.

[0076] Binding Segment Identifier (BSID): AAAA:1:1::100, a locally valid SID (AAAA:1::100). Other traffic sent to this address will be introduced into this policy.

[0077] Reverse BSID: AAAA:1:4::100.

[0078] Packet forwarding process: Step 1: When traffic matches the Policy, A performs SRv6 encapsulation: Outer IPv6 header: Destination address: A:1:2::1 (first SID of segment list, end SID of B), SRH (segment routing header): Segment list: [A:1:2::1, A:1:3::1, A:1:4::1], Segments Left: 2, Inner packet: Destination address: A1:44::1 (address of D).

[0079] Step 2: Node B processes the data packet. When B receives the data packet with a destination address of A1:2::1, it recognizes that this is its own End SID and performs the End operation, including: decrementing Segments Left by 1 (making it 1), and updating the outer destination address to the next SID: A:1:3::1 (C's End SID), and then forwarding the data packet to C.

[0080] Step 3: Node C processes the data packet. C receives the data packet with a destination address of A:1:3::1, performs the End operation: decrements SegmentsLeft by 1 (becoming 0), updates the outer destination address to the last SID: A:1:4::1 (D's End SID), and forwards the data packet to D.

[0081] Step 4: Node D processes (tail end). D receives a data packet with a destination address of A:1:4::1 and performs an End operation (Segments Left=0), which includes: removing the SRH and outer IPv6 header, exposing the inner original data packet (destination address A:1:44::1).

[0082] For traffic forwarding services, the SID corresponding to node D (tail node) is usually the End SID, specifically END.XSID. The End.X SID is used in the segment list to indicate the next processing step of the traffic after decapsulation. For example, after removing the SRH and outer IPv6 header, node D will forward the decapsulated inner original data packet (destination address A:1:44::1) according to the instructions defined by the End.X SID.

[0083] It should be noted that the construction of the backhaul message in the probe and backhaul service involved in this application differs from the traffic forwarding process described above. When constructing the BFD backhaul message, the segment list of its SRH is intended to guide the message back along the original path, therefore it is not necessary to specify an End.X SID to indicate subsequent service forwarding actions.

[0084] The process from D to A is the same as the process from A to D, so it will not be repeated here.

[0085] Due to its flexible deployment, precise path scheduling, high resource utilization, and support for differentiated business needs, it is often used in areas such as operator traffic scheduling, data center interconnection, and deterministic transmission in the industrial internet. For example, in cross-regional data scheduling projects, SRv6 TE Policy can be used to achieve precise scheduling of cross-regional computing network traffic: for real-time services (such as financial transactions) on the computing power demand side, low-latency and high-reliability transmission paths are planned to ensure service response speed; for non-real-time computing power needs (such as backup storage), traffic is guided to be transmitted along high-bandwidth and low-cost computing power node paths, thereby achieving a balanced allocation of cross-regional computing power resources.

[0086] However, before implementing any strategy, its reliability needs to be verified, and SRv6 TE Policy is no exception, especially the connectivity of the paths. Existing hardware-based testing solutions suffer from high costs, low efficiency, and poor scenario adaptability, failing to meet the large-scale and diverse testing needs of SRv6 TE Policy. Therefore, a lightweight and highly flexible testing solution is urgently needed.

[0087] like Figure 2 As shown, this application proposes a test system, including: a device under test 201 and a test device 202. The device under test 201 and the test device 202 are communicatively connected.

[0088] The device under test (DUT) 201 and the testing device 202 are directly connected via a communication link. One end of the communication link is connected to a port of the DUT 201, and the other end is connected to a port of the testing device 202. The communication link can be a fiber optic link or an Ethernet link; no specific restrictions are imposed here.

[0089] In some embodiments, the test device 202 simulates multiple virtual nodes supporting SRv6, which correspond to forwarding nodes in a real network, generates virtual topology data and path information, and sends the virtual topology data and path information to the device under test 201. Then, the test device 202 receives probe packets from the device under test, determines the packet encapsulation mode of the return packet based on preset mode configuration information, constructs and sends a return packet carrying the return path, and finally determines the test result based on the status of the device under test 201 receiving the return packet.

[0090] The testing device 202 can be a server equipped with virtualization software (i.e., the testing method in the following embodiments), a dedicated network tester, or other equipment, and no specific restrictions are imposed here.

[0091] The device under test 201 generates and sends a probe message carrying the probe path to the test device 202, receives the return message returned by the test device 202, and cooperates to complete the connectivity test of the SRv6 bidirectional path based on the status of the device under test receiving the return message.

[0092] Among them, the device under test 201 can be a router, switch, gateway or other network forwarding device that supports the SRv6 protocol, and there can be one or more of them, without any specific limit.

[0093] It should be noted that, as Figure 3 As shown, the hardware entity of the test device 202 is the hardware platform shown in the figure. The hardware platform is connected to the device under test 201 through communication links such as network cables and optical fibers. The software implementation logic of the test method is executed based on the software platform shown in the figure.

[0094] For example, in a cross-domain network scenario, the device under test is a router that supports the SRv6 protocol. The testing device can be a network tester, which can simulate multiple edge nodes and intermediate forwarding nodes that support SRv6, thereby constructing a virtual topology for multi-domain interconnection. The network tester sends virtual topology data to the router and probes the path. By switching between IP mode and SRv6 tunnel mode, it verifies the connectivity stability of the bidirectional path, ensuring that cross-domain service traffic can be transmitted stably according to the preset SRv6 TE Policy.

[0095] It should be noted that the above embodiments are only used as examples of data center interconnection scenarios to illustrate the implementation process of the test system of this application, and do not constitute a limitation on this application. The test system of this application can also be applied to various scenarios such as the deployment test of operator SRv6 backbone network, which will not be described one by one here.

[0096] In some embodiments, such as Figure 4 As shown, the testing device may include: a topology simulation module 2021, a tunnel sending module 2022, a packet receiving module 2023, and a packet sending module 2024.

[0097] Among them, the topology simulation module 2021 is used to simulate multiple virtual nodes supporting SRv6, generate virtual topology data, and send the virtual topology data to the tunnel distribution module 2022 and the device under test 201.

[0098] The tunnel delivery module 2022 is used to generate path information based on virtual topology data and user detection requirements, and send the path information to the device under test 201. After receiving the path information, the device under test 201 generates a detection message based on the path information and virtual topology data.

[0099] The receiving module 2023 is used to receive probe packets, process the probe packets, and send the processed probe packets to the sending module 2024.

[0100] The packet sending module 2024 is used to generate a return message based on the processed probe message and the message encapsulation mode represented by the mode configuration information, and send the return message to the device under test 201.

[0101] In some embodiments, the above modules can be implemented in software, hardware, or a combination of both, and this application is not limited to this. Generally, if the speed requirement is sufficient, software implementation can be used, which is cheaper and more flexible; if the speed requirement is higher, hardware implementation can be used.

[0102] In this application, "implemented through software" means that the processor reads and executes program instructions stored in memory to implement the functions corresponding to the aforementioned modules or units. Here, the processor refers to a processing circuit capable of executing program instructions, including but not limited to at least one of the following: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, etc., and other processing circuits capable of running program instructions. In other embodiments, the processor may also include circuits with other processing functions (such as hardware circuits for hardware acceleration, bus and interface circuits, etc.). The processor can be presented as an integrated chip, for example, as an integrated chip whose processing function only includes executing software instructions, or it can also be presented as a SoC (system on a chip), that is, on a single chip, in addition to the processing circuit capable of running program instructions (usually referred to as the "core"), it also includes other hardware circuits for implementing specific functions (of course, these hardware circuits can also be implemented separately based on ASIC or FPGA). Correspondingly, the processing functions, in addition to executing software instructions, may also include various hardware acceleration functions (such as AI calculation, encoding / decoding, compression / decompression, etc.).

[0103] In this application, "implemented in hardware" means that the functions of the above-mentioned modules or units are implemented through hardware processing circuits that do not have program instruction processing capabilities. These hardware processing circuits can be composed of discrete hardware components or integrated circuits. To reduce power consumption and size, integrated circuits are typically used. Hardware processing circuits can include ASICs (application-specific integrated circuits) or PLDs (programmable logic devices); PLDs can include FPGAs (field-programmable gate arrays), CPLDs (complex programmable logic devices), and so on. These hardware processing circuits can be a single packaged semiconductor chip (e.g., packaged as an ASIC); or they can be integrated with other circuits (e.g., CPUs, DSPs) and packaged into a single semiconductor chip. For example, multiple hardware circuits and a CPU can be formed on a silicon substrate and packaged into a single chip; this type of chip is also called a SoC. Alternatively, circuits for implementing FPGA functions and a CPU can be formed on a silicon substrate and encapsulated into a single chip; this type of chip is also called a SoPC (system on a programmable chip).

[0104] When this application is implemented through software, hardware, or a combination of both, different software and hardware can be used, and it is not limited to using only one type of software or hardware. For example, one module or unit can be implemented using a CPU, while another module or unit can be implemented using a DSP. Similarly, when implemented using hardware, one module or unit can be implemented using an ASIC, while another module or unit can be implemented using an FPGA. Of course, it is not limited to using the same software (e.g., all through a CPU) or the same hardware (e.g., all through an ASIC) to implement some or all modules or units. Furthermore, those skilled in the art will understand that software is generally more flexible but less performant than hardware, while hardware is the opposite. Therefore, those skilled in the art can choose software, hardware, or a combination of both based on actual needs.

[0105] In some embodiments, such as Figure 5 As shown, the device under test 201 includes a first port 2011, and the test device 202 includes a second port 2111 and a processor 2112, wherein the processor 2112 includes multiple CPU cores 21121.

[0106] The device under test 201 and the test device 202 are directly connected through a communication link. One end of the communication link is connected to the first port 2011, and the other end of the communication link is connected to the second port 2111.

[0107] In some embodiments, one or more target CPU cores among the multiple CPU cores are used only for the maintenance of Bidirectional Forwarding Detection (BFD) sessions and the processing of BFD packets, thereby achieving computational isolation of BFD-related services and avoiding resource contention with other test tasks.

[0108] During communication between the device under test (DUT) and the testing device, path connectivity detection is based on the BFD protocol. That is, the probe message sent by the DUT to the testing device is actually a BFD message with an SRH header. Due to the low detection latency of BFD, path connectivity detection can quickly detect interruptions or anomalies in the path link, significantly shortening the detection cycle and ensuring the timeliness and accuracy of the test results.

[0109] However, while the test device simulates multiple virtual nodes, it needs to handle a large number of message parsing and path calculation tasks. If BFD message processing shares a CPU core with other tasks, it is prone to delays in BFD message processing due to computing power contention and frequent CPU core switching, failing to achieve the low latency goal intended by this application using the BFD protocol. Therefore, this application proposes a core-binding mechanism, which forcibly binds BFD-related services to one or more designated CPU cores, allocating dedicated computing power resources to them. This achieves physical computing power isolation between BFD services and other test tasks, eliminates the overhead of inter-core switching and computing power contention, and ensures the low latency characteristics of BFD message processing.

[0110] As one possible implementation, upon startup of the test device, one or more dedicated CPU cores are allocated from multiple CPU cores and marked as target CPU cores through firmware configuration or system software presets. Other non-BFD tasks are prohibited from occupying these kernel resources. The target CPU core is then bound to a BFD process. The BFD process is used to maintain the BFD session lifecycle, handle the reception, parsing, and response generation of BFD packets, execute SRv6 path connectivity detection logic, etc. One target CPU core corresponds to one BFD process, and all services within a BFD process are processed by the corresponding target CPU core.

[0111] The number of target CPU cores can be determined based on the number of the first ports of the device under test (DUT). The first ports refer to all available physical communication ports on the DUT, all of which support SRv6 and BFD protocols and can independently establish wired communication links with the test device to conduct SRv6 path connectivity tests.

[0112] It is understandable that there is a one-to-one mapping relationship between the first port of the device under test, the BFD process of the test device, and the target CPU core: each first port corresponds to an independent BFD process, and this BFD process is uniquely bound to a target CPU core. Based on this mapping relationship, all BFD sessions and related message processing tasks under a first port (including parsing probe messages, constructing return messages, maintaining session state, etc.) will be uniformly scheduled by the corresponding BFD process and completely handed over to the target CPU core bound to the process for independent processing. There will be no competition for computing power with BFD tasks or non-BFD test tasks of other ports, ensuring low latency for single-port BFD service processing.

[0113] In some embodiments, the testing apparatus further includes a forwarding unit.

[0114] In some embodiments, the forwarding unit is configured to parse the received probe packets to obtain the characteristic parameters corresponding to the probe packets, and then guide the probe packets to the corresponding BFD process for further processing based on the parsing results. Specifically, the forwarding unit parses the probe packets, extracts the SRH header, the type field of the BFD protocol, or the UDP port number from the packets, matches these characteristic parameters with preset BFD service identification rules, and determines whether the probe packets belong to BFD-related SRv6 test packets. If the match is successful, the probe packets are submitted to the BFD process that has been pre-bound to the target CPU core, and the BFD process processes the probe packets on the corresponding target CPU core.

[0115] The forwarding unit can be implemented using software, hardware, or a combination of both. Since its forwarding function is relatively simple, it is typically implemented using hardware processing circuitry. For example, see again... Figure 5 The forwarding unit is a hardware processing circuit 2113, which can be a programmable logic device (such as an FPGA) and can guarantee processing speed. Of course, this application does not limit other implementation methods and does not impose specific restrictions here.

[0116] In some embodiments, the testing method of this application can be applied to the testing apparatus of the above-described testing system.

[0117] Based on the above embodiments, such as Figure 6 As shown, this application provides a testing method, including the following steps:

[0118] S601. In response to receiving a probe message from the device under test, determine the message encapsulation mode of the return message based on the mode configuration information.

[0119] The probe message carries a probe path, with the starting point of the probe path being the device under test; the intermediate and ending points of the probe path are nodes among multiple virtual nodes that support SRv6.

[0120] The mode configuration information is a set of parameters pre-set by the user in the testing device, including test scenario type, message transmission requirements, encapsulation mode, etc. In one implementation, the mode configuration information can be automatically determined by manually inputting test requirement parameters or by matching test requirements based on the nodes simulated by the testing device. For example, testers input parameters based on test requirements through the testing device's human-machine interface (such as a command-line interface), such as the test scenario being industrial internet deterministic transmission test and the message encapsulation mode being tunnel mode. The system can then generate the corresponding mode configuration information based on the input. Another example is that the testing device has a built-in mode configuration information library, which can automatically match mode configuration information based on the test task and preset matching rules. The configuration library automatically matches tunnel mode; when the test task only requires basic connectivity verification, the configuration library matches IP mode.

[0121] The message encapsulation modes include: IP mode and one or more tunnel modes; when the message encapsulation mode is IP mode, the return message is transmitted through routing; when the message encapsulation mode is one or more tunnel modes, the return message is transmitted through a preset tunnel.

[0122] As one possible implementation, the mode configuration information includes: message encapsulation mode. By reading the message encapsulation mode field that is pre-set in the mode configuration information, the message encapsulation mode of the return message can be obtained.

[0123] It should be understood that if the test scenario is a standard IPv6 network connectivity verification, the IP mode is sufficient to meet the requirements, with low packet overhead and high processing efficiency. However, if the test scenario is an SRv6 tunnel service verification (such as tunnel transmission in cross-regional computing power scheduling), then the tunnel mode must be used to simulate real tunnel forwarding logic. Therefore, it is necessary to select the encapsulation mode based on the preset mode configuration information to ensure that the test scenario is consistent with the real deployment scenario and improve the validity of the test results.

[0124] As one possible implementation, the test device and the device under test establish communication through a bidirectional forwarding detection BFD session, so that probe messages and return messages are transmitted based on the BFD protocol.

[0125] BFD is a lightweight, general-purpose network layer bidirectional forwarding detection protocol designed for quickly detecting connectivity failures in communication paths between network devices. Its working logic is as follows: both parties establish a BFD session on the path to be detected, maintaining the session state by periodically exchanging BFD probe packets. If one party does not receive a packet from the other end within a preset timeout period, it can quickly determine that there is a connectivity failure in the current bidirectional forwarding path.

[0126] It should be understood that BFD sessions support millisecond-level message interaction cycles and timeout determination mechanisms. This application uses BFD sessions for communication, which can significantly shorten the detection latency of path connectivity and improve detection efficiency.

[0127] S602. Based on the message encapsulation mode, construct and send a return message to the device under test.

[0128] The return message carries the return path, the destination of which is the device under test, and the start and middle points of the return path are nodes among multiple virtual nodes that support SRv6.

[0129] It should be understood that the return path and the probe path can be symmetrical or asymmetrical. When symmetrical, the node sequences of the two are completely reversed and the number of hops is the same. When asymmetrical, the node composition or the number of hops of the two differs. For example, the probe path is Device under Test → Virtual Node V1 → Virtual Node V3 (2 hops), while the return path is Virtual Node V3 → Virtual Node V2 → Virtual Node V1 → Device under Test (3 hops).

[0130] As one possible implementation, one or more tunneling modes include insert tunneling mode and encapsulation tunneling mode. Specifically, in insert tunneling mode, an SRH corresponding to the return path is inserted before the original segment routing header (SRH) of the probe packet to obtain a return packet; or, in encapsulation tunneling mode, an outer IPv6 header containing the return SRH is added before the IPv6 header of the probe packet to obtain a return packet; or, in IP encapsulation mode, the SRH in the probe packet is removed, and the destination address in the probe packet is modified to the source address of the probe packet to obtain a return packet.

[0131] For example, assume the probe packet includes the following information: the probe path is the device under test (source IP: 10::1, SID1: A:1:1::1) → virtual node V1 (SID2: A:1:2::1) → virtual node V2 (SID3: A:1:3::1) → virtual node V3 (SID4: A:1:4::1, destination IP: 10::4), the original packet carries an SRH header with the content [SID2, SID3, SID4], and the remaining number of segments = 3.

[0132] (1) Insert tunnel mode

[0133] After parsing the probe packet, the test device generates an SRH header corresponding to the return path, containing [SID3, SID2, SID1], with 3 remaining segments. This return SRH header is then inserted directly before the original SRH header of the probe packet, forming a double SRH header structure. The core structure of the final return packet is: IPv6 header + return SRH [SID3, SID2, SID1] + original SRH [SID2, SID3, SID4] + payload. During packet transmission, the preceding return SRH instruction is executed first, and the packet is forwarded along the path V3→V2→V1→DUT.

[0134] Among them, the remaining number of segments in the original SRH needs to be set to 1.

[0135] (2) Encapsulated tunnel mode

[0136] The testing device retains the complete structure of the probe packet (IPv6 header + original SRH + payload), and adds an IPv6 header on the outer layer. This outer IPv6 header carries the SRH header for the return path, with the content [SID3, SID2, SID1]. The remaining segment count is 3. The source IP of the outer IPv6 header is the IP of the V4 version (10::4), and the destination IP is the IP of the device under test (10::1). The core structure of the final return packet is: outer IPv6 header + return SRH [SID3, SID2, SID1] + inner probe packet complete structure.

[0137] In the inner probe message, the Segment Left in the IPv6 header needs to point to SRH[0], that is, set the SL value to 0, and point the destination IP in this IPv6 header to the address of SRH[0]. This address is the interface address of the device under test.

[0138] (3) IP mode

[0139] The testing device removes the original SRH header from the probe packet, modifies the destination IPv6 address of the packet to the IP address of the device under test (10::1), and modifies the source IPv6 address to the IP address of the V4 device (10::4), leaving other data unchanged. The core structure of the final return packet is: IPv6 header (source 10::4, destination 10::1) + payload. The packet does not rely on SRv6 segment routing instructions and completes the return transmission directly based on the network routing table.

[0140] S603. Determine the test result based on whether the device under test successfully received the return message.

[0141] The test results include the connectivity of the probe path and the return path.

[0142] As one possible implementation, successfully receiving a return message within a preset time threshold indicates that both the probe path and the return path are in a bidirectional connectivity state. If the device under test does not receive a return message within the preset time, it indicates that both the probe path and / or the return path are faulty.

[0143] For example, assuming a preset time threshold of 10ms, the probe path is Device Under Test → Virtual Node V1 → V2, the return path is V2 → V1 → Device Under Test, and the encapsulation mode is tunnel mode. If the Device Under Test receives the return message within 10ms, the probe path and return path are considered to be bidirectionally connected, and the test passes. If the Device Under Test fails to receive the message, the path is considered to be abnormal, and the test fails.

[0144] Understandably, the testing device and the device under test establish communication through a bidirectional forwarding detection (BFD) session, enabling probe and return packets to be transmitted based on the BFD protocol. Due to the low latency and high packet transmission frequency of BFD, it sends out a high frequency of probe packets in a short period of time. By using the successful receipt of a return packet within a preset time threshold as a criterion, it can quickly detect forwarding anomalies and improve the reliability and accuracy of connectivity determination for the probe and return paths.

[0145] Therefore, the test device communicates with the device under test. By simulating multiple virtual nodes that support SRv6 using the test device, a large number of SRv6-supporting hardware devices are not required. This reduces hardware costs and simplifies the network topology setup process, thereby greatly improving test efficiency.

[0146] When testing with the aforementioned testing device, the device under test (DUT) sends probe messages to the testing device. Upon receiving the probe messages, the testing device determines the message encapsulation mode of the return message based on the mode configuration information, constructs the return message according to the message encapsulation mode, and sends the return message to the DUT. The connectivity between the probe path and the return path is determined by monitoring whether the DUT receives the return message. The intermediate and final points of the probe path, as well as the starting and intermediate points of the return path, all utilize virtual nodes on the testing device. This not only eliminates the additional overhead of deploying hardware and improves testing efficiency, but also allows for simultaneous verification of the connectivity between the probe path and the return path through a single interaction of probe and return messages, ensuring that the test results comprehensively cover the bidirectional traffic transmission link.

[0147] Messages are encapsulated according to different message encapsulation modes. In IP mode, return messages are transmitted via routing; in one or more tunnel modes, return messages are transmitted through a preset tunnel. This approach allows for differentiated selection and flexible adaptation of message encapsulation modes, meeting the diverse needs of various SRv6 testing scenarios and thus improving the flexibility of the testing method.

[0148] In summary, the testing method proposed in this application replaces hardware deployment with virtual node simulation, verifies bidirectional paths through single-interaction, and flexibly adapts to multiple encapsulation modes. This significantly reduces the hardware cost and topology construction complexity of SRv6 path testing while maintaining both testing flexibility and efficiency.

[0149] For example, the probe message includes information such as: Segments Left, Last Entry, Segment List, ReverseBSID, probe count, BFD session identifier, probe interval, etc.

[0150] The details are as follows:

[0151] / / SRH Header

[0152] Next Header: UDP (17)

[0153] Length: 12

[0154] [Length: 104 bytes]

[0155] Type: Segment Routing (4)

[0156] Segments Left: 5

[0157] Last Entry: 5

[0158] Flags: 0x02

[0159] Tag: 0000

[0160] Address[0]: 100::1

[0161] Address[1]: aaaa:1:1:4::100

[0162] Address[2]: aaaa:1:1:4::1

[0163] Address[3]: aaaa:1:1:3::1

[0164] Address[4]: aaaa:1:1:2::1

[0165] Address[5]: aaaa:1:1:1::1

[0166] / / BFD related parameters

[0167] Detect Time Multiplier: 3 (= 30 ms Detection time) / / Number of detections

[0168] My Discriminator: 0x00004add / / BFD session identifier

[0169] Your Discriminator: 0x00004add / / BFD session identifier

[0170] Desired Min TX Interval: 10 ms (10000 us) / / Probe interval

[0171] Required Min RX Interval: 10 ms (10000 us) / / Probe interval

[0172] Required Min Echo Interval: 10 ms (10000 us) / / Probe interval

[0173] In the above message, Segments Left is 5 and Last Entry is 5, indicating that the maximum index value in the Segment List is 5. The Segment List is the content corresponding to Address[0]-Address[5], where Address[1] is ReverseBSID.

[0174] Since probe and return packets are transmitted based on the BFD protocol, the probe packet also includes relevant BFD parameters and a BFD session identifier. When multiple BFD sessions exist, the BFD session identifier is used to distinguish between them. The probe count is 3, and the probe interval is 10ms.

[0175] Timeout duration = Number of probes The detection interval means that if no message (return message) is received from the peer within this distance (timeout period) for 30ms, the BFD session will be set to down, indicating that there is an abnormality in the path and the test fails.

[0176] In Insert mode, an SRH (Search Engine Response) is inserted into the IPv6 header of the probe packet, as shown in the box in the diagram. When inserting the SRH, the user needs to configure parameters such as Segment List and Segments Left. When the starting position of Segment List is 2022:2022:1::1, Segments Left is automatically filled with 0. The specific content of the return packet in Insert mode can be as follows:

[0177] / / First SRH

[0178] Routing Header for IPv6 (Segment Routing)

[0179] Next Header: Routing Header for IPv6 (43)

[0180] Length: 8

[0181] [Length: 72 bytes]

[0182] Type: Segment Routing (4)

[0183] Segments Left: 0

[0184] Last Entry: 3

[0185] Flags: 0x00

[0186] Tag: 0000

[0187] Address[0]: 2022:2022:1::1

[0188] Address[1]: 2022:2022:1:1::1

[0189] Address[2]: 2022:2022:1:2::1

[0190] Address[3]: 2022:2022:1:3::1

[0191] / / Second SRH

[0192] Routing Header for IPv6 (Segment Routing)

[0193] Next Header: UDP (17)

[0194] Length: 12

[0195] [Length: 104 bytes]

[0196] Type: Segment Routing (4)

[0197] Segments Left: 1

[0198] Last Entry: 5

[0199] Flags: 0x00

[0200] Tag: 0000

[0201] Address[0]: 100::1

[0202] Address[1]: aaaa:1:1:4::100

[0203] Address[2]: aaaa:1:1:4::1

[0204] Address[3]: aaaa:1:1:3::1

[0205] Address[4]: aaaa:1:1:2::1

[0206] Address[5]: aaaa:1:1:1::1

[0207] It should be noted that the return path is 2022:2022:1::1-2022:2022:2::1-2022:2022:3::1, where 2022:2022:1::1 is the SID value of the device under test. This means that users need to ensure that the last SID value is their own during configuration in order to process this return packet. When simulating the packet sending behavior of the node 2022:2022:1::1, the segment list should be configured with the starting position of 2022:2022:1::1, and segments left=0.

[0208] In Encap mode, an IPv6 header is added to its outer layer.

[0209] The specific content of the return message can be as follows:

[0210] / / First IPv6 header

[0211] Internet Protocol Version 6, Src: aaaa:1:1:4::1, Dst: 2022:2022:1::1

[0212] 0110 .... = Version: 6

[0213] .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP:CS0, ECN: Not-ECT)

[0214] .... 0000 0000 0000 0110 0000 = Flow Label: 0x00060

[0215] Payload Length: 248

[0216] Next Header: Routing Header for IPv6 (43)

[0217] Hop Limit: 255

[0218] Source Address: aaaa:1:1:4::1

[0219] Destination Address: 2022:2022:1::1

[0220] [Stream index: 0]

[0221] Routing Header for IPv6 (Segment Routing)

[0222] Next Header: IPv6 (41)

[0223] Length: 8

[0224] [Length: 72 bytes]

[0225] Type: Segment Routing (4)

[0226] Segments Left: 0

[0227] Last Entry: 3

[0228] Flags: 0x00

[0229] Tag: 0000

[0230] Address[0]: 2022:2022:1::1

[0231] Address[1]: 2022:2022:1:1::1

[0232] Address[2]: 2022:2022:1:2::1

[0233] Address[3]: 2022:2022:1:3::1

[0234] / / Second IPv6 packet header

[0235] Internet Protocol Version 6, Src: 100::1, Dst: 100::1

[0236] 0110.... = Version: 6

[0237] .... 0000 0000.... .... .... .... .... = Traffic Class: 0x00 (DSCP:CS0, ECN: Not-ECT)

[0238] .... 0000 0000 0000 0110 0000 = Flow Label: 0x00060

[0239] Payload Length: 136

[0240] Next Header: Routing Header for IPv6 (43)

[0241] Hop Limit: 255

[0242] Source Address: 100::1

[0243] Destination Address: 100::1

[0244] [Stream index: 1]

[0245] Routing Header for IPv6 (Segment Routing)

[0246] In IP mode, the original SRH header in the probe message needs to be removed.

[0247] The specific content of the return message can be as follows:

[0248] Internet Protocol Version 6, Src: 100::1, Dst: 100::1

[0249] 0110 .... = Version: 6

[0250] .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP:CS0, ECN: Not-ECT)

[0251] .... 0000 0000 0000 0110 0000 = Flow Label: 0x00060

[0252] Payload Length: 32

[0253] Next Header: UDP (17)

[0254] Hop Limit: 255

[0255] Source Address: 100::1

[0256] Destination Address: 100::1

[0257] [Stream index: 0]

[0258] User Datagram Protocol, Src Port: 4784, Dst Port: 4784

[0259] Source Port: 4784

[0260] Destination Port: 4784

[0261] Length: 32

[0262] Checksum: 0xa881 [unverified]

[0263] [Checksum Status: Unverified]

[0264] [Stream index: 0]

[0265] [Stream Packet Number: 1]

[0266] [Timestamps]

[0267] UDP payload (24 bytes)

[0268] In some embodiments, the return message includes: the number of remaining segments, which represents the number of SRv6-supporting virtual nodes remaining to be traversed in the return message; wherein the number of remaining segments is determined by return parameter configuration information.

[0269] It should be understood that the value of this field is not a fixed preset, but is calculated and generated by the test device based on the return parameter configuration information.

[0270] In one implementation, the user can manually input return path parameter configuration information in the display interface of the test device. Based on the starting virtual node of the return path in the return path parameter configuration information, the test device will automatically count the total number of virtual nodes in the path according to the complete path from the selected starting node to the device under test, use this value as the initial value of the remaining number of segments, and fill it into the SRH header of the return message.

[0271] Therefore, by setting the number of remaining segments, the hop-by-hop forwarding logic of return packets can be precisely controlled, flexibly simulating packet forwarding scenarios at different locations in a real network.

[0272] In some embodiments, the return message may further include a list of return path segments.

[0273] The Segment List is a collection of SIDs stored in the SRH header. Each SID corresponds to a virtual node supporting SRv6, and the list order strictly follows the forwarding order of the return packets. The Segment List can also be determined through return parameter configuration information. In one implementation, the user can manually input return parameter configuration information on the test device's display interface: according to the test requirements, the user selects the SIDs of each node in the order of starting virtual node → intermediate virtual node → device under test. The system then integrates these SIDs into a Segment List according to the input order and writes it into the SRH header of the return packet.

[0274] For example, such as Figure 7As shown, the Segment List configuration structure of the return path is as follows, including: a:1:4::1, a:1:3::1, a:1:2::1, with the index increasing from 0. Assuming that the forwarding node represented by the SID value a:1:3::1 is specified as the starting position of the return packet, the Segments Left value in the SRH of the return packet will be automatically filled with 1. The simulation is based on the packet sent from the second-to-last hop forwarding node.

[0275] It should be understood that the core function of the return path segment list is to provide the address sequence for packet forwarding, which, together with the remaining segment left, ensures that packets are transmitted strictly according to the preset path.

[0276] In some embodiments, after receiving a backhaul packet, the device under test reads the backhaul path segment list, remaining segments (SL), Last Entry identifier, and other control flags from the SRH header, and performs the backhaul packet validity verification and forwarding processing according to the following logic:

[0277] (1) First, verify the validity of the SRH header of the return message: Combine the return path segment list, SL value and LastEntry identifier (used to mark how many hops the return path has taken) to determine whether the three match. If the three match, the return message is considered valid.

[0278] (2) If the verification is valid, the SL value obtained by the device under test is further checked to see if it is 0. If the SL value is 0, it indicates that the return message has gone through all virtual nodes in the return path and the destination is the device under test itself. At this time, the device under test will parse the BFD service header of the message and check whether the message is the return response corresponding to the probe message it previously sent. If the match is successful, it is determined that the probe path and the return path form a complete loop and the path connectivity is normal. If the match fails, it is determined that there is a fault in the intermediate link of the path.

[0279] (3) If the SL value is not 0, it indicates that the return packet still needs to be forwarded. The device under test will first decrement the SL value by 1, then query the list of return path segments, and obtain the SID of the next hop virtual node according to the index corresponding to the SL value. If the next hop SID can be successfully matched and the forwarding conditions are met, the packet will be forwarded to the corresponding node. If the next hop information cannot be obtained or the forwarding conditions are not met, the packet will be discarded directly.

[0280] (4) If the return message in (1) is invalid, it is judged as an erroneous message and discarded directly.

[0281] In some embodiments, the probe message further includes: a first reverse binding identifier; the first reverse binding identifier indicates that it is used to bind a return path. S602 includes: if the first reverse binding identifier is consistent with a preset reverse binding identifier, constructing and sending a return message to the device under test based on the message encapsulation mode; the preset reverse binding identifier is configured by the test device when establishing a BFD session.

[0282] The first reverse binding identifier is essentially a parameter written to a specified position in the SRH header of the probe packet by the device under test (DUT) based on its own backhaul mode configuration. It identifies the expected backhaul processing mode for this probe packet. The preset reverse binding identifier is essentially a backhaul mode matching benchmark pre-set by the test device for the current BFD session, representing the parameters corresponding to the backhaul processing modes supported by this session. Only when the first reverse binding identifier in the probe packet matches this benchmark is it considered that the backhaul mode requirement of the probe packet is compatible with the configuration of this session.

[0283] When constructing a BFD probe message, the device under test will fill the first reverse binding identifier into the SRH[1] position in the probe message. As a possible implementation, the first reverse binding identifier of the second segment position (SRH[1]) of the SRH header in the probe message is extracted, and the identifier is compared with the preset reverse binding identifier configured by the test device when establishing the BFD session. If the two are consistent, it is determined that the return mode configuration matches the packet receiving structure, and the return message is constructed and sent based on the packet encapsulation mode. If the two are inconsistent, the S402 process is terminated directly without any response.

[0284] For example, assume that the test device configures the preset reverse binding identifier for the current BFD session as 2001:db8:1::100, and the specified verification position is the second position of the SRH header (i.e., SRH[1]). If the segment list of the SRH header in the probe message sent by the device under test is [2001:db8:1::200, 2001:db8:1::100, 2001:db8:1::300], where the first reverse binding identifier at the SRH[1] position is 2001:db8:1::100, which is completely consistent with the preset reverse binding identifier. The test device determines that the return mode configuration matches the packet receiving structure, and then constructs the return message according to the preset encapsulation mode.

[0285] It should be understood that when the device under test constructs a BFD probe message, it will fill the first reverse binding identifier into the SRH[1] position in the probe message. After receiving the probe message, the test device will parse the value of the SRH[1] position. If the value of the SRH[1] position is inconsistent with the value configured in the local BFD session, it will be determined that the return mode configuration and the packet receiving structure do not match. It may be that the probe message has taken the wrong path or the configuration is incorrect. At this time, the test device will not respond, thereby avoiding invalid return messages from interfering with the test.

[0286] like Figure 8 As shown, the content of this embodiment corresponds to the packet sending module of the aforementioned test device. After packet sending begins, the return mode configured by the test device is first determined, and then return packets are encapsulated according to different return modes. Return modes (packet encapsulation modes) include: Insert mode, Encap mode, and IP mode.

[0287] like Figure 9 As shown, if the configured message encapsulation mode is Insert mode, the following process will be executed:

[0288] Determine whether the SRH[1] in the received packet is consistent with the Reverse BSID configured in the BFD process. If they are inconsistent, it means that the return mode configuration does not match the received packet structure and no reply is given. If they are consistent, construct the return packet according to the following rules.

[0289] 1. Use the SRH from the received packet as the inner SRH and set SL to 1, leaving the rest of the received packet content unchanged. 2. Add an outer SRH, constructing the SRH structure based on the configured Segment List and Segments Left. 3. Construct the destination IP as the IP address pointed to by the Segments Left in the outer SRH. 4. The source MAC address is the MAC address of the BFD process interface, and the destination MAC address is the gateway MAC address obtained from that interface. After completing these four steps, the return packet construction is complete.

[0290] like Figure 10 As shown, if the configured message encapsulation mode is Encap mode, the following process is executed:

[0291] Determine whether the SRH[1] in the received packet is consistent with the Reverse BSID configured in the BFD process. If they are inconsistent, it means that the return mode configuration does not match the received packet structure and no reply is given. If they are consistent, construct the return packet according to the following rules.

[0292] 1. Set the Segment Left of the SRH in the received packet to SRH[0], and simultaneously modify the destination IP to the address it points to. The rest of the received packet content remains unchanged. 2. Add an outer IPv6 header and construct the SRH structure according to the configured Segment List and Segments Left. 3. Construct the destination IP of the outer IPv6 header to the IP address pointed to by Segments Left in the SRH, and the source IP to the IP address of the BFD process interface. 4. The source MAC address is the MAC of the BFD process interface, and the destination MAC is the gateway MAC obtained by this interface. After completing these four steps, the return packet construction is complete.

[0293] like Figure 11 As shown, if the configured message encapsulation mode is IP mode, the following process is executed:

[0294] Determine whether the SRH[1] in the received packet is consistent with the interface IP address configured by the BFD process. If they are inconsistent, it means that the return mode configuration does not match the received packet structure and no reply is given. If they are consistent, construct the return packet according to the following rules.

[0295] Remove the SRH from the received packet, fill the destination IP address with the source IP address of the received packet, and leave the rest of the received packet content unchanged. After completing this step, the return packet construction is complete.

[0296] In some embodiments, the communication link between the testing device and the device under test may contain other packets besides the probe packets used for SRv6 path connectivity testing, such as ordinary IPv6 service packets. If these irrelevant packets are mixed into the backhaul packet construction process, it will lead to packet parsing errors. To accurately identify the probe packets corresponding to the current test session and ensure the accuracy of backhaul packet construction and the reliability of the test logic, the probe packets need to be filtered upon receipt. Figure 12 As shown, the above S601 includes:

[0297] S1201. Based on whether the probe packets carry a double-layer IPv6 header, the probe packets are filtered and preprocessed to obtain preprocessed packets.

[0298] The preprocessing includes removing the outer IPv6 header and retaining the inner IPv6 header for probe packets with two IPv6 headers, as preprocessed packets.

[0299] The two-layer IPv6 header is the SRv6 message structure. The outer IPv6 header is the tunnel transport header, used for forwarding messages within the tunnel, while the inner IPv6 header is the service payload header, carrying interface configuration information, SRH header, and other information.

[0300] As one possible implementation, if the probe packet is a double-header packet, the outer IPv6 header is stripped, leaving only the inner IPv6 header, to generate a preprocessed packet. If the probe packet is a single-header packet, no processing is required; the original packet is directly marked as a preprocessed packet.

[0301] It should be understood that the outer header does not contain test-related information. If the double-header message is directly parsed subsequently, the outer header will interfere with the extraction of the SRH header and BFD interface configuration information, causing the filtering logic to fail. Therefore, the message format can be standardized through preprocessing.

[0302] S1202. Based on whether there is an SRH header in the preprocessed message, the preprocessed message is filtered to obtain the first message.

[0303] The first message indicates a preprocessed message containing an SRH header.

[0304] The SRH header, or Segment Routing Header, is a unique header for SRv6 protocol messages, containing information such as the SID list and the number of remaining segments.

[0305] One possible implementation is to parse the IPv6 header of the preprocessed message, check if there is an SRH header identifier, and if there is an SRH header identifier, mark the message as the first message; if there is no SRH header identifier, determine it as a non-SRv6 protocol message.

[0306] It should be understood that in addition to SRv6+BFD messages, ordinary messages may also be mixed in. These messages lack an SRH header and are not involved in path connectivity testing. Allowing them into subsequent processes would interfere with the testing logic. Therefore, it is necessary to filter non-SRv6 protocol messages using SRH header filtering.

[0307] S1203. Based on the matching result of the interface configuration information of the BFD session in the first message and the preset interface configuration information, the first message is filtered to obtain the second message.

[0308] The second message represents the first message that conforms to the preset interface configuration information.

[0309] The interface configuration information for a BFD session consists of the interface parameters carried in the first packet, which are bound to the current BFD session. These parameters indicate the identity of the probe packet, i.e., the BFD session to which the first packet belongs. The preset interface configuration information is the set of parameters configured by the test device when establishing the current BFD session. Only when both are consistent can it be confirmed that the first packet is the target SRv6+BFD probe packet corresponding to the current test session, and not some other interference packet.

[0310] Specifically, the interface configuration information includes: Media Access Control MAC address, Virtual LAN VLAN tag, User Datagram Protocol (UDP) port number or interface IP address.

[0311] MAC address: Used to accurately identify the source physical interface of the packet, ensuring that the second packet comes from the first port specified by the device under test, rather than interference packets from other devices in the same network segment.

[0312] VLAN tag: Used to limit the transmission range of packets, ensuring that the packets to be screened come from the preset test-specific VLAN, and preventing management packets and service packets from crossing VLANs from entering the test process.

[0313] UDP port number: The BFD protocol uses port 3784 for communication by default. The UDP port number can be used to distinguish BFD protocol messages from other UDP service messages.

[0314] Interface IP address: Used to verify whether the source IP address of the packet is the device under test, ensuring that the packet comes from the device under test and not from other network nodes.

[0315] Among them, VLAN tags are optional. In actual testing scenarios, VLAN tags can be flexibly configured or not configured according to the planning and business needs of the network under test.

[0316] As one possible implementation, the interface configuration information in the first packet is extracted: MAC address, VLAN tag, interface IP address, and UDP port number. The extracted information is then compared with the preset interface configuration information item by item. If all configuration items match completely, the packet is marked as the second packet. If any configuration item does not match, the packet is determined to be a packet that is not in the current session and is discarded directly, terminating subsequent processing.

[0317] For example, suppose the default interface configuration information for the current test session is: MAC address: 00:1B:44:11:3A:7D, VLAN tag: 10, interface IP address: 2001:db8:1::1, UDP port number: 3784. The interface configuration information extracted by the test device from the first packet is: MAC address: 00:1B:44:11:3A:7D, VLAN tag: 10, interface IP address: 2001:db8:1::1, destination UDP port number: 3784. After item-by-item comparison, if all configuration items are completely consistent, the first packet is determined to be the target packet of the current test session and marked as the second packet. Conversely, if the extracted VLAN tag is 20 and all other parameters match, due to the existence of configuration item mismatch, the test device determines that the packet is an interference packet not belonging to the current session, discards it directly, and terminates subsequent processing.

[0318] S1204. In response to receiving the probe message corresponding to the second message, determine the message encapsulation mode of the return message based on the mode configuration information.

[0319] Therefore, by preprocessing the probe packets' double-layer IPv6 headers, checking for the presence of an SRH header, and verifying whether the interface configuration information matches the preset interface configuration information, illegal and invalid traffic can be filtered out, ensuring that the test packets are probe packets associated with the current BFD test session.

[0320] For example, the implementation process of S1201-S1204 in the above embodiments corresponds to the packet receiving module of the testing device. Figure 13 As shown, the packet receiving module processes received probe packets and establishes a BFD session process for detecting tunnel connectivity. At the start of packet receiving, establishing the session process requires configuring necessary interface attributes, including but not limited to: MAC address, VLAN tag, UDP port number, and interface IP address. These interface attribute configurations ensure the accuracy of packet reception and parsing.

[0321] The processing flow of the packet receiving module is as follows:

[0322] (1) Check if there are two layers of IPv6 headers. If so, one layer of IPv6 header needs to be stripped. If not, proceed to the next step.

[0323] (2) Receive the message that has been checked and processed in the previous step, check if there is an SRH header. If there is no SRH header, it means that the message is not the target message and no further processing is performed. If there is an SRH header, proceed to the next step.

[0324] (3) Receive the message that has been checked and processed in the previous step, and check whether the destination MAC, VLAN and destination UDP port number are consistent with the BFD process interface attributes. If they are not consistent, it means that the message is not the target message and will not be processed in the next step; if they are consistent, it will be handed over to the packet sending module.

[0325] (4) The package collection process is complete.

[0326] In some embodiments, prior to S601, the method further includes: sending path information of the test device to the device under test, so that the device under test generates a probe message based on the path information.

[0327] The path information includes: the detection path and the first reverse binding identifier, which indicates that it is used to bind the return path.

[0328] This embodiment corresponds to the tunnel delivery module of the test device. This module receives virtual topology data from the topology simulation module and generates path information based on the virtual topology data. This path includes all forwarding nodes of the probe path. The path information delivered to the device under test includes, but is not limited to:

[0329] 1) Endpoint node interface address: used to identify the end point of the probe path.

[0330] 2) Segment List: Composed of the SIDs of the simulation nodes, defining the path forwarding order.

[0331] 3) First Reverse Binding SID (RBSID): Used to guide the Endpoint node in responding to BFD probe messages. When the device under test constructs a probe message, the RBSID value is embedded in the SRH[1] position of the SRH to identify the return path.

[0332] The explanation of RBSID can be found in the description in the above embodiments, and will not be repeated here.

[0333] As one possible implementation, the path information is determined based on user-input configuration information and / or SRv6-based traffic engineering policy information; the SRv6-based traffic engineering policy information is used to guide traffic transmission on the probe path; the SRv6-based traffic engineering policy information includes probe requirements; the probe requirements include: minimizing the number of SRv6-enabled virtual nodes traversed from the start point to the end point of the probe path, and / or minimizing the time taken from the start point to the end point of the probe path.

[0334] For example, such as Figure 14 As shown, DUT represents the device under test, which is the starting point of the probe path. B and C are intermediate forwarding nodes, and D (Endpoint) is the ending point of the probe path. Each node has a corresponding SID. If it is necessary to test the path of DUT-D, the path information includes: (1) Endpoint: A:1:44::1, which is the final destination of the policy, i.e., the address of node D. (2) Segment List: A:1:2::1, A:1:3::1, A:1:4::1. (3) Reverse BSID: AAAA:1:4::100. A:1:11::1 / 128 is the loopback interface of DUT, and A:1:44::1 / 128 is the loopback interface of D.

[0335] In some embodiments, before sending the path information of the test device to the device under test, the method further includes: sending virtual topology data generated by the test device simulation to the device under test, so that the device under test generates a probe message based on the virtual topology data and the path information, wherein the virtual topology data includes graph information between multiple virtual nodes supporting SRv6.

[0336] Graph information represents an abstract virtual network topology based on graph theory models. It abstracts SRv6-enabled virtual nodes as vertices and communication links between nodes as edges. Specifically, graph information includes: connection relationships between nodes (also known as adjacency relationships), node attribute information, and link attribute information.

[0337] The connection relationships between nodes include: which virtual nodes that support SRv6 have direct communication links, for example, virtual nodes V1 and V2 are bidirectionally connected, while virtual node V2 is only unidirectionally connected to V3.

[0338] Node attribute information represents characteristic parameters related to the virtual node itself, including node type, node unique identifier (Node SID), node SRv6 capabilities (whether it supports Segment List forwarding, whether it has Endpointbehavior termination capability), etc.

[0339] Link attribute information includes link bandwidth, transmission latency, etc.

[0340] This embodiment corresponds to the topology simulation module of the test device. This module generates IGP (such as IS-IS, OSPF) protocol configurations to simulate two types of SRv6 nodes: one type is the Endpoint node that serves as the endpoint of the SRv6 TE Policy path, and the other type is the Transit Node that supports SRv6 Segment List forwarding. Simultaneously, this module has a network announcement function, which can proactively announce the SRv6-related identification information of the simulated nodes to the device under test (DUT), allowing the DUT to identify the virtual nodes.

[0341] The generated virtual topology data contains simulated forwarding node information, including basic topology information and SRv6-specific capability identifiers. Basic topology information includes, but is not limited to, nodes, adjacency relationships between nodes, and node routing prefixes. SRv6-specific capability identifiers include, but are not limited to, Node SID, Locator, End SID, and Endpointbehavior, providing a complete path basis for the device under test to generate probe packets.

[0342] Node SID is a unique identifier for a node, used to identify a specific node in the path.

[0343] Locator: The prefix part of the SRv6 address, used to divide the address domain of a node and quickly locate the network segment to which the node belongs.

[0344] End SID: A unique identifier for the Endpoint node, used to mark the end point of a path.

[0345] Endpoint behavior: The forwarding behavior attribute of a node defines the processing logic (such as forwarding, terminating, encapsulation, etc.) after the node receives an SRv6 message.

[0346] For example, such as Figure 15 As shown, there are multiple nodes between the device under test and the tail end, and the topology between the nodes is as follows. Figure 15 As shown. Figure 16 As shown, the device under test is the starting point of the probe path, the nodes within the dashed box are all virtual nodes supporting SRv6 simulated by the topology simulation module, and the tail end is the ending point of the probe path.

[0347] It should be understood that by sending virtual topology data to the device under test, the authenticity of the test results is ensured by ensuring that the probe messages generated by the device under test match the virtual topology of the test device.

[0348] In some embodiments, the number of virtual nodes supporting SRv6, graph information, probe path, first reverse binding identifier, probe message reception and filtering strategy, and remaining segment count are all obtained based on the configuration information entered by the user on the display interface of the test device.

[0349] Therefore, users can customize the input configuration information to specify relevant parameters for the test process. The test device automatically generates corresponding virtual topology data, path information and other parameters based on the configuration information, and then automatically executes the test process, improving the convenience and flexibility of the test plan.

[0350] For example, the display interface of the test device includes: a topology simulation component, a tunnel delivery component, a packet receiving processing component, and a packet sending processing component; the topology simulation component is used to configure the number of virtual nodes supporting SRv6 and graph information; the tunnel delivery component is used to configure the probe path and the first reverse binding identifier; the packet receiving processing component is used to configure the reception and filtering strategy for probe packets; and the packet sending processing component is used to configure the list of return path segments and the number of remaining segments.

[0351] (1) The topology simulation component is used to visualize the configuration of the number of virtual nodes, node attributes and graph information (connection relationship, link attribute, etc.) supporting SRv6, and finally generate virtual topology data and send it to the device under test so that the device under test can perceive the virtual network structure.

[0352] Configuration details: Number of virtual nodes: Total number of SRv6 virtual nodes in the custom simulation. Graph information: Node type, node SID, adjacency relationships between nodes, etc.

[0353] For example, the user enters the number of virtual nodes as 3 in the topology simulation component interface, names them V1, V2, and V3, and then configures the graph information: Node attributes: V1 (Endpoint node, SID: a:1:1::1), V2 (Transit Node, SID: a:1:2::1), V3 (Endpoint node, SID: a:1:3::1); Connection relationship: V1 and V2 are bidirectionally connected, V2 and V3 are bidirectionally connected, and V1 and V3 have no direct connection.

[0354] (2) The tunnel delivery component is used to configure the parameters of the probe messages sent by the device under test based on the virtual topology constructed by the topology simulation component.

[0355] Configuration details: Probe path: Select the virtual nodes configured in the topology and generate a probe path sequence according to the forwarding order; First reverse binding identifier.

[0356] For example, the user selects the probe path: V1→V2→V3 in the tunnel delivery component interface. Then, the first reverse binding identifier is configured.

[0357] (3) Packet receiving processing component is used to configure the filtering strategy after the test device receives probe messages, to ensure that only target probe messages that meet the conditions enter the subsequent processing process, and to filter out irrelevant interference messages.

[0358] Configuration content: Interface configuration information (MAC address, VLAN tag, UDP port number, interface IP); whether to verify the SRH header and whether the first reverse binding identifier is consistent with the preset value.

[0359] For example, users can configure basic filtering conditions in the packet processing component interface: MAC address: 00:1B:44:11:3A:7D; VLAN tag: 10; UDP port number: 3784, etc.

[0360] (4) Packet processing component: used to configure the parameters for the test device to construct return messages.

[0361] Configuration details: List of return path segments, number of remaining segments.

[0362] For example, the user configures the list of return path segments in the packet processing component interface: enter [a:1:3::1, a:1:2::1, a:1:1::1]; specify the starting node of the return message: select a:1:3::1 (V3 node), and the component automatically calculates the number of remaining segments.

[0363] Therefore, the path connectivity test process can be visualized and configured through topology simulation components, tunnel delivery components, packet receiving processing components, and packet sending processing components. Topology construction, probe path and identifier configuration, probe packet filtering strategy configuration, and return packet parameter configuration are all integrated into the visual interface. No professional operation knowledge is required for the process personnel, making the configuration of SRv6 path connectivity test simple and easy to operate.

[0364] In some embodiments, the device under test includes a first port, and the testing device includes a second port and a processor; the first port of the device under test and the second port of the testing device are connected via a communication link, and the processor includes multiple CPU cores.

[0365] like Figure 17 As shown, the above method also includes:

[0366] S1701. Bind the BFD process to a target CPU core among multiple CPU cores, so that a BFD process exclusively occupies the computing resources of a target CPU core.

[0367] The BFD process is used to maintain the BFD session and to receive probe messages and construct and send return messages based on the BFD session.

[0368] As one possible implementation, when the test device starts up, a target CPU core is allocated from the processor's multiple CPU cores through firmware configuration or system software presets, and its resource attributes are marked. This core can only be called by the BFD process. A one-to-one binding strategy is adopted, so that one BFD process exclusively uses the full computing power of one target CPU core, ensuring that there is no situation where multiple processes share core resources.

[0369] In one possible implementation, affinity attribute configuration is performed on the marked target CPU cores: at the operating system kernel level, the scheduling attributes of these target CPU cores are set to allow only bound processes to run, prohibiting scheduling access for unbound processes. A BFD process is created, corresponding one-to-one with the first port of the device under test. Through a system call interface, the CPU affinity mask of the BFD process is set to contain only the corresponding target CPU core ID, forcibly restricting the process to run only on that target CPU core, thereby completing the binding between the BFD process and the target CPU core.

[0370] It should be understood that if BFD message processing shares a CPU core with other tasks, the processing of BFD messages will be delayed due to task switching overhead and computing power preemption, which will prevent the BFD protocol from leveraging its low-latency detection technology advantage. However, by using exclusive binding, such problems can be eliminated, ensuring the low-latency characteristics of BFD services.

[0371] S1702. Based on the target CPU core, run the BFD process to execute the test method.

[0372] It should be understood that the target CPU core being bound only carries all business operations of the corresponding BFD process, including parsing probe packets, verifying reverse binding identifiers, constructing and encapsulating return packets, and sending return packets. Since the target CPU core is not interfered with by other tasks, it only executes the test method in the above embodiments. The execution of the BFD process does not need to wait for the release of computing power, thereby shortening the latency of packet processing and improving the timeliness and accuracy of test results.

[0373] As one possible implementation, in response to receiving a configuration operation from the user on the display interface of the test device, a BFD process is run based on the target CPU core to execute the test method.

[0374] For example, the display interface shows a processor settings component, which displays the text "CPU core binding completed: BFD process 1001 → CPU core 2". A start button is provided on the right side of the processor settings component, which the user clicks to issue the command. In one possible implementation, after the user completes the binding of the BFD process and the target CPU core, they click trigger buttons such as "Start BFD process" or "Start test" in the processor settings component of the test device's display interface, issuing a command to the test device to run the BFD process based on the target CPU core. The BFD process running on the target CPU core loads the preset SRv6 path connectivity test logic and executes the test method.

[0375] Therefore, by triggering the BFD process based on the target CPU core through the user's configuration operation, it is possible to determine whether to run the BFD process based on the target CPU core according to the user's needs, thereby realizing the on-demand allocation of test resources and the on-demand allocation of computing resources of the test device. This ensures the high-performance processing capability of the test device while avoiding the waste of computing resources, thereby improving the flexibility of the test method.

[0376] In some embodiments, the number of first ports is one or more, the number of BFD processes and the number of target CPU cores are the same as the number of first ports, and there is a one-to-one correspondence between the first ports, BFD processes and target CPU cores.

[0377] For example, as shown in Table 1, the processor has a total of 64 CPU cores, including CPU0 to CPU63, and the number of first ports of the device under test is 20, including Port1 to Port20. Therefore, CPU0 to CPU19 are isolated and correspond one-to-one with Port1 to Port20, while the remaining CPU20 to CPU63 run system processes / user processes.

[0378] Table 1

[0379]

[0380] It should be understood that each first port corresponds to an independent BFD process, and this process is uniquely bound to a target CPU core. Based on this mapping relationship, all BFD sessions and message processing tasks under a single first port are completed independently by the corresponding target CPU core, and will not compete for computing power with BFD tasks of other ports, ensuring that the BFD service processing latency of each port can be guaranteed during multi-port parallel testing.

[0381] In some embodiments, the testing apparatus further includes: a hardware processing circuit; before S1702, the above method further includes: the hardware processing circuit parsing the probe message to obtain feature parameters; the feature parameters are used to distinguish whether the probe message is an SRv6 message of a BFD session; the hardware processing circuit distributes the probe message to the corresponding target CPU core for processing based on the feature parameters.

[0382] The hardware processing circuit acts as a "relay station" for message distribution, parsing the received probe messages and extracting characteristic parameters: SRH header (to determine whether it is an SRv6 protocol message), BFD protocol type field (to determine whether it is a BFD protocol message), and UDP port number (to verify protocol attributes).

[0383] As one possible implementation, the hardware processing circuit matches the extracted feature parameters with the preset BFD service identification rules. If the match is successful, the message is determined to be an SRv6 test message of the current BFD session, and then it is distributed to the corresponding BFD process for processing.

[0384] It should be understood that parsing and distributing probe messages through hardware processing circuits can prevent non-BFD messages from entering the target CPU core and consuming computing power, thereby ensuring the low-latency processing capability of the BFD process.

[0385] Figure 18 This is a schematic structural diagram of the test apparatus provided in this application. The test apparatus 202 includes a processor 2112, which is coupled to a memory 12. The memory 12 is used to store computer programs or instructions and / or data. The processor 2112 is used to execute the computer programs or instructions stored in the memory 12, or to read the data stored in the memory 12, in order to perform the method steps executed by the processor above.

[0386] Optionally, there may be one or more processors 2112.

[0387] Optionally, the memory 12 may be one or more.

[0388] Alternatively, the memory 12 can be integrated with the processor 2112, or it can be set separately.

[0389] Optionally, such as Figure 18 As shown, the test apparatus 202 also includes a transceiver 13, which is used for receiving and / or transmitting signals. For example, the processor 2112 is used to control the transceiver 13 to receive and / or transmit signals.

[0390] In addition, this application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the methods in the various method embodiments of this application to be performed.

[0391] This application also provides a computer program product, which includes computer program code or instructions, such that when the computer program code or instructions are run on a computer, the methods in the various method embodiments of this application are executed.

[0392] Furthermore, this application also provides a chip including a processor. A memory for storing a computer program is provided independently of the chip, and the processor is used to execute the computer program stored in the memory to perform the methods in the various method embodiments of this application.

[0393] Furthermore, the chip may also include a communication interface. The communication interface may be an input / output interface or an interface circuit, etc. Furthermore, the chip may also include a memory.

[0394] Optionally, the testing device further includes hardware processing circuitry to implement the method steps performed by the aforementioned forwarding unit.

[0395] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with the ability to process signals. In implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware encoding processor, or by a combination of hardware and software modules in the encoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0396] Given the extremely high latency requirements of BFD services, high-performance hardware is needed to support the high frequency of message processing. Therefore, a processor can be used to ensure the efficient operation of the BFD process. However, the parsing and forwarding of probe messages are relatively simpler compared to maintaining the BFD session process; therefore, hardware processing circuits can be used to improve processing efficiency. For example, a central processing unit (CPU) can be used as the processor, and a field-programmable gate array (FPGA) can be used as the hardware processing circuit.

[0397] The memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), and synchronous link dynamic memory (SLDRAM).

[0398] It should be noted that when the processor is a general-purpose processor, DSP, etc., the memory can be integrated into the processor.

[0399] It should also be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0400] The foregoing preferred embodiments have further illustrated the objectives, technical solutions, and advantages of the present invention. It should be understood that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A test method characterized by, The application is applied to a test device which is connected with a device under test; The test device comprises a plurality of SRv6-enabled virtual nodes; The method comprises: In response to receiving a probe packet from the device under test, determining a packet encapsulation mode of a backhaul packet based on mode configuration information; the backhaul packet comprises a remaining segment number representing a number of SRv6-enabled virtual nodes remaining to be passed through in the backhaul packet; wherein the remaining segment number is determined by backhaul parameter configuration information; The packet encapsulation mode comprises an IP mode, an inserted tunnel mode or an encapsulated tunnel mode; in the case of the IP mode, the backhaul packet is transmitted by routing; in the case of the inserted tunnel mode or the encapsulated tunnel mode, the backhaul packet is transmitted by a preset tunnel; the probe packet carries a probe path, the start point of the probe path being the device under test, and the intermediate point and the end point of the probe path being nodes in the plurality of SRv6-enabled virtual nodes; Based on the packet encapsulation mode, constructing and sending the backhaul packet to the device under test; the backhaul packet carries a backhaul path, the end point of the backhaul path being the device under test, and the start point and the intermediate point of the backhaul path being nodes in the plurality of SRv6-enabled virtual nodes; wherein in the case of the inserted tunnel mode, an SRH corresponding to the backhaul path is inserted before a segment routing header SRH of the probe packet to obtain the backhaul packet; or in the case of the encapsulated tunnel mode, an outer IPv6 packet header containing a backhaul SRH is added before an IPv6 packet header of the probe packet to obtain the backhaul packet; or in the case of the IP mode, the SRH in the probe packet is removed, and the destination address in the probe packet is modified to the source address of the probe packet to obtain the backhaul packet; Based on whether the backhaul packet is successfully received by the device under test, a test result is determined; the test result comprises connectivity of the probe path and the backhaul path.

2. The method of claim 1, wherein, The test device and the device under test are connected by a bidirectional forwarding detection BFD session to enable the probe packet and the backhaul packet to be transmitted based on the BFD protocol.

3. The method of claim 2, wherein, The probe packet further comprises a first reverse binding identifier; the first reverse binding identifier represents a binding for the backhaul path; The constructing and sending the backhaul packet to the device under test based on the packet encapsulation mode comprises: In the case that the first reverse binding identifier is consistent with a preset reverse binding identifier, the constructing and sending the backhaul packet to the device under test based on the packet encapsulation mode; the preset reverse binding identifier is configured by the test device when the BFD session is established.

4. The method of claim 1, wherein, The method further comprises: based on the mode configuration information, determining a packet encapsulation mode of a backhaul packet in response to receiving a probe packet from the device under test; based on whether the probe packet carries a double-layer IPv6 packet header, screening and preprocessing the probe packet to obtain a preprocessed packet; the preprocessing includes: for the probe packet with the double-layer IPv6 packet header, removing the outer IPv6 packet header and retaining the inner IPv6 packet header as the preprocessed packet; based on whether an SRH header exists in the preprocessed packet, screening the preprocessed packet to obtain a first packet; the first packet represents the preprocessed packet with the SRH header; based on a matching result of interface configuration information of a BFD session in the first packet and preset interface configuration information, screening the first packet to obtain a second packet; the second packet represents the first packet that meets the preset interface configuration information; the interface configuration information includes: a media access control (MAC) address, a virtual local area network (VLAN) tag, a user datagram protocol (UDP) port number, or an interface IP address; 5. The method of claim 1, wherein, based on the mode configuration information, determining a packet encapsulation mode of a backhaul packet in response to receiving a probe packet from the device under test. Before the method of determining a packet encapsulation mode of a backhaul packet based on mode configuration information in response to receiving a probe packet from the device under test, the method further comprises: issuing path information of the test device to the device under test, so that the device under test generates the probe packet based on the path information; the path information is determined based on user input configuration information and / or SRv6-based traffic engineering policy information; the SRv6-based traffic engineering policy information is used to guide traffic transmission on the probe path; 6. The method of claim 5, wherein, wherein the path information includes: the probe path, a first reverse binding identifier, and the first reverse binding identifier represents a binding for the backhaul path. Before the method of issuing path information of the test device to the device under test, the method further comprises:

7. The method according to any one of claims 1 to 6, characterized in that, sending virtual topology data simulated and generated by the test device to the device under test, so that the device under test generates the probe packet based on the virtual topology data and the path information; the virtual topology data includes graph information between the plurality of SRv6-enabled virtual nodes. The device under test includes a first port, and the test device includes a second port and a processor; the first port of the device under test and the second port of the test device are connected through a communication link, and the processor includes a plurality of CPU cores; The method further comprises: binding a BFD process to a target CPU core in the plurality of CPU cores, so that one BFD process exclusively occupies the computing resources of one target CPU core; the BFD process is used to maintain a BFD session and perform the reception of the probe packet and the construction and sending of the backhaul packet based on the BFD session; based on the target CPU core, running the BFD process to execute the test method.

8. The method of claim 7, wherein, The number of the first ports is one or more, the number of the BFD processes and the target CPU cores is the same as the number of the first ports, and the first ports, the BFD processes and the target CPU cores are one-to-one corresponding.

9. The method of claim 7, wherein, The BFD process is run based on the target CPU core to execute the test method, including: In response to receiving a configuration operation of a user on a display interface of the test device, the BFD process is run based on the target CPU core to execute the test method.

10. The method of claim 5, wherein, The number of virtual nodes supporting SRv6, graph information, the probe path, the first reverse binding identifier, the probe packet receiving and screening strategy, and the remaining segment number are all obtained based on configuration information input by a user on a display interface of the test device.

11. The method of claim 7, wherein, The test device further includes a hardware processing circuit; Before the BFD process is run based on the target CPU core to execute the test method, the method further includes: The hardware processing circuit analyzes the probe packet to obtain a characteristic parameter; the characteristic parameter is used to distinguish whether the probe packet is an SRv6 packet of a BFD session; The hardware processing circuit distributes the probe packet to the target CPU core for processing based on the characteristic parameter.

12. A test device, characterized in that Comprise: A processor; A memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method of any one of claims 1-10.

13. The test device of claim 12, wherein, The test device further comprises: A hardware processing circuit for implementing the method of claim 11.

14. A test system, characterized by Comprise: A device under test and a test device for executing the method of any one of claims 1-11.

15. A computer readable storage medium, characterized in that, When the computer-executable instructions stored in the computer-readable storage medium are executed by the processor of the device, the test device can execute the method of any one of claims 1-10.

16. A computer program product comprising computer instructions, characterized in that, When the computer instructions are running on the processor of the device, the test device can execute the method of any one of claims 1-10.

Images