Detection method and device

Abstract

The embodiment of the invention provides a detection method and device. The method comprises the following steps: acquiring to-be-detected network address information; and when the conflict event of the to-be-detected network address information is detected, a traceability query message is sent to the second device, and the traceability query message is used for querying a conflict source of the conflict event. And receiving a traceability response message sent by the second device, wherein the traceability response message is used for indicating a conflict source device corresponding to the conflict event. And the conflict source is positioned through the traceability query message, so that accurate positioning and traceability of the address conflict event in the network can be realized.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a detection method and apparatus. Background Technology

[0002] IP (Internet Protocol) address conflicts have been a long-standing problem since the birth of IP networks. Issues such as IP address conflicts and IP segment conflicts can both lead to network incidents. Once an IP conflict occurs in a network, it will affect business operations and require a significant amount of time to troubleshoot, making it difficult to restore operations quickly.

[0003] When IP address conflicts exist in a network, they can cause network routing oscillations, network service interruptions, or traffic disruptions, which can significantly impact user operations. To minimize IP address conflicts caused by incorrect network configurations or user misconfigurations, it is desirable for devices to autonomously detect IP address conflicts and promptly identify the root cause when a conflict is detected. This helps network maintenance personnel quickly resolve the conflicting configurations and effectively reduce the impact on services.

[0004] While some conflict detection solutions have emerged, they only support specific protocols, specific scopes, and limited scenarios. There is a lack of solutions that can adapt to a wide range of network scenarios, large networks, and complex environments for address conflict protection, rapid discovery, and tracing. Summary of the Invention

[0005] This application provides a detection method and apparatus. In this method, the apparatus can trace the source of network address conflicts to accurately locate the source of the conflict.

[0006] Firstly, this application provides a detection method. The method is applied to a first device and includes: acquiring network address information to be detected; upon detecting a conflict event involving the network address information to be detected, sending a source tracing query message to a second device, the source tracing query message being used to query the source of the conflict event; and receiving a source tracing response message sent by the second device, the source tracing response message being used to indicate the conflict source device corresponding to the conflict event. Thus, through the detection method provided in this embodiment, devices in the network can perform conflict detection and source tracing of the network address information to be detected, so as to accurately locate the source of the conflict when a conflict event with the network address to be detected is detected in the network, achieving automated detection and accurate source tracing of conflict events.

[0007] In one possible implementation, sending a source tracing query message to the second device includes: flooding the source tracing query message among at least one device within the first network; the first device belongs to the first network, all devices within the first network belong to the same routing domain, and at least one device within the first network supports the source tracing protocol. Thus, when the first device and the second device are in the same routing domain, the first device can query the second device for specific information about the source of the conflict. The second device can then provide the first device with the conflict source information, enabling the user to accurately locate the conflict source.

[0008] In one possible implementation, the second device belongs to the first network. Thus, when the first and second devices are in the same routing domain, the first device can query the second device for specific information about the source of the conflict. The second device can then relay this conflict source information back to the first device, allowing the user to accurately locate the source of the conflict.

[0009] In one possible implementation, if the second device does not belong to the first network, sending a source tracing query message to the second device further includes: flooding the source tracing query message among at least one device within the second network, where the first network and the second network belong to different routing domains, and at least one device within the second network supports the source tracing protocol. Thus, this application can flood the message across multiple routing domains to achieve cross-routing domain conflict tracing functionality.

[0010] In one possible implementation, before obtaining the network address information to be detected, the method further includes: each device in the network exchanging traceability capability negotiation messages with its corresponding neighboring devices. These traceability capability negotiation messages are used to indicate to the neighboring devices whether the local device supports the traceability protocol. In this way, through pre-negotiation among the devices, each device can know whether its neighboring devices support the traceability protocol. If a neighboring device does not support the traceability protocol, a traceability message will not be sent to the neighboring device to avoid affecting the routing function of the device that does not support the traceability protocol.

[0011] In one possible implementation, the tracing protocol is used to indicate a specified network interface to be listened to, and to receive and / or send messages conforming to the tracing protocol's message format from the specified network interface.

[0012] In one possible implementation, after receiving the tracing response message sent by the second device, the method further includes: flooding a tracing report message among at least one device in the network. The tracing report message indicates that a conflict event corresponding to the network address information to be detected has occurred between the first device and the conflict source device. In this way, after obtaining the conflict source information, the device can flood the tracing report message across the network, enabling all devices in the network to obtain relevant information about the conflict source in the conflict event. This allows users to log in to any device in the network that supports the tracing protocol to obtain the conflict source information, thereby accurately locating the conflict source and enabling timely network troubleshooting.

[0013] In one possible implementation, the source tracing report message includes at least one of the following: routing information of the first device, routing information of the conflict source device, and network address information to be detected.

[0014] In one possible implementation, obtaining the network address information to be detected includes: in response to a received user instruction, obtaining the network address information to be detected; wherein the user instruction is used to instruct conflict detection of the network address information to be detected, or the user instruction is used to instruct the configuration and activation of the network address information to be detected in the network. Thus, the detection method in this application can perform conflict detection and conflict tracing for both inactive and activated network address information to meet the needs of different scenarios.

[0015] In one possible implementation, before sending the source tracing query message to the second device, the method further includes: detecting whether there is a conflict event corresponding to the network address information to be detected based on local routing information. This enables automated detection of network address information conflicts, timely discovery of network address conflict events in the network, and prompt tracing of the conflict events to reduce the impact of network address conflicts on network services.

[0016] In one possible implementation, the source query message is a User Datagram Protocol (UDP) message.

[0017] In one possible implementation, the source tracing query message includes the routing information of the first device and the network address information to be detected.

[0018] In one possible implementation, the second device is the source of the collision, or the second hop device on the transmission path from the source of the collision to the first device. In this way, if the source of the collision does not support a tracing protocol, the network location information fed back by the penultimate hop device can be used to quickly locate the source of the collision.

[0019] Secondly, this application provides a detection device. The method is applied to a first device, and the device includes: an acquisition module for acquiring network address information to be detected; a communication module for sending a source tracing query message to a second device when a conflict event is detected in the network address information to be detected, the source tracing query message being used to query the source of the conflict event; and the communication module is further configured to receive a source tracing response message sent by the second device, the source tracing response message being used to indicate the conflict source device corresponding to the conflict event.

[0020] In one possible implementation, the communication module is specifically used to: flood source tracing query messages between at least one device in the first network; the first device belongs to the first network, all devices in the first network belong to the same routing domain, and at least one device in the first network supports the source tracing protocol.

[0021] In one possible implementation, the second device belongs to the first network.

[0022] In one possible implementation, if the second device does not belong to the first network, the communication module is further configured to: flood source tracing query messages between at least one device in the second network, wherein the first network and the second network belong to different routing domains, and at least one device in the second network supports the source tracing protocol.

[0023] In one possible implementation, the communication module is also used for: exchanging traceability capability negotiation messages between each device in the network and its corresponding neighboring devices, wherein the traceability capability negotiation messages are used to indicate to the neighboring devices whether the local end supports the traceability protocol.

[0024] In one possible implementation, the tracing protocol is used to indicate a specified network interface to be listened to, and to receive and / or send messages conforming to the tracing protocol's message format from the specified network interface.

[0025] In one possible implementation, the communication module is further configured to: flood source report messages between at least one device in the network, the source report messages indicating that a conflict event corresponding to the network address information to be detected has occurred between the first device and the conflict source device.

[0026] In one possible implementation, the source tracing report message includes at least one of the following: routing information of the first device, routing information of the conflict source device, and network address information to be detected.

[0027] In one possible implementation, the acquisition module is specifically used to: acquire the network address information to be detected in response to a received user instruction; wherein the user instruction is used to instruct the network address information to be detected to perform conflict detection, or the user instruction is used to instruct the network address information to be detected to be configured and activated in the network.

[0028] In one possible implementation, the device further includes a conflict detection module for detecting, based on local routing information, whether there is a conflict event corresponding to the network address information to be detected.

[0029] In one possible implementation, the source query message is a User Datagram Protocol (UDP) message.

[0030] In one possible implementation, the source tracing query message includes the routing information of the first device and the network address information to be detected.

[0031] In one possible implementation, the second device is the collision source device, or the second device is the second hop device on the transmission path from the collision source device to the first device.

[0032] Thirdly, this application provides a path restoration method. In this method: a first device sends a path restoration probe message to at least one device, the path restoration probe message being used to query whether the at least one device belongs to a first path between the first device and a target device; the first device, in response to a path restoration response message received from the at least one device, determines the path to which each of the at least one device belongs. Thus, by performing path queries on the devices, the network topology can be restored. Furthermore, by probing the devices through path query messages, the first device can obtain information on whether any devices on the path are experiencing anomalies, thereby enabling early detection of potentially abnormal paths and preventing handover failures during path switching.

[0033] In one possible implementation, the path reconstruction probe message includes routing information of a first device, target address information of a target device, and routing information of a receiving device, wherein the receiving device belongs to the at least one device.

[0034] In one possible implementation, the first path is the planned path recorded in the routing information of the first device.

[0035] In one possible implementation, the first path is an unplanned path recorded in the routing information of the first device.

[0036] In one possible implementation, multiple paths exist between the first device and the target device, including a primary path and backup paths, with the first path being a backup path. For example, the primary path can also be an active path, and the backup path can also be an inactive path. One or more backup paths may exist between the first device and the target device.

[0037] Fourthly, this application provides a detection device, comprising: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and when the computer programs are executed by the one or more processors, the device executes instructions of the method in the first aspect or any possible implementation of the first aspect, or executes instructions of the method in the second aspect or any possible implementation of the second aspect, or executes instructions of the method in the third aspect or any possible implementation of the third aspect.

[0038] Fifthly, embodiments of this application provide a computer-readable medium for storing a computer program, the computer program including instructions for performing a method in the first aspect or any possible implementation of the first aspect, or instructions for performing a method in the second aspect or any possible implementation of the second aspect, or instructions for performing a method in the third aspect or any possible implementation of the third aspect.

[0039] In a sixth aspect, embodiments of this application provide a computer program including instructions for executing a method in the first aspect or any possible implementation thereof, or for executing a method in the second aspect or any possible implementation thereof, or for executing a method in the third aspect or any possible implementation thereof.

[0040] In a seventh aspect, embodiments of this application provide a chip including a processing circuit and transceiver pins. The transceiver pins and the processing circuit communicate with each other via an internal connection path. The processing circuit executes instructions of the method in the first aspect or any possible implementation thereof, or executes instructions of the method in the second aspect or any possible implementation thereof, or executes instructions of the method in the third aspect or any possible implementation thereof, to control the receiving pin to receive signals and to control the transmitting pin to transmit signals. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the detection method process as an example.

[0042] Figure 2 This is a schematic diagram illustrating the message format of a source tracing query message;

[0043] Figure 3 This is a schematic diagram illustrating the traceability capability negotiation process as an example.

[0044] Figure 4 This is a schematic diagram illustrating the structure of a traceability capability negotiation message;

[0045] Figure 5This is a schematic diagram illustrating the structure of a traceability capability negotiation response message;

[0046] Figure 6 This is a schematic diagram illustrating the structure of a source tracing response message;

[0047] Figure 7 This is a schematic diagram illustrating an application scenario;

[0048] Figure 8 This is a schematic diagram illustrating an application scenario;

[0049] Figure 9 This is a schematic diagram illustrating an application scenario;

[0050] Figure 10 This is a schematic diagram illustrating an application scenario;

[0051] Figure 11 This is a schematic diagram illustrating an application scenario;

[0052] Figure 12 This is a schematic diagram illustrating an application scenario;

[0053] Figure 13 This is a schematic diagram illustrating an application scenario;

[0054] Figure 14 This is a schematic diagram illustrating an application scenario;

[0055] Figure 15 This is a schematic diagram illustrating an application scenario;

[0056] Figure 16 This is a schematic diagram illustrating an application scenario;

[0057] Figure 17 This is a schematic diagram illustrating an application scenario;

[0058] Figure 18 This is a schematic diagram illustrating the path restoration process as an example.

[0059] Figure 19 This is a schematic diagram illustrating the path restoration negotiation process as an example.

[0060] Figure 20 This is a schematic diagram illustrating the structure of a path restoration negotiation message;

[0061] Figure 21 This is a schematic diagram illustrating the structure of a path restoration negotiation response message;

[0062] Figure 22 This is a schematic diagram illustrating the structure of a path restoration response message;

[0063] Figure 23 This is a schematic diagram illustrating an application scenario;

[0064] Figure 24 This is a schematic diagram illustrating an application scenario;

[0065] Figure 25 This is a schematic diagram of the structure of an exemplary detection device. Detailed Implementation

[0066] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0067] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0068] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0069] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0070] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0071] Figure 1 For an illustrative example of the detection method flowchart, please refer to... Figure 1 Specifically, including but not limited to the following steps:

[0072] S101, the first device obtains the network address information to be detected.

[0073] For example, the first device can obtain network address information to be detected, wherein the network address information to be detected can also be network address information to be traced, and this application does not limit it.

[0074] For example, the network address information to be detected can be different types of addresses such as public network addresses and service addresses. That is, the detection method of this application can not only support conflict detection and tracing of network-side device addresses, but also conflict detection and tracing of IP addresses on the service-bearing side. Optionally, the network-side device address can include, but is not limited to: IP address (or IP network segment, including IP address (or network segment) and subnet mask, etc.), SRv6 (Segment Routing IPv6, segment routing based on the IPv6 forwarding plane) address (e.g., SRv6Locator), Sub-IP address (sub-IP address), etc. Optionally, the service address can be, for example, a service VPN (Virtual Private Network) private network address, or an internal service address, etc., which is not limited in this application. In other words, this application can perform conflict detection and corresponding conflict tracing for different types of network addresses (or network segments), thereby achieving network address conflict detection and tracing that supports a wide range of network scenarios, and can adapt to multi-scenario address conflict detection, massive networks, multi-hop networks, cross-routing area scenarios, and cross-multiple routing area scenarios, etc.

[0075] In one possible implementation, the network address information to be detected is obtained by the first device in response to a received user instruction. In one example, the user instruction instructs the network address information to be detected to undergo conflict detection. For instance, before configuring a new address for the network (which could be any device in the network), the user can instruct the user to perform conflict detection on the new address (i.e., the network address information to be detected). If a network address conflict is detected, the user can either not configure the new address, or change the conflicting address before configuring the new address. In another example, the user instruction instructs the user to configure and activate the network address information to be detected in the network. For instance, the user configures and activates a new address for any device in the network. After the new address takes effect, the device to which the new address belongs, or any device that may have an address conflict with it (referred to as the conflict source device), will automatically perform conflict detection. Optionally, if the network address information to be detected has already taken effect, any device in the network can initiate conflict detection and conflict tracing for the network address information to be detected. For example, device A can, in response to a received user instruction, determine that conflict detection and conflict tracing are needed for address X (i.e., the network address information to be detected).

[0076] Optionally, after a conflict is detected, conflict attribution will be performed. In another example, the user instruction is used to instruct the network address information to be detected to undergo conflict detection and conflict attribution. That is, in some examples, the device may simply perform conflict detection and report it. In other instances, the device may perform conflict detection and, after detecting an address conflict, perform conflict attribution on the network address information to be detected (which can also be understood as performing conflict attribution on the conflict event).

[0077] In this embodiment, conflict detection, also known as network address conflict detection or network address information conflict detection, refers to detecting network address information to determine whether a network address information conflict exists. It can also be understood as determining whether a conflict event exists corresponding to the network address information (e.g., the network address information to be detected). Optionally, a network address information conflict can be defined as the existence of identical network address information within a network (which can refer to the same routing domain or multiple routing domains that can communicate with each other). This can be understood as network address information being unique; one network address corresponds to one device. If one network address corresponds to two or more devices, a network address conflict is considered to have occurred. Specifically, a first device (which can be any device in the network) can detect whether a conflict event corresponding to the network address information to be detected exists based on local routing information. If the first device detects that a network address in the routing information corresponds to different devices, it can determine that a conflict event has occurred for that network address.

[0078] In this application embodiment, conflict tracing can also be called network address conflict tracing, network address information conflict tracing, or conflict event tracing, etc., and this application does not limit it. Conflict tracing refers to tracing the source of conflicting network address information, that is, tracing the source of the network address information conflict. The device corresponding to the source is called the conflict source device in this application embodiment. In this application embodiment, two or more devices that have network address conflicts are all called conflict sources. For example, if a first device detects a network address information conflict and traces the network address information, and the conflict source tracing back to the second device (that is, the first device and the second device may have the same network address information configured (e.g., the same service address)), then the first device and the second device are conflict source devices for each other. The first device can be called the first conflict source device, and the second device can be called the second conflict source device. Of course, if there is a third device (or more devices) that has the same network address information conflict event with the first device and the second device, they can be called the third conflict source device. In this embodiment, only the example of a network address conflict between the first device and another device is used for illustration. In some instances, there may be multiple conflict events corresponding to network address information in the network. The conflict detection method and conflict tracing method are the same. This application will not provide examples for each of them.

[0079] S102, when the first device detects a conflict event in the network address information to be detected, it sends a source tracing query message to the second device. The source tracing query message is used to query the source of the conflict event.

[0080] For example, when a first device detects a conflict event involving network address information to be detected, it sends a source lookup message to a second device in the network. The source lookup message is used to query the second device for the source of the conflict event. The source lookup message includes, but is not limited to, at least one of the following: routing information of the first device, routing information of the second device, and network address information to be detected. Alternatively, it can be understood that the conflict lookup message is used to query the second device for the source of the conflict event corresponding to the network address information to be detected.

[0081] Optionally, the second device may be the source of the conflict itself, or it may be the second-hop device on the transmission path from the source of the conflict to the first device. Optionally, the source of the conflict on the transmission path to the first device is the first-hop device. Of course, in some instances, the second device can also be considered the first-hop device on the transmission path from the source of the conflict to the first device (also called the first-hop routing device, which is not limited in this application), and this application does not impose any limitations. In other instances, the second device can also be understood as the penultimate-hop device on the transmission path from the first device to the source of the conflict, where the source of the conflict is the last-hop device.

[0082] In the embodiments of this application, the source tracing query message, as well as the source tracing capability negotiation message, source tracing capability negotiation response message, source tracing response message, and source tracing report message mentioned below, can be User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or other protocol messages; this application does not limit them. This application only uses UDP messages as an example for illustration; this application does not limit the message type.

[0083] Figure 2 For an illustrative example of the message format of a source tracing query message, please refer to... Figure 2 Specifically, including but not limited to at least one of the following:

[0084] Source Port: This field indicates the port from which the message was sent.

[0085] Destination Port: This field indicates the destination port of the message.

[0086] UDP Length: This field indicates the length of the message.

[0087] UDP Checksum: This field is used to indicate message verification information.

[0088] Sequence Number: This field carries the message sequence number, which indicates whether the message is the latest message.

[0089] Acknowledgment Number: This field indicates the sequence number of the ACK message (such as the source response message mentioned below).

[0090] Type (Type), this field is used to indicate the type of the message. In the embodiments of the present application, a value of 1 for this field indicates that the message type is a traceability capability negotiation message, a value of 2 indicates that the message type is a traceability capability negotiation response message, a value of 3 indicates that the message type is a traceability report message, and a value of 4 indicates that the message type is a traceability report response message. Optionally, the number and position of the fields carried by different message types may be different, or the meanings indicated by the same fields of different message types may also be different. In the embodiments of the present application, the message type of the traceability query message is the traceability report message, that is, the Type type is 3, which can also be understood as the message format of the traceability query message being the same as the message format of the traceability report message. Of course, in some instances, more message types can also be set. For example, a message type of 5 is used to indicate a traceability query message, and a message type of 6 is used to indicate a traceability response message. In the embodiments of the present application, for the convenience of description, the traceability query message, traceability response message, traceability capability negotiation message, traceability capability negotiation response message, traceability report message, etc. involved in the present application can all be referred to as traceability messages.

[0091] Version (Version), this field is used to indicate the protocol version number.

[0092] Reserved (Reserved), reserved field.

[0093] Sender ID (Sender ID). This field is used to indicate the sender (or called the sending device) of the traceability message (which can be any kind of message involved in the present application, such as a traceability query message), and the field carries the identification information of the sender. For example, it is the routing identification information of the sender (it can also be other identifications, which are not limited in the present application).

[0094] Sender name (Sender name), this field is used to indicate the sender of the traceability message, and the field carries the name of the sender. For example, it is the routing name, which can be set according to actual needs and is not limited in the present application.

[0095] Conflict address (Conflict address), this field is used to indicate the conflict address. In the embodiments of the present application, the conflict address is the network address information where the conflict occurs. The network address information where the conflict occurs can be different types or different protocol network addresses such as IP addresses, SRv6loctor and other public network addresses, service addresses, etc., which are not limited in the present application. That is to say, the present application can perform conflict detection and conflict traceability on any type or protocol of network address information, so as to be applicable to different types of network scenarios.

[0096] The Local Conflict Source field indicates information about the local conflict source. In this embodiment, as described above, multiple devices experiencing network address information conflicts are referred to as conflict sources, including local conflict sources (also known as local conflict sources) and remote conflict sources. In this embodiment, if a device is the sender of a tracing message and is a conflict source, then that device is a local conflict source. If a device is the receiver of a tracing message and is a conflict source, or may be a conflict source, then that device is a remote conflict source. For example, if a first device detects a network address information conflict event (hereinafter referred to as a network address conflict) with a second device, the first device sends a tracing query message. The local conflict source field in the tracing query message carries information about the first device, and the remote conflict source field carries information about the second device. In this context, the second device may or may not be the source of the conflict. The significance of the first device sending the source query message can be understood as the first device believing that a network address conflict has occurred with the second device. The first device sends the source query message to confirm whether the second device is another source of the conflict.

[0097] Optionally, the Local Conflict Source field includes, but is not limited to:

[0098] Conflict source ID: This field indicates the source of conflict on this end, or its location within the network. It includes identification information such as route ID, route name, and device serial number (SN), and may also include other information such as device type and version number. This application does not impose any limitations on the information provided. Essentially, the information in this field uniquely identifies a device within the network, allowing operators to accurately locate a conflict source.

[0099] Conflict source information: This field indicates the routing information of the conflict source, which may include, but is not limited to: the specific physical port number corresponding to the network address conflict, the loopback number, static routing information, IGP (Interior Gateway Protocol) routing information, BGP (Border Gateway Protocol) path information, etc.

[0100] Remote Conflict Source: This field indicates information about the remote conflict source. This field may include, but is not limited to, the Conflict source ID field and the Conflict source information field. For a detailed description, please refer to the above text; it will not be repeated here.

[0101] The Track Forward field indicates whether further tracing is required. Optionally, a value of 1 indicates that further tracing is required, while a value of 0 or empty indicates that further tracing is not required.

[0102] The PHP (Penultimate Hop Popping) field is used to query whether the second device is the penultimate hop device. In this embodiment, devices in the network may or may not support the tracing protocol. Supporting the tracing protocol can be understood as the device having the ability to listen on a specified port (which can be set according to actual needs, and this application does not limit it) and send or receive tracing messages from the specified port. If the source device of the conflict is a device that supports the tracing protocol, the source device of the conflict can respond to the tracing request of the first device and reply with the corresponding response message. If the source device of the conflict is a device that does not support the tracing protocol, the second device, which is the penultimate hop device, needs to reply with the response message to the first device on behalf of the source device of the conflict. In some instances, there may also be one or more devices that do not support the tracing protocol between the second device and the source device of the conflict. That is, the second device can be understood as the device that is closest to the source device of the conflict in the transmission path from the first device to the source device of the conflict (meaning the closest position on the routing path) and supports the tracing protocol. For example, on the path between the second device and the source of the conflict, the device closest to the source of the conflict may be the third device. If neither the third device nor the source device supports the tracing protocol, then the second device, as the device closest to the source of the conflict on the transmission path between the first device and the source device and which supports the tracing protocol, is the penultimate hop device from the first device to the source device, or the second hop device from the source of the conflict to the first device.

[0103] New Remote Conflict Source: This field indicates an updated remote conflict source, including but not limited to updated routing information for the remote conflict source.

[0104] The `Advert` (advertise) / `Redistribute` node list indicates conflict information related to network address conflicts; it can also be understood as event information about network address conflict events. Fields include, but are not limited to, at least one of the following:

[0105] 1) Router id / system-id 1 (Router ID or System ID): This field indicates the routing identification information of neighbors, Area Border Routers (ABRs), or Autonomous System Boundary Routers (ASBRs). This field includes, but is not limited to, at least one of the following:

[0106] Router name: This field indicates the name of the router of the neighboring router, ABR, or ASBR.

[0107] The Preference field indicates the protocol corresponding to the neighbor, ABR, or ASBR.

[0108] COST (Cost) is a field that indicates the routing cost to reach the Conflict address in the neighbor, ABR, or ASBR routing information.

[0109] IGP Process ID (Process Identifier): This field indicates the routing process ID that arrives at the Conflict address in the routing information of this neighbor, ABR, or ASBR.

[0110] BGP AS Path (BGP Autonomous Path) This field indicates the AS Path that leads to the Conflict address in the routing information of this neighbor, ABR, or ASBR.

[0111] NextHop is a field that indicates the next hop in the routing information of the neighbor, ABR, or ASBR that leads to the Conflict address.

[0112] Exit Interface: This field indicates the exit interface that leads to the Conflict address in the neighbor, ABR, or ASBR routing information.

[0113] Redistribute time (number of redistributions) is a field that indicates the number of times a route to the Conflict address is redistributed in the routing information of this neighbor, ABR, or ASBR (incremented by 1 for each ASBR traversal).

[0114] Hop time is a field that indicates the number of hops required to reach the Conflict address in the routing information of the neighbor, ABR, or ASBR (incremented by 1 for each neighbor or ABR traversed).

[0115] 2) Router id / system-id field.

[0116] Other fields can be set according to actual needs; this application does not impose any restrictions.

[0117] In one possible implementation, the first device uses a flooding transmission method to send a source query message to the second device. Specifically, the first device sends a source query message to its neighboring devices, and neighboring devices can send source query messages to each other. That is, devices in the network that receive a source query message can send source query messages to their neighboring devices until the message is flooded to the second device. In this embodiment, a neighboring device can refer to the next-hop device in an IGP route, BGP route, or static route; this application is not limited to this.

[0118] In one example, if all devices in the network support the source tracing protocol, the flooding method can be called hop-by-hop flooding. This means that after each device receives a source tracing query message, it sends a source tracing query message to its corresponding neighboring device. In this example, after the source tracing query message is flooded to other devices in the network, any device that supports this feature can log in and view the relevant information corresponding to the conflict event (such as the routing information of the conflict source and the conflict address information), making it convenient for maintenance personnel to quickly identify the faulty node in the network and troubleshoot and modify the address of the faulty node.

[0119] In another example, if devices in the network do not support the source tracing protocol, the flooding method can be called next-hop flooding. The source tracing query message is flooded from the first device to a specific device (i.e., the next-hop device), which is a device that supports the source tracing protocol. In this example, after logging in, the device supporting the source tracing protocol can query relevant source tracing information. That is, in this embodiment, devices that do not support the source tracing protocol (e.g., older devices in the network) will not be affected. Specifically, source tracing query messages (and source tracing report messages below) may not be sent to older devices to avoid being identified as attack messages by them. This achieves backward compatibility with older devices in the network that do not support the source tracing protocol, allowing incremental deployment without affecting the routing function of older devices.

[0120] In this embodiment of the application, each device in the network can negotiate with neighboring devices to determine whether the neighboring devices support the tracing protocol. As described above, if a neighboring device does not support the tracing protocol, when flooding tracing messages (e.g., tracing query messages), it is optional not to send tracing messages to neighboring devices that do not support the tracing protocol, so as to avoid affecting the neighboring devices.

[0121] Figure 3 This is a schematic diagram illustrating the traceability capability negotiation process. Please refer to [the diagram]. Figure 3 Specifically, including but not limited to the following steps:

[0122] S301, Device A sends a traceability capability negotiation message to Device B.

[0123] For example, device A and device B establish IGP neighbor, BGP neighbor or static route neighbor, and the specific establishment process can refer to existing technology and is not limited in this application.

[0124] Device A sends a traceability capability negotiation message to its neighboring device (i.e., device B). This message indicates that device A supports the traceability protocol and queries whether device B supports it. Optionally, device A can trigger execution of step S301 after enabling the traceability capability. Enabling the traceability capability means that device A starts the traceability capability in response to a received user operation. In this embodiment, if the device's traceability capability is disabled, it is also considered that the device does not support the traceability protocol. This can be understood as the device no longer having the ability to listen to a specified port and send or receive traceability messages after its traceability capability is disabled. In this embodiment, the device's traceability capability can be a computer program (or module) in the device capable of executing the method flow in this embodiment. The device can be a new device with the module integrated at the factory, or an older device in the network that has been upgraded to have the module (i.e., can run the corresponding computer program). This application does not limit the scope of the invention.

[0125] Figure 4 For an illustrative example of the structure of a traceability capability negotiation message, please refer to... Figure 4 Specifically, including but not limited to at least one of the following:

[0126] The fields Source Port, Dest Port, UDP Length, UDP Checksum, SequenceNumber, Acknowledgment Number, Version, Reserved, and SenderID are described above and will not be repeated here.

[0127] The Type field, in this example, is 1, indicating that the message is a traceability capability negotiation message.

[0128] The Track conflict source capability field indicates whether the device has a tracking capability, or supports a tracking protocol. As mentioned above, in this embodiment, having tracking capability and supporting a tracking protocol both mean being able to listen to a specified port and send or receive tracking messages from that port. If the device itself supports a tracking protocol but the tracking capability is disabled, then the device does not have a tracking capability, or it can be understood as not supporting the tracking protocol. Optionally, a value of 1 in this field indicates that the device supports the tracking protocol, i.e., has a tracking capability. A value of 0 in this field indicates that the device does not support the tracking protocol, i.e., does not have a tracking capability, or it can be understood as the device not enabling the tracking capability. In this embodiment, after the device responds to a received user operation to activate the tracking capability (or the device initializes and activates the tracking capability by default), the device can send a tracking capability negotiation message to its neighboring devices. The Track conflict source capability field in the message is used to indicate that the device supports the tracking protocol (e.g., a value of 1), i.e., has a tracking capability. Optionally, after the device responds to the received user operation to disable the traceability capability, the device sends a traceability capability negotiation message to the neighboring device. The Track conflict source capability field in the message is used to indicate that the device does not support the traceability protocol (e.g., the value is 0), that is, it does not have traceability capability.

[0129] The "Need Ack" field indicates whether a traceability negotiation response message is required; in other words, whether an ACK message is needed. Optionally, a value of 1 indicates that an ACK is required, and a value of 0 indicates that an ACK is not required.

[0130] S302, Device B sends a traceability capability negotiation response message to Device A.

[0131] For example, after receiving the traceability capability negotiation message sent by device A, device B determines that device A supports the traceability protocol. Device B can locally record that device A supports the traceability protocol. In response to the traceability capability negotiation message, device B sends a traceability capability negotiation response message to device A, indicating whether device B has traceability capability or whether it supports the traceability protocol.

[0132] Figure 5 For an illustrative diagram of the structure of a traceability capability negotiation response message, please refer to... Figure 5 Specifically, including but not limited to at least one of the following:

[0133] The fields Source Port, Dest Port, UDP Length, UDP Checksum, SequenceNumber, Acknowledgment Number, Version, Reserved, and SenderID are described above and will not be repeated here.

[0134] The Type field, in this example, is 2, indicating that the message is a traceability capability negotiation response message.

[0135] Track conflict source capability ACK: This field indicates whether the local end has the capability to trace conflict sources. It can also be understood as indicating whether the local end supports the traceability protocol, and it is also used to confirm that the local end has received the traceability capability negotiation message sent by the other end.

[0136] Device A receives a traceability capability negotiation response message from Device B, determines whether Device B supports the traceability protocol, and records this information. In this way, each device in the network can obtain information about whether its neighbors support the traceability protocol through traceability capability negotiation. If a neighbor does not support the traceability protocol, no further traceability messages will be sent to the neighbor in subsequent traceability message exchange processes to avoid being mistaken for attack messages.

[0137] In some instances, even after device B disables its traceability capability, it can still receive traceability capability negotiation messages and indicate in its response message that it lacks traceability capability. In other instances, after disabling its traceability capability, device B may stop listening to the corresponding port, i.e., it will no longer receive traceability capability negotiation messages. In this embodiment, if device B does not support the traceability protocol (either because it originally supported the protocol but this function was disabled, or because it never supported the protocol in the first place), device B will not respond to traceability capability negotiation messages; that is, it will neither receive nor send back the corresponding message. If device A does not receive a traceability capability negotiation response message from device B within a predetermined time period (which can be set according to actual needs, and is not limited in this application), device A can resend the traceability capability negotiation message (the number of resends can be set according to actual needs, and is not limited in this application). If device A still does not receive a traceability capability negotiation response message from device B after resending a specified number of times, device A can determine that device B does not have traceability capability, i.e., it does not support the traceability protocol.

[0138] Optionally, this application only uses the example of device A sending a traceability capability negotiation message to device B as an example. In this embodiment, two devices that are neighbors can send traceability capability negotiation messages. For example, if device B completes initialization first and sends a traceability capability negotiation message to device A, then device A will reply with a traceability capability negotiation response message and will not send another traceability capability negotiation message.

[0139] In one possible implementation, the first device may also directly send a source tracing query message to the second device. The transmission path of the source tracing query message can be the optimal transmission path between the first device and the second device (path selection can refer to existing technologies, and this application does not limit it).

[0140] S103, the first device receives the source tracing response message sent by the second device. The source tracing response message is used to indicate the source device corresponding to the conflict event.

[0141] For example, in response to the received source tracing query message, the second device sends a source tracing response message to the first device. The source tracing response message indicates the source device corresponding to the conflict event. The first device receives the source tracing response message sent by the second device.

[0142] In this embodiment of the application, as described above, in one example, the second device can be the source of the conflict, and correspondingly, the source of the conflict indicated in the tracing response message is the second device. In another example, the second device can also be the penultimate hop device of the source of the conflict, and correspondingly, the source of the conflict indicated in the tracing response message is the device that has a network address conflict with the first device. Optionally, the tracing response message may also include routing information of the second device to indicate the location of the second device in the network, so that the operator can locate the second device based on its location in the network, and further locate the source of the conflict based on the relationship between the second device and the source of the conflict (i.e., the penultimate hop device of the source of the conflict).

[0143] Figure 6 For an illustrative example of the structure of a source tracing response message, please refer to... Figure 6 The Type field is 4, indicating that the message is a source query response message. The ACK field indicates whether the second device acknowledges (e.g., 1) that it is the source device of the conflict or denies (e.g., 0) that it is the source device of the conflict.

[0144] Optionally, the PHP field may include, but is not limited to, routing information of the penultimate hop device. This routing information includes, but is not limited to, route ID, route name, device hardware serial number, and other information that can uniquely identify a device's location in the network; this application does not impose any limitations on this. It should be noted that in this embodiment, devices in the network may have partially identical routing information. Therefore, the routing information in the Local Conflict Source, PHP, and other fields in this embodiment may be a combination of multiple routing information entries, thereby uniquely identifying a device's location in the network.

[0145] Other fields can be referred to the description above, and will not be repeated here.

[0146] In one possible implementation, the second device can be a conflict source device. In one example, the first and second devices are in the same network; in this embodiment, the same network may optionally be the same routing domain. That is, in this example, multiple conflict sources are in the same routing domain. In another example, the first and second devices are in different networks, i.e., in different routing domains. In other words, multiple conflict sources can be in different routing domains. In this example, the first device can flood source tracing query messages to other routing domains via an ABR or ASBR between the routing domain and the first device to query the conflict source.

[0147] In another possible implementation, the second device is not the source of the conflict; that is, the second device sends a source tracing response message (also called a source tracing query response message, which is not limited in this application) to the first device on behalf of the source of the conflict. In one example, the first device and the second device are in the same routing domain, while the first device and the source of the conflict are not in the same routing domain. In another example, the first device, the second device, and the source of the conflict are all in the same routing domain. In yet another example, the second device and the source of the conflict are in the same routing domain, while the first device is not in that routing domain.

[0148] In this embodiment, after the first device determines the source device (which can be the second device or a non-second device) based on the source tracing response message (also known as the source tracing query response message) fed back by the second device, the first device can flood the entire network with a source tracing report message. The source tracing report message indicates that a conflict event has occurred between the first device and the source device regarding the address information to be detected (e.g., address X). This ensures that all devices in the network receive information about the conflict event between the first device and the second device regarding the network address information to be detected (e.g., address X). The flooding method is described above and will not be repeated here. Thus, a user can log in to any device and determine that a conflict event has occurred in the network through device logs and other information, and obtain the description information of the conflict event. This description information is the relevant information carried in the source tracing report message. The structure of the source tracing report message can be referred to... Figure 3 The Type field can be 3 or other values; this application does not impose any restrictions. Descriptions of each field can be found above and will not be repeated here.

[0149] The following specific examples illustrate... Figure 1 The process will be explained in detail.

[0150] Figure 7 This is an illustrative diagram of an application scenario; please refer to it. Figure 7 In this scenario, the first device is device A (abbreviated as A), and the second device is device H (abbreviated as H). There is a conflict event between the first device (i.e. device A) and the second device (i.e. device H) at address X. Both the first device and the second device are sources of conflict.

[0151] Optionally, the first device and the second device are in the same routing domain, and all network devices in that routing domain support the tracing protocol. The scenario also includes devices B to G (abbreviated as B to G).

[0152] Please refer to Figure 7In this application, devices in the network establish neighbor relationships. The neighbor establishment process can refer to existing technical embodiments, and will not be described in detail here. For example, device A and device B establish BGP neighbors (or OSPF (Open Shortest Path First), ISIS (Intermediate System to Intermediate System) neighbors, etc., which are not limited here), device B and device C establish BGP neighbors, device B and device D establish BGP neighbors, etc., and will not be described one by one here. That is to say, in the embodiments of this application, a device can establish neighbors with at least one other device.

[0153] For example, neighboring devices negotiate traceability capabilities. Taking device A and device B as an example, after device A enables traceability capabilities, device A sends a traceability capability negotiation message to device B. This message indicates that device A supports the traceability protocol and requests a query to determine if device B also supports it. The traceability capability negotiation message includes, but is not limited to: traceability message type (e.g., Type 1), a SenderID field indicating device A's identification information, a Track conflict sourcecapability field indicating device A's support for the traceability protocol, and a Need ACK field indicating the need for an ACK response. Other fields can be found in [reference needed]. Figure 4 The relevant descriptions will not be repeated here.

[0154] Upon receiving the traceability capability negotiation message, Device B determines that Device A supports the traceability protocol. Device B records locally that Device A supports the traceability protocol. Device B then sends a traceability capability negotiation response message back to Device A. This response message indicates that Device B has received Device A's traceability capability negotiation message and that Device B supports the traceability protocol. The response message includes, but is not limited to: the traceability message type (Type 2), the SenderID field (Device B's identifier), and the Track conflict source capability ACK field indicating that Device B has received Device A's traceability capability negotiation message and supports the traceability protocol. Upon receiving the traceability capability negotiation response message from Device B, Device A determines that Device B supports the traceability protocol and records locally that Device B supports the traceability protocol. The traceability capability negotiation between Device A and Device B is successful.

[0155] The process of negotiating traceability capabilities between other devices can be referenced from that of devices A and B, and will not be repeated here.

[0156] Please continue to refer to Figure 7Device A (which can be understood as the first device involved in this application) responds to the received user instruction and determines that the network address information to be detected is address X. Based on routing information (including routing tables or routing databases, etc., which are not limited in this application), Device A determines that a conflict event has occurred at address X, and that another source of the conflict is device H. Optionally, the information about device H determined by device A may be correct or incorrect. Incorrect situations include: the source of the conflict may not be device H, or the information about device H stored locally by device A (e.g., including routing information) may be incomplete or erroneous. Device A queries the source device of the conflict event by sending a source lookup message to device H (which can be understood as the second device involved in this application). It should be noted that the completeness or incompleteness of the routing information described in this application refers to the completeness required by the tracing protocol. For example, if the tracing protocol indicates that obtaining routing information A to D constitutes complete routing information, the routing information of a network device may include routing information A to X. Device A only needs to obtain routing information A to D from device H to be considered to have obtained complete routing information for device H. This can also be understood as meaning that accurate location of device H can be achieved through routing information A to D.

[0157] For example, device A sends a source tracing query message to device H in the network via flooding. This example and the examples below illustrate the use of device A sending a source tracing query message to device H via flooding. As mentioned above, device A can also directly send a source tracing query message to device H; this application does not impose any limitations on this.

[0158] Specifically, device A sends a source tracing query message to its neighboring device (i.e., device B). The structure of the source tracing query message can be found in [reference needed]. Figure 3 The description in the source tracing query message includes, but is not limited to:

[0159] Source tracing message type (i.e., Type 3);

[0160] The SenderID field contains the identification information for device A;

[0161] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0162] The Local conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device A.

[0163] The Remote conflict source field includes partial or complete routing information for device H, indicating that the conflict source of the conflict event for address X includes device H;

[0164] PHP fields and Adv / Redidstribute Node List fields (hereinafter referred to as Adv fields) can be 0 or empty. For descriptions of other fields, please refer to [link / reference needed]. Figure 3 This will not be elaborated upon here.

[0165] Please continue to refer to Figure 7 Device B receives a source tracing query message sent by Device A. Device B determines whether the conflict source includes Device B based on the Remoteconflict source field. If it does, Device B will perform the same steps as Device H. If it does not, Device B records the conflict information of the corresponding conflict event. Optionally, non-conflict source devices in the network may not record relevant information after receiving the source tracing query message, or they may record all or part of the information; this application does not impose any limitations. For example, the information recorded by Device B based on the source tracing query message may include, but is not limited to: conflict address, routing information of the conflict source, etc.; this application does not impose any limitations.

[0166] For example, device B sends a source lookup message to its neighboring devices (including devices C and D), and the content of the data portion of the source lookup message is the same as that sent by device A (e.g., including the fields after the UDP Checksum).

[0167] Other devices in the network perform the same steps as device B, which will not be described further here.

[0168] For example, when device H receives a source tracing query message, device H can determine, based on routing information, that it is indeed the source device of the conflict, i.e., a conflict with device A over address X has occurred. Optionally, device H may continue to send source tracing query messages to its neighboring devices, or it may choose not to send them; this application does not impose any limitations on this.

[0169] Device H sends a source tracing query response message 1 to Device A. This message indicates that Device H is the source of the conflict. The message format of source tracing query response message 1 can be found in [reference needed]. Figure 6 The source tracing query response message 1 includes, but is not limited to:

[0170] The Type field is 4, which indicates that the type of the traceability message is an ACK message;

[0171] The Sender ID field contains the identification information for device H;

[0172] The Sender Name field is the route name for device H;

[0173] The Conflict address field is the X address;

[0174] The Local Conflict Source field contains the routing information for device H, which indicates the source of the conflict event where device H is the address of X. The routing information of device H carried in the message sent by device H is the routing information stored locally by device H. The routing information is accurate and can be used to accurately locate the position of device H in the network.

[0175] The Remote Conflict Source field contains routing information for device A, indicating that another source of conflict is device A. This routing information for device A is obtained by device H from the source lookup message. This can be understood as the routing information for the conflict source in the source lookup response message returned by device H being accurate and essentially complete.

[0176] The ACK field being 1 indicates that the device H has received a source query message, and that this message is an ACK message replied to the source query message, i.e., a response message.

[0177] The New Remote Conflict Source, Track Forward, PHP, and Adv fields are 0 or empty. The descriptions of other fields can be found above and will not be repeated here.

[0178] Optionally, the transmission path for device H to directly send the traceability query response message to device A can be set based on actual needs, and this application does not impose any restrictions.

[0179] In response to the received source tracing query response message 1, device A determines that device H is another source of the conflict event at address X. Device A stores routing information for address X and the conflict sources (including device A and device H). Thus, if a user logs into device A, they can view device A's logs (or other files) to find out that the conflict at address X occurred between device A and device H. The user can then accurately locate the specific location of the devices using the routing information from both device A and device H.

[0180] Optionally, device A sends a source tracing query response message 2 to device H to indicate that device A has received device H's source tracing query response message 1. In source tracing query response message 1, the Local Conflict Source field contains device A's routing information, and the Remote Conflict Source field contains device H's routing information. The routing information of device H in source tracing query response message 2 sent by device A is the routing information obtained by device A from device H, which can be understood as complete and accurate routing information of device H. Other fields are described above and will not be repeated here.

[0181] Still refer to Figure 7 For example, device A floods source tracing report messages across the network. The message structure of the source tracing report message can be found in [reference needed]. Figure 2 This will not be elaborated upon here. The source tracing report message includes, but is not limited to:

[0182] Source tracing message type (i.e., Type 3);

[0183] The SenderID field contains the identification information for device A;

[0184] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0185] The Local conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device A.

[0186] The Remote conflict source field includes routing information for device H, indicating that the conflict source for the X address conflict event includes device H. The routing information for device H is the complete and accurate routing information that device A obtains from device H.

[0187] PHP fields and Adv / Redidstribute Node List fields (hereinafter referred to as Adv fields) can be 0 or empty. For descriptions of other fields, please refer to [link / reference needed]. Figure 3 This will not be elaborated upon here.

[0188] For example, device A sends a source tracing report message to its neighboring device (i.e., device B). Device B receives the source tracing report message and stores relevant information about the conflict event at address X, such as, but not limited to: routing information of the conflict source (i.e., routing information between device A and device H), and the conflicting address (e.g., address X). Optionally, device B can determine that the message is the latest message regarding the conflict event at address X based on the sequence number in the message. Device B can update the relevant information about the conflict event at address X; for example, device B can optionally delete previously recorded information about the conflict event at address X and update it with the latest obtained information, which is not limited in this application.

[0189] Device B continues to send the source tracing report message to its neighboring devices. After receiving the source tracing report message, each device in the network sends a source tracing report message to its neighboring devices. In this way, a user can log in to any network device that supports the source tracing protocol to query the details of the conflict event at address X.

[0190] In one possible implementation, after receiving a source tracing report message, if the Type field of the source tracing report message is a value other than 1 to 4, used to uniquely identify the message as a source tracing report message, device H determines that it has received a source tracing report message, and device H does not need to reply with an ACK message. In another example, if the Type field of the source tracing report message is 3, device H compares the content of the message with the relevant information of the conflict event of address X already recorded locally, and can determine that the message is a source tracing report message; device H does not need to reply with an ACK message. This is to avoid misidentifying the source tracing report message as a source tracing query message and thus repeatedly replying with an ACK message.

[0191] In another possible implementation, if the sources of the X address conflict are within the same routing domain, the source lookup message and source report message are flooded among devices within the same routing domain during flooding.

[0192] Figure 8 This is an illustrative diagram of an application scenario; please refer to it. Figure 8 In this scenario, the first device is device A (abbreviated as A), and the second device is device H (abbreviated as H). There is a conflict at address X between the first device (device A) and the second device (device H), making both the first and second devices sources of the conflict. The scenario also includes devices B through G (abbreviated as B through G).

[0193] Optionally, the first device and the second device are in the same routing domain, and all network devices in the routing domain except for device C support the tracing protocol.

[0194] Please refer to Figure 8 In this application, devices in the network establish neighbor relationships. The neighbor establishment process can refer to existing technical embodiments, and will not be described in detail here. For example, device A and device B establish BGP neighbors (or OSPF (Open Shortest Path First), ISIS (Intermediate System to Intermediate System) neighbors, etc., which are not limited here), device B and device C establish BGP neighbors, device B and device D establish BGP neighbors, etc., and will not be described one by one here. That is to say, in the embodiments of this application, a device can establish neighbors with at least one other device.

[0195] For example, neighboring devices negotiate traceability capabilities. Taking device A and device B as an example, after device A enables traceability capabilities, device A sends a traceability capability negotiation message to device B. This message indicates that device A supports the traceability protocol and requests a query to determine if device B also supports it. The traceability capability negotiation message includes, but is not limited to: traceability message type (e.g., Type 1), a SenderID field indicating device A's identification information, a Track conflict sourcecapability field indicating device A's support for the traceability protocol, and a Need ACK field indicating the need for an ACK response. Other fields can be found in [reference needed]. Figure 4 The relevant descriptions will not be repeated here.

[0196] For example, neighboring devices negotiate traceability capabilities. Taking device A and device B as an example, after device A enables traceability capabilities, device A sends a traceability capability negotiation message to device B. This message indicates that device A supports the traceability protocol and requests a query to determine if device B also supports it. The traceability capability negotiation message includes, but is not limited to: traceability message type (e.g., Type 1), a SenderID field indicating device A's identification information, a Track conflict sourcecapability field indicating device A's support for the traceability protocol, and a Need ACK field indicating the need for an ACK response. Other fields can be found in [reference needed]. Figure 4 The relevant descriptions will not be repeated here.

[0197] Upon receiving the traceability capability negotiation message, Device B determines that Device A supports the traceability protocol. Device B records locally that Device A supports the traceability protocol. Device B then sends a traceability capability negotiation response message back to Device A. This response message indicates that Device B has received Device A's traceability capability negotiation message and that Device B supports the traceability protocol. The response message includes, but is not limited to: the traceability message type (Type 2), the SenderID field (Device B's identifier), and the Track conflict source capability ACK field indicating that Device B has received Device A's traceability capability negotiation message and supports the traceability protocol. Upon receiving the traceability capability negotiation response message from Device B, Device A determines that Device B supports the traceability protocol and records locally that Device B supports the traceability protocol. The traceability capability negotiation between Device A and Device B is successful.

[0198] Device B enables traceability and, having not received a traceability negotiation message from its neighbor Device C, sends a traceability negotiation message to Device C. In this scenario, Device C does not support the traceability protocol; consequently, Device C is not listening to the specified interface and does not receive the traceability negotiation message. If Device B does not receive a traceability negotiation response message from Device C within a preset time period (which can be set according to actual needs, not limited in this application), Device B can resend the traceability negotiation message multiple times. After resending the traceability negotiation message twice (which can be set according to actual needs, not limited in this application), and failing to receive the corresponding traceability negotiation response message on both resends, Device B determines that Device C does not support the traceability protocol. That is, the traceability negotiation between Device B and Device C fails. Similarly, the traceability negotiation between Device C and Device E fails. Traceability negotiation between other devices succeeds; for details not described, please refer to [link to relevant documentation]. Figure 7 This will not be elaborated upon here.

[0199] Please continue to refer to Figure 8 Device A (which can be understood as the first device involved in this application) responds to the received user instruction and determines that the network address information to be detected is address X. Based on routing information (including routing tables or routing databases, etc., which are not limited in this application), device A determines that a collision event has occurred at address X, and that the other source of the collision is device H.

[0200] For example, device A sends a source tracing query message to device H via flooding in the network. The message format and field content can be found in [reference needed]. Figure 7 This will not be elaborated upon here.

[0201] Still refer to Figure 8 Device A sends a source tracing query message to its neighbor, Device B. Device B receives the message and, based on the source tracing capability negotiation results, determines that neighboring Device C does not support the source tracing protocol, while neighboring Device D does. Accordingly, Device B sends a source tracing query message to Device D, but not to Device C, thus avoiding being identified as an attack message by Device C and preventing interference with Device C's routing function. Other network devices follow the same procedure. Figure 7 The description and processing in the text will not be repeated here.

[0202] In this example, device C does not support the tracing protocol. Consequently, device E cannot obtain the tracing query message from device C. During the flooding of tracing query messages, after receiving the tracing query message, device G sends it to its neighboring devices. Device E acts as the tracing query message for device G, and device G sends the tracing query message to its neighbor device E. This can be understood as devices that are neighbors in the network flooding tracing query messages to their next-hop neighbors. If a device receives a tracing query message from a peer, that device can then forward the tracing query message to other neighboring devices that have not sent tracing query messages to it. Figure 7 In the scenario shown, if device G receives a traceability query message sent by device F, but has not yet received a traceability query message sent by device E, device G can also send a traceability query message to device E. After receiving the traceability query message sent by device G, device E will not send a traceability query message to device G again, but will send traceability query messages to other neighboring devices of device E (not shown in the figure).

[0203] For example, when device H receives a source tracing query message, it can determine, based on routing information, that it is indeed the source device of the conflict, i.e., a conflict with device A over address X. Device H sends a source tracing query response message 1 to device A, indicating that device H is the source device of the conflict. In response to the received source tracing query response message 1, device A determines that device H is another source of the conflict over address X. Device A sends a source tracing query response message 2 to device B, indicating that device A has received device H's source tracing query response message 1. For a more detailed description, please refer to [link to relevant documentation]. Figure 7 This will not be elaborated upon here.

[0204] For example, device A floods source tracing report messages across the network. A description of the source tracing report message can be found in [reference needed]. Figure 7 This will not be elaborated upon here. Figure 8 In the scenario shown, device C does not support the tracing protocol. Therefore, during the flooding transmission of tracing report messages, to avoid affecting device C's routing function, its flooding method is the same as that of tracing query messages. That is, device G sends tracing report messages to device E. The flooding transmission methods of other devices can be referred to [the relevant protocol]. Figure 7 This will not be elaborated upon here.

[0205] Figure 9 This is an illustrative diagram of an application scenario; please refer to it. Figure 9 In this scenario, the first device is device A (abbreviated as A), and the second device is device H (abbreviated as H). There is a conflict at address X between the first device (device A) and the second device (device H), making both the first and second devices sources of the conflict. The scenario also includes devices B through G (abbreviated as B through G).

[0206] Optionally, the first device and the second device are in the same routing domain, and all network devices in the routing domain except for device C and device D support the tracing protocol.

[0207] Devices in the network negotiate traceability capabilities. The traceability capability negotiation process can be referred to above and will not be repeated here. In this example, device C does not support the traceability protocol. Consequently, devices B and E both fail to negotiate with device C. Related descriptions can be found in [link to relevant documentation]. Figure 8 This will not be elaborated upon here.

[0208] Please continue to refer to Figure 9 Device A (which can be understood as the first device involved in this application) responds to the received user instruction and determines that the network address information to be detected is address X. Based on routing information (including routing tables or routing databases, etc., which are not limited in this application), device A determines that a collision event has occurred at address X, and that the other source of the collision is device H.

[0209] For example, device A sends a source lookup message to device H via flooding in the network. Device A then sends a source lookup message to its neighbor device B. Device B receives the source lookup message and, based on the source lookup capability negotiation results, determines that neighbor devices C and D do not support the source lookup protocol. Therefore, device B will no longer send source lookup messages to devices C and B. Thus, in this example, device H does not receive the source lookup message from device A with the sender ID. Consequently, device A does not receive the response message from device H after sending the source lookup message.

[0210] For example, after a preset time period (which can be set according to actual needs, and is not limited in this application), device A directly sends a traceability query message to device H. The transmission path can be set according to actual needs, and is not limited in this application.

[0211] In response to the received source lookup message, device H can determine, based on routing information, that it is indeed the source device of the conflict, i.e., that a conflict with device A occurred at address X. Optionally, device H can continue to send source lookup messages to its neighboring devices, for example, such as... Figure 9 As shown, device H can send a source query message to its neighbor device G, and neighbor device G can send source query messages to devices E and F. In some instances, device H may choose not to continue flooding source query messages; this application does not impose any limitations on this. In this example, in the source query message sent by device H, the Sender ID field is the identification information of device H, the Local Conflict Source field is the routing information of device H, and the Remote Conflict Source field is the routing information of device A.

[0212] For example, device H sends a source tracing query response message to device A. The source tracing query response message is used to indicate that device H is the source device of the conflict. Optionally, the transmission path for device H to directly send the source tracing query response message to device A can be set based on actual needs, and this application does not limit it. The relevant description of the source tracing query response message can be referred to above, and will not be repeated here.

[0213] In response to the received source tracing query response message, device A determines that device H is another source of the conflict event at address X. Optionally, device A may directly send a source tracing query response message to device H to indicate that it has received the response message sent by device H.

[0214] Still refer to Figure 9 For example, device A floods source tracing report messages across the network. The message structure of the source tracing report message can be found in [reference needed]. Figure 2 This will not be elaborated upon here. The source tracing report message includes, but is not limited to:

[0215] Source tracing message type (i.e., Type 3);

[0216] The SenderID field contains the identification information for device A;

[0217] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0218] The Local conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device A.

[0219] The Remote conflict source field includes routing information for device H, indicating that the conflict source for the X address conflict event includes device H. The routing information for device H is the complete and accurate routing information that device A obtains from device H.

[0220] PHP fields and Adv / Redidstribute Node List fields (hereinafter referred to as Adv fields) can be 0 or empty. For descriptions of other fields, please refer to [link / reference needed]. Figure 3 This will not be elaborated upon here.

[0221] For example, device A sends a source tracing report message to its neighboring device (i.e., device B). Device B receives the source tracing report message and stores relevant information about the conflict event at address X, such as, but not limited to: routing information of the conflict source (i.e., routing information between device A and device H), and the conflicting address (e.g., address X). Optionally, device B can determine that the message is the latest message regarding the conflict event at address X based on the sequence number in the message. Device B can update the relevant information about the conflict event at address X; for example, device B can optionally delete previously recorded information about the conflict event at address X and update it with the latest obtained information, which is not limited in this application.

[0222] Based on the traceability capability negotiation results, device B determines that neither its neighboring device C nor its neighboring device D supports the traceability protocol. Device B will no longer flood traceability report messages.

[0223] In this example, after device H sends a source tracing query response message, it does not receive a source tracing report message within a predetermined time period (which can be set according to actual needs; this application does not limit this period). Device H, as the initiator, continues to flood the source tracing report message across the network in place of device A.

[0224] The traceability report messages sent by device H include, but are not limited to:

[0225] Source tracing message type (i.e., Type 3);

[0226] The SenderID field contains the identification information for device H;

[0227] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0228] The Local conflict source field includes routing information for device H, indicating that the conflict source for the conflict event at address X includes device A;

[0229] The Remote conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device H;

[0230] PHP fields and Adv / Redidstribute Node List fields (hereinafter referred to as Adv fields) can be 0 or empty. For descriptions of other fields, please refer to [link / reference needed]. Figure 3 This will not be elaborated upon here.

[0231] Still refer to Figure 9Device H sends a source tracing report message to its neighbor device G. Device G receives the source tracing report message sent by device H and continues to send source tracing report messages to neighbor devices E and F. Details not described herein can be found above and will not be repeated here.

[0232] Figure 10 This is an illustrative diagram of an application scenario; please refer to it. Figure 10 In this scenario, the first device is device A (abbreviated as A), and the second device is device Z (abbreviated as Z). There is a conflict event between the first device (i.e. device A) and the second device (i.e. device Z) at address X. Both the first device and the second device are sources of conflict.

[0233] Optionally, the first device and the second device are in different routing domains. For example, the first device (i.e., device A) belongs to the first routing domain (which can also be called the first network), and the first routing domain also includes devices B to H. The second device (i.e., device Z) belongs to the second routing domain (which can also be called the second network), and the second routing domain includes, but is not limited to, devices H, M, and Z. Device H is the ASBR device between the first and second routing domains. All devices in the network (including the first and second networks) support the tracing protocol. Optionally, the number of devices in the second routing domain is only an illustrative example, and the second routing domain can include more network devices; this application is not limited. Optionally, device H acting as the ASBR between the first and second networks is only an illustrative distance, and device H can also span multiple routing domains; this application is not limited.

[0234] Please refer to Figure 10 In this network (including the first and second networks), devices establish neighbor relationships, and neighboring devices negotiate source tracing capabilities. A detailed description can be found above and will not be repeated here. For example, device A, based on routing information, determines that it has a conflict with device H at address X. In this example, device H is identified as the conflict source by device A. However, in reality, device Z is the conflict source, and device H is an edge network device of the first network. Therefore, device A identifies device H as the conflict source. This is the scenario mentioned above where device A incorrectly identifies the conflict source.

[0235] In this embodiment, device A transmits a source tracing query message to the conflict source device Z via flooding within the network. Specifically, device A floods the source tracing query message within the first network, and then device H floods the source tracing query message within the second network.

[0236] Please refer to Figure 10 Device A floods source tracing query messages within the first network. Specifically, Device A sends source tracing query messages to its neighboring device (i.e., Device B). The structure of the source tracing query message can be found in [reference needed]. Figure 3The description in the source tracing query message includes, but is not limited to:

[0237] Source tracing message type (i.e., Type 3);

[0238] The SenderID field contains the identification information for device A;

[0239] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0240] The Local conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device A.

[0241] The Remote conflict source field includes partial or complete routing information for device H, indicating that the conflict source of the conflict event for address X includes device H;

[0242] PHP fields and Adv / Redidstribute Node List fields (hereinafter referred to as Adv fields) can be 0 or empty. For descriptions of other fields, please refer to [link / reference needed]. Figure 3 This will not be elaborated upon here.

[0243] The flooding method of source tracing query messages in the first network can be referred to Figure 7 This will not be elaborated upon here.

[0244] For example, when device H receives a source tracing query message, device H can determine itself as a non-conflict source device based on routing information, and determine that the device with the X address conflict with device A is device Z. Device H sends a source tracing query response message 1 to device A to indicate that device H is not a conflict source. The source tracing query response message 1 includes, but is not limited to:

[0245] The Type field is 4, which indicates that the type of the traceability message is an ACK message;

[0246] The Sender ID field contains the identification information for device H;

[0247] The Sender Name field is the route name for device H;

[0248] The Conflict address field is the X address;

[0249] The Local Conflict Source field can be empty;

[0250] The Remote Conflict Source field contains routing information for device A, indicating that another source of conflict is device A. This routing information for device A is obtained by device H from the source lookup message. This can be understood as the routing information for the conflict source in the source lookup response message returned by device H being accurate and essentially complete.

[0251] The ACK field being 0 indicates that the device H received the source query message, and that the message is an ACK message that is a response message based on the source query message, and that the device H is a non-conflict source; where device H may be an ABR or an ASBR.

[0252] The New Remote Conflict Source field includes, but is not limited to, all or part of the routing information for device Z, to indicate that another source of conflict is device Z;

[0253] The Adv field includes routing information for the second routing domain to which device Z belongs, as detailed above; it will not be repeated here.

[0254] The Track Forward and PHP fields are either 0 or empty. For descriptions of other fields, please refer to the above text, and they will not be repeated here.

[0255] In response to the received source tracing query response message 1, device A determines that device Z may be another source of the conflict event at address X. Device A sends a source tracing probe message to device H. Optionally, the source tracing probe message can reuse the format of the source tracing query response message, or it can be other message formats; this application does not limit this. In this embodiment, the source tracing probe message and the source tracing query response message have the same format, which is an example. The source tracing probe message includes, but is not limited to:

[0256] The Type field is 4, which indicates that the type of the source tracing message is an ACK message. It can also be other types to indicate that it is a source tracing probe message. This application does not limit it.

[0257] The Sender ID field contains the identification information for device A;

[0258] The Sender Name field is the route name for device A;

[0259] The Conflict address field is the X address;

[0260] The Local Conflict Source field contains routing information for device A, indicating the source of the conflict for device A at address X.

[0261] The Remote Conflict Source field contains routing information for device Z, indicating that another source of conflict is device Z. This routing information for device Z is obtained by device A from the source tracing response message sent by device H.

[0262] The ACK field being 1 indicates that device A has received a traceability query response message, and that the message is an ACK message replied to based on traceability query response message 1, i.e., a response message.

[0263] The New Remote Conflict Source field can optionally be empty;

[0264] The Adv field includes routing information for the second routing domain to which device Z belongs, as detailed above; it will not be repeated here.

[0265] The Track Forward field includes forward probe indication information (e.g., a value of 1), which instructs device H to continue probing forward;

[0266] PHP fields are 0 or empty. For descriptions of other fields, please refer to the above text, and they will not be repeated here.

[0267] Device H receives a source tracing probe message sent by Device A. In response to the received source tracing probe message, Device H continues to probe forward, which can also be understood as replacing Device A in flooding source tracing query messages in the second network.

[0268] Specifically, device H floods a source lookup message within the second network to indicate that there is an address conflict between device A and device Z. The source lookup message includes, but is not limited to:

[0269] Source tracing message type (i.e., Type 3);

[0270] The SenderID field contains the identification information for device H;

[0271] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0272] The Local conflict source field includes the routing information of device A, that is, the conflict source used to indicate the conflict event at address X includes device A; where the routing information of device A is the complete routing information obtained by device H from device A.

[0273] The Remote conflict source field includes partial or complete routing information for device Z, indicating that the conflict source of the conflict event at address X includes device Z; where the routing information of device Z is obtained by device H from the routing information stored locally.

[0274] The Adv field includes routing information for the second routing domain to which device Z belongs, as detailed above; it will not be repeated here.

[0275] PHP fields can be 0 or empty. See the descriptions for other fields. Figure 3 This will not be elaborated upon here.

[0276] Specifically, device H sends a source tracing query message to its neighboring device M, and neighboring device M forwards the source tracing query message to its neighboring device Z (and may also include other neighboring devices, which are not limited in this application). The specific flooding method can be found above and will not be repeated here.

[0277] For example, device Z receives a source tracing query message. Optionally, device Z may continue to flood the source tracing query message; this application does not limit this.

[0278] Specifically, device Z can determine, based on routing information, that it is indeed the source of the conflict, i.e., a conflict event involving address X occurs with device A.

[0279] Device Z sends a source tracing query response message 2 to Device A. Message 2 indicates that Device Z is the source of the conflict. The message format of message 2 can be found in [reference needed]. Figure 6 The source tracing query response report 2 includes, but is not limited to:

[0280] The Type field is 4, which indicates that the type of the traceability message is an ACK message;

[0281] The Sender ID field contains the identification information for device Z;

[0282] The Sender Name field is the route name for device Z;

[0283] The Conflict address field is the X address;

[0284] The Local Conflict Source field contains the routing information for device Z, which indicates the source of the conflict event where device Z is the target of address X. The routing information carried in the message sent by device Z is the routing information stored locally by device Z. This routing information is accurate and can be used to accurately locate the position of device Z in the network.

[0285] The Remote Conflict Source field contains routing information for device A, indicating that another source of conflict is device A. This routing information for device A is what device Z obtained from the source lookup message. This can be understood as the routing information for the conflict source in the source lookup response message returned by device Z being accurate and essentially complete.

[0286] The ACK field being 1 indicates that device Z has received the source tracing query message, and that the message is an ACK message, i.e., a response message, based on the source tracing query message.

[0287] The Adv field includes routing information for the second routing domain to which device Z belongs, as detailed above; it will not be repeated here.

[0288] The New Remote Conflict Source, Track Forward, and PHP fields are 0 or empty. For descriptions of other fields, please refer to the above text, which will not be repeated here.

[0289] In response to the received source tracing query response message 2, device A determines that device Z is another source of the collision event for address X. Device A stores the routing information for address X and the collision sources (including device A and device Z).

[0290] Optionally, device A sends a source tracing query response message 3 to device Z, indicating that device A has received device Z's source tracing query response message 2. In this message 3, the Local Conflict Source field contains device A's routing information, and the Remote Conflict Source field contains device Z's routing information. The routing information for device Z in the source tracing query response message 3 sent by device A is the routing information obtained by device A from device Z, and can be understood as complete and accurate routing information for device Z. Other fields are described above and will not be repeated here.

[0291] For example, device A floods a source tracing report message in the network (including the first network and the second network). The source tracing report message is used to indicate that a collision event occurred between device A and device Z at address X. The message structure of the source tracing report message can be found in [reference]. Figure 2 This will not be elaborated upon here. The source tracing report message includes, but is not limited to:

[0292] Source tracing message type (i.e., Type 3);

[0293] The SenderID field contains the identification information for device A;

[0294] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0295] The Local conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device A.

[0296] The Remote conflict source field includes routing information for device Z, indicating that the conflict source for the conflict event at address X includes device Z. The routing information for device Z is the complete and accurate routing information that device A obtains from device Z.

[0297] The Adv field includes routing information for the second routing domain to which device Z belongs, as detailed above; it will not be repeated here.

[0298] PHP fields can be 0 or empty. See the descriptions for other fields. Figure 3 This will not be elaborated upon here.

[0299] Specifically, device A floods the source tracing report message in the first network, and then device H floods the source tracing report message in the second network. The specific flooding method of device A in the first network is described above and will not be repeated here. Device H receives the source tracing report message, determines that the message type is a source tracing report message, and can determine the other routing domain to be flooded based on the Adv field, which is the second routing domain. Device H sends the source tracing report message to its neighbor device M located in the second routing domain. The flooding methods of other devices are described above and will not be repeated here. Optionally, the Sender ID in the source tracing report message flooded by device H in the second network can still be the identification information of device A, or it can be the identification information of device H; this application does not limit this. Undescribed parts are described above and will not be repeated here.

[0300] Figure 11 This is an illustrative diagram of an application scenario; please refer to it. Figure 11 In this scenario, the first device is device A (abbreviated as A), and the second device is device Z (abbreviated as Z). There is a conflict event between the first device (i.e. device A) and the second device (i.e. device Z) at address X. Both the first device and the second device are sources of conflict.

[0301] Optionally, the first device and the second device are in different routing domains. For example, the first device (i.e., device A) belongs to the first routing domain (which can also be called the first network), and the first routing domain also includes devices B to H. The second device (i.e., device Z) belongs to the second routing domain (which can also be called the second network), and the second routing domain includes, but is not limited to, devices H, M, and Z. Device H is the ASBR device between the first and second routing domains. Optionally, all network devices in the network (including the first and second networks) except for device C support the source tracing protocol.

[0302] Please refer to Figure 11Devices in the network (including the first and second networks) establish neighbor relationships, and neighboring devices negotiate traceability capabilities. For details, please refer to the above; they will not be repeated here. In this example, device B fails to negotiate with device C, and device C fails to negotiate with device E. For details, please refer to [link to relevant documentation]. Figure 8 This will not be elaborated upon here.

[0303] For example, device A determines, based on routing information, that there is a conflict with device H at address X. Device A then transmits a source lookup message to the conflict source device Z via flooding within the network. (For details not described, please refer to...) Figure 10 This will not be elaborated upon here.

[0304] In this example, during the flooding process of device A in the first network, device C does not support the traceability protocol. Accordingly, the flooding method in the first network can be referred to Figure 8 The description in [the previous text] will not be repeated here. The flooding methods in the second network can be found in [the relevant documentation]. Figure 10 The description in the text will not be repeated here.

[0305] In response to the received source tracing query message, device Z sends a source tracing query response message 2 to device A to determine that device Z is another source of conflict. In response to the received source tracing query response message 2, device A sends a source tracing query response message 3 to device Z. Figure 11 The execution process of the scene can be referred to Figure 10 This will not be elaborated upon here.

[0306] For example, device A floods a source report message in the network (including the first network and the second network) to indicate that a conflict event occurred between device A and device Z at address X. The flooding process of the source report message in the first network can be referred to... Figure 8 The relevant descriptions and source tracing report messages regarding the flooding process in the second network can be found by referring to... Figure 10 The relevant descriptions in the document will not be repeated here.

[0307] Figure 12 This is an illustrative diagram of an application scenario; please refer to it. Figure 12 In this scenario, the first device is device A (abbreviated as A), and the second device is device Z (abbreviated as Z). There is a conflict event between the first device (i.e. device A) and the second device (i.e. device Z) at address X. Both the first device and the second device are sources of conflict.

[0308] Optionally, the first device and the second device reside in different routing domains. For example, the first device (i.e., device A) belongs to the first routing domain (which can also be called the first network), and the first routing domain also includes devices B to H. The second device (i.e., device Z) belongs to the second routing domain (which can also be called the second network), and the second routing domain includes, but is not limited to, devices H, M, and Z. Device H is the ASBR device between the first and second routing domains. Optionally, all network devices in the network (including the first and second networks) except for devices C and D support the tracing protocol.

[0309] Please refer to Figure 12 Devices in the network (including the first and second networks) establish neighbor relationships, and neighboring devices negotiate source tracing capabilities. For details, please refer to the above; they will not be repeated here. In this example, device B fails to negotiate with device C, device C fails to negotiate with device E, device B fails to negotiate with device D, and device D fails to negotiate with device F. For details, please refer to... Figure 9 This will not be elaborated upon here.

[0310] For example, device A determines, based on routing information, that there is a conflict with device H at address X. Device A then transmits a source lookup message to the conflict source device Z via flooding within the network. (For details not described, please refer to...) Figure 10 This will not be elaborated upon here.

[0311] In this example, during the flooding process of device A in the first network, devices C and D do not support the traceability protocol. Accordingly, the flooding method in the first network can be referred to Figure 9 The description in the document states that device A sends a source tracing query message to device H. For details, please refer to [the relevant documentation / reference]. Figure 9 This will not be elaborated further here. Device H is not a conflict source device. Device H sends a source tracing query response message 1 to Device A to deny that Device H is a conflict source device and indicates that Device Z in the second network may be another conflict source. Device A sends a source tracing probe message to Device H to instruct Device H to probe for conflict sources in the second network. The flooding method and source tracing method in the second network can be found in [reference needed]. Figure 10 The descriptions in the previous section will not be repeated here. Of course, in some instances, there may be devices in the second network that do not support the traceability protocol. For specific handling of such devices, please refer to the above text, which will not be repeated here.

[0312] In response to the received source tracing query message, device Z sends a source tracing query response message 2 to device A to determine that device Z is another source of conflict. In response to the received source tracing query response message 2, device A sends a source tracing query response message 3 to device Z. Figure 12 The execution process of the scene can be referred to Figure 10 This will not be elaborated upon here.

[0313] For example, device A floods a source report message in the network (including the first network and the second network) to indicate that a conflict event occurred between device A and device Z at address X. The flooding process of the source report message in the first network can be referred to... Figure 9 The relevant descriptions and source tracing report messages regarding the flooding process in the second network can be found by referring to... Figure 10 The relevant descriptions in the document will not be repeated here.

[0314] Figure 13 This is an illustrative diagram of an application scenario; please refer to it. Figure 13 In this scenario, the first device is device A (abbreviated as A), and the second device is device H (abbreviated as H). There is an address conflict between device A and device Y, with both device A and device Y being conflict sources. Device H is the penultimate hop device in the transmission path from device A to device Y (meaning the penultimate hop device among devices supporting the tracing protocol on the path; there may be at least one other device between device H and device Y that does not support the tracing protocol). In other words, this application can accurately locate the conflict source even if the conflict source device does not support the tracing protocol, based on the location of the network device closest to the conflict source (meaning the shortest transmission path).

[0315] Optionally, Figure 13 All network devices shown can belong to the same routing domain. Optionally, device A and device H can belong to the same routing domain, device A and device Y can belong to different routing domains, and device H can be an ASBR device. This application does not impose any limitations. In this example, it is illustrated by the premise that all devices except device Y support the tracing protocol. Of course, this scenario can also be combined with the above. Figure 8 or Figure 9 The network shown may contain other devices that do not support the traceability protocol, but this application does not limit this scenario.

[0316] Please refer to Figure 13 Specifically, neighboring devices negotiate their source tracing capabilities. A detailed description can be found above and will not be repeated here. For example, device A, based on routing information, determines that there is a conflict event with device Y at address X.

[0317] In this embodiment, device A transmits a source tracing query message to the conflict source device Y via flooding within the network. Specifically, device A sends the source tracing query message to its neighboring device (i.e., device B). The structure of the source tracing query message can be found in [reference needed]. Figure 3 The description in the source tracing query message includes, but is not limited to:

[0318] Source tracing message type (i.e., Type 3);

[0319] The SenderID field contains the identification information for device A;

[0320] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0321] The Local conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device A.

[0322] The Remote conflict source field includes partial or complete routing information for device Y, indicating that the conflict source of the conflict event at address X includes device Y;

[0323] PHP fields and Adv / Redidstribute Node List fields (hereinafter referred to as Adv fields) can be 0 or empty. For descriptions of other fields, please refer to [link / reference needed]. Figure 3 This will not be elaborated upon here.

[0324] The specific flooding process can be referred to above, and will not be repeated here. In this example, device Y does not support the traceability protocol. Therefore, based on the negotiation result, device H determines that device Y does not support the traceability protocol, and accordingly, device H does not send a traceability query message to device Y.

[0325] For example, after a preset time (which can be set according to actual needs, and is not limited in this application) has elapsed, if device A does not receive a response message corresponding to the traceability query message, device A will directly send the traceability query message to device Y. Similarly, since device Y does not support the traceability protocol, device Y will not receive the traceability query message. If device A does not receive a traceability query response message from device Y within a predetermined time (which can be set according to actual needs, and is not limited in this application), device A may, optionally, repeatedly send the traceability query message to device Y multiple times (e.g., twice, which can be set according to actual needs, and is not limited in this application).

[0326] In this example, device A queries the penultimate hop device on the transmission path from device A to device Y based on routing information (including routing tables or routing databases). For example, in this example, the penultimate hop device is device H. Device A sends a penultimate hop query message to device H.

[0327] In one possible implementation, the penultimate hop device described in the embodiments of this application can be understood as the penultimate hop device that supports the traceability protocol on the support path, or as the last hop device that supports the traceability protocol on the transmission path from device A to device Y. This application does not limit it.

[0328] In another possible implementation Figure 12This example illustrates the situation using device H as the penultimate hop device of device Y. In other embodiments, at least one device that does not support the tracing protocol may exist between device Y and device H. For example, in this scenario, there might be a device M that does not support the tracing protocol. Device A can send a penultimate hop query message to device M. If device A does not receive a response from device M within a preset time period, device A can query the previous hop device of device M based on routing information, which is the third-to-last hop device on the transmission path from device A to device Y. Device A then sends a penultimate hop query message to device H. If device A receives a penultimate hop query response message from device H, then device A can determine that device H is the penultimate hop device from device A to device Y, i.e., a penultimate hop device that supports the tracing protocol.

[0329] Optionally, the penultimate hop query message can have the same message format as the source lookup query message, or it can have other message formats; this application does not limit this. This application uses the example of the penultimate hop query message having the same format as the source lookup query message for illustration. The penultimate hop query message includes, but is not limited to, at least one of the following:

[0330] Source tracing message type (i.e., Type 3);

[0331] The SenderID field contains the identification information for device A;

[0332] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0333] The Local conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device A.

[0334] The Remote conflict source field includes partial or complete routing information for device Y, indicating that the conflict source of the conflict event at address X includes device Y;

[0335] The PHP field includes penultimate hop query information, used to check whether the message receiver (i.e., device H) is the penultimate hop device;

[0336] The Adv field can be 0 or empty. For descriptions of other fields, please refer to [link / reference]. Figure 3 This will not be elaborated upon here.

[0337] For example, device H receives a penultimate hop query message. Based on routing information, device H determines that it is the penultimate hop device supporting the tracing protocol on the transmission path from device A to device Y. Device H sends a penultimate hop query response message to device A. In this embodiment, the message format of the penultimate hop response message is the same as that of the tracing query response message. In other embodiments, the message can be in other formats, and this application does not limit this. The penultimate hop query response message includes, but is not limited to, at least one of the following:

[0338] The Type field is 4, which indicates that the type of the traceability message is an ACK message;

[0339] The Sender ID field contains the identification information for device H;

[0340] The Sender Name field is the route name for device H;

[0341] The Conflict address field is the X address;

[0342] The Local Conflict Source field contains routing information for device A, indicating the source of the conflict for device A at address X.

[0343] The Remote Conflict Source field includes partial or complete routing information for device Y, indicating that the source of the conflict event for address X includes device Y. Of course, in some instances, the Local Conflict Source field can also be the routing information for device Y, and the Remote Conflict Source field can include the routing information for device A. This application does not impose any limitations on this.

[0344] The ACK field being 1 indicates that device H received the penultimate hop query message, and that the message is an ACK message replied to based on the penultimate hop message, i.e., a response message, and that device H is the penultimate hop device;

[0345] The PHP field includes routing information for device H; that is, device H obtains complete and correct routing information for device H stored locally and sends it to device A via the PHP field; this field is used to indicate that device H is the penultimate hop device.

[0346] The New Remote Conflict Source, Track Forward, and Adv fields are 0 or empty. The descriptions of other fields can be found above and will not be repeated here.

[0347] For example, device A receives a penultimate hop query response message, determining that device H is the penultimate hop device on the transmission path from device A to the conflict source device Y. Device A floods a source report message in the network, indicating that a conflict event occurred between device A and device Y at address X, and that device H is the penultimate hop device. The source report message includes, but is not limited to, at least one of the following:

[0348] Source tracing message type (i.e., Type 3);

[0349] The SenderID field contains the identification information for device A;

[0350] The Conflict address field is the X address, used to indicate a conflict event that occurred at the X address;

[0351] The Local conflict source field includes routing information for device A, indicating that the conflict source of the conflict event at address X includes device A.

[0352] The Remote conflict source field includes all or part of the routing information for device Y;

[0353] The PHP field includes the routing information for device H; this information is the complete and correct routing information for device H obtained by device A from device H.

[0354] The Adv / Redidstribute Node List field (hereinafter referred to as the Adv field) can be 0 or empty. For descriptions of other fields, please refer to [link / reference needed]. Figure 3 This will not be elaborated upon here.

[0355] For specific flood control methods, please refer to the above text; they will not be repeated here.

[0356] In summary, this application provides a conflict detection method that allows devices to proactively check for risks. For example, users can use commands to perform conflict detection on a new address to be configured, thereby detecting whether the new address might conflict and preventing service interruptions caused by address conflicts after configuration.

[0357] This application also provides a conflict tracing method, which allows the device to trace the source of a conflict event when it is detected, enabling operators to locate and investigate the source of the conflict in a timely manner.

[0358] The solution provided in this application embodiment can realize conflict detection and conflict source tracing of address information within a single routing domain, such as... Figure 14 As shown. The solution provided in this embodiment can also perform conflict detection and conflict tracing in cross-routing domain scenarios, such as... Figure 15 As shown.

[0359] Furthermore, the solution provided in this application embodiment can realize conflict detection and conflict source identification of address information in the public network, as well as conflict detection and conflict source identification of VPN private network addresses, such as... Figure 16 As shown. Furthermore, conflict detection and source tracing are performed on scenarios involving the merging of two or more routing domains (which can also be understood as networks). For example, before network merging, the device can perform conflict detection and source tracing on network addresses, thereby avoiding address conflicts after the merging of multiple routing domains, which could lead to service interruptions.

[0360] In this embodiment of the application, any device in the network can obtain relevant information about the conflict event through flooding transmission. Operators can log in to any device in the network to obtain relevant information about the conflict event, thereby locating and investigating the source of the conflict event and further improving the efficiency of conflict event handling.

[0361] In this embodiment of the application, if some devices in the network do not support the tracing protocol, the devices can use a leapfrog approach to flood the transmission of messages during the tracing process. The devices that do not support the tracing protocol can include at least one scenario where at least one device within the same routing domain does not support the tracing protocol, the source of the conflict does not support the tracing protocol (this may or may not be within the same routing domain), or at least one device in different routing domains does not support the tracing protocol. Figure 17 As shown.

[0362] After the network address is configured, this application can automatically detect conflicts and trace the source of conflict events, enabling operators to investigate conflicts in a timely manner and intercept conflict events in real time.

[0363] Furthermore, in this embodiment of the application, the message query and response mechanism enables the device to obtain accurate routing information of the conflict source, allowing operators to quickly and accurately locate the conflict source and promptly investigate and resolve conflict events.

[0364] This application embodiment also provides a path restoration method, in which a first device sends a path query message to a second device to detect whether the path to which the second device belongs is within the planning range, and can further determine whether there are any abnormalities in the path within the planning range.

[0365] Figure 18 For a flowchart illustrating the path restoration method, please refer to [link / reference]. Figure 18 Specifically, including but not limited to the following steps:

[0366] S1801, the first device obtains the target network address information.

[0367] For example, in response to a received user instruction, the first device obtains target network address information. The target network address information belongs to the target device, and the user instruction is used to instruct the probe to determine the attributes and status of at least one path between the first device and the target device. In this embodiment, the path attributes include planned paths and unplanned paths. The path status includes normal status and abnormal status.

[0368] The planned path can optionally be the path recorded in the path information of the first device. For example, the communication path between the first device and the second device may include a first path, a second path, and a third path. The first device selects the first path as the optimal path according to the routing protocol and communicates with the second device through the first path. In this example, the first path, the second path, and the third path are all planned paths, and the routing information corresponding to the paths (including the routing information of each device on the path) is stored in the routing information of the first device (e.g., a routing table or a routing database). The first path can be called the primary path, and the second and third paths can be called backup paths. If there is a fourth path between the first device and the second device, but the fourth path is not stored in the routing information of the first path, that is, the first device is unaware of the fourth path, then the fourth path is called an unplanned path.

[0369] Optionally, a normal path state means that the first device can communicate with the target device through the path, that is, the communication between the devices on the path is normal. Conversely, an abnormal path state means that the first device and the target device cannot communicate through the path, which may be due to an abnormality in the communication of at least one node (or device) on the path.

[0370] Optionally, in some instances, the first device may also periodically perform a path restoration process for any network address in the network. This can be configured according to actual needs, and this application does not impose any limitations.

[0371] S1802, the first device sends a path restoration probe message to the second device.

[0372] For example, the first device sends a path query message to the second device. The path query message includes, but is not limited to, destination address information, routing information of the first device, and routing information of the second device. A path reconstruction probe message is used to query whether the destination address information originates from the second device; it can also be understood as querying whether the second device belongs to the communication path between the first device and the target device, where the target device is the device corresponding to the destination address information. In this embodiment, if the second device has learned the destination address information, then the second device belongs to the communication path between the first device and the target device. Conversely, if the second device has not learned the destination address information, then the second device does not belong to the communication path between the first device and the target device.

[0373] In this embodiment, "address information from a device" means that the user has configured the address information for that device, and that device can communicate with other devices through that address information. The first device receives a path query response message from the second device. The first device can determine the target device corresponding to the destination address based on the path query response message. The target device can be the second device or other devices.

[0374] In one possible implementation, the first device can query whether a device is on the planned path using a hop-by-hop (or leapfrog) query method. Here, "hop-by-hop" means that each device on the path supports the path restoration protocol. "Leapfrog" means that in this embodiment, if at least one device on the path does not support the path restoration protocol, then path restoration messages (including path restoration probe messages and / or path restoration response messages) are only exchanged between devices that support the path restoration protocol. In this embodiment, a device that supports the path restoration protocol refers to a device that listens on a designated port and is capable of receiving or sending path restoration messages. Its meaning is similar to that of the source tracing protocol and will not be repeated here.

[0375] In this embodiment, before executing S1801, each device in the network can determine whether a neighboring device supports the path restoration protocol by using the path restoration negotiation message and path restoration negotiation response message in the path restoration message. For example, a device can send a path restoration negotiation message to a neighboring device to indicate that it supports the path restoration protocol and to query whether the neighboring device supports it. If the neighboring device supports the restoration protocol, it will receive the path restoration negotiation message through a designated port and send back a path restoration response message to indicate that it also supports the path restoration protocol. Of course, if the neighboring device does not support the path restoration protocol (meaning the device lacks the capability, or has the capability but it is disabled), it will not receive the path restoration negotiation message. The interaction method can be referred to the path restoration protocol negotiation process, which will not be elaborated here.

[0376] Figure 19For an illustrative diagram of the structure of a path restoration capability negotiation message, please refer to... Figure 19 Specifically, including but not limited to:

[0377] The fields for Source Port, Dest Port, UDP Length, UDP Checksum, SequenceNumber, Acknowledgment Number, Version, Reserved, and SenderID are described in the source tracing protocol and will not be repeated here.

[0378] In this example, the Type field is 1, indicating that the message is a path restoration message. Optionally, in this embodiment, the path restoration protocol and the source tracing protocol can also share the same interface. In this scenario, the path restoration protocol can reuse various messages from the source tracing protocol and add fields related to path restoration. The value of the Type field can be set according to actual needs, and this application does not impose any limitations.

[0379] Path Tracing capability: This field indicates whether the local device has path tracing capability. The description is similar to that of the tracing protocol and will not be repeated here.

[0380] The "Need Ack" field indicates whether a path restoration capability negotiation response message is required; in other words, whether an ACK message is needed. Optionally, a value of 1 indicates that an ACK is required, and a value of 0 indicates that an ACK is not required.

[0381] Figure 20 For an exemplary schematic diagram of the path restoration capability negotiation response message structure, please refer to... Figure 20 Specifically, including but not limited to:

[0382] The fields Source Port, Dest Port, UDP Length, UDP Checksum, SequenceNumber, Acknowledgment Number, Version, Reserved, and SenderID are described above and will not be repeated here.

[0383] The Type field, in this example, is 2, indicating that the message is a path restoration capability negotiation response message.

[0384] Path Tracing capability ACK: This field indicates whether the local end has path tracing capability, or whether it supports the path tracing protocol. It also indicates that the local end has received the path tracing capability negotiation message sent by the other end.

[0385] For any parts not described, please refer to the traceability protocol; they will not be elaborated upon here.

[0386] In the embodiments of this application, the path restoration message, as well as the path restoration capability negotiation message, path restoration capability negotiation response message, path restoration probe message, and path restoration response message mentioned below, can all be User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or other protocol messages; this application does not impose any limitations. This application only uses UDP messages as an example for illustration; this application does not limit the message type.

[0387] Figure 21 For an exemplary schematic diagram of the path reconstruction probe message structure, please refer to... Figure 21 Specifically, including but not limited to the following fields:

[0388] Source Port: This field indicates the port from which the message was sent.

[0389] Destination Port: This field indicates the destination port of the message.

[0390] UDP Length: This field indicates the length of the message.

[0391] UDP Checksum: This field is used to indicate message verification information.

[0392] Sequence Number: This field carries the message sequence number, which indicates whether the message is the latest message.

[0393] Acknowledgment Number: This field indicates the sequence number of the ACK message (such as the source response message mentioned below).

[0394] The Type field indicates the type of message. In this embodiment, the Type value of the path restoration capability negotiation message is 1, the Type value of the path restoration capability negotiation response message is 2, the Type value of the path restoration probe message is 3, and the Type value of the path restoration response message is 4.

[0395] Version, which is used to indicate the protocol version number.

[0396] Reserved, a reserved field.

[0397] Sender ID. This field is used to indicate the sender (or called the sending device) of the path restoration message (which can be any message involved in this application, such as the path restoration probe message), and the identification information of the sending end is carried in the field. For example, it is the routing identification information of the sending end (it can also be other identifications, which are not limited in this application).

[0398] Sender name, which is used to indicate the sender of the path restoration message, and the name of the sending end is carried in the field. For example, it is the routing name, which can be set according to actual needs and is not limited in this application.

[0399] Path tracing address, which is used to carry the target network address information. It can include network address and mask, etc., which are not limited in this application.

[0400] Path Tracing info, which is used to indicate the path information of the path. Including but not limited to:

[0401] 1) Path Tracing destination ID, which can include but not limited to: routing ID, routing name, device hardware serial number (SN), etc.

[0402] 2) Path Tracing destination info, which includes but not limited to: specific physical port number, loopback number, static routing information, IGP (Interior Gateway Protocol) routing information, BGP (Border Gateway Protocol) path information, etc.

[0403] PHP (Penultimate Hop Popping), which is used in the path restoration probe message to indicate whether the query receiving end is the penultimate hop device that supports the path restoration protocol. This field is used in the path restoration response message to indicate whether the local end is the penultimate hop device.

[0404] The description of the Adv (advertise) / Redistribute node list field can be found in the traceability protocol and will not be repeated here.

[0405] In the embodiments of this application, the second device can be any device on the path or the target device.

[0406] S1803, the second device sends a path restoration detection response message to the first device.

[0407] For example, when the second device receives the path recovery probe message sent by the first device, it can send a path recovery probe response message to the first device to indicate whether the local end has learned the target network address information, which can also be understood as whether the local end is on the path between the first device and the target device.

[0408] Figure 22 For an illustrative diagram of the structure of a path reconstruction probe response message, please refer to... Figure 22 Specifically, including but not limited to the following fields:

[0409] Source Port: This field indicates the port from which the message was sent.

[0410] Destination Port: This field indicates the destination port of the message.

[0411] UDP Length: This field indicates the length of the message.

[0412] UDP Checksum: This field is used to indicate message verification information.

[0413] Sequence Number: This field carries the message sequence number, which indicates whether the message is the latest message.

[0414] Acknowledgment Number: This field indicates the sequence number of the ACK message.

[0415] The Type field indicates the type of message. In this embodiment, the Type value of the path restoration capability negotiation message is 1, the Type value of the path restoration capability negotiation response message is 2, the Type value of the path restoration probe message is 3, and the Type value of the path restoration probe response message is 4.

[0416] Version, this field is used to indicate the protocol version number.

[0417] Reserved, reserved field.

[0418] Sender ID. This field is used to indicate the sender (or called sending device) of the path restoration message (which can be any message involved in this application, such as the path restoration probe message), and the identification information of the sender is carried in the field. For example, it is the routing identification information of the sender (it can also be other identifications, which are not limited in this application).

[0419] Sender name, this field is used to indicate the sender of the path restoration message, and the name of the sender is carried in the field. For example, it is the routing name, which can be set according to actual requirements and is not limited in this application.

[0420] Path tracing address, this field is used to carry the target network address information. It can include network address and mask, etc., which are not limited in this application.

[0421] Path Tracing info, this field is used to indicate the path information of the path. Including but not limited to:

[0422] 1) Path Tracing destination ID, this field can include but not limited to: routing ID, routing name, device hardware serial number (SN), etc.

[0423] 2) Path Tracing destination info, this field includes but not limited to: specific physical port number, loopback number, static routing information, IGP (Interior Gateway Protocol) routing information, BGP (Border Gateway Protocol) path information, etc.

[0424] ACK, this field is used to indicate whether the local end is the target device.

[0425] New Remote Path Tracing Source, this field is used to indicate the source device of the target address learned by the local device;

[0426] Track Forward, this field is used to indicate whether it is necessary to continue the path restoration probe forward. Optionally, in some embodiments, a separate forward traceback message can also be set. For example, the Type value is 5, which is similar to the traceback protocol and will not be elaborated here.

[0427] PHP (Penultimate Hop Popping) is a field used in path restore probe messages to indicate whether the receiving end is a penultimate hop device that supports the path restore protocol. In path restore probe response messages, this field indicates whether the local end is the penultimate hop device.

[0428] The description of the Adv (advertise) / Redistribute node list field can be found in the traceability protocol and will not be repeated here.

[0429] Optionally, if the message replied by the second device indicates that the second device has not learned the target network address information, but the second device should have learned the target network address information in the path information of the first device, then the first device can determine that the path where the second device is located is abnormal.

[0430] Optionally, if the message replied by the second device indicates the target network address learned by the second device, but the second device is not in the planned path, then it indicates that there is a normally communicating but unplanned path in the network.

[0431] Thus, in this embodiment, the first device can detect devices along the path to determine the devices on the communication path with the target device, thereby reconstructing the corresponding path (also known as topology or path topology). Based on the reconstructed path and local routing information, the first device can determine whether the path is a planned path. Furthermore, in this embodiment, the first device can also detect each device along the planned path to determine whether any abnormalities have occurred in the backup path within the planned path. If an abnormality occurs in the backup path, the first device can issue an alarm, prompting staff to promptly investigate the backup path to prevent failure during primary / backup path switching due to backup path abnormalities.

[0432] Figure 23 For illustrative application scenario diagrams, please refer to... Figure 23 In this scenario, the path from device A to device B to device C to device E to device G to device H to device M to device Z is the planned path and the primary path. The path from device A to device B to device D to device F to device G to device H to device M to device Z is also a planned path and a backup path. The path from device A to device B to device I to device J to device G to device H to device M to device Z is a non-planned path from device A to device Z.

[0433] First, a detailed explanation of how device A detects alternative routes to the planned route will be provided:

[0434] For example, device A (i.e., the first device) probes each device on the planned path to detect whether the backup path is abnormal, or in other words, to check if the backup path is connected (or available). For example, based on routing information, device A determines that device B is on the planned path, is a device on the backup path, and supports the path restoration protocol. Device A sends a path restoration probe message to device B to probe the path where device B is located. For example, the path probe message may include, but is not limited to:

[0435] The path recovery message type field is used to indicate that the message type is a path detection message. For example, it can be set to 1. It can be set according to actual needs, and this application does not limit it.

[0436] The SenderID field contains the identification information for device A;

[0437] The Path tracing address field is the target network address information (referred to as the target address), which is used to indicate the path on the device (referred to as the target device) corresponding to the target address. In this example, the target device corresponding to the target address is device Z, that is, the target address is the address configured by the user for device Z.

[0438] PHP fields and Adv / Redidstribute Node List fields (hereinafter referred to as Adv fields) can be 0 or empty, which will not be elaborated here. Other field descriptions can be found above, and will not be repeated here.

[0439] Device B receives path reconstruction probe messages. Based on path information (including routing tables or routing databases, etc.), Device B detects that the target address was learned from Device D and Device C. That is, Device B is the penultimate hop device from Device A to Device C, and the penultimate hop device from Device A to Device D.

[0440] Device B sends a path probing response message to Device A, indicating that Device B is not the target device, i.e., Device B is not the device corresponding to the target address, and the target address of Device B was learned from Device C and Device D. In this embodiment, the message format of the path probing response message can refer to the message format of the path probing response message in the above embodiment. Of course, in some instances, the path probing response message can also be in other formats, which are not limited in this application. The path probing response message includes, but is not limited to, at least one of the following:

[0441] The Type field is 6, which indicates that the type of the path restoration message is a path probe response message;

[0442] The Sender ID field contains the identification information for device B;

[0443] The Sender Name field is the route name for device B;

[0444] The Path tracing address field contains the target address information;

[0445] The Path Tracing info field is used to carry information about device B.

[0446] The ACK field being 0 indicates that device B received a path recovery probe message, and that this message is an ACK message replied to based on the path recovery probe message, i.e., a response message, and that device B is not the target device.

[0447] The New Remote Path Tracing Source field includes all or part of the routing information for device C, and all or part of the routing information for device D; the routing information for device C and device D is obtained by device B from its local routing information.

[0448] The PHP field includes routing information for device B, indicating that device B is the penultimate hop device on the transmission path from device A to device C, and the penultimate hop device on the transmission path from device A to device D; optionally, the PHP field can be empty.

[0449] The Track Forward and Adv fields are 0 or empty. The descriptions of other fields can be found above and will not be repeated here.

[0450] When device A receives the path restoration probe response message from device B, device A can determine and record that device B is the penultimate hop device from device A to device C, and the penultimate hop device from device A to device D. That is, device A can determine that the communicable paths on the current backup path include: device A-device B-device D, and device A-device B-device C.

[0451] For example, device A sends a forward probe message to device B, instructing device B to continue probing its neighboring devices to see if the target device is included. Optionally, the forward probe message can also be understood as device A sending a path recovery probe response message to device B, using the track Forward field in the message to indicate continued forward probing. Of course, similar to the tracing protocol, a separate forward probe message can be set up, and its format can be the same as the path recovery probe response message; this application does not limit this. To distinguish it from other messages, the following explanation still uses device A sending a forward probe message to device B as an example.

[0452] The following example illustrates the process using device A instructing device B to probe the path of device D. The path probing for device C is the same and will not be illustrated further. Probing messages include, but are not limited to, at least one of the following:

[0453] The Type field is 7 (it can also be set according to actual needs, and this application does not limit it), which is used to indicate that the type of the path restoration message is a forward probe message; each value can be set according to actual needs, and this application does not limit it.

[0454] The Sender ID field contains the identification information for device A;

[0455] The Sender Name field is the route name for device A;

[0456] The Conflict address field contains the target address information;

[0457] The Path tracing address field contains the target address information;

[0458] The Path Tracing info field is used to carry information about device B.

[0459] An ACK field of 1 indicates that device A has received a path probe response message, and that the message is a reply message based on the path probe response message.

[0460] The New Remote Conflict Source field can optionally be empty;

[0461] The Track Forward field includes forward probe indication information (e.g., a value of 1) to instruct device B to continue probing forward; in some instances, this field may also indicate the routing information of the device probing forward, such as the routing information of device D, to instruct device B to continue probing towards device D.

[0462] The PHP and Adv fields are 0 or empty. For descriptions of other fields, please refer to the above text. They will not be repeated here.

[0463] Device B receives a forward probe message. In response to the forward probe message, Device B continues to probe its neighboring devices to see if the target device is included.

[0464] In one possible implementation, as described above, neighboring devices in the network exchange path restoration capability negotiation / response messages to determine whether the other end supports the path restoration protocol. Optionally, there may be at least one device in the network (or on the path) that does not support the path restoration protocol. In one example, if device B determines that a node it needs to continue probing, such as device D, does not support the path restoration protocol, device B can send a path restoration probe response message (also known as a forward probe response message) to device A to indicate that device D does not support the path restoration protocol. Device A can find the neighboring devices of path D based on routing information and send path restoration probe messages to the neighboring devices. The execution process is the same as the interaction between device A and device B, and will not be repeated here. Optionally, if device A does not receive a response message after sending a path restoration probe message, it can be determined that the device does not support the path restoration protocol. Device A can continue to probe downwards, and the probe process can be referred to above, and will not be repeated here.

[0465] This example illustrates the scenario where all devices in the network support the path restoration protocol. For instance, device B sends a path restoration probe message to device D. This path restoration probe message includes, but is not limited to:

[0466] The SenderID field contains the identification information for device A;

[0467] The Sender Name field contains the identification information for device A; the Sender ID field and the Sender Name field are used to indicate that the path restoration was initiated by device A, so that other devices that receive the path restoration message can send the corresponding message back to device A.

[0468] The Path tracing address field contains the target network address information (referred to as the target address);

[0469] PHP fields and Adv fields, among others, can be 0 or empty. For descriptions of other fields, please refer to [link / reference]. Figure 3 This will not be elaborated upon here.

[0470] Device D receives a path probe message. In response, based on its local routing information, device D determines that it is not the target device and finds that the target address was learned from device F. Device D can send a path probe response message to device A based on the Sender ID and Sender Name fields. This message indicates that device D is not the target device corresponding to the target address and that the target address was learned from device F.

[0471] When device A receives the path probe response message from device D, device A can determine and record that device D is the penultimate hop device from device A to device F. That is, device A can determine that the communicable paths on the current backup path include: device A-device B-device D.

[0472] For example, device A sends a forward probe message to device D, instructing device D to continue probing its neighboring devices to see if the target device is included.

[0473] Device D receives a forward probe message. In response to the forward probe message, device D continues to probe its neighboring devices to see if the target device is included.

[0474] Device F receives a path probe message. In response, based on its local routing information, device F determines that it is not the target device and finds that the target address was learned from device G. Device F then sends a path probe response message to device A, indicating that it is not the target device corresponding to the target address and that the target address was learned from device G.

[0475] Optionally, if device F is an ABR or ASBR device, the Adv field in the path restoration probe response message fed back by device F may include information about other routing domains to which device F belongs. The description can be found in the tracing protocol and will not be repeated here.

[0476] When device A receives the path query response message from device F, device A can determine and record that device F is the penultimate hop device from device A to device G. That is, device A can determine that the communicable paths on the current backup path include: device A-device B-device D-device F.

[0477] Device A sends a forward probe message to device F. In response, device F probes device G. Device G, in response to the path recovery probe message sent by device F, sends a path recovery probe response message to device A, indicating that device G is not the target device corresponding to the target address, and that the target address of device G was learned from device H. Further details can be found above and will not be repeated here.

[0478] When device A receives the path restoration probe response message from device G, device A can determine and record that device G is the penultimate hop device from device A to device H. That is, device A can determine that the communicable paths on the current backup path include: device A-device B-device D-device F-device G.

[0479] Device A sends a forward probe message to device G. In response to the received forward probe message, device G probes device H. In response to the path probe message received from device G, device H sends a path probe response message to device A, indicating that device H is not the target device corresponding to the target address, and that device H's target address was learned from device M. Optionally, H can be an ASBR device. The path recovery probe response message returned by device H may include routing information from other routing domains, carried in the Adv field.

[0480] When device A receives the path restoration probe response message from device H, device A can determine and record that device H is the penultimate hop device from device A to device M. That is, device A can determine that the communicable paths on the current backup path include: device A-device B-device D-device F-device G-device H.

[0481] Device A sends a forward probe message to device H. In response to the received forward probe message, device H probes device M. In response to the path recovery probe message sent by device H, device M sends a path recovery probe response message to device A, indicating that device M is not the target device corresponding to the target address, and that the target address of device M was learned from device Z.

[0482] When device A receives the path restoration probe response message from device M, device A can determine and record that device M is the penultimate hop device from device A to device Z. That is, device A can determine that the communicable paths on the current backup path include: device A-device B-device D-device F-device G-device H-device M.

[0483] Device A sends a forward probe message to device M. In response to the received forward probe message, device M probes device Z. In response to the path probe message sent by device M, device Z sends a path probe response message to device A, indicating that device Z is the target device corresponding to the target address.

[0484] When device A receives the path restoration probe response message from device Z, device A can determine and record that device Z is the target device corresponding to the target address. That is, device A can determine that the communicable paths on the current backup path include: device A-device B-device D-device F-device G-device H-device M-device Z.

[0485] In this way, device A can detect the backup path in advance to obtain the communication status of the backup path, so as to avoid the problem of switching failure caused by the switching of the primary and backup paths, improve the risk pre-check capability of the system, and further enhance the stability of the system.

[0486] In one possible implementation, if device M (using only device M as an example, it can be any device) does not support the path restoration protocol, and device A does not receive a path restoration response message within a predetermined time period after sending a forward probe message (which can be set according to actual needs, and this application does not limit it), device A may optionally send a path restoration message directly to device M. If it still does not receive a path restoration response message, device A can directly send a path restoration probe message to device M's next-hop device Z. Alternatively, device A can also send a forward probe message to device H to instruct device H to continue probing to device M's next-hop device.

[0487] In another possible implementation, devices G to Z are devices on the main path, and device A's detection of the backup path can be limited to device F or device G. This application does not impose any restrictions.

[0488] In another possible implementation, device A may probe the path only for ASBR devices and / or ABR devices on the path, which is not limited in this application.

[0489] Still refer to Figure 23 Devices I and J belong to unplanned paths. Device A can determine if a path belonging to Device I and / or Device J is an unplanned path by probing Device I and / or Device J. For example, if Device A probes the path between Device I and Device J and determines that the path is available but not recorded in its routing information, Device A can identify it as an unplanned path. Device A can issue an alarm to prompt operators to investigate unplanned paths, thereby preventing them from posing a threat to the system. Specific detection methods are described above and will not be repeated here.

[0490] In summary, this application provides a path restoration method that allows any device within the network to probe the path to the target device to determine whether the path is the planned path and whether the backup path within the planned path is available. This eliminates the risk of unplanned paths and proactively investigates potential anomalies in backup paths, preventing failover issues during primary / backup path switching and improving system stability.

[0491] In one possible implementation, the path reconstruction method of this application can also detect possible loop paths in the system, such as... Figure 24As shown, device A probes each device along the path. Based on the path query response messages returned by each device, device A can determine that a loop path has formed between multiple devices. For example, the next-hop device of device B is device C, and the next-hop device of device C is device B (this may also include other devices, which are not limited in this application). Device A can issue an alarm to notify the user that a loop path exists in the system. Operators can then promptly troubleshoot the loop path in the system, thereby preventing the loop path from affecting the system's service transmission.

[0492] In another possible implementation, the device can perform a path restoration process at any time, or periodically (which can be set according to actual needs and is not limited in this application), or in response to a received user operation, to detect path availability and restore the network topology.

[0493] Figure 25 A schematic block diagram of a detection device 2000 according to an embodiment of this application is shown. The detection device may include a processor 2001 and a transceiver / transceiver pin 2002, and optionally, a memory 2003. The processor 2001 can be used to execute the steps performed by the detection device in the methods of the foregoing embodiments, and control the receive pin to receive signals, and control the transmit pin to transmit signals.

[0494] The various components of the detection device 2000 are coupled together via a bus 2004, which includes a data bus, a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as bus system 2004 in the figure.

[0495] Optionally, the memory 2003 can be used for storage instructions in the foregoing method embodiments.

[0496] It should be understood that the detection device 2000 according to the embodiments of this application may correspond to the first device in the methods of the foregoing embodiments, and the above and other management operations and / or functions of each element in the detection device 2000 are respectively for implementing the corresponding steps of the foregoing methods, which will not be described in detail here for the sake of brevity.

[0497] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0498] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a detection device to control the detection device to implement the above-described method embodiments.

[0499] Based on the same technical concept, this application also provides a computer program, which, when executed by a detection device, is used to implement the above-described method embodiments.

[0500] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

[0501] Based on the same technical concept, this application also provides a processor for implementing the above-described method embodiments. The processor can be a chip.

[0502] The steps of the methods or algorithms described in conjunction with the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in a network device. Alternatively, the processor and storage medium can exist as discrete components in the network device.

[0503] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

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

Claims

1. A detection method, characterized in that, Applied to a first device, the method includes: Obtain the network address information to be detected; In the event of a conflict event detected in the network address information to be detected, a source tracing query message is sent to the second device, the source tracing query message being used to query the source of the conflict event; The system receives a source tracing response message sent by the second device, the source tracing response message being used to indicate the conflict source device corresponding to the conflict event.

2. The method according to claim 1, characterized in that, Sending the source tracing query message to the second device includes: The tracing query message is flooded between at least one device in the first network; the first device belongs to the first network, all devices in the first network belong to the same routing domain, and at least one device in the first network supports the tracing protocol.

3. The method according to claim 2, characterized in that, The second device belongs to the first network.

4. The method according to claim 2, characterized in that, If the second device does not belong to the first network, the step of sending a source tracing query message to the second device further includes: The tracing query message is flooded between at least one device in the second network, wherein the first network and the second network belong to different routing domains, and at least one device in the second network supports the tracing protocol.

5. The method according to claim 1, characterized in that, Before obtaining the network address information to be detected, the method further includes: Each device in the network exchanges traceability capability negotiation messages with its corresponding neighboring devices. These traceability capability negotiation messages are used to indicate to the neighboring devices whether the local device supports the traceability protocol.

6. The method according to claim 2, 4 or 5, characterized in that, The tracing protocol is used to indicate the monitoring of a specified network interface and to receive and / or send messages conforming to the message format of the tracing protocol from the specified network interface.

7. The method according to claim 1, characterized in that, After receiving the source tracing response message sent by the second device, the method further includes: A source tracing report message is flooded between at least one device in the network, the source tracing report message being used to indicate that a conflict event corresponding to the network address information to be detected has occurred between the first device and the conflict source device.

8. The method according to claim 7, characterized in that, The source tracing report message includes at least one of the following: The routing information of the first device, the routing information of the conflict source device, and the network address information to be detected.

9. The method according to claim 1, characterized in that, The process of obtaining the network address information to be detected includes: In response to a received user instruction, the network address information to be detected is obtained; wherein the user instruction is used to instruct conflict detection on the network address information to be detected, or the user instruction is used to instruct the network address information to be detected to be configured and activated in the network.

10. The method according to claim 1, characterized in that, Before sending the source tracing query message to the second device, the method further includes: Based on local routing information, detect whether there are any conflict events corresponding to the network address information to be detected.

11. The method according to any one of claims 1 to 10, characterized in that, The source tracing query message is a User Datagram Protocol (UDP) message.

12. The method according to any one of claims 1 to 11, characterized in that, The source tracing query message includes the routing information of the first device and the network address information to be detected.

13. The method according to any one of claims 1 to 12, characterized in that, The second device is the conflict source device, or the second device is the second hop device on the transmission path from the conflict source device to the first device.

14. A detection device, characterized in that, Applied to a first device, the device includes: The acquisition module is used to acquire the network address information to be detected. The communication module is used to send a source tracing query message to the second device when a conflict event of the network address information to be detected is detected. The source tracing query message is used to query the source of the conflict event. The communication module is further configured to receive a source tracing response message sent by the second device, the source tracing response message being used to indicate the conflict source device corresponding to the conflict event.

15. The apparatus according to claim 14, characterized in that, The communication module is specifically used for: The tracing query message is flooded between at least one device in the first network; the first device belongs to the first network, all devices in the first network belong to the same routing domain, and at least one device in the first network supports the tracing protocol.

16. The apparatus according to claim 15, characterized in that, The second device belongs to the first network.

17. The apparatus according to claim 15, characterized in that, If the second device does not belong to the first network, the communication module is further configured to: The tracing query message is flooded between at least one device in the second network, wherein the first network and the second network belong to different routing domains, and at least one device in the second network supports the tracing protocol.

18. The apparatus according to claim 14, characterized in that, The communication module is also used for: Each device in the network exchanges traceability capability negotiation messages with its corresponding neighboring devices. These traceability capability negotiation messages are used to indicate to the neighboring devices whether the local device supports the traceability protocol.

19. The apparatus according to claim 15, 17 or 18, characterized in that, The tracing protocol is used to indicate the monitoring of a specified network interface and to receive and / or send messages conforming to the message format of the tracing protocol from the specified network interface.

20. The apparatus according to claim 14, characterized in that, The communication module is also used for: A source tracing report message is flooded between at least one device in the network, the source tracing report message being used to indicate that a conflict event corresponding to the network address information to be detected has occurred between the first device and the conflict source device.

21. The apparatus according to claim 20, characterized in that, The source tracing report message includes at least one of the following: The routing information of the first device, the routing information of the conflict source device, and the network address information to be detected.

22. The apparatus according to claim 14, characterized in that, The acquisition module is specifically used for: In response to a received user instruction, the network address information to be detected is obtained; wherein the user instruction is used to instruct conflict detection on the network address information to be detected, or the user instruction is used to instruct the network address information to be detected to be configured and activated in the network.

23. The apparatus according to claim 14, characterized in that, The device further includes: The conflict detection module is used to detect whether there are conflict events corresponding to the network address information to be detected, based on local routing information.

24. The apparatus according to any one of claims 14 to 23, characterized in that, The source tracing query message is a User Datagram Protocol (UDP) message.

25. The apparatus according to any one of claims 14 to 24, characterized in that, The source tracing query message includes the routing information of the first device and the network address information to be detected.

26. The apparatus according to any one of claims 14 to 25, characterized in that, The second device is the conflict source device, or the second device is the second hop device on the transmission path from the conflict source device to the first device.

27. A detection device, characterized in that, include: One or more processors; Memory; And one or more computer programs, wherein the one or more computer programs are stored on the memory, and when the computer programs are executed by the one or more processors, cause the apparatus to perform the method as described in any one of claims 1-13.

28. A computer storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-13.

29. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-13.

Images