Cross-switch configuration method and system based on netconf capability awareness

Abstract

This application provides a cross-switch configuration method and system based on NETCONF capability awareness. The method includes: obtaining NETCONF deep capability parameters of a network device, the deep capability parameters characterizing the network device's ability to process configuration data; parsing the topology dependencies of the configuration to be distributed to generate initial segments; adjusting the granularity of the initial segments according to the deep capability parameters; determining the write mode of the initial segments according to the deep capability parameters; locking candidate configurations of the network device; writing the configuration to be distributed segments into the candidate configurations according to a segmented write strategy; and atomically discarding all written configurations if any segment write fails. This application ensures the atomicity of full configuration while avoiding timeouts for large-volume configuration distribution, and can automatically adapt to heterogeneous devices from different vendors.

Description

Technical Field

[0001] This invention belongs to the field of network device configuration management technology, and in particular relates to a cross-switch configuration method and system based on NETCONF capability awareness. Background Technology

[0002] In software-defined networking (SDN) scenarios with multiple switches, single-service operations often involve configuration changes on multiple switches. These configurations must remain consistent to avoid network anomalies. The NETCONF protocol only provides a single-device configuration transaction mechanism, supporting configuration verification and submission through the separation of candidate and running configurations, but it lacks cross-device transaction coordination capabilities. In existing cross-device large-volume configuration distribution solutions, if a single edit-config RPC is used to distribute the full configuration, RPC timeouts will occur when the configuration volume exceeds the device's single-batch processing capacity. The controller may determine the configuration has failed, but the device may still be executing in the background, leading to inconsistencies between the two ends. If the distribution is split into multiple independent RPCs, atomicity between these RPCs cannot be guaranteed, and configurations already written cannot be automatically rolled back when some RPCs fail, also causing configuration inconsistencies. Furthermore, the NETCONF capabilities of heterogeneous devices from different vendors vary significantly, and a fixed segmentation strategy cannot adapt to all devices, easily leading to frequent timeouts on some devices or underutilization of device capabilities. Summary of the Invention

[0003] This application provides a cross-switch configuration consistency implementation scheme based on NETCONF capability awareness. Without modifying the atomicity boundary of the NETCONF protocol, it can solve the problem of timeout in a single edit-configRPC with a large amount of configuration, ensure the atomicity of pre-committing the full configuration, and adapt to the differences in NETCONF capabilities of heterogeneous devices from different manufacturers.

[0004] This application discloses a cross-switch configuration method based on NETCONF capability awareness, including: Obtain the NETCONF deep capability parameters of the network device, which characterize the network device's ability to process configuration data; The dependency topology to be configured is parsed to generate an initial segment, the granularity of the initial segment is adjusted according to the depth capability parameter, and the write mode of the initial segment is determined according to the depth capability parameter. Lock the candidate configuration of the network device, write the configuration to be distributed into the candidate configuration in segments according to the segmented writing strategy, and atomically discard all written configurations if any segment writing fails.

[0005] Optionally, obtain the NETCONF deep capability parameters of the network device, including: When establishing a NETCONF session with the network device, the candidate configuration sub-capability set, the device configuration processing capability set, and the device storage capability set are obtained through capability negotiation. The acquired candidate configuration sub-capability set, device configuration processing capability set, and device storage capability set are used as the deep capability parameters and bound to the device identifier of the network device for storage.

[0006] Optionally, parsing the dependent topology of the configuration to be distributed to generate initial segments includes: The configuration to be distributed is parsed into a YANG model node tree; Based on the dependency statements in the YANG model, a directed acyclic graph representing the dependency relationships between nodes is constructed. Perform topological sorting on the directed acyclic graph to generate an initial segment list without dependency conflicts; The configuration nodes with cyclic dependencies in the directed acyclic graph are merged into a composite segment, and the composite segment is added to the initial segment list.

[0007] Optionally, adjusting the granularity of the initial segmentation based on the depth capability parameter includes: When the network device supports error rollback capability, multiple independent initial segments are merged into a composite segment, wherein the number of nodes in the composite segment does not exceed the maximum number of nodes processed in a single batch of the network device, and the data volume of the composite segment does not exceed the maximum cache capacity of the candidate configuration of the network device. When the network device does not support error rollback capability, the initial segment with more than a preset threshold of nodes is split into multiple sub-segments, wherein the number of nodes in each sub-segment is less than the maximum number of nodes processed in a single batch, and the amount of data in each sub-segment is less than the maximum cache capacity of the candidate configuration.

[0008] Optionally, locking the candidate configurations of the network device includes: When the network device supports partial locking capability, partial locking is performed only on the configuration subtree involved in this transaction; When the network device does not support partial locking capabilities, global locking is performed on the entire candidate configuration of the network device.

[0009] Optionally, determining the write mode of the initial segment based on the depth capability parameters includes: The write mode of the initial segment is determined based on the maximum concurrent edit count of the network device. When the maximum concurrent edit count is 1, all segments are written serially in dependency order. When the maximum concurrent edit count is greater than 1, segments without dependencies are divided into parallel groups. Segments within the same group are written in parallel, while segments in different groups are written serially according to their dependency order. The number of segments in the parallel group does not exceed the maximum concurrent edit count.

[0010] Optionally, the configuration to be issued is written to the candidate configuration in segments according to a segmented writing strategy, including: For each segment, a timeout threshold is dynamically calculated for the edit configuration request of that segment based on the number of nodes contained in that segment and the configured processing throughput of the network device. Based on the calculated timeout threshold, wait for the execution result of this segment.

[0011] Optionally, if any segment write fails, atomically discard all written configurations, including: Immediately stop writing subsequent segments; While the candidate configuration remains locked, a candidate configuration discard operation is performed to clear all written configurations; When the candidate configuration discarding operation fails, the candidate configuration discarding operation is retried according to the exponential backoff strategy. After the candidate configuration discard operation is successful or the retry terminates, the lock on the candidate configuration is released.

[0012] Optionally, the method further includes: Once all segments have been successfully written, the lock on the candidate configuration is released, and the candidate configuration is submitted to the running configuration to make the configuration effective.

[0013] This application also discloses a cross-switch configuration system based on NETCONF capability awareness, including: The deep capability parameter acquisition module is used to acquire the NETCONF deep capability parameters of the network device, which are used to characterize the network device's ability to process configuration data. The write strategy generation module is used to parse the dependency topology to be configured to generate initial segments, adjust the granularity of the initial segments according to the depth capability parameters, and determine the write mode of the initial segments according to the depth capability parameters. The write and atomic rollback module is used to lock the candidate configuration of the network device, write the configuration to be issued into the candidate configuration in segments according to the segmented write strategy, and atomically discard all written configurations if any segmented write fails.

[0014] As can be seen from the above technical solution, obtaining the device's NETCONF deep capability parameters before configuration distribution can accurately grasp the actual configuration processing boundary of the device, providing an accurate adaptation basis for subsequent policy generation. Then, generating initial segments based on the dependency topology of the configuration to be distributed can avoid dependency order errors during subsequent configuration writing. Adjusting the granularity and writing mode of the initial segments based on the deep capability parameters ensures that the generated segment size and writing logic perfectly match the processing capacity of the corresponding device, preventing the configuration volume from exceeding the device threshold. Subsequently, locking candidate configurations before performing segmented writing ensures that no other transactions modify candidate configurations during segmented writing, preventing external operations from interfering with the configuration to be written. If any segment fails, all written configurations are atomically discarded, allowing the candidate configurations to be directly restored to the state before locking. The entire process is seamless, avoiding timeout issues with large-volume configuration distribution and ensuring the atomicity of full configuration. It can also automatically adapt to heterogeneous devices from different manufacturers. Attached Figure Description

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

[0016] Figure 1 This is one of the flowcharts of a cross-switch configuration method based on NETCONF capability awareness in the embodiments of this application; Figure 2 This is a flowchart illustrating a cross-switch configuration method based on NETCONF capability awareness to obtain the NETCONF deep capability parameters of a network device, as described in an embodiment of this application. Figure 3 This is a flowchart illustrating a cross-switch configuration method based on NETCONF capability awareness in an embodiment of this application, which parses the dependent topology of the configuration to be distributed to generate initial segments. Figure 4 This is a flowchart illustrating the adjustment of the granularity of the initial segment based on the deep capability parameters in a cross-switch configuration method based on NETCONF capability awareness, as described in an embodiment of this application. Figure 5 This is a flowchart illustrating a cross-switch configuration method based on NETCONF capability awareness to lock the candidate configuration of the network device in an embodiment of this application; Figure 6 This is a flowchart illustrating a cross-switch configuration method based on NETCONF capability awareness, as described in this application embodiment, which determines the write mode of the initial segment according to the deep capability parameters. Figure 7 This is a flowchart illustrating a cross-switch configuration method based on NETCONF capability awareness in an embodiment of this application, in which the configuration to be distributed is written into the candidate configuration in segments according to a segmented writing strategy; Figure 8 This is a flowchart of another step in a cross-switch configuration method based on NETCONF capability awareness, as described in an embodiment of this application. Figure 9 This is a schematic diagram of a cross-switch configuration system based on NETCONF capability awareness, provided as an embodiment of this application. Detailed Implementation

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

[0018] In this application embodiment, the specific implementation methods of the prior art are first described. Taking the batch creation of cross-switch logical networks as an example, there are two typical implementation methods in the prior art. The first implementation method uses a single edit-configRPC to issue the full configuration. When 100 logical networks need to be created, the full configuration includes 5000 YANG nodes. If the maximum number of nodes that the device can process in a single batch is 1000, this RPC will exceed the processing capacity of the device, resulting in a timeout. The controller will determine that the configuration has failed after the timeout, but the device may still be executing the configuration writing in the background, ultimately leading to an inconsistency between the state of the controller and the device. The second implementation method splits the full configuration into 300 independent RPCs, issuing one configuration item each time. When the 150th RPC fails, the configurations of the previous 149 RPCs have already been written to the candidate configurations. The prior art cannot automatically roll back these written configurations, resulting in some configurations taking effect and some not taking effect, causing inconsistencies in cross-device configurations. Furthermore, existing technologies employ a fixed segmentation strategy. For high-end devices that support error rollback capabilities, this strategy cannot fully utilize their capabilities to reduce the number of segments, resulting in low write efficiency. For low-end devices that do not support error rollback capabilities, the fixed large segments lead to frequent timeouts. It should be noted that the parameters mentioned above in this application are merely illustrative, and those skilled in the art can set them according to actual needs; this application does not limit such settings.

[0019] Based on this, embodiments of this application provide a cross-switch configuration method based on NETCONF capability awareness, such as... Figure 1 As shown, the method includes: S100: Obtain the NETCONF deep capability parameters of the network device, which are used to characterize the network device's ability to process configuration data; S200: Parse the dependent topology of the configuration to be issued to generate an initial segment, adjust the granularity of the initial segment according to the depth capability parameter, and determine the write mode of the initial segment according to the depth capability parameter; S300: Lock the candidate configuration of the network device, write the configuration to be sent into the candidate configuration in segments according to the segmented writing strategy, and atomically discard all written configurations if any segmented writing fails.

[0020] This application provides a cross-switch configuration method based on NETCONF capability awareness. Before configuration distribution, the method first obtains the device's NETCONF deep capability parameters, which can accurately grasp the actual configuration processing boundary of the device and provide an accurate adaptation basis for subsequent policy generation. Then, it generates initial segments based on the dependent topology of the configuration to be distributed, which can avoid dependency order errors during subsequent configuration writing. Then, it adjusts the granularity and writing mode of the initial segments based on the deep capability parameters, which can ensure that the generated segment size and writing logic are completely matched with the processing capacity of the corresponding device, and will not cause the configuration volume to exceed the device threshold. Subsequently, the candidate configuration is locked before segment writing, which can ensure that no other transactions modify the candidate configuration during the segment writing period, and avoid the configuration to be written being interfered with by external operations. If any segment fails, all written configurations are atomically discarded, allowing the candidate configuration to be directly restored to the state before locking. The entire process is seamless, which can not only avoid the problem of timeout for large configuration volume distribution, but also ensure the atomicity of full configuration, and can automatically adapt to heterogeneous devices from different manufacturers.

[0021] It should be noted that the concept of this application specifically addresses the issue that in software-defined networking (SDN) scenarios with multiple switches, single-service operations often involve configuration changes on multiple switches. These configurations must remain consistent, otherwise network anomalies may occur. The NETCONF protocol only provides a single-device configuration transaction mechanism, supporting configuration verification and submission through the separation of candidate and running configurations, but it does not provide cross-device transaction coordination capabilities. In existing cross-device large-volume configuration distribution schemes, if a single edit-config RPC is used to distribute the full configuration, an RPC timeout will occur when the configuration volume exceeds the device's single-batch processing capacity. The controller determines the configuration has failed, but the device may still be executing in the background, leading to inconsistencies between the two ends. If it is split into multiple independent RPC distributions, the atomicity between multiple RPCs cannot be guaranteed. When some RPCs fail, the configurations already written cannot be automatically rolled back, also causing configuration inconsistencies. Furthermore, the NETCONF capabilities of heterogeneous devices from different vendors vary significantly, and a fixed segmentation strategy cannot adapt to all devices, easily leading to frequent timeouts on some devices or underutilization of device capabilities.

[0022] The embodiments of this application will be described in detail below.

[0023] In this embodiment, obtaining the NETCONF deep capability parameters of the network device is a prerequisite for the entire solution. The NETCONF protocol defines a standard capability negotiation mechanism. When a device establishes a session with the controller, it announces its supported capabilities through hello messages. This application not only obtains basic candidate configuration capabilities but also deeply mines other standard capability parameters of the device. These parameters directly determine the device's configuration processing capabilities and atomicity guarantee capabilities. Based on the deep capability parameters and the dependency topology of the configuration to be distributed, a segmented write strategy adapted to the network device is generated. This step solves the problem of timeout for large configuration volumes. By parsing the dependency topology of the configuration, the correctness of the segmented write order can be guaranteed, avoiding configuration failures due to incorrect dependency order. Dynamically adjusting the segmentation granularity and write mode according to the device capabilities allows the segmentation strategy to accurately match the actual capabilities of each device, avoiding a one-size-fits-all problem. The candidate configurations of the network device are locked, and segmented writes are executed according to the segmented write strategy. If any segmented write fails, all written configurations are atomically discarded. This step is crucial to ensuring the atomicity of the full configuration. By using global locking, multiple segmented writes are encapsulated within an isolated transaction period, ensuring that no other transactions interfere with the candidate configuration during the segmented write process. If any segment fails, the candidate configuration is restored to its state before locking through atomic discard, ensuring that when the lock is released, the candidate configuration either succeeds completely or is rolled back completely.

[0024] It should be noted that the generation of the segmented write strategy adapted to the network device includes three sub-steps: parsing the dependent topology of the configuration to be distributed to generate initial segments, adjusting the granularity of the initial segments according to the depth capability parameters, and determining the write mode according to the depth capability parameters. These three sub-steps form a complete segmented strategy generation logic. The inputs are the depth capability parameters and the configuration to be distributed, and the output is the segmented write strategy adapted to the device. Among them, parsing the dependent topology to generate initial segments is fundamental, ensuring the correctness of the dependencies between segments; adjusting the granularity of the initial segments solves the timeout problem for large configuration volumes; and determining the write mode is an optimization, making full use of the device's concurrent processing capabilities to improve write efficiency.

[0025] For example, adjusting the granularity of the initial segment based on the depth capability parameters includes two sub-steps: adjusting the granularity of the initial segment based on the maximum number of processing nodes per batch and the maximum cache capacity of the candidate configuration of the network device, and adjusting the granularity of the initial segment based on whether the network device supports error rollback capability. These two sub-steps adjust the granularity of the initial segment from the two dimensions of the device's hardware processing capability and protocol capability, respectively. The maximum number of processing nodes per batch and the maximum cache capacity of the candidate configuration determine the maximum configuration amount of a single segment, while error rollback capability determines whether multiple independent segments can be merged.

[0026] In alternative implementations, such as Figure 2 As shown, obtaining the NETCONF deep capability parameters of the network device includes: S210: When establishing a NETCONF session with the network device, obtain the candidate configuration sub-capability set, the device configuration processing capability set, and the device storage capability set through capability negotiation.

[0027] S220: The acquired candidate configuration sub-capability set, device configuration processing capability set, and device storage capability set are used as the deep capability parameters and bound to the device identifier of the network device for storage.

[0028] In this embodiment, the acquisition of NETCONF deep capability parameters of the network device is performed when establishing a NETCONF session with the network device. NETCONF sessions are typically established based on the SSH protocol. After the session is established, the controller and the device first exchange hello messages to negotiate capabilities. The device includes URN identifiers for all NETCONF capabilities it supports in the hello message. This application focuses on analyzing three types of deep capability parameters: candidate configuration sub-capability sets, device configuration processing capability sets, and device storage capability sets. Candidate configuration sub-capability sets include confirmation and commit capabilities, partial locking capabilities, and error rollback capabilities, which determine the device's atomicity guarantee capabilities. Device configuration processing capability sets include the maximum number of YANG nodes that can be processed in a single batch, the maximum number of concurrent edit-config calls, and configuration processing throughput, which determine the device's configuration processing efficiency. Device storage capability sets include the maximum cache capacity of candidate configurations and whether incremental configuration caching is supported, which determine the maximum amount of configurations the device can cache. The acquired deep capability parameters are bound to the device identifier and stored in the controller-side cache. Before each configuration transaction is initiated, the cache is checked for expiration; if expired, capability negotiation is re-performed.

[0029] Specifically, the URN identifiers of candidate configuration sub-capability sets follow the NETCONF standard definition. The URN for error rollback capability is `urn:ietf:params:netconf:capability:rollback-on-error:1.0`. Devices supporting this capability will automatically roll back all configuration operations within an `edit-config` RPC if a configuration operation fails, ensuring atomicity within a single RPC. The URN for partial locking capability is `urn:ietf:params:netconf:capability:partial-lock:1.0`. Devices supporting this capability can lock only specific subtrees within the candidate configuration, rather than locking the entire candidate configuration, thereby improving concurrent throughput. The device configuration processing capability set and storage capability set are obtained through the NETCONF standard `get` operation. The device's state data includes the `netconf-state` node, and the `capabilities` sub-nodes under this node contain the device's processing and storage capability parameters.

[0030] In an optional embodiment, the dependent topology of the configuration to be distributed is parsed to generate initial segments, such as... Figure 3 As shown, it includes: S230: Parse the configuration to be distributed into a YANG model node tree.

[0031] S240: Based on the dependency statements in the YANG model, construct a directed acyclic graph representing the dependency relationships between nodes.

[0032] S250: Perform topological sorting on the directed acyclic graph to generate an initial segment list without dependency conflicts.

[0033] S260: Merge the configuration nodes with cyclic dependencies in the directed acyclic graph into a composite segment, and add the composite segment to the initial segment list.

[0034] In this embodiment, the process of parsing the dependency topology of the configuration to be distributed to generate initial segments is as follows: First, the full configuration data to be distributed is parsed into a YANG model node tree, with each configuration item corresponding to a node in the YANG model. Then, a directed acyclic graph is constructed based on the dependency statements in the YANG model. The dependency statements in the YANG model include must, when, augment, leafref, etc. The must statement defines the conditions that a node must meet, the when statement defines the conditions for the existence of a node, the augment statement defines the extension to other modules, and the leafref statement defines the reference to other nodes. By parsing these dependency statements, the dependency relationships between various configuration nodes can be determined. For example, the leafref statement in the interface configuration node references the VLAN ID of the VLAN configuration node, indicating that the interface configuration depends on the VLAN configuration. The constructed directed acyclic graph is topologically sorted to generate an initial segment list without dependency conflicts. The topological sorting ensures that all preceding dependent nodes are placed before the dependent nodes. If there is a circular dependency, i.e., A depends on B and B depends on A, then all configuration nodes in the circular dependency are merged into a composite segment to avoid write failures caused by dependency conflicts.

[0035] For example, in configuring the batch creation of logical networks, the VLAN configuration node has no prerequisites and is a first-level node. The interface configuration node references the VLAN ID of the VLAN configuration node and depends on the VLAN configuration, making it a second-level node. The ACL configuration node references the interface name of the interface configuration node and depends on the interface configuration, making it a third-level node. The initial segment list generated after topology sorting consists of 100 VLAN segments, 100 interface segments, and 100 ACL segments, for a total of 300 initial segments. If an ACL configuration node references two interface configuration nodes, and these two interface configuration nodes reference different VLAN configuration nodes, there is no circular dependency, and the initial segments are still generated according to the topology sorting. If there is a circular dependency where A depends on B, B depends on C, and C depends on A, then nodes A, B, and C are merged into a composite segment. It should be noted that the parameters mentioned above in this application are merely illustrative, and those skilled in the art can set them according to actual needs; this application does not limit them in this regard.

[0036] In alternative implementations, such as Figure 4 As shown, adjusting the granularity of the initial segmentation according to the depth capability parameter includes: S270: When the network device supports error rollback capability, multiple independent initial segments are merged into a composite segment, wherein the number of nodes in the composite segment does not exceed the maximum number of nodes processed in a single batch of the network device, and the data volume of the composite segment does not exceed the maximum cache capacity of the candidate configuration of the network device.

[0037] S280: When the network device does not support error rollback capability, the initial segment with more than a preset threshold of nodes is split into multiple sub-segments, wherein the number of nodes in each sub-segment is less than the maximum number of nodes processed in a single batch, and the amount of data in each sub-segment is less than the maximum cache capacity of the candidate configuration.

[0038] In this embodiment, the granularity of the initial segments is adjusted based on the maximum number of processing nodes per batch of the network device and the maximum cache capacity of the candidate configuration. When the network device supports error rollback capability, the device can guarantee the atomicity within a single edit-config RPC. Therefore, adjacent, independent initial segments can be merged into larger composite segments, reducing the number of segments and improving write efficiency. The number of nodes in the merged composite segment does not exceed the maximum number of processing nodes per batch of the device, and the data volume does not exceed a preset proportion of the maximum cache capacity of the candidate configuration. This preset proportion is set to 80%, reserving 20% ​​of the redundancy space to avoid the actual size of the encoded configuration data exceeding the device threshold. When the network device does not support error rollback capability, the device cannot guarantee the atomicity within a single RPC. If the configuration volume of a single RPC is too large, partial operation failures will cause some configurations to take effect while others do not, thus compromising the atomicity of the single segment. Therefore, initial segments exceeding the preset threshold need to be split into smaller sub-segments. The number of nodes in a single sub-segment does not exceed 60% of the maximum number of processing nodes per batch, and the data volume does not exceed 50% of the maximum cache capacity of the candidate configuration, reserving more redundancy space to avoid timeout and partial failure issues. In a specific example, for devices supporting error rollback capabilities, the maximum number of nodes processed in a single batch is 3000, and the maximum cache capacity for candidate configurations is 1024KB. The initial segment list contains 300 segments, with a total of 1200 nodes and a total data volume of 200KB, far less than the device's threshold. Therefore, all 300 initial segments are merged into a single composite segment, requiring only one edit-configRPC to complete the write. For devices not supporting error rollback capabilities, the maximum number of nodes processed in a single batch is 1000, and the maximum cache capacity for candidate configurations is 512KB. Each initial segment has fewer than 600 nodes and less than 256KB of data, so the initial segment granularity remains unchanged at 300 segments. If an initial segment has 800 nodes, exceeding the 600 threshold, it is split into two sub-segments, each with 400 nodes. It should be noted that the parameters mentioned above are merely illustrative, and those skilled in the art can set them according to actual needs; this application does not limit them.

[0039] In an optional embodiment, candidate configurations of the network device are locked, such as... Figure 5 As shown, it includes: S310: When the network device supports partial locking capability, partial locking is performed only on the configuration subtree involved in this transaction.

[0040] S320: When the network device does not support partial locking capability, perform global locking on the entire candidate configuration of the network device.

[0041] In this embodiment, partial locking capability is preferentially used when locking candidate configurations of the network device. When the network device supports partial locking capability, only the configuration subtree involved in the current transaction is locked, rather than the entire candidate configuration. For example, if the current transaction only involves three configuration modules: VLAN, interface, and ACL, then only the configuration subtrees / if:interfaces, / vlan:vlans, and / acl:acls are locked. Other transactions can freely operate on the unlocked configuration subtrees, such as routing configurations and system configurations, thereby improving concurrent throughput. When the network device does not support partial locking capability, only full locking capability can be used to lock the entire candidate configuration. In this case, other transactions cannot modify any configuration of the device until the lock is released. Partial locking capability is a capability defined by the NETCONF standard and can be used without modifying the device protocol stack. This application automatically detects whether the device supports this capability through capability negotiation and selects the optimal locking method.

[0042] It should be noted that partial locking operations are implemented using the NETCONF standard partial-lockRPC, which carries the path to the configuration subtree to be locked. Upon receiving the partial-lockRPC, the device locks the specified configuration subtree and returns a lock identifier. Releasing the lock involves sending this lock identifier via unlockRPC. Full locking operations are implemented using the standard lockRPC, locking the entire candidate configuration. Regardless of the locking method used, the lock holding time should be as short as possible to minimize the impact on other transactions. This scheme limits the lock holding time to the period between segmented writes and atomic discards; the lock is released immediately after all segmented writes are successful, and immediately after an atomic discard if a segment fails.

[0043] In an optional embodiment, the write mode of the initial segment is determined based on the depth capability parameters, such as... Figure 6 As shown, it includes: S330: Determine the write mode of the initial segment based on the maximum concurrent edit count of the network device. When the maximum concurrent edit count is 1, all segments are written serially in dependency order.

[0044] S340: When the maximum concurrent edit count is greater than 1, segments without dependencies are divided into parallel groups. Segments within the same group are written in parallel, and different groups are written serially according to their dependency order. The number of segments in the parallel group does not exceed the maximum concurrent edit count.

[0045] In this embodiment, the write mode is determined based on the depth capability parameter. When the maximum concurrent edit count of the network device is 1, the device can only process edit-config RPCs serially. If multiple RPCs are sent in parallel, the device will queue them, which will increase processing latency and may even cause timeouts. Therefore, all segments are written serially in the order of topology sorting. The next segment's RPC is sent only after the previous segment's RPC returns a success. When the maximum concurrent edit count of the network device is greater than 1, the device can process multiple edit-config RPCs in parallel. In this case, the initial segment list can be divided into multiple independent parallel groups. Segments within the same group send RPCs in parallel, while segments between different groups are written serially in the order of dependency. The size of the parallel group does not exceed the device's maximum concurrent edit count to avoid exceeding the device's concurrent processing capacity, which could lead to queuing or rejection.

[0046] In a specific example, for a device with a maximum concurrent edit count of 2, the initial segment list contains 300 segments, of which 100 VLAN segments, 100 interface segments, and 100 ACL segments are independent of each other. The 100 VLAN segments are divided into 50 parallel groups, each containing 2 VLAN segments. RPCs are sent in parallel between the two segments within the same group, while execution is serial between different groups. After all VLAN segments are written, the interface segments and ACL segments are written in the same way. This fully utilizes the device's concurrent processing capabilities, reducing the write time by approximately half. For a device with a maximum concurrent edit count of 1, all 300 segments can only be written serially, with the next segment being sent only after the RPC of each segment returns a successful response. It should be noted that the parameters described above are merely illustrative, and those skilled in the art can set them according to actual needs; this application does not limit their implementation.

[0047] In an optional embodiment, the configuration to be issued is written to the candidate configuration in segments according to a segmented writing strategy, such as... Figure 7 As shown, it includes: S350: For each segment, dynamically calculate the timeout threshold for the edit configuration request of that segment based on the number of nodes contained in that segment and the configuration processing throughput of the network device.

[0048] S360: Based on the calculated timeout threshold, wait for the execution result of this segment.

[0049] In this embodiment, when performing segmented writing according to the segmented writing strategy, the RPC timeout threshold for each segment is dynamically calculated. A fixed timeout threshold cannot adapt to the differences in configuration volume between different segments; small segments have excessively long waiting times, while large segments are prone to timeouts. This solution dynamically calculates the timeout threshold for each segment based on the number of nodes in each segment and the device's configured processing throughput. The configured processing throughput is the number of YANG nodes that the device can process per second, obtained through capacity negotiation. The timeout threshold is calculated by adding the base timeout time to the number of nodes in the segment divided by the processing throughput, and then multiplying by a redundancy coefficient. The base timeout time is set to 5 seconds to cover network transmission latency and the device's base processing latency. The redundancy coefficient is set to 1.5 to cope with increased processing latency caused by temporary load fluctuations in the device.

[0050] For example, for a device configured with a processing throughput of 1000 nodes / second, the timeout threshold for a composite segment containing 1200 nodes is 5 seconds plus 1200 divided by 1000 multiplied by 1.5, which equals 6.8 seconds, rounded down to 7 seconds. For a device configured with a processing throughput of 500 nodes / second, the timeout threshold for a VLAN segment containing 5 nodes is 5 seconds plus 5 divided by 500 multiplied by 1.5, which approximately equals 5.02 seconds, rounded down to 6 seconds. Each segment calculates its corresponding timeout threshold based on its own number of nodes, thus avoiding both excessively long waiting times for small segments and misjudgments of timeouts in large segments. It should be noted that the parameters mentioned above in this application are merely exemplary, and those skilled in the art can set them according to actual needs; this application does not limit them in this regard.

[0051] In optional embodiments, such as Figure 8 As shown, if any segment write fails, the atom discards all written configurations, including: S311: Immediately stop writing subsequent segments.

[0052] S312: While the candidate configuration remains locked, perform a candidate configuration discard operation to clear all written configurations.

[0053] S313: When the candidate configuration discarding operation fails, the candidate configuration discarding operation shall be retried according to the exponential backoff strategy.

[0054] S314: After the candidate configuration discard operation is successful or the retry terminates, release the lock on the candidate configuration.

[0055] In this embodiment, all written configurations are atomically discarded when any segment write fails. When an RPC for a segment returns a failure, including any error such as timeout, syntax error, insufficient resources, or permission denial, writing to all subsequent segments is immediately stopped to avoid writing more invalid configurations. Then, a candidate configuration discard operation is performed while the lock is active, i.e., the discard-changesRPC of the NETCONF standard. Discard-changesRPC restores the candidate configuration to its state before locking, atomically discarding all written segment configurations. Since the candidate configuration lock is still held, other transactions cannot modify the candidate configuration, thus ensuring the atomicity of the discard-changes operation. If the discard-changes operation fails, possibly due to temporary device load fluctuations or link jitter, it is retried 3 times using an exponential backoff strategy. The initial delay is 1 second, and the delay time doubles with each retry, with a maximum delay of 8 seconds. If the retry still fails, a detailed error log is recorded, including the device identifier, information of the failed segment, error information, and the execution status of the discard-changes operation. Finally, the candidate configuration lock is released, the transaction is terminated, and a failure result is returned to the business application.

[0056] It's important to note that the discard-changes operation must be performed while the lock is engaged. If the lock is released before discard-changes, other transactions might modify candidate configurations during the interval, preventing the discard-changes from restoring the state before the lock was engaged and violating atomicity. This solution strictly guarantees that the discard-changes operation is performed within the lock, ensuring the reliability of atomic discard. The exponential backoff strategy avoids frequent retries that could further increase device load, while also improving the success rate of atomic discard.

[0057] In an optional embodiment, the method further includes: Once all segments have been successfully written, the lock on the candidate configuration is released, and the candidate configuration is submitted to the running configuration to make the configuration effective.

[0058] In this embodiment, after all segments are successfully written, the candidate configuration lock is released, and the candidate configuration is committed to the running configuration to make the configuration effective. After all segments are successfully written, the candidate configuration contains the full configuration of this transaction, and the state is consistent. At this time, the candidate configuration lock is released, allowing other transactions to modify the candidate configuration. Then, the NETCONF standard commitRPC is executed to commit the candidate configuration to the running configuration, making the configuration officially effective. After the commitRPC is executed successfully, this cross-device configuration transaction is completed, and the configuration of all devices is consistent. If the commitRPC fails, the compensation and rollback phase is entered, and the reverse configuration is executed on the devices that have been successfully committed to restore them to the initial state.

[0059] This application also provides a cross-switch configuration system based on NETCONF capability awareness, such as... Figure 9 As shown, it includes: The deep capability parameter acquisition module 11 is used to acquire the NETCONF deep capability parameters of the network device, which are used to characterize the network device's ability to process configuration data.

[0060] The write strategy generation module 12 is used to parse the dependency topology to be configured to generate an initial segment, adjust the granularity of the initial segment according to the depth capability parameter, and determine the write mode of the initial segment according to the depth capability parameter.

[0061] The write and atomic rollback module 13 is used to lock the candidate configuration of the network device, write the configuration to be issued into the candidate configuration in segments according to the segmented write strategy, and atomically discard all written configurations when any segmented write fails.

[0062] In this embodiment, the NETCONF-aware cross-switch configuration system comprises five functional modules. The NETCONF capability awareness module negotiates NETCONF capabilities with the device, acquiring and caching the device's deep capability parameters. The dynamic segmentation strategy generation module parses the dependent topology of the configuration to be distributed, generates initial segments, and adjusts the segmentation granularity and write mode based on device capabilities. The global locking execution module selects an appropriate locking method based on the device's capabilities and locks candidate configurations. The segmented write execution module executes segmented writes according to the segmented write strategy and dynamically calculates the timeout threshold for each segment. The atomic discard fallback module performs an atomic discard operation to restore the candidate configuration to its initial state should any segment write fail. The modules interact with each other through internal interfaces to collaboratively achieve cross-switch configuration consistency.

[0063] Specifically, the NETCONF capability awareness module starts when the controller establishes a NETCONF session with the device, and stores the deep capability parameters in the controller's distributed cache after capability negotiation. The dynamic segmentation strategy generation module starts when the business application initiates a configuration request, receives the configuration data to be distributed and the device identifier, retrieves the device's deep capability parameters from the cache, and generates a segmentation write strategy. The global lock execution module starts before segmentation write, sends a lock RPC to the device, and obtains the lock identifier. The segmentation write execution module sends edit-config RPCs sequentially according to the segmentation write strategy, and waits for the execution result of each RPC. The atomic discard fallback module starts when any segmentation fails, executes discard-changes RPC, releases the lock, and terminates the transaction.

[0064] The following is a detailed explanation of this solution using a specific application example. A business application initiates a request to create 100 cross-switch logical networks in batches. This requires configuring 100 VLANs, 100 interface configurations, and 100 ACL rules on two switches respectively. The full configuration data includes approximately 5000 YANG nodes. Switch A supports error rollback and partial locking capabilities, with a maximum batch processing capacity of 3000 nodes, a maximum concurrent edit count of 2, a configuration processing throughput of 1000 nodes / second, and a maximum candidate configuration cache capacity of 1024KB. Switch B does not support error rollback but supports partial locking capabilities, with a maximum batch processing capacity of 1000 nodes, a maximum concurrent edit count of 1, a configuration processing throughput of 500 nodes / second, and a maximum candidate configuration cache capacity of 512KB.

[0065] When the controller establishes a NETCONF session with the two switches, it negotiates capabilities separately, obtains the aforementioned deep capability parameters, binds them to the device identifier, and stores them in the cache. After the service application initiates a configuration request, the dynamic segmentation policy generation module parses the configuration to be distributed into a YANG model node tree, and constructs a directed acyclic graph based on the dependency statements of the YANG model. VLAN configuration nodes are first-level nodes, interface configuration nodes that depend on VLAN configurations are second-level nodes, and ACL configuration nodes that depend on interface configurations are third-level nodes, with no circular dependencies. The directed acyclic graph is topologically sorted to generate an initial segmentation list containing 100 VLAN segments, 100 interface segments, and 100 ACL segments, for a total of 300 initial segments.

[0066] For switch A, because it supports error rollback, the dynamic segmentation strategy generation module merges all 300 initial segments into a single composite segment. This composite segment has a total of 1200 nodes, less than the maximum number of nodes that can be processed in a single batch (3000). The total data volume is 200KB, less than 80% of the maximum cache capacity of the candidate configuration (819.2KB). The write mode is determined to be serial write because it is merged into a single segment. For switch B, because it does not support error rollback, the number of nodes in each initial segment is less than 60% of the maximum number of nodes that can be processed in a single batch (600), and the data volume is less than 50% of the maximum cache capacity of the candidate configuration (256KB). Therefore, the initial segment granularity remains unchanged at 300 segments. The write mode is determined to be serial write because its maximum concurrent edit count is 1.

[0067] The global lock execution module sends partial-lockRPCs to both switches to lock the three configuration subtrees: / if:interfaces, / vlan:vlans, and / acl:acls, and obtain lock identifiers. The segmented write execution module first processes the composite segmentation of switch A, dynamically calculating its timeout threshold as 5 seconds plus 1200 divided by 1000 multiplied by 1.5, which equals 6.8 seconds, rounded down to 7 seconds. It then sends an edit-configRPC containing 1200 nodes, with a timeout threshold set to 7 seconds. Switch A utilizes its native error rollback capability to handle this RPC; all configurations are either written to the candidate configurations or rolled back entirely. The RPC returns success after 4.2 seconds.

[0068] Then, the segmented write execution module processes 300 segments from switch B. Each VLAN segment has 5 nodes, and the timeout threshold is 5 seconds plus 5 divided by 500 multiplied by 1.5, approximately equal to 5.02 seconds, rounded down to 6 seconds. 100 VLAN segment RPCs are sent sequentially, each taking an average of 0.5 seconds, and all succeed. Next, 100 interface segment RPCs are sent sequentially, each with 3 nodes, and a timeout threshold of 6 seconds, all succeeding. When sending the 50th ACL segment RPC, a timeout occurs after 5.8 seconds due to a temporary increase in switch B's load.

[0069] The atomic discard fallback module immediately stops writing the subsequent 50 ACL segments. While locked, it sends a discard-changesRPC to switch B, atomically discarding all written configurations for 100 VLANs, 100 interfaces, and 49 ACLs. The discard-changesRPC executes successfully. Then, it sends unlockRPC to both switches to release the candidate configuration locks. The transaction is terminated, and a failure result is returned to the application. The candidate configurations on both switches are restored to their initial state before locking, with no configuration residue, ensuring cross-device configuration consistency.

[0070] It should be noted that the parameters mentioned above in this application are merely illustrative, and those skilled in the art can set them according to actual needs; this application does not limit them in this regard.

[0071] Those skilled in the art will understand that the above example is merely an exemplary embodiment of this application, and the scope of protection of this application is not limited thereto. For example, when the maximum concurrent edit count of the device is greater than 1, independent segments can be divided into parallel groups and RPCs can be sent in parallel to further improve write efficiency. When the device does not support partial locking capabilities, full locking capabilities can be used as a fallback. When discard-changes operations fail, a retry mechanism can be used to improve the success rate. All such equivalent substitutions or modifications should be covered within the scope of protection of this application. It should be noted that the parameters mentioned above in this application are merely exemplary, and those skilled in the art can set them according to actual needs; this application does not limit them in this regard.

[0072] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0073] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for cross-switch configuration based on NETCONF capability awareness, characterized in that, The method includes: Obtain the NETCONF deep capability parameters of the network device, which characterize the network device's ability to process configuration data; The dependency topology to be configured is parsed to generate an initial segment, the granularity of the initial segment is adjusted according to the depth capability parameter, and the write mode of the initial segment is determined according to the depth capability parameter. Lock the candidate configuration of the network device, write the configuration to be distributed into the candidate configuration in segments according to the segmented writing strategy, and atomically discard all written configurations if any segment writing fails.

2. The method of claim 1, wherein, The acquisition of the NETCONF depth capability parameters of the network device includes: When establishing a NETCONF session with the network device, the candidate configuration sub-capability set, the device configuration processing capability set, and the device storage capability set are obtained through capability negotiation. The acquired candidate configuration sub-capability set, device configuration processing capability set, and device storage capability set are used as the deep capability parameters and bound to the device identifier of the network device for storage.

3. The method of claim 1, wherein, The process of parsing the dependency topology of the configuration to be distributed to generate initial segments includes: The configuration to be distributed is parsed into a YANG model node tree; Based on the dependency statements in the YANG model, a directed acyclic graph representing the dependency relationships between nodes is constructed. Perform topological sorting on the directed acyclic graph to generate an initial segment list without dependency conflicts; The configuration nodes with cyclic dependencies in the directed acyclic graph are merged into a composite segment, and the composite segment is added to the initial segment list.

4. The method of claim 1, wherein, The step of adjusting the granularity of the initial segmentation according to the depth capability parameter includes: When the network device supports error rollback capability, multiple independent initial segments are merged into a composite segment, wherein the number of nodes in the composite segment does not exceed the maximum number of nodes processed in a single batch of the network device, and the data volume of the composite segment does not exceed the maximum cache capacity of the candidate configuration of the network device. When the network device does not support error rollback capability, the initial segment with more than a preset threshold of nodes is split into multiple sub-segments, wherein the number of nodes in each sub-segment is less than the maximum number of nodes processed in a single batch, and the amount of data in each sub-segment is less than the maximum cache capacity of the candidate configuration.

5. The method of claim 1, wherein, The process of locking the candidate configurations of the network device includes: When the network device supports partial locking capability, partial locking is performed only on the configuration subtree involved in this transaction; When the network device does not support partial locking capabilities, global locking is performed on the entire candidate configuration of the network device.

6. The method of claim 1, wherein, The step of determining the write mode of the initial segment based on the depth capability parameters includes: The write mode of the initial segment is determined based on the maximum concurrent edit count of the network device. When the maximum concurrent edit count is 1, all segments are written serially in dependency order. When the maximum concurrent edit count is greater than 1, segments without dependencies are divided into parallel groups. Segments within the same group are written in parallel, while segments in different groups are written serially according to their dependency order. The number of segments in the parallel group does not exceed the maximum concurrent edit count.

7. The method of claim 1, wherein, The step of writing the configuration to be issued into the candidate configuration in segments according to the segmented writing strategy includes: For each segment, a timeout threshold is dynamically calculated for the edit configuration request of that segment based on the number of nodes contained in that segment and the configured processing throughput of the network device. Based on the calculated timeout threshold, wait for the execution result of this segment.

8. The method of claim 1, wherein, The statement that in the event of a write failure in any segment, all written configurations are discarded atomically includes: Immediately stop writing subsequent segments; While the candidate configuration remains locked, a candidate configuration discard operation is performed to clear all written configurations; When the candidate configuration discarding operation fails, the candidate configuration discarding operation is retried according to the exponential backoff strategy. After the candidate configuration discard operation is successful or the retry terminates, the lock on the candidate configuration is released.

9. The method of claim 8, wherein, The method further includes: Once all segments have been successfully written, the lock on the candidate configuration is released, and the candidate configuration is submitted to the running configuration to make the configuration effective.

10. A NETCONF capability-aware cross-chassis configuration system, comprising: The system includes: The deep capability parameter acquisition module is used to acquire the NETCONF deep capability parameters of the network device, which are used to characterize the network device's ability to process configuration data. The write strategy generation module is used to parse the dependency topology to be configured to generate initial segments, adjust the granularity of the initial segments according to the depth capability parameters, and determine the write mode of the initial segments according to the depth capability parameters. The write and atomic rollback module is used to lock the candidate configuration of the network device, write the configuration to be issued into the candidate configuration in segments according to the segmented write strategy, and atomically discard all written configurations if any segmented write fails.

Images