A configuration delivery fault location method, device and program product

Abstract

The application discloses a kind of configuration issue fault locating method, equipment and program product, method includes: for each containing several index configuration table entries of fragmented message, according to the service content of which configuration table entry generates and each index corresponding service identification, the mapping relationship of index in fragmented message with service identification is established, and the mapping relationship is associated with the first information for identifying fragmented message Storage in cache;Fragmented message is sent to target remote device asynchronously;Receive and analyze the confirmation message returned by remote device, when the index of at least one failed table item is carried in confirmation message, the corresponding service identification is obtained according to the index of confirmation message failed table item, generate the failure details containing service identification, and the configuration table item of retransmission is determined by failure details.The application can solve the problem of information fault, retry coarse granularity and other problems in the scene of batch configuration issue, improve the delicacy and operation efficiency of configuration management.

Description

Technical Field

[0001] This invention belongs to the field of network communication and distributed configuration management technology, specifically relating to a configuration distribution fault location method, device, and program product. Background Technology

[0002] In satellite networks, large routing clusters, or Software Defined Network (SDN) controllers, the control center frequently needs to send configuration information, such as routing entries, segment routing (SR) path entries, and forwarding entries, to a large number of remote devices (e.g., satellite nodes, routers). Due to the large number of configuration entries, a single send may contain hundreds or thousands of entries, while network link bandwidth is limited. Therefore, the following batch configuration steps are typically used: 1. Fragmented Sending: The configuration entries for a satellite are split into multiple fragmented packets, each carrying several entries. 2. Asynchronous Concurrency: Configuration packets are sent to multiple satellites simultaneously, using multithreading or asynchronous frameworks to improve sending efficiency. 3. Acknowledgment Mechanism: Each configuration packet requires the remote device to return an ACK acknowledgment packet, containing the overall processing result (success / failure). If a failure occurs, it may carry a list of indexes of failed entries and the corresponding error codes.

[0003] Existing batch configuration solutions have the following drawbacks:

[0004] 1. Information Gap: The control center can only obtain the index of the failed entry in the fragmented packet (e.g., the 3rd entry failed) and the error code from the ACK packet, but cannot know the business meaning corresponding to the index—e.g., which tunnel ID, which destination network segment, which SR tag path the entry corresponds to. After receiving the failure result, the upper-layer business (such as the path calculation module and tunnel management module) cannot directly locate which specific business configuration has a problem.

[0005] 2. Coarse retry granularity: Due to the inability to accurately identify failed entries, maintenance personnel or automated retry mechanisms often have to retransmit all configurations of the entire satellite or the entire fragment, resulting in a large amount of redundant transmission and processing overhead. Summary of the Invention

[0006] The purpose of this invention is to provide a configuration distribution fault location method, device, and program product, which aims to solve the problems of information gaps and coarse retry granularity when the control center distributes configurations to remote devices in batches in the existing technology, thereby improving the precision of configuration management and operation and maintenance efficiency.

[0007] To achieve the above-mentioned objectives, in a first aspect, the present invention provides a configuration-based fault location method, comprising the following steps:

[0008] For each fragmented packet containing several indexed configuration entries, a service identifier corresponding to each index is generated based on the service content of the configuration entries, a mapping relationship between the indexes and service identifiers within the fragmented packet is established, and the mapping relationship is associated with and stored in the cache with the first information used to identify the fragmented packet.

[0009] The fragmented message is asynchronously sent to the target remote device;

[0010] The system receives and parses the acknowledgment message returned by the remote device. When the acknowledgment message carries an index of at least one failure entry, it queries the mapping relationship based on the index of the failure entry in the acknowledgment message to obtain the corresponding service identifier, and generates failure details containing the service identifier. The failure details are used to determine the configuration entry for retransmission.

[0011] Further, the first information is composed of a remote device identifier and a fragmented message sequence number; the step of querying the mapping relationship based on the index of the acknowledgment message failure entry to obtain the corresponding service identifier includes:

[0012] The remote device identifier and fragment sequence number are parsed from the confirmation message, combined to form the first information, and the corresponding mapping relationship is obtained from the cache based on the first information. The mapping relationship is then queried to convert the index of each failure entry in the confirmation message into the corresponding service identifier.

[0013] Furthermore, after obtaining the corresponding mapping relationship from the cache based on the first information, the mapping relationship corresponding to the first information is deleted from the cache.

[0014] Furthermore, for each fragmented packet, a service identifier corresponding to each index is generated based on the service content of the configuration table entries, including: extracting the service fields in the configuration table entries according to the configuration table entry type and concatenating them into a string with business meaning as the service identifier.

[0015] Furthermore, generating failure details containing a service identifier includes: creating a first failure details object for each failure index, wherein the first failure details object includes a service identifier, a failure index, and a corresponding error code carried in the acknowledgment message.

[0016] Furthermore, for each fragmented packet, a service identifier corresponding to each index is generated based on the service content of the configuration table entries, including: serializing all service fields of the configuration table entries into a string of a uniform format as the service identifier.

[0017] Furthermore, generating failure details containing service identifiers includes: creating a second failure details object for each response type used to determine the configuration entry type in the confirmation message. The second failure details object includes the response type, as well as each failure index associated with the response type, the corresponding service identifier, and the corresponding error code carried in the confirmation message.

[0018] Furthermore, the configuration distribution fault location method also includes: aggregating the failure details generated by all fragmented packets under the same configuration batch for the same target remote device and returning them to the upper-layer service.

[0019] In a second aspect, the present invention provides an electronic device, including a memory, a processor, and a computer program / instructions stored in the memory and executable on the processor, wherein the computer program / instructions, when executed by the processor, implement the steps of the configuration-based fault location method described in the first aspect.

[0020] Thirdly, the present invention provides a computer program product, including a computer program / instruction, wherein when the computer program / instruction is executed by a processor, it implements the steps of the configuration-based fault location method described in the first aspect.

[0021] Compared with the prior art, the present invention has the following beneficial effects:

[0022] 1. Precisely Locating Failed Entries: In the method of this invention, a mapping relationship between the index and the service identifier within the fragmented message is established before transmission, and the mapping relationship is associated with and stored in the cache with the first information used to identify the fragmented message. After receiving the acknowledgment message, the mapping relationship is queried based on the index of the failed entry in the acknowledgment message, and the failed index without business meaning is converted into a service identifier. The specific business information of the failed configuration item can be obtained directly without having to query the business database or logs in reverse through the index, which solves the problem of information gap and improves the efficiency of fault location.

[0023] 2. Fine-grained retry: In the method of this invention, the index of each failed entry in the confirmation message is converted into the corresponding service identifier, and failure details containing the service identifier are generated to determine the configuration entries to be retransmitted. This can effectively support fine-grained retries. Based on the failure details, only the failed entries can be retransmitted, avoiding the waste of network bandwidth and computing resources caused by full or full fragment retransmission due to the inability to locate the failed entries. This effect is particularly significant in satellite networks where link bandwidth is precious.

[0024] 3. Protocol independent and transparent to remote end: In the method of this invention, the establishment of mapping relationship, caching, querying and indexing and conversion to business identifier are all implemented on the control center side. The communication protocol between the remote device is not modified, the confirmation message format remains unchanged, the remote device does not need any upgrade or modification, and it is compatible with the existing system.

[0025] 4. The electronic equipment and program products provided by this invention have the same effect as the configuration distribution fault location method provided. Attached Figure Description

[0026] Figure 1 This is a flowchart of a configuration-based fault location method provided in an embodiment of the present invention.

[0027] Figure 2 A flowchart of another configuration-based fault location method provided in an embodiment of the present invention.

[0028] Figure 3 This is a schematic diagram of a configuration-based fault location system provided in an embodiment of the present invention.

[0029] Figure 4 This is a timing diagram illustrating the batch configuration and fault location of the diversion table in a satellite network, as exemplified in this embodiment of the invention.

[0030] Figure 5 This is a schematic diagram of an electronic device structure provided in an embodiment of the present invention. Detailed Implementation

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

[0032] The following provides a further description of the configuration distribution fault location method involved in the embodiments of the present invention.

[0033] This invention provides a configuration distribution fault location method applicable to scenarios where a control center distributes configurations in batches to remote devices. The core idea is to pre-establish a mapping relationship between the table entry index and service identifier within the fragment in the local cache before sending the batch configuration fragment packets. When an ACK confirmation packet carrying a list of failure indices is received, this mapping relationship is used to convert the failure indices into service identifiers and assemble them into structured failure details to determine the configuration entries to be retransmitted. The entire process does not modify the original communication protocol and is transparent to the remote device. Figure 1 As shown, the configuration-based fault location method described in this embodiment may include the following steps S1 to S3.

[0034] S1. Mapping registration before configuration transmission: For each fragmented packet containing several indexed configuration entries, generate a service identifier corresponding to each index based on the service content of the configuration entries, establish a mapping relationship between the index and the service identifier within the fragmented packet, and store the mapping relationship in the cache in association with the first information used to identify the fragmented packet.

[0035] S2. Asynchronous transmission: The fragmented message is asynchronously transmitted to the target remote device;

[0036] S3. Receive confirmation message and associate failure information: Receive and parse the confirmation message returned by the remote device. When the confirmation message carries an index of at least one failure entry, query the mapping relationship based on the index of the failure entry in the confirmation message to obtain the corresponding service identifier, and generate failure details containing the service identifier. The failure details are used to determine the configuration entry for retransmission.

[0037] In this embodiment, by establishing a mapping relationship between the index and service identifier within the fragmented message before transmission, and storing the mapping relationship in a cache along with the first information used to identify the fragmented message, upon receiving the acknowledgment message, the mapping relationship is queried based on the index of the failed entry in the acknowledgment message. Failure indexes without service meaning are converted into service identifiers, allowing direct access to the specific service information of the failed configuration item. This eliminates the need for reverse lookup of the service database or logs via the index, solving the information gap problem and improving fault location efficiency. Converting the index of each failed entry in the acknowledgment message into the corresponding service identifier generates failure details containing the service identifier, used to determine the retransmission configuration entries. This effectively supports fine-grained retries, allowing retransmission only of failed entries based on the failure details. This avoids the waste of network bandwidth and computing resources caused by full or full fragment retransmission due to the inability to locate failed entries, which is particularly effective in satellite networks where link bandwidth is precious. Furthermore, in this embodiment, the establishment, caching, querying, and conversion of indexes to business identifiers are all implemented on the control center side without modifying the communication protocol with the remote device. The confirmation message format remains unchanged, and the remote device does not require any upgrades or modifications, ensuring compatibility with the existing system.

[0038] In some possible implementations, in step S1, the first information is composed of a remote device identifier and a fragmented packet sequence number; in step S3, the step of querying the mapping relationship based on the index of the failure entry in the acknowledgment packet to obtain the corresponding service identifier includes: parsing the remote device identifier and the fragmented packet sequence number from the acknowledgment packet, combining them to form the first information, obtaining the corresponding mapping relationship from the cache based on the first information, and querying the mapping relationship to convert the index of each failure entry in the acknowledgment packet into the corresponding service identifier.

[0039] For example, taking the target remote device as a satellite node, in step S1, the first information can be composed of a satellite identifier (such as a satellite IP address) and a fragment sequence number. In this scheme, the first information is composed of the remote device identifier and the fragment sequence number to associate the mapping relationship between the index and the service identifier within the fragment message. In scenarios with multiple target remote devices and multiple fragment messages occurring concurrently, the mapping relationship uniquely corresponding to the current acknowledgment message can be accurately obtained from the local cache, ensuring that the conversion from the failed index to the service identifier is accurate in complex asynchronous concurrent environments.

[0040] In some possible implementations, in step S3, after obtaining the corresponding mapping relationship from the cache based on the first information, the mapping relationship corresponding to the first information is deleted from the cache. By promptly cleaning up used mapping relationships, memory safety is ensured. The cache space usage is only related to the number of currently en route, unreceived fragmented packets, and will not accumulate memory usage with the number of configurations, thus ensuring the long-term stability of the system.

[0041] In some possible implementations, in step S1, for each fragmented packet, a business identifier corresponding to each index is generated based on the business content of the configuration table entries. This includes: extracting the business fields from the configuration table entries according to their types and concatenating them into a string with business meaning as the business identifier. By unifying the differentiated business content of different configuration table entry types into a string-based business identifier, the generated failure details contain directly readable, specific business information. This achieves accurate description of failure entries and decoupling from specific entry types, improving system versatility and effectively reducing development and maintenance costs.

[0042] In step S3, generating failure details containing the service identifier includes: creating a first failure details object for each failure index, wherein the first failure details object includes the service identifier, the failure index, and the corresponding error code carried in the acknowledgment message. This solution provides complete structured data about a failure item, laying a data foundation for refined operation and maintenance and automated processing.

[0043] In some possible implementations, in step S1, for each fragmented packet, a service identifier corresponding to each index is generated based on the service content of the configuration table entries. This includes serializing all service fields of the configuration table entries into a string of a unified format as the service identifier. For example, the unified format string can be a JSON-formatted string. In this solution, the complete information of the configuration table entries is preserved, and the original failed configuration can be completely restored through deserialization. The logic for generating the service identifier is the same for each configuration table entry type, i.e., serializing all fields is sufficient, further improving system versatility and reducing development and maintenance costs.

[0044] In step S3, generating failure details containing service identifiers includes: creating a second failure detail object for each response type in the acknowledgment message used to determine the configuration entry type. The second failure detail object includes the response type, as well as each failure index associated with the response type, its corresponding service identifier, and the corresponding error code carried in the acknowledgment message. This solution utilizes the response type in the acknowledgment message to uniquely determine the configuration entry type, aggregating failure information according to entry type. During refined retries, failure items of specific configuration entry types can be batch deserialized and processed, reducing processing complexity.

[0045] In some possible implementations, the configuration-based fault location method, such as Figure 2 As shown, the solution also includes step S4, aggregation and reporting: aggregating the failure details generated by all fragmented packets under the same target remote device and the same configuration batch, and returning them to the upper-layer service. This solution aggregates the scattered failure information of all fragmented packets, enabling the upper-layer service to obtain complete failure details of configuration tasks under the same target remote device and the same configuration batch, facilitating multi-dimensional analysis and refined processing. Failure details can also be output to structured logs or monitoring systems, supporting automated alarms and visual displays, improving the operational experience.

[0046] Specifically, when aggregating failure details and returning them to the upper-layer business logic, the first or second failure detail object list obtained from the aggregation is appended to the configuration result object as a new dedicated field, and the configuration result object is then returned to the upper-layer business logic. Extending the configuration result object by adding dedicated fields allows the upper-layer business logic to obtain all detailed failure details information simply by parsing the newly added failure detail list fields, without changing the original processing logic. This balances forward compatibility with the availability of new features, achieving a smooth upgrade.

[0047] The configuration distribution fault location device involved in the embodiments of the present invention will be further described below. The configuration distribution fault location device described below can be referred to in correspondence with the configuration distribution fault location method described above.

[0048] like Figure 3As shown in the figure, an embodiment of the present invention provides a configuration distribution fault location device, including a sending module 11, a receiving module 12, and a mapping cache 13. The sending module 11 is used to generate a service identifier corresponding to each index based on the service content of each configuration table entry in a fragmented packet containing several indexed configuration table entries, establish a mapping relationship between the indexes and service identifiers within the fragmented packet, and store the mapping relationship in the mapping cache 13 in association with first information used to identify the fragmented packet; and asynchronously send the fragmented packet to a target remote device 14. The receiving module 12 is used to receive and parse an acknowledgment message returned by the remote device 14. When the acknowledgment message carries an index of at least one failed entry, it queries the mapping relationship based on the index of the failed entry in the acknowledgment message to obtain the corresponding service identifier, and generates failure details containing the service identifier. The failure details are used to determine the configuration table entry to be retransmitted.

[0049] The following example, using the control center's remote batch configuration of a satellite node, further illustrates the fault location method for configuration distribution.

[0050] According to step S1, when the sending module receives a batch configuration request from the upper-layer service in the control center to send a batch of configuration entries (such as diversion entries or SR entries) to a satellite, it first splits the batch configuration entries to be sent into multiple fragmented messages according to the maximum message length allowed by the protocol. Each fragmented message contains several batch entries, and these configuration entries have a fixed sequential index in the fragmented messages (usually starting from 1 and incrementing).

[0051] For each fragmented packet, the sending module performs the following operations: First, it iterates through all entries within the fragmented packet, generating a service identifier string for each entry. The generation rule for the service identifier is determined by the entry type. For example, for a traffic redirection entry, a string like "Tunnel ID=1001, Destination Network Segment=192.168.1.0 / 24" can be generated; for an SR path entry, a string like "Tunnel Index=5, Tag Stack=100,200,300" can be generated. Then, a mapping dictionary from "index" to "service identifier" is established. Finally, this mapping dictionary is stored in a global mapping cache, where the cache key consists of the satellite identifier (such as the satellite IP address) and the fragmented packet sequence number (unique to each fragment).

[0052] According to step S2, the sending module sends the fragmented message to the target satellite and simultaneously creates a countdown latch for the fragmented message to wait for the satellite to return an ACK response. The sending module continues to process other fragments or other satellites without blocking.

[0053] According to step S3, after the control center receives the ACK message returned by the satellite, the receiving module parses out the satellite address, message sequence number, and overall processing result (success / partial failure / complete failure). If it is a partial failure, it carries an index list of failure entries and the error code corresponding to each failure entry.

[0054] When a processing failure occurs, the receiving processing module performs the following operations: using the satellite address and message sequence number as keys, it retrieves the previously stored "index → ​​service identifier" mapping dictionary from the cache and immediately deletes the mapping from the cache (to prevent memory leaks). If the mapping dictionary exists and is not empty, it iterates through the list of failure indices in the ACK, and for each failure index: queries the corresponding service identifier from the mapping dictionary; creates a first failure details object containing: service identifier, failure index, error code (and an optional error description). If the mapping dictionary does not exist (e.g., in an exceptional case), it performs a fallback processing: using only the index value as the identifier, or recording the original failure information.

[0055] According to step S4, firstly, the first failure detail objects generated from all fragmented packets within the same configuration batch for the same satellite are collected into a list. If configuration requests exist for multiple satellites, they are aggregated separately for each satellite. Then, this list is set into a dedicated field of the configuration result object. The configuration result object also includes other common fields such as overall success / failure status and timeout information. Finally, the configuration result object is returned to the upper-layer business module. The upper-layer business can directly traverse the failure detail list to obtain the business identifier and error code for each failure entry, thereby performing fine-grained processing: for example, retrying only failed entries, recording alarm logs, and updating the database status.

[0056] In this embodiment, the following key data structures and fields are introduced:

[0057] (1) Index Identifier Mapping Table: A cache table with (satellite address, message sequence number) as the key and "index → ​​service identifier" mapping dictionary as the value. This table supports high-concurrency read and write and has automatic cleanup capability (entries are deleted immediately after response processing).

[0058] (2) First Failure Details Object: Contains at least three attributes—Business Identifier (string), Failure Index (integer), and Error Code (integer). Optional: Includes Error Description (string).

[0059] (3) Configure the result object: In addition to the original fields (overall result, error information, timeout information, etc.), add a failure details list field.

[0060] In this embodiment, the abstract layer of the business identifier string is used to decouple it from the specific table item type. Different business modules (traffic referral table, SR table, forwarding table) only need to implement their own business identifier generation logic in step S1 (e.g., concatenating the key fields of the table item into a string), and the remaining steps can be completed by general components without repeated development.

[0061] To achieve generality, completeness, and scalability of failure details, the following enhancements are introduced in a preferred embodiment:

[0062] (1) Generation of business identifiers in a unified format serialization: When generating business identifiers in step S1, the field concatenation method is not used. Instead, all business fields of the configuration table are serialized into strings in a unified format (such as JSON format). This preserves the complete information and eliminates the need to write concatenation logic for each table item. After obtaining the complete information, the upper-layer business can directly restore the original configuration.

[0063] (2) Parsing and transmission of response type: The acknowledgment message returned by the remote device usually carries the response type (such as the subtype in the protocol), which can uniquely identify the type of configuration entry. In this embodiment, the response type is recorded in the failure details so that the upper-layer service can obtain the entry type and achieve accurate deserialization.

[0064] (3) Second Failure Details Object (Aggregated by Entry Type): In addition to the basic first failure details object for each failure index, this invention also provides a second failure details object (Detail), whose structure is as follows: type: The response type (integer) parsed from the acknowledgment message, used to determine the configuration entry type. items: A list of all failure entries belonging to this type, each entry containing a business identifier (such as a JSON string), a failure index, and an error code. This aggregation method reduces the processing complexity of upper-layer business processes, and presents failure information of the same table type in a centralized manner, facilitating batch analysis and retries.

[0065] The following is combined with Figure 4 The embodiments of the present invention will be further illustrated by taking the scenario of distributing diversion tables in a satellite network as an example.

[0066] Scenario: The control center needs to send 10 redirection entries to a low-Earth orbit satellite (satellite ID=Sat-01, IP address 192.168.1.100). Due to protocol limitations, each message can only carry a maximum of 5 entries, so it needs to be split into 2 fragmented messages.

[0067] Implementation steps:

[0068] 1. Upper-layer service sends batch configuration: The upper-layer service module sends a batch configuration task to the sending module, consisting of 10 traffic redirection entries, corresponding to tunnels 1 to 10 respectively. Each entry contains information such as the destination network segment and the outgoing interface.

[0069] 2. The sending module performs fragmentation: The sending module divides the 10 entries into two fragmented packets. The first fragmented packet contains entries with indices 1 to 5 (tunnels 1 to 5), and the second fragmented packet contains entries with indices 6 to 10 (tunnels 6 to 10).

[0070] 3. Generate Service Identifier: For each fragment, the sending module generates a corresponding service identifier based on the table entry index. For the first fragment packet (containing entries indices 1-5), the service identifier generation rule is "tunnelId=tunnel number". For example, index 1 corresponds to "tunnelId=1", index 2 corresponds to "tunnelId=2", and so on. The second fragment packet follows the same principle.

[0071] 4. Mapping Registration: The sending module registers the mapping relationship between the index and the service identifier in the mapping cache. The key is (satellite IP, fragment sequence number), and the value is a mapping dictionary from the index to the service identifier within the fragment. For example:

[0072] Key: ("192.168.1.100", fragment sequence number = 1) → Mapping dictionary {1: "tunnelId=1", 2: "tunnelId=2", 3: "tunnelId=3", 4: "tunnelId=4", 5: "tunnelId=5"}

[0073] Key: ("192.168.1.100", fragment sequence number = 2) → Mapping dictionary {1: "tunnelId=6", 2: "tunnelId=7", 3: "tunnelId=8", 4: "tunnelId=9", 5: "tunnelId=10"}

[0074] 5. Send configuration fragmented messages: The sending module sends two fragmented messages to the satellite concurrently.

[0075] 6. Create a countdown latch and wait: The sending module creates a countdown latch for each fragmented message and enters a waiting state to receive the ACK returned by the satellite.

[0076] 7. Return ACK: The satellite returns ACKs for each of the two fragments:

[0077] The ACK for the first fragment: Assuming the overall result is a partial failure, it carries the failure index [2,4] and the corresponding error code (error code 5 for index 2, error code 3 for index 4).

[0078] The ACK for the second shard: Assume the overall result is a complete success with no failure indexes.

[0079] 8. Query and delete mapping cache: The receiving module queries the corresponding mapping dictionary from the mapping cache based on (satellite IP, fragment sequence number) and deletes the cache entry. If the satellite does not return an ACK for a long time (timeout), the mapping dictionary in the cache will be cleared during the timeout handling process and will not permanently occupy memory.

[0080] For the first shard: using the key ("192.168.1.100", 1), we obtain the mapping dictionary {1:"tunnelId=1",2:"tunnelId=2",3:"tunnelId=3",4:"tunnelId=4",5:"tunnelId=5"}.

[0081] For the second shard: Since the ACK is all successful, no query is needed.

[0082] 9. Return mapping dictionary: The mapping cache returns the mapping dictionary corresponding to the first shard to the receiving module, which contains {2: "tunnelId=2", 4: "tunnelId=4"}.

[0083] 10. Traverse the failure indices and assemble the first failure detail object: The receiving module traverses the failure indices [2, 4] in the first fragment ACK, retrieves the service identifier from the mapping dictionary, and assembles the first failure detail object (FailDetail): Object A (service identifier = "tunnelId=2", index = 2, error code = 5); Object B (service identifier = "tunnelId=4", index = 4, error code = 3). The second fragment does not generate a first failure detail object.

[0084] 11. Collect all shard failure details into a list: The receiving module puts the two first failure detail objects generated by the first shard into a list.

[0085] 12. Return the configuration result object: The receiving module constructs a configuration result object (CfgResult), places the two first failure detail objects into the failure details list field (failDetails) of the configuration result object, and sets the overall result of the configuration result object to "partial failure". This configuration result object is then returned to the upper-level business module.

[0086] 13. Refined processing: When the upper-layer business module reads the failure details list in the configuration result object and finds that the configuration of tunnel 2 and tunnel 4 has failed, it can retry the configuration only for these two tunnels or log alarms.

[0087] Extensions for different entry types: If the above embodiment is changed to issue SR path entries, only the business identifier generation rule in step 3 needs to be modified to, for example, "tunnelIndex=5, labelStack=100,200", and the remaining steps are exactly the same. No changes are needed to the general components.

[0088] In a scheme that uses a uniform format (such as JSON) to serialize strings, the business identifier string generated in step 3 can be as follows:

[0089] For the SR path table entry corresponding to index 2, its original configuration content (including tunnel index and tag stack) is as follows:

[0090] {

[0091] "tunnelIndex": 5,

[0092] "labelStack": "100,200"

[0093] }

[0094] The serialized business identifier string is the compact form of the JSON above (with newlines and extra spaces removed):

[0095] {"tunnelIndex":5,"labelStack":"100,200"}

[0096] The failure details in step 10 can be generated as follows:

[0097] The receiving module constructs a Detail object based on the acknowledgment type in the acknowledgment message (e.g., the subType of the SR path entry is set to 86, this is just an example).

[0098] {

[0099] "type": 86,

[0100] "items": [

[0101] {

[0102] "index": 2,

[0103] "reason": 5,

[0104] "item": "{\"tunnelIndex\":5,\"labelStack\":\"100,200\"}"

[0105] } ]

[0107] }

[0108] After receiving this object, the upper-layer business can identify it as an SR path entry based on type=86, and deserialize the uniform format string in the item to restore the original configuration content (such as the tag stack information of tunnel 5), thereby accurately retrying the two failed SR path configurations or recording alarm logs.

[0109] like Figure 5 As shown, this embodiment of the invention also provides an electronic device, including a memory 21, a processor 22, and a computer program / instructions stored on the memory 21 and executable on the processor 22. When the computer program / instructions are executed by the processor 22, they implement the steps of the configuration-based fault location method in any of the above embodiments.

[0110] This invention also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the configuration-based fault location method in any of the above embodiments. The program code for implementing the method of this invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the steps of the method of this invention to be implemented.

[0111] The configuration and distribution fault location device, electronic equipment, and computer program products provided in this embodiment have the same beneficial effects as the location method described above, and will not be repeated here.

[0112] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.

[0113] It should also be noted that relational terms such as "first" and "second" in this specification are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The term "and / or" includes any and all combinations of one or more of the associated listed items. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0114] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for fault location via configuration distribution, characterized in that, Includes the following steps: For each fragmented packet containing several indexed configuration entries, a service identifier corresponding to each index is generated based on the service content of the configuration entries, a mapping relationship between the indexes and service identifiers within the fragmented packet is established, and the mapping relationship is associated with and stored in the cache with the first information used to identify the fragmented packet. The fragmented message is asynchronously sent to the target remote device; The system receives and parses the acknowledgment message returned by the remote device. When the acknowledgment message carries an index of at least one failure entry, it queries the mapping relationship based on the index of the failure entry in the acknowledgment message to obtain the corresponding service identifier, and generates failure details containing the service identifier. The failure details are used to determine the configuration entry for retransmission.

2. The configuration-based fault location method according to claim 1, characterized in that, The first information is composed of a remote device identifier and a fragmented packet sequence number; obtaining the corresponding service identifier by querying the mapping relationship based on the index of the acknowledgment packet failure entry includes: The remote device identifier and fragment sequence number are parsed from the confirmation message, combined to form the first information, and the corresponding mapping relationship is obtained from the cache based on the first information. The mapping relationship is then queried to convert the index of each failure entry in the confirmation message into the corresponding service identifier.

3. The configuration-based fault location method according to claim 2, characterized in that, After obtaining the corresponding mapping relationship from the cache based on the first information, the mapping relationship corresponding to the first information is deleted from the cache.

4. The configuration-based fault location method according to claim 1, characterized in that, For each fragmented packet, a service identifier corresponding to each index is generated based on the service content of the configuration table entries, including: extracting the service fields in the configuration table entries according to the configuration table entry type and concatenating them into a string with business meaning as the service identifier.

5. The configuration-based fault location method according to claim 4, characterized in that, The step of generating failure details containing a service identifier includes: creating a first failure details object for each failure index, wherein the first failure details object includes a service identifier, a failure index, and a corresponding error code carried in the acknowledgment message.

6. The configuration-based fault location method according to claim 1, characterized in that, For each fragmented packet, a service identifier corresponding to each index is generated based on the service content of the configuration table entries, including: serializing all service fields of the configuration table entries into a string of a uniform format as the service identifier.

7. The configuration-based fault location method according to claim 6, characterized in that, The generation of failure details containing service identifiers includes: creating a second failure details object for each response type used to determine the configuration table entry type in the confirmation message. The second failure details object includes the response type, as well as each failure index associated with the response type, the corresponding service identifier, and the corresponding error code carried in the confirmation message.

8. The configuration-based fault location method according to claim 1, characterized in that, Also includes: The failure details generated by all fragmented packets under the same configuration batch for the same target remote device are aggregated and returned to the upper-layer service.

9. An electronic device, comprising a memory, a processor, and a computer program / instructions stored in the memory and executable on the processor, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the configuration-based fault location method according to any one of claims 1-8.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the configuration-based fault location method according to any one of claims 1-8.

Images