A network slicing configuration processing method, device, equipment and medium

Abstract

The present application relates to a kind of network cutting configuration processing method, device, equipment and medium, in the present application, the basic configuration data of each device in the network to be cut, dynamic operation data and network topology relationship data are acquired, data is carried out three-dimensional backup processing, and backup set is obtained;Virtual network topology is constructed based on network topology relationship data, virtual device is configured based on backup set, according to build virtual network topology and virtual device, obtain network twin environment, and execute cutting preplay in network twin environment, and obtain cutting preplay result;When cutting preplay result is cutting pass, cutting configuration information is issued, to make device execute network cutting process, and collect device operation data and service performance data;Fault detection is carried out to device operation data and service performance data, and fault detection result is obtained, when fault detection result is network fault exists, according to backup set, rollback processing is carried out, to restore network service.

Description

Technical Field

[0001] This invention relates to the field of network cutover technology, and specifically to a network cutover configuration processing method, apparatus, device, and medium. Background Technology

[0002] With the rapid development of 5G (fifth-generation mobile communication technology), cloud computing, and the industrial internet, the scale of communication networks continues to expand, and the heterogeneity of equipment has significantly increased. Network cutover has become a core, high-frequency operation in communication operations and maintenance, including equipment upgrades, topology adjustments, and bandwidth expansion. Network cutover essentially involves direct modification of the production environment's network architecture. Any configuration errors or delayed fault recovery can trigger cascading network failures and widespread service interruptions. Configuration regression and rapid recovery, as core components of the network cutover security system, directly determine the scope of the cutover failure's impact and the service recovery time, making them crucial technologies for ensuring the stable and reliable operation of communication networks.

[0003] Currently, configuration regression and rapid recovery during network cutover are mainly achieved through three technical paths: First, the traditional configuration backup and manual rollback scheme, which uses a command-line interface to back up the complete configuration file of the device and store it on a local server. When a cutover failure occurs, the maintenance engineer manually logs into the faulty device and performs the configuration file import operation to complete the rollback. Second, the configuration synchronization scheme based on link state broadcasting, which achieves network-wide configuration synchronization by sending link state messages including configuration descriptors through network nodes. When a failure occurs, the link state message flooding is triggered, and each node performs the rollback based on the pre-stored overall configuration snapshot. This scheme completes message distribution according to link state protocols such as the Open Shortest Path First protocol. Third, the cutover simulation scheme based on the live network twin, which simulates the cutover process in a virtual environment by building a live network digital twin model. When a failure occurs, the pre-verified service failover route is called to achieve service recovery.

[0004] However, the existing network cutover configuration regression and rapid recovery technologies have not yet built a complete technical system covering accurate backup, automated recovery, cross-device adaptation, and fault prediction. As a result, during the cutover process, fault recovery not only relies heavily on manual labor and the recovery speed is difficult to meet the stringent service level agreement requirements of the business, but also gives rise to a series of problems such as insufficient accuracy of configuration rollback which can easily cause normal business interruption, poor cross-vendor device compatibility, lack of fault prediction mechanism, and chaotic configuration version management. These problems seriously restrict the execution efficiency and security reliability of network cutover.

[0005] Therefore, improving the accuracy of configuration regression and the timeliness of fault recovery during network cutover, as well as achieving universal compatibility across vendor devices and early fault prediction, are technical problems that urgently need to be solved. Summary of the Invention

[0006] The technical problem to be solved by this invention is how to improve the accuracy of configuration regression and the timeliness of fault recovery during network cutover, and to achieve universal compatibility across vendor devices and early fault prediction.

[0007] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: This application provides a network cutover configuration processing method, including: Acquire the basic configuration data, dynamic operation data, and network topology relationship data of each device in the network to be cut over, and perform three-dimensional backup processing on the basic configuration data, the dynamic operation data, and the network topology relationship data to obtain a backup set including basic configuration, dynamic configuration, and context configuration; A virtual network topology is constructed based on the network topology relationship data. Virtual devices in the virtual network topology are configured based on the backup set. A network twin environment is obtained based on the constructed virtual network topology and the virtual devices. A cutover simulation is performed in the network twin environment to obtain the cutover simulation results. When the cutover simulation result is that the cutover is successful, cutover configuration information is sent to each device in the network to be cut over, so that the device executes the network cutover process based on the cutover configuration information, and collects device operation data and service performance data during the network cutover process at a preset frequency. Fault detection is performed on the device operation data and the service performance data to obtain fault detection results. When the fault detection results indicate that a network fault exists, a rollback process is performed based on the backup set to restore network services. Once the network cutover process is completed, all configuration versions in the network cutover process are archived to obtain a configuration version file.

[0008] The beneficial effects of this invention are as follows: It collects three types of data—basic configuration, dynamic operation, and network topology—and completes a three-dimensional backup including basic, dynamic, and contextual configurations, generating a dedicated backup set. This breaks through the limitations of traditional single full configuration backups. Based on contextual configurations and topology relationships, it locks various related and dependent configurations. During rollback, it can accurately retrieve the corresponding configuration content as needed, avoiding the problem of accidental reset of normal business configurations caused by overall configuration overwrite. It improves the accuracy of configuration regression from the root of backup, and the data format of the unified structured storage of all configurations can adapt to the configuration conversion needs of different vendors' devices. Based on the topology, it builds a virtual topology and deploys virtual devices using the backup set to build a network twin environment and conduct cutover rehearsals in advance. It can completely simulate the entire cutover process in the virtual environment before the cutover configuration is issued in the real network, identify potential faults such as configuration conflicts and link anomalies in advance, and truly predict actual faults in advance, reducing network outbursts. The probability of failure is reduced; the formal cutover configuration is only issued after the pre-rehearsal verification is passed. During the cutover, equipment operation and service performance data are continuously collected at a fixed frequency to achieve real-time monitoring of the operation status during the cutover process, shorten the time for fault detection, provide real-time data support for rapid fault handling, and improve the timeliness of fault recovery. After a fault occurs, the pre-generated standardized backup set is directly invoked to automatically perform rollback, abandoning the inefficient mode of manually logging into the device, manually searching for the configuration, and entering the rollback command one by one. This significantly reduces the time spent on rollback operations and further optimizes the timeliness of fault recovery. The unified and standardized backup data format is compatible with the configuration logic of heterogeneous devices from multiple vendors, achieving unified rollback adaptation for devices of different brands. After the cutover is completed, the full lifecycle configuration version is archived to form an archive. In subsequent operation and maintenance or secondary fault rollback, the corresponding historical configuration version can be quickly retrieved, which facilitates the accurate selection of the rollback data source and further enhances the accuracy of configuration regression.

[0009] Based on the above technical solution, the present invention can be further improved as follows.

[0010] Furthermore, the three-dimensional backup processing of the basic configuration data, the dynamic operation data, and the network topology relationship data yields a backup set including basic configuration, dynamic configuration, and context configuration, comprising: Get the cutover configuration command; The cutover configuration command is parsed to determine the configuration object and configuration parameters; Based on preset configuration semantic association information, semantic association processing is performed on the configuration object and the configuration parameters to obtain the direct dependency configuration corresponding to the configuration object; Based on the direct dependency configuration and the network topology relationship data, trace the indirect dependency configuration of the configuration object across devices; The context configuration is obtained by integrating the direct dependency configuration and the indirect dependency configuration, and the backup set is obtained by combining the context configuration with the basic configuration and the dynamic configuration.

[0011] The beneficial effects of adopting the above-mentioned further solutions are as follows: syntactic decomposition of configuration elements, semantic association to find direct dependencies on local devices, and tracing cross-device indirect dependencies through topological relationships. Based on the dual-layer mechanism of rule lists and topological tracing, all-dimensional related configurations can be completely captured to form contextual configurations. This not only eliminates the large amount of redundant data and saves storage space caused by traditional indiscriminate full backups, but also avoids the problem of missing related configurations causing the failure of supporting functions after rollback, improving the completeness of three-dimensional backup content and thus improving the accuracy of configuration rollback. At the same time, the unified rule matching processing logic can be compatible with the configuration association rules of multi-brand devices, providing a foundation for integrated backup of cross-vendor devices.

[0012] Furthermore, before sending the cutover configuration information to each device in the network to be cut over, the process also includes: Obtain standardized configuration commands; The standardized configuration command is parsed to obtain configuration semantic information, which includes configuration type, configuration object and parameter list. Based on a pre-built vendor feature library, the configuration semantic information is subjected to vendor feature adaptation processing to obtain a semantic model of the functional differences of the target device. Based on the manufacturer information of the target device, determine the corresponding manufacturer adaptation dictionary, and based on the manufacturer adaptation dictionary, convert the semantic model into the configuration command corresponding to the target manufacturer; The configuration commands corresponding to the target vendor are subjected to syntax validation to obtain a syntax validation result. If the syntax validation result is passed, the configuration commands corresponding to the target vendor are used as the cutover configuration information.

[0013] The beneficial effects of adopting the above-mentioned further solution are as follows: structured configuration information is extracted through semantic decomposition, the differences in functions and function implementation forms between different devices are made up by the vendor feature library, and the unified semantics are automatically converted into the private commands of each vendor by the vendor adaptation dictionary. At the end, syntax verification is added to screen out configuration syntax errors in advance, so as to realize the automatic adaptation of a set of configuration requirements to multiple heterogeneous devices, solve the problem of cross-vendor adaptation difficulties from the source of configuration distribution, and at the same time, the pre-syntax verification can avoid the device configuration anomalies caused by the distribution of incorrect configurations to the production network, and reduce the probability of sudden failures during the cutover execution phase.

[0014] Furthermore, before performing the cutover rehearsal in the network twin environment, the procedure also includes: According to a preset time interval, real-time status change data of the existing network is collected. The real-time status change data includes configuration change data, interface status data, and traffic fluctuation data. Based on the real-time status change data, incremental synchronization processing is performed on the network twin environment to update the changed parts of the network twin environment, resulting in an updated network twin environment. The consistency between the updated network twin environment and the existing network is verified from three dimensions: configuration consistency, state consistency, and traffic consistency, resulting in consistency verification results across multiple dimensions. When the consistency check result of any dimension is inconsistent, incremental synchronization processing is performed on the updated network twin environment until the consistency check results of all dimensions are consistent, and the target network twin environment is obtained. The target network twin environment is used to perform cutover rehearsal.

[0015] The beneficial effects of adopting the above-mentioned further solution are as follows: periodically and dynamically collecting changes in the existing network and performing local incremental updates, abandoning the inefficient mode of replacing all data in the twin environment, and repeatedly correcting the simulation environment data through a three-layer quantitative verification mechanism of configuration, device operating status, and service traffic, continuously narrowing the data matching degree between the virtual network and the actual network, avoiding the distortion of the pre-drill conclusions due to the disconnect between the simulation environment and the operating status of the existing network, and relying on the precisely calibrated twin environment to conduct pre-drills can accurately and in advance identify various cutover risks. At the same time, incremental synchronization can reduce the system resource consumption caused by large-scale full data updates and reduce the hardware operating load of the pre-drill environment.

[0016] Furthermore, the step of performing fault detection on the device operation data and the service performance data to obtain fault detection results includes: Anomalies were identified in the device operation data and the service performance data, resulting in multiple abnormal events. Obtain the historical prior probability corresponding to each of the aforementioned abnormal events, and the fault condition probability when each of the aforementioned abnormal events occurs; Based on the CPU utilization, interface traffic, and memory usage of the device at the time of the abnormal event, calculate the real-time state weight coefficient corresponding to each abnormal event. Based on the historical prior probability, the fault condition probability, and the real-time state weight coefficient, the fault probability corresponding to each of the abnormal events is calculated by an improved Bayesian inference algorithm. A fault propagation path is constructed, and the fault detection result is obtained based on the fault propagation path and the fault probability corresponding to each of the abnormal events.

[0017] The beneficial effects of adopting the above-mentioned further solution are as follows: relying on anomaly identification to filter all abnormal events, using the three real-time operating indicators of the equipment to generate weight coefficients to optimize Bayesian probability, eliminating the probability calculation bias caused by traditional algorithms that only refer to historical fault data and ignore the real-time load on site, improving the accuracy of fault probability calculation, and sorting out the fault propagation link according to the anomaly sequence and topology structure, distinguishing between root cause faults and related derivative faults, quickly locating the real fault location, greatly shortening the fault investigation time, and being able to quickly output accurate detection conclusions after the cutover anomaly occurs, providing a reliable basis for starting backup set rollback processing, and effectively improving the overall timeliness of fault recovery.

[0018] Furthermore, the construction of the fault propagation path and the obtaining of the fault detection result based on the fault propagation path and the fault probability corresponding to each of the abnormal events include: Extract the event timestamps corresponding to all abnormal events, and generate an abnormal event time series based on the chronological order of the event timestamps; Based on the network topology data, construct a physical connection diagram and a logical connection diagram between all abnormal devices; Based on the time sequence of the abnormal events and the device connection relationships in the physical connection diagram and the logical connection diagram, a fault propagation path is constructed to allow the fault to propagate from the root device to other devices. Based on the fault propagation path and the fault probability corresponding to each abnormal event, the root cause device and the fault cause are determined, and the fault detection result is obtained by combining the root cause device and the fault cause.

[0019] The beneficial effects of adopting the above-mentioned further solutions are as follows: by organizing the order of anomalies according to timestamps, and by restoring the device-related links with physical and logical dual-layer topology maps, the complete path of fault propagation layer by layer can be accurately sorted out. In addition, by combining the quantitative fault probability of each anomaly to screen the earliest occurring and most credible source fault, the problem of downstream related faults being misjudged as the source of the fault can be effectively avoided, the accuracy of fault location can be improved, and the time spent on fault cause analysis can be shortened.

[0020] Furthermore, the rollback process based on the backup set to restore network services includes: The backup set is processed in parallel using multiple threads to obtain the rollback execution results for each faulty device. Atomically verify the rollback execution results of all faulty devices to obtain the rollback completion status; Based on the rollback completion status and the preset service priority, the service path is switched to the pre-stored backup path to restore network services.

[0021] The beneficial effects of adopting the above-mentioned further solutions are as follows: Multi-threaded parallel processing enables simultaneous rollback operations on multiple devices, eliminating the inefficient single-device serial rollback mode, shortening the configuration recovery time for batch devices, and constraining the integrity of the entire batch rollback task through atomic verification. This avoids the problem of chaotic and incorrect network configurations caused by successful rollbacks on some devices while others fail. Furthermore, by prioritizing business operations and switching pre-stored backup links in an orderly manner, high-value services are given priority for rapid recovery. The entire process from instruction issuance, result verification, and business switching compresses the duration of fault interruptions, further improving fault recovery timeliness. Simultaneously, based on a unified backup set, the parallel rollback instructions can adapt to heterogeneous devices from different brands, continuously improving cross-vendor unified rollback adaptation capabilities.

[0022] This application embodiment also provides a network cutover configuration processing apparatus, the apparatus comprising: The backup module is used to acquire the basic configuration data, dynamic operation data and network topology relationship data of each device in the network to be cut over, and to perform three-dimensional backup processing on the basic configuration data, the dynamic operation data and the network topology relationship data to obtain a backup set including basic configuration, dynamic configuration and context configuration. The pre-drill module is used to construct a virtual network topology based on the network topology relationship data, configure virtual devices in the virtual network topology based on the backup set, obtain a network twin environment according to the constructed virtual network topology and the virtual devices, and perform a cutover pre-drill in the network twin environment to obtain the cutover pre-drill result. The cutover module is used to send cutover configuration information to each device in the network to be cut over when the cutover pre-rehearsal result is that the cutover is successful, so that the device executes the network cutover process based on the cutover configuration information, and collects device operation data and service performance data during the network cutover process at a preset frequency. The rollback module is used to perform fault detection on the device operation data and the service performance data, obtain fault detection results, and when the fault detection results indicate that there is a network fault, perform rollback processing based on the backup set to restore network services. The archiving module is used to archive all configuration versions in the network cutover process after the network cutover process is completed, thereby obtaining a configuration version archive.

[0023] This application also provides an electronic device, including a processor and a memory, wherein the memory stores a plurality of instructions; the processor loads instructions from the memory to execute steps in any of the network cutover configuration processing methods provided in this application.

[0024] This application also provides a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute steps in any of the network cutover configuration processing methods provided in this application. Attached Figure Description

[0025] Figure 1 A flowchart illustrating the network cutover configuration processing method provided in an embodiment of the present invention; Figure 2 A schematic diagram of the configuration processing device for network cutover provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0026] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0027] This application provides a network cutover configuration processing method, apparatus, electronic device, and medium.

[0028] Specifically, the network cutover configuration processing device can be integrated into an electronic device, such as a terminal or server. The terminal can be a mobile phone, tablet, smart Bluetooth device, laptop, or personal computer (PC); the server can be a single server or a server cluster consisting of multiple servers.

[0029] In some embodiments, the network cutover configuration processing apparatus may also be integrated into multiple electronic devices. For example, the network cutover configuration processing apparatus may be integrated into multiple servers, and the network cutover configuration processing method of this application may be implemented by multiple servers.

[0030] In some embodiments, the terminal can also be used as a server to implement some or all of the functions of a server.

[0031] In the embodiments of this application, the terms "module" or "unit" may refer to a computer program or part of a computer program with a predetermined function, which works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) may be used to implement one or more modules or units. Furthermore, each module or unit may be part of an overall module or unit that includes the functions of that module or unit.

[0032] The following sections provide detailed descriptions of each example. It should be noted that the order of the following embodiments is not intended to limit the preferred order of the embodiments.

[0033] This embodiment provides a configuration processing method for network cutover. See also Figure 1 , Figure 1 This is a flowchart illustrating the network cutover configuration processing method provided in an embodiment of the present invention, as shown below. Figure 1 As shown, the specific process of configuring this network cutover can be described as follows: 110. Obtain the basic configuration data, dynamic operation data and network topology relationship data of each device in the network to be cut over, and perform three-dimensional backup processing on the basic configuration data, the dynamic operation data and the network topology relationship data to obtain a backup set including basic configuration, dynamic configuration and context configuration; 120. Construct a virtual network topology based on the network topology relationship data, configure virtual devices in the virtual network topology based on the backup set, obtain a network twin environment according to the constructed virtual network topology and the virtual devices, and perform a cutover simulation in the network twin environment to obtain the cutover simulation results; 130. When the cutover simulation result is that the cutover is successful, cutover configuration information is sent to each device in the network to be cut over, so that the device executes the network cutover process based on the cutover configuration information, and collects device operation data and service performance data during the execution of the network cutover process at a preset frequency. 140. Perform fault detection on the device operation data and the service performance data to obtain fault detection results, and when the fault detection results indicate that there is a network fault, perform rollback processing based on the backup set to restore network services; 150. After the network cutover process is completed, all configuration versions in the network cutover process are archived to obtain a configuration version file.

[0034] Among them, the basic configuration data consists of static parameter information of network devices that remain unchanged. This includes device hardware model, firmware version, IP (Internet Protocol) address and transmission rate of each physical interface, virtual LAN partitioning rules, basic parameters of routing protocols such as open shortest path routing and border gateway routing, access control entries, firewall security policies, etc. It can be collected through three methods: remote command login, standardized networking protocol collection, and simplified network management protocol. The parameters will not change autonomously during the normal short-term operation of the device, and it is a static data source for building the device networking operation framework.

[0035] Among them, dynamic operation data are the operating parameters that are generated in real time during the online operation of the device, including interface connectivity status, neighbor negotiation status of various routing protocols, real-time bandwidth utilization of links, packet loss rate and transmission latency, device processor and memory resource usage, transmission control session forms, access control real-time session data, etc. They are collected periodically with the help of network-wide traffic statistics protocols, link connectivity detection commands, and device proactive alarm message push. The data values ​​will continuously change with network traffic fluctuations.

[0036] Among them, the network topology relationship data records the physical wiring associations and logical networking dependencies of all network devices. It relies on the link layer discovery protocol to collect the physical connection information of devices, and combines the routing neighbor interaction data such as border gateway routing and open shortest path routing to sort out the logical networking structure. It uses a graph database to store all topology information, which can accurately locate the upstream and downstream related devices of a single device to be cut over, as well as all the service transmission links carried by the device.

[0037] In the three-dimensional backup process, three types of original collected data are used to distinguish three types of configuration content and adopt differentiated backup strategies. Based on the three-layer processing logic of syntax decomposition, configuration dependency rule matching, and cross-device tracing of the entire network topology, related configurations are filtered. Static content is backed up with full data and incremental backup, dynamic content is backed up with scheduled snapshots, and related configurations are backed up by means of targeted extraction based on dependencies. Finally, the three types of configurations are summarized to form a complete backup data package.

[0038] The basic configuration is a static configuration content extracted from the basic configuration data. A full backup is performed once before the cutover starts. During the cutover process, incremental backups are performed synchronously for each configuration modification. Only the modified configuration entries are stored, as well as long-term fixed configuration information such as corresponding device interface parameters, basic routing deployment, and security management policies.

[0039] Among them, dynamic configuration is the real-time running configuration that is dynamically stored according to a fixed snapshot period. The snapshot collection frequency follows the device's dynamic monitoring period and is set to once every hundred milliseconds. It mainly stores dynamic parameters temporarily generated during device operation, such as routing table entries, protocol neighbor sessions, and real-time connection forms.

[0040] Among them, context configuration is a set of associated configurations obtained by parsing the configuration command to be modified, matching the system's preset configuration dependency rules, and combining the entire network topology to trace the links. It includes the direct binding configuration of the configuration to be modified, as well as the indirect dependency configuration generated across different devices, such as the address translation rules, bandwidth control policies, and uplink device connection routes when modifying the interface IP.

[0041] The backup set is a complete set of backup data packets that integrates three types of content: basic configuration, dynamic configuration, and context configuration. Each data packet is equipped with a unique identification code, which marks additional information such as device number, backup time, and backup type. The data adopts a dual storage architecture of local server storage plus off-site data center backup. Local storage is used for quick data retrieval during failure rollback, while off-site storage is used for data disaster recovery in the event of accidental damage.

[0042] Among them, the virtual network topology is a network architecture that is replicated on the virtualization simulation platform based on the actual network topology data. It fully restores the network device hierarchy, physical link connection, and logical service dependency path, and is the underlying framework for building the simulation running environment.

[0043] Among them, the network twin environment is based on a virtual network topology architecture. It retrieves various configurations from the backup set and fills them into the corresponding virtual devices. It is a virtualized simulation environment that completely replicates the hardware parameters, configuration content and operating status of real devices. It can fully simulate the entire operating logic of network configuration interaction and service transmission.

[0044] During the cutover rehearsal, the entire process of configuration distribution, parameter change, and service switching during the actual cutover is fully replicated in the twin simulation environment. Five tests are carried out in sequence: configuration syntax verification, conflict investigation between old and new configurations, routing connectivity simulation, device hardware load calculation, and rollback verification under fault scenarios.

[0045] The cutover rehearsal results are comprehensive evaluation data compiled after the entire rehearsal process is completed. They mark various potential problems found during the rehearsal, such as configuration errors, routing interruptions, and equipment performance overload. Control standards are divided according to the degree of impact of the potential problems. If a high-risk problem that could cause large-scale business interruption occurs, the on-site cutover will be terminated. If there are no major potential problems, the rehearsal will be deemed to have passed.

[0046] Among them, the cutover configuration information is the configuration command issued to the physical device for the implementation of network transformation. The command is processed through a cross-vendor configuration conversion process. Based on a unified semantic model and combined with the exclusive command dictionary of each brand's device, it is converted into the original factory command adapted to the target device. After the syntax is verified to be correct, it is issued as the formal transformation configuration.

[0047] Among them, equipment operation data are hardware operation indicators that are periodically collected during the cutover and transformation implementation phase. These include parameters such as interface connectivity status, routing neighbor negotiation status, and processor and memory usage. The collection interval can be flexibly adjusted according to the cutover phase, and the collection cycle can be shortened and the sampling density increased during the key periods of configuration.

[0048] Among them, the service performance data are the link operation indicators of various services, including the packet loss ratio, transmission delay, and link bandwidth utilization ratio of voice services and enterprise private line services. Anomaly judgment thresholds are set in advance, and the corresponding service is judged to be abnormal when the indicator value exceeds the threshold.

[0049] The fault detection result is a judgment conclusion generated after abnormal data screening, improved Bayesian probability calculation, and fault propagation link tracing. It includes the fault originating device number, the cause of the fault, the complete link of the fault propagation along the topology, and a list of all services affected by the fault.

[0050] During the rollback process, the existing backup set is retrieved, and the faulty equipment is restored to its pre-cutover state through three types of operations: multi-threaded synchronous instruction issuance, atomic transaction management, and parallel switching of backup links. The multi-threaded mechanism supports the simultaneous execution of rollback on hundreds of devices, and the atomic rules ensure that the rollback operation is either completely successful or completely invalid.

[0051] The configuration version archive is a collection of all configuration changes throughout the entire cutover cycle. It includes three categories: the initial base version, the intermediate change version during the transformation process, and the derivative version after failure rollback. Each archive includes notes on the change time, the operator, and the reason for the configuration modification. It supports visual comparison of configuration differences between any two versions.

[0052] For example, the specific method for obtaining a backup set can be: Basic configuration data is collected through three methods: remote command login, standardized device networking protocol, and simplified network management, summarizing static parameters. Dynamic operation data is collected periodically through network-wide traffic collection tools, link connectivity detection, and device fault alarm push notifications. Network topology data is extracted based on link discovery protocols to extract physical connections, combined with border gateway routing, open shortest path routing, and neighbor information to organize logical networks and store them using a graph database. In the three-dimensional backup phase, the configuration objects are extracted by parsing the keywords of the configuration to be cut over. The system's preset configuration dependency rules are invoked to match directly associated configurations. Then, the indirect dependency configurations are traced across devices using full topology data to generate context configurations. Basic configurations are backed up fully before cutover and incrementally when configurations are changed. Dynamic configurations are continuously backed up with snapshots at millisecond intervals. Finally, the three types of configurations are integrated to generate a backup set with a unique code, and a dual-database storage scheme of local and off-site is used to retain the data.

[0053] For example, the specific method for obtaining the cutover simulation results can be: A virtual network topology is generated by replicating the link connections based on the stored topology data. Various configurations from the backup set are retrieved and populated into the corresponding virtual devices one by one. At the same time, real-time change data from the live network is collected at fixed intervals. An incremental synchronization mechanism is used to update only the content that has changed in the twin environment. Then, consistency checks are performed against preset thresholds in three dimensions: configuration differences, device operating status, and service traffic. If any deviation exceeds the standard, incremental synchronization is repeated until all three indicators meet the deviation standard, and a usable network twin environment is generated. In the pre-drill phase, five tests are completed in sequence: configuration syntax correctness detection, configuration conflict screening, routing path simulation, device load calculation, and fault rollback simulation. All test issues are summarized to form the pre-drill results. The decision on whether to allow on-site cutover is made based on the risk level.

[0054] For example, the specific method for executing the network cutover process can be as follows: After the pre-rehearsal results are approved, the configuration is distributed. Before distribution, the general standardized configuration is processed through a three-layer cross-vendor adaptation logic. First, the configuration content is parsed and converted into a unified structured semantic. Then, the functional differences between different devices are supplemented by comparing with the vendor's feature library. Next, the vendor's command dictionary corresponding to the target device is retrieved, and the unified semantic is converted into configuration commands that can be used by the original equipment manufacturer (OEM) device and syntax verification is completed. The verified commands are distributed to the physical devices in batches as cutover configuration information. During the cutover execution phase, the monitoring cycle is distinguished. High-frequency collection of hundreds of milliseconds is used during the critical window period of configuration distribution, and one-second single collection is used during the normal operation period. Device operation data and business performance data are continuously captured, and all collected data is stored in the database in real time for subsequent fault analysis.

[0055] For example, the rollback process can be specifically handled as follows: By comparing the data with preset abnormal thresholds, all abnormal events are extracted from the collected data that exceed the limits. The historical prior probabilities of various faults and the corresponding conditional fault probabilities are retrieved. The real-time status weight coefficient is calculated by combining the real-time processor, memory, and interface traffic usage values ​​of the device. The fault probability of each abnormal event is calculated based on the probability extrapolation algorithm after weight correction. The occurrence timestamps of all abnormal events are extracted and sorted by time. The fault propagation path at each level is sorted by combining the network topology connection map, and the source device of the fault is identified to form a complete fault detection result. After determining that the fault actually exists, the backup set of local high-speed storage is retrieved. Multi-threading technology is used to issue rollback instructions in batches and in parallel. Atomized management ensures the integrity of the rollback operation. Simultaneously, according to the pre-set business priority, the affected business is switched to the pre-stored backup link to achieve rapid business recovery.

[0056] For example, the specific method for obtaining the configuration version file can be: After a successful cutover or after a fault rollback is completed, all configuration versions generated throughout the cutover process are categorized and organized. The original configuration before the cutover begins is marked as the baseline version. Each configuration modification during the transformation process generates a separate intermediate version. After a fault triggers a rollback operation, a dedicated rollback version is generated. All versions are stored in a document-based database. Each file includes supplementary information such as modification time, operator, and reason for change. The system supports highlighting and comparing configuration differences between any versions and one-click retrieval and rollback of historical versions. After summarizing all version data, a complete configuration version file is formed.

[0057] For example, a provincial telecom operator is carrying out a core routing equipment replacement project during the off-peak business window in the early morning. It needs to replace two old domestic routing devices with new devices of the same series. The project needs to ensure that voice services and government and enterprise private line services are uninterrupted throughout the process. In the early stages of the project, staff used three different data collection methods to capture basic configuration data such as interface addresses, access control policies, and routing protocol parameters of the old equipment. They also continuously collected dynamic operational data, including border gateway routing session status, bandwidth usage, and packet loss, using traffic collection tools and link detection commands. Based on link discovery protocols and routing neighbor information, they analyzed the connection relationships between the uplink and downlink switches and the upper-layer core routers, compiling complete network topology data. Subsequently, a three-dimensional backup process was initiated. The configuration commands corresponding to this interface replacement were parsed, and address translation and bandwidth control directly configured by matching the interface bindings using preset configuration dependency rules. Then, the topology data was combined to trace cross-device indirect configurations such as uplink device routing, summarizing and generating context configurations. Basic configurations were fully backed up, and dynamic configurations were saved as snapshots every 100 milliseconds. These three types of configurations were packaged into backup sets with unique numbers and stored on local data center servers and off-site disaster recovery data centers, respectively. Afterwards, a virtual network topology was built based on the topology data. The backup sets were used to fill the simulated virtual devices with a complete set of configurations. The changes in the live network were periodically synchronized, and deviations in the simulation environment were corrected from three dimensions: configuration, device status, and traffic. Once the verification was successful, the replacement of the old and new equipment was fully simulated in the twin environment. The cutover process involved verifying the configuration syntax, routing neighbor establishment effectiveness, and service connectivity item by item. A configuration error was simulated, and automatic rollback efficiency was tested. The pre-run was deemed successful after confirming no fatal failures. Subsequently, the adapted configuration, validated for syntax errors, was distributed to the new physical routers in batches to initiate the cutover. During the critical configuration distribution phase, device operation and service performance data were continuously collected at a frequency of hundreds of milliseconds. In the actual operation, a human error in the border gateway routing neighbor IP parameters caused the packet loss rate on the enterprise leased line to exceed the 1% threshold. The system automatically captured the abnormal event and, combined with the device's real-time load weight, calculated the packet loss rate using a weighted and corrected probability estimation algorithm. Failure probability was assessed by analyzing the timing of anomalies and the topology links to pinpoint the source of the failure as a routing configuration error on a new device. Local backup sets were immediately retrieved, and rollback commands were executed in parallel using multiple threads. Atomistic management ensured the overall configuration was rolled back, while government and enterprise dedicated lines were prioritized for switching to pre-stored backup links, completing service recovery within hundreds of milliseconds. The secondary cutover was successfully completed after the fault was rectified. The initial baseline version, the erroneous intermediate configuration version, and the fault rollback version were categorized and archived, with details of each version change noted. A complete set of configuration version files was then generated, allowing for direct retrieval of these files for comparison of configuration changes during subsequent fault investigations.

[0058] As can be seen, in this embodiment, three types of data—basic configuration, dynamic operation, and network topology—are collected, and a three-dimensional backup including basic, dynamic, and contextual configurations is completed, generating a dedicated backup set. This breaks through the limitations of traditional single full configuration backup. Based on the contextual configuration and topology relationships, various related and dependent configurations are locked. During rollback, the corresponding configuration content can be accurately retrieved as needed, avoiding the problem of erroneous reset of normal business configurations caused by overall configuration overwrite. This improves the accuracy of configuration regression from the root of the backup, and the data format of the unified structured storage of all configurations can adapt to the configuration conversion needs of different vendors' devices. Based on the topology, a virtual topology is built, and virtual devices are deployed using the backup set to build a network twin environment and conduct cutover rehearsals in advance. Before the cutover configuration is issued in the real network, the entire cutover process can be completely simulated in the virtual environment, identifying potential faults such as configuration conflicts and link anomalies in advance. This allows for real-time fault prediction and reduces network outbursts. The probability of failure is reduced; the formal cutover configuration is only issued after the pre-rehearsal verification is passed. During the cutover, equipment operation and service performance data are continuously collected at a fixed frequency to achieve real-time monitoring of the operation status during the cutover process, shorten the time for fault detection, provide real-time data support for rapid fault handling, and improve the timeliness of fault recovery. After a fault occurs, the pre-generated standardized backup set is directly invoked to automatically perform rollback, abandoning the inefficient mode of manually logging into the device, manually searching for the configuration, and entering the rollback command one by one. This significantly reduces the time spent on rollback operations and further optimizes the timeliness of fault recovery. The unified and standardized backup data format is compatible with the configuration logic of heterogeneous devices from multiple vendors, achieving unified rollback adaptation for devices of different brands. After the cutover is completed, the full lifecycle configuration version is archived to form an archive. In subsequent operation and maintenance or secondary fault rollback, the corresponding historical configuration version can be quickly retrieved, which facilitates the accurate selection of the rollback data source and further enhances the accuracy of configuration regression.

[0059] Preferably, in an embodiment, the three-dimensional backup processing of the basic configuration data, the dynamic operation data, and the network topology relationship data to obtain a backup set including basic configuration, dynamic configuration, and context configuration includes: Get the cutover configuration command; The cutover configuration command is parsed to determine the configuration object and configuration parameters; Based on preset configuration semantic association information, semantic association processing is performed on the configuration object and the configuration parameters to obtain the direct dependency configuration corresponding to the configuration object; Based on the direct dependency configuration and the network topology relationship data, trace the indirect dependency configuration of the configuration object across devices; The context configuration is obtained by integrating the direct dependency configuration and the indirect dependency configuration, and the backup set is obtained by combining the context configuration with the basic configuration and the dynamic configuration.

[0060] Among them, the cutover configuration command is the equipment configuration modification instruction drafted by the operation and maintenance personnel for the cutover and transformation. The content includes interface parameter rewriting, routing entry addition, security policy adjustment and other transformation content. It is the starting raw data for carrying out dependency configuration identification work. Each transformation instruction corresponds to a device configuration change requirement.

[0061] During syntax parsing, the configuration text is broken down by the splitting logic of building a syntax tree. Functional keywords and attribute fields within the configuration are separated, and the configuration body and corresponding parameters are extracted from the complete configuration statement. This is a standardized processing method to distinguish between configuration objects and configuration parameters.

[0062] The configuration object is the main unit of device configuration extracted after syntactic decomposition, including device configuration entities such as physical interfaces, virtual LANs, routing processes, and access control entries. It serves as the search benchmark for retrieving various related configurations.

[0063] The configuration parameters are attribute values ​​that are filled in for the configuration object, including interface address, subnet range, routing domain number, bandwidth limit value and other limiting contents, which are used to accurately define the running attributes of the configuration object.

[0064] Among them, the configuration semantic association information is a pre-organized list of configuration subordinate rules. The list records the binding relationships between various configurations, such as the correspondence between interface address configuration and address translation rules, and between routing neighbor configuration and routing filtering policies.

[0065] Among them, the direct dependency configuration is the supporting configuration that is deployed on the same device as the target configuration object and has a fixed binding relationship. It can be directly retrieved according to the rule list. When the target configuration is modified or rolled back, this part of the configuration needs to be restored synchronously.

[0066] Among them, indirect dependency configurations are supporting configurations deployed on other interconnected devices that form business linkages based on the entire network link. They cannot be queried by single device configuration rules and need to be traced layer by layer according to the topology link to be determined.

[0067] For example, the specific method for obtaining the configuration command to be cutover can be: Extract all the device configuration instructions that need to be modified from the cutover task list one by one, store all instructions in a temporary cache queue, and start subsequent parsing operations one by one in order. In the case of multiple configuration parallel transformation scenarios, a queuing and polling processing mode is adopted.

[0068] For example, the specific methods for obtaining configuration objects and configuration parameters can be as follows: The method of generating a syntax tree by decomposing keywords is adopted. Functional keywords in configuration statements are identified one by one. The corresponding configuration objects are located by keywords, and the numbers and characters filled in after the keywords are extracted as configuration parameters to complete the element decomposition of a single configuration.

[0069] For example, the specific way to obtain direct dependency configuration can be: Using the split configuration object as the search keyword, a matching search is performed in the configuration subordinate rule list. According to the pre-set binding entries in the list, all configuration content bound to the configuration object in the current device is summarized, and the summarized result is the direct dependency configuration.

[0070] For example, the specific way to obtain indirect dependency configuration can be: Based on the network topology link information stored in the graph database, all interconnected devices are traversed along the uplink and downlink links of the target device. Combined with the network linkage relationship of routing neighbors, configuration entries in other devices that have service interoperability with the target configuration are filtered out. All cross-device entries are summarized to form indirect dependency configuration.

[0071] For example, the specific method for obtaining a backup set can be: The local direct dependency configuration and the cross-device indirect dependency configuration are merged and summarized to form a complete context configuration. This configuration is then packaged and integrated with the pre-backed basic configuration and dynamic configuration. After adding a unique identifier code, the final backup set is generated according to the local and off-site dual storage mode.

[0072] For example, a carrier is carrying out interface address change cutover for core layer routing equipment. The operation and maintenance team plans to modify the address content of the gigabit service interface of the equipment. First, the interface modification instruction is extracted as the configuration command to be cutover. The instruction content is decomposed by parsing using a syntax tree splitting method, and the gigabit interface name is extracted as the configuration object and the four address numbers filled in by the interface are extracted as configuration parameters. Then, the configuration subordinate rule list is retrieved, and the address translation rules and service quality control policies bound to the interface are matched according to the binding rules corresponding to the interface configuration. The above content is used as the direct dependency configuration of the local machine. According to the network topology data, the upper-layer routing devices are traced upwards to find the routing configuration used to establish neighbor relationships in the device. This cross-device configuration content is the indirect dependency configuration. The two types of dependency configurations are merged to generate context configuration. Then, combined with the basic configuration of the previous full backup and the dynamic configuration of the hundred-millisecond snapshot storage, a backup set with a unique number is generated and stored on the local server and the off-site disaster recovery storage device respectively.

[0073] In this embodiment, configuration elements are split syntactically, direct dependencies on the local machine are found through semantic association, and indirect dependencies across devices are traced through topological relationships. Based on the two-layer mechanism of rule list and topological tracing, the full-dimensional related configurations can be completely captured to form context configuration. This not only eliminates the large amount of redundant data and saves storage space caused by traditional indiscriminate full backup, but also avoids the problem of missing related configurations causing the failure of supporting functions after rollback, thus improving the completeness of the three-dimensional backup content and improving the accuracy of configuration rollback. At the same time, the unified rule matching processing logic can be compatible with the configuration association rules of multi-brand devices, providing a foundation for the implementation of integrated backup of cross-vendor devices.

[0074] Preferably, in this embodiment, before sending the cutover configuration information to each device in the network to be cut over, the method further includes: Obtain standardized configuration commands; The standardized configuration command is parsed to obtain configuration semantic information, which includes configuration type, configuration object and parameter list. Based on a pre-built vendor feature library, the configuration semantic information is subjected to vendor feature adaptation processing to obtain a semantic model of the functional differences of the target device. Based on the manufacturer information of the target device, determine the corresponding manufacturer adaptation dictionary, and based on the manufacturer adaptation dictionary, convert the semantic model into the configuration command corresponding to the target manufacturer; The configuration commands corresponding to the target vendor are subjected to syntax validation to obtain a syntax validation result. If the syntax validation result is passed, the configuration commands corresponding to the target vendor are used as the cutover configuration information.

[0075] Among them, standardized configuration commands are configuration instructions written according to unified functional semantic rules, which abandon the unique syntax format constraints of various equipment manufacturers. The content only specifies the configuration function to be implemented, the target object and parameter indicators, and does not bind the command wording of any brand of equipment. It is the benchmark original text for realizing cross-vendor configuration conversion.

[0076] Among them, configuration semantic information is structured data formed by parsing and splitting through syntax. It consists of three parts: configuration type, configuration object, and parameter list. It fully extracts the functional definition and constraints of a single configuration and serves as the basic data source for carrying out vendor-differentiated adaptation.

[0077] The configuration type is a classification identifier based on the business functions implemented by the configuration, including categories such as interface parameter configuration, routing neighbor configuration, access control configuration, and bandwidth limit configuration, which are used to quickly match the corresponding function items in the vendor's feature library.

[0078] The parameter list is a collection of constraint values ​​and auxiliary attributes required for configuration, including interface address, subnet range, rate limit value, policy number, etc. It will participate in subsequent adaptation and command conversion in sync with the configuration type.

[0079] Among them, the Manufacturer Feature Library is a database that summarizes the functional differences of mainstream device brands on the market. It records the differences in the writing of keywords for the same function configuration from different manufacturers, and also includes information on unique functions of each brand and alternative functions that can achieve the same effect. It serves as a reference for carrying out function adaptation.

[0080] In the process of adapting to vendor features, the software and hardware function differences recorded in the vendor feature library are used as a reference to adjust and optimize the standardized semantic content, and the process of replacing equivalent implementation schemes for vendor-specific functions and correcting syntactic differences is carried out.

[0081] The semantic model is a structured semantic carrier that has been modified to adapt to the manufacturer's functions. It retains the original configuration type, configuration object and core parameters, and adds additional modified content to adapt to the functional characteristics of the target device, serving as intermediate data for conversion into the device's native configuration commands.

[0082] Among them, the vendor adaptation dictionary is a table that stores a one-to-one correspondence between unified configuration semantics and native commands of devices from various vendors. It marks the device-specific keywords and sentence structures corresponding to various semantics, and supports the format conversion of semantics into actual device commands.

[0083] During syntax verification, the target device's own command writing specifications are referenced to check the keywords, parameter formats, and sentence structure of the converted configuration statements one by one to identify syntax errors.

[0084] For example, the specific way to obtain standardized configuration commands can be as follows: The configuration content compiled according to the unified semantic specification is extracted from the cutover implementation plan. The text only describes the business transformation requirements and does not include any vendor-specific syntax. All configurations are uniformly stored in a temporary cache queue and enter the syntax parsing process in the order of the queue.

[0085] For example, the specific methods for obtaining configuration semantic information can be: The entire standardized configuration text is decomposed according to the syntax tree splitting logic. The configuration type representing the function category, the configuration object representing the operation carrier, and the parameter list representing the constraint index are extracted from the statement. The three types of information are combined and encapsulated to form complete configuration semantic information.

[0086] For example, the specific methods for obtaining a semantic model can be: The system retrieves the manufacturer's feature library using the configuration type as the search index, compares the functional gap between the target device and the general configuration standard, and replaces the configuration requirement with a manufacturer-specific function with an equivalent function that can be implemented on the device. If there are keyword differences, the system marks the replacement rules within the semantics. After all the content is corrected, a semantic model is generated.

[0087] For example, the specific way to obtain configuration commands can be: Based on the manufacturer's brand of the device to be deployed, the matching manufacturer adaptation dictionary is retrieved. By comparing the semantic and device command mapping entries in the dictionary, keywords in the semantic model are replaced one by one, and the sentence format is adjusted to finally generate native configuration commands that conform to the writing specifications of the device.

[0088] For example, the specific methods for obtaining cutover configuration information can be as follows: Following the command writing specifications of the target device, each converted configuration statement was checked. If the parameter format was disordered or the keyword was misspelled, the verification was deemed to have failed and the statement was returned for revision. After all items were verified to be correct, the batch of configuration commands was officially confirmed as cutover configuration information.

[0089] For example, a campus network cutover required configuring interface addresses and inbound bandwidth limiting policies for gigabit service interfaces of multiple access switches from different brands. Staff first wrote standardized configuration commands, specifying only the network segment address to be configured for the designated gigabit interface and the inbound bandwidth limit value, without using any manufacturer-specific instructions. The system then decomposed this configuration to generate configuration semantic information. The configuration types were divided into interface address configuration and bandwidth control configuration, with the configuration object being the corresponding gigabit physical interface. The parameter list included the interface address, subnet, and bandwidth limit value. One of the target devices was a non-domestic mainstream model. The system searched the manufacturer's feature library and found that this model lacked a universal standard bandwidth control instruction, requiring replacement with the device's built-in peer-to-peer bandwidth management function. Based on the original semantics, adaptation modifications were completed to generate a semantic model. Subsequently, the system retrieved the corresponding manufacturer adaptation dictionary for this model and translated the unified semantics into device-specific configuration statements according to mapping rules. The system then verified the command format and parameter values ​​against the model's syntax specifications, confirming no writing errors. After confirming there were no errors, this set of commands was selected as the officially issued cutover configuration information.

[0090] In this embodiment, structured configuration information is extracted through semantic segmentation. The differences in functions and implementation forms between different devices are compensated by the vendor feature library. Then, the unified semantics are automatically converted into the private commands of each vendor with the help of the vendor adaptation dictionary. At the end, syntax verification is added to screen out configuration syntax errors in advance. This realizes that a set of configuration requirements can be automatically adapted to multiple heterogeneous devices. The problem of cross-vendor adaptation difficulties is solved from the source of configuration distribution. At the same time, the pre-processing syntax verification can avoid device configuration anomalies caused by the distribution of incorrect configurations to the production network and reduce the probability of sudden failures during the cutover execution phase.

[0091] Preferably, in an embodiment, before performing the cutover rehearsal in the network twin environment, the method further includes: According to a preset time interval, real-time status change data of the existing network is collected. The real-time status change data includes configuration change data, interface status data, and traffic fluctuation data. Based on the real-time status change data, incremental synchronization processing is performed on the network twin environment to update the changed parts of the network twin environment, resulting in an updated network twin environment. The consistency between the updated network twin environment and the existing network is verified from three dimensions: configuration consistency, state consistency, and traffic consistency, resulting in consistency verification results across multiple dimensions. When the consistency check result of any dimension is inconsistent, incremental synchronization processing is performed on the updated network twin environment until the consistency check results of all dimensions are consistent, and the target network twin environment is obtained. The target network twin environment is used to perform cutover rehearsal.

[0092] Among them, real-time status change data is the full amount of operational information that is dynamically modified during the operation of the live network. It consists of three types of content: configuration change data, interface status data, and traffic fluctuation data. It is the original data source for correcting the twin simulation environment and is continuously collected from physical network devices at a fixed collection frequency.

[0093] Among them, the configuration change data refers to the configuration changes generated by temporary adjustments during daily operation and maintenance of the live network before the formal cutover starts. These changes include three types: adding configuration entries, modifying parameters, and deleting policies. The data records the device number and specific configuration content corresponding to the changes, which is used to correct the static configuration information of the twin devices.

[0094] Among them, the interface status data is the dynamic change information of whether the network physical interface is online or offline, marking the time of interface status switching and the corresponding device, intuitively reflecting the real-time changes in link connectivity.

[0095] Among them, traffic fluctuation data are the changes in bandwidth occupancy ratio, data packet transmission delay, and packet loss ratio of various service transmission links. They centrally reflect the real-time fluctuations of service load and are key indicators for verifying the service simulation effect of the twin environment.

[0096] In incremental synchronization, the data that has been modified in the current period in the existing network is synchronously written into the twin environment. The original data of configuration, device status and traffic parameters that have not changed are all retained, without overwriting the full data of the entire virtual environment.

[0097] Configuration consistency is a criterion used to measure the degree of conformity between the configuration of the twin device and the configuration of the physical device on the network. The difference rate is calculated by the ratio of the number of differentiated configuration items to the total number of configuration items, and 0.5 percent can be used as the compliance threshold.

[0098] Among them, state consistency is the matching standard for comparing the interface start / stop status, routing protocol connection status, processor and memory usage parameters of the twin and the live network devices. The duration of state misalignment is limited to no more than 100 milliseconds, and the numerical deviation of software and hardware resource usage cannot exceed 5%.

[0099] Among them, traffic consistency is a matching rule set for the three parameters of bandwidth, latency, and packet loss for critical business links. The upper limit for bandwidth data deviation is 10%, the upper limit for packet loss rate deviation is 0.1%, and the transmission delay deviation cannot exceed 10 milliseconds.

[0100] The consistency verification result is formed after comparing data in three dimensions: configuration, status, and traffic. Each data item is marked to indicate whether it exceeds the preset deviation threshold.

[0101] Among them, the target network twin environment is a simulated network environment that has undergone multiple rounds of incremental synchronization and repeated verification, and has met the consistency standards in all three dimensions. All parameters are consistent with the actual operating state of the network and meet the usage conditions for cutover pre-rehearsal.

[0102] For example, the specific methods for obtaining real-time status change data can be as follows: Data collection is initiated according to a fixed time cycle. During the critical period of cutover preparation, a collection interval of 100 milliseconds is used, while a collection interval of one second is used during the regular preparation phase. Three types of data are captured through three paths: configuration change information is obtained from the configuration collection link, interface start and stop information is captured by the link detection program, and link traffic change data is summarized by the traffic statistics tool. After collection, the data is classified and stored in a temporary database.

[0103] For example, the updated network twin environment can be obtained in the following ways: By comparing the stored baseline data of the current network, the data entries that have changed during the current collection cycle are selected, and the corresponding virtual devices and configuration items in the twin environment are located. Only the selected changed content is rewritten, while the unchanged data remains unchanged. After processing, an updated network twin environment is generated.

[0104] For example, the specific method for obtaining consistency verification results across multiple dimensions can be as follows: The configuration dimension calculates the configuration difference rate by statistically analyzing the percentage of configuration difference items, and makes a judgment against the threshold of 0.5 percent; the status dimension calculates the interface status offset duration and the percentage of hardware and software resource differences, and compares them against the limit of 100 milliseconds and 5 percent; the traffic dimension calculates the deviation of bandwidth, latency, and packet loss, and compares them against their respective thresholds. The three dimensions generate corresponding verification conclusions, which are then summarized to form a consistency verification result across multiple dimensions.

[0105] For example, the specific method for obtaining the target network twin environment can be: If any verification indicator exceeds the preset threshold, the latest real-time data from the live network is immediately retrieved again to carry out a new round of incremental synchronization. After the synchronization is completed, the consistency verification is repeated three times, and the operation is iterated until all three dimensions meet the standards, and finally a target network twin environment that can be used for pre-simulation is generated.

[0106] In this embodiment, the changes in the live network are periodically and dynamically collected and incrementally refreshed locally. This avoids the inefficient mode of replacing all data in the twin environment. The simulation environment data is repeatedly corrected through a three-layer quantitative verification mechanism of configuration, device operating status, and service traffic. This continuously narrows the data matching degree between the virtual network and the actual network, avoiding the distortion of the simulation conclusions due to the disconnect between the simulation environment and the live network operating status. Relying on the precisely calibrated twin environment to conduct the simulation can accurately identify various cutover risks in advance. At the same time, incremental synchronization can reduce the system resource consumption caused by large-scale full data refresh and reduce the hardware operating load of the simulation environment.

[0107] Preferably, in this embodiment, the step of performing fault detection on the device operation data and the service performance data to obtain fault detection results includes: Anomalies were identified in the device operation data and the service performance data, resulting in multiple abnormal events. Obtain the historical prior probability corresponding to each of the aforementioned abnormal events, and the fault condition probability when each of the aforementioned abnormal events occurs; Based on the CPU utilization, interface traffic, and memory usage of the device at the time of the abnormal event, calculate the real-time state weight coefficient corresponding to each abnormal event. Based on the historical prior probability, the fault condition probability, and the real-time state weight coefficient, the fault probability corresponding to each of the abnormal events is calculated by an improved Bayesian inference algorithm. A fault propagation path is constructed, and the fault detection result is obtained based on the fault propagation path and the fault probability corresponding to each of the abnormal events.

[0108] Among them, abnormal events are abnormal records generated when the device operation data and business performance data exceed the preset abnormal judgment threshold. The record content includes the abnormal type, the device number to which it belongs, and the occurrence time accurate to milliseconds. Common types include interface status offline, routing neighbor negotiation interruption, and excessive service packet loss, etc., which are the basic materials for fault analysis.

[0109] Among them, the historical prior probability is a value derived from the statistical summary of a large number of past cutover failure records. It represents the natural probability of a single type of anomaly occurring in the whole network operation and maintenance scenario without additional conditions. All data is generated from the statistical summary of long-term accumulated failure logs.

[0110] Among them, the fault condition probability is a statistical value obtained from historical fault cases. It represents the probability of a corresponding derivative anomaly occurring after the occurrence of a source fault, and is used to characterize the degree of causal relationship between different faults.

[0111] Among them, the improved Bayesian inference algorithm incorporates real-time state weight coefficients into the original probability calculation formula, corrects the original prior probability, and then combines it with conditional probability to complete the calculation of fault probability, thus making up for the shortcomings of traditional algorithms that only refer to historical data and ignore the real-time working conditions on site.

[0112] The failure probability is a probability value obtained after weighted correction calculation, representing the degree of confidence that the current anomaly is caused by entity configuration or hardware failure.

[0113] Among them, the fault propagation path is a fault propagation link obtained by sorting out the fault propagation link according to the time sequence of the anomaly occurrence and the interconnection relationship of the equipment topology. It can intuitively reflect the complete process of the fault being transmitted from the root device to downstream devices and various services.

[0114] For example, the specific method for obtaining multiple exception events can be: The system compares various operational metrics collected in real time with pre-set judgment thresholds one by one. When metrics such as interface disconnection, packet loss rate exceeding one percent, link latency exceeding fifty milliseconds, or hardware resource usage exceeding the limit are exceeded, the system automatically marks and generates anomaly records, synchronously binds the occurrence time and corresponding device information, and summarizes them into multiple abnormal events.

[0115] For example, the specific methods for obtaining historical prior probabilities and fault condition probabilities can be as follows: Retrieve historical fault statistics ledgers stored in long-term archives, search according to the classification information of abnormal events, extract the historical occurrence ratio of the same type of fault as the historical prior probability, and then retrieve the historical occurrence ratio of secondary anomalies caused by the fault as the fault conditional probability.

[0116] For example, the specific method for obtaining real-time state weight coefficients can be: According to the pre-defined resource indicator tier rules, the weight coefficient is fixed at one when all three operating parameters are in the normal range; if the interface traffic is close to the bandwidth limit, or the processor or memory usage is high, the coefficient value is adjusted upward according to the corresponding tier standard of each indicator, and the final weight coefficient is determined by combining the results of the three indicators.

[0117] For example, the specific method for obtaining the failure probability corresponding to each abnormal event can be: The prior parameters are corrected by multiplying the real-time state weight coefficient with the historical prior probability. Then, based on the corrected value and the fault condition probability, the fault probability is quantified and solved, so that the calculation result fits the current real operating environment of the equipment.

[0118] For example, the specific method for obtaining fault detection results can be: Extract the timestamps of all abnormal events to complete the time sequence sorting, combine the network topology connection information to sort out the links where the fault spreads layer by layer to form the fault propagation path, and select the node with the highest fault probability and the first occurrence in the entire link as the fault source based on the path sequence and the fault probability values ​​of various anomalies. Integrate the fault location, fault cause, and affected business scope to generate a complete fault detection result.

[0119] In this embodiment, all abnormal events are screened by anomaly identification, and the Bayesian probability is optimized by generating weight coefficients using three real-time operating indicators of the equipment. This eliminates the probability calculation bias caused by traditional algorithms that only refer to historical fault data and ignore the real-time load on site, thus improving the accuracy of fault probability calculation. Furthermore, the fault propagation link is sorted out according to the anomaly sequence and topology, distinguishing between root cause faults and related derivative faults, and quickly locating the real fault location. This significantly shortens the time spent on fault investigation and can quickly output accurate detection conclusions after the cutover anomaly occurs, providing a reliable basis for initiating backup set rollback processing and effectively improving the overall timeliness of fault recovery.

[0120] Preferably, in an embodiment, constructing a fault propagation path and obtaining the fault detection result based on the fault propagation path and the fault probability corresponding to each of the abnormal events includes: Extract the event timestamps corresponding to all abnormal events, and generate an abnormal event time series based on the chronological order of the event timestamps; Based on the network topology data, construct a physical connection diagram and a logical connection diagram between all abnormal devices; Based on the time sequence of the abnormal events and the device connection relationships in the physical connection diagram and the logical connection diagram, a fault propagation path is constructed to allow the fault to propagate from the root device to other devices. Based on the fault propagation path and the fault probability corresponding to each abnormal event, the root cause device and the fault cause are determined, and the fault detection result is obtained by combining the root cause device and the fault cause.

[0121] Among them, the event timestamp is a millisecond-level time marker that accurately records the instant when an abnormal event occurs. Each marker is bound to the corresponding abnormal event and faulty device to objectively distinguish the order in which each abnormality occurs. It is the basic data for arranging the event sequence.

[0122] Among them, the abnormal event time series is an ordered queue composed of all generated abnormal events arranged in order of time from first to last. It can intuitively reflect the order of occurrence of various abnormalities in the process of fault propagation from the initial stage to the gradual spread of the fault.

[0123] The physical connection diagram is a relationship map drawn based on the physical cabling data collected by the link layer discovery protocol. It fully restores the actual connection structure of physical cables between the optical ports and network ports of the devices, reflecting the device connectivity at the hardware level.

[0124] Among them, the logical connection relationship diagram is a network map generated by sorting out neighbor interaction data based on various routing protocols. It reflects the virtual association of devices at the routing forwarding and service carrying levels and is not limited by the physical cabling location.

[0125] For example, the specific method for obtaining the time series of abnormal events can be: Iterate through all the abnormal events generated in this round of fault detection, retrieve the millisecond-level timestamps stored in the event information one by one, compare the time values ​​of the timestamps, and sort the abnormal events in order from early to late according to the time arrangement rules, and finally form an ordered abnormal event time sequence.

[0126] For example, the specific methods for obtaining the physical connection graph and the logical connection graph can be as follows: The system filters out all device information that is abnormal from the existing topology data, extracts the physical connection data corresponding to the link layer discovery protocol to draw a physical connection relationship diagram, and then extracts the networking data of various routing neighbors to generate a logical connection relationship diagram according to the routing interconnection rules. The two diagrams together show the two-layer networking association of the abnormal devices.

[0127] For example, the specific way to construct a fault propagation path can be: Following the chronological order of the arrangement, and comparing the device connectivity in the two topology diagrams, and according to the logic of the source device first and the derived faulty devices later, all the device nodes through which the fault spread sequentially are connected, thus completely sorting out the entire fault propagation path.

[0128] For example, the specific method for obtaining fault detection results can be: The device with the earliest time sequence and the highest failure probability value in the propagation path is selected as the root cause of the failure. Then, the anomaly type corresponding to the device is matched to pinpoint the specific cause of the failure. The failure location, failure cause, failure propagation link, and affected business content are summarized and integrated to generate a complete failure detection result.

[0129] In this embodiment, the order of anomalies is organized according to timestamps, and the physical and logical dual-layer topology map is used to restore the device-related links. The complete path of the fault spreading layer by layer is accurately sorted out. Then, the source fault with the earliest occurrence and the highest credibility is selected by combining the quantitative fault probability of each anomaly. This can effectively avoid the problem of downstream related faults being misjudged as the source of the fault, improve the accuracy of fault location, and shorten the time spent on fault cause analysis.

[0130] Preferably, in this embodiment, the rollback process based on the backup set to restore network services includes: The backup set is processed in parallel using multiple threads to obtain the rollback execution results for each faulty device. Atomically verify the rollback execution results of all faulty devices to obtain the rollback completion status; Based on the rollback completion status and the preset service priority, the service path is switched to the pre-stored backup path to restore network services.

[0131] In the case of multi-threaded parallel processing, the rollback task of batch devices is split into multiple independently running processing branches. Multiple branches simultaneously initiate configuration rollback instructions, and rollback operations can be issued to hundreds of faulty devices at the same time, instead of processing them one by one in sequence according to the device order.

[0132] The rollback execution result is the configuration restoration performed by a single faulty device after receiving the rollback command. The execution receipt information returned by the device includes the device number, configuration entry restoration details, and execution success or failure status flags.

[0133] During atomic verification, the rollback tasks of all faulty devices in this round are defined as an indivisible whole, following the judgment rules of either a complete success or a complete withdrawal. If any device rollback fails, all modified configurations of the entire batch of devices are revoked and restored.

[0134] The rollback completion status is a status information formed after summarizing all device receipts and performing atomic overall verification. It is divided into two statuses: overall rollback successful and overall rollback failed.

[0135] Among them, the business priority is the order of priority based on the business operation value. VIP dedicated line business for government and enterprise has the highest priority, followed by public broadband business, and finally equipment back-end management business. This is used to determine the order of business switching.

[0136] Among them, the backup path is a backup transmission link that has been simulated and verified in the early cutover and rehearsal stage and stored in the rehearsal result library in advance. It can directly take over the service traffic after the original service link fails.

[0137] For example, the specific method to obtain the rollback execution result can be: Based on the backup set data pre-stored in the device's local cache, the list of faulty devices is split to generate multiple independent processing tasks. Multiple processing branches simultaneously send rollback configuration instructions to the corresponding faulty devices. Each device independently performs the configuration restore operation and then reports its own execution status upwards, generating the rollback execution result for each device one by one.

[0138] For example, the specific method to obtain the rollback completion status can be: A comprehensive verification is conducted by summarizing the execution receipts of all failed devices in this round. If all device receipts are marked as successful, the overall verification passes. If any device fails to execute, an automatic reversal command is issued to revert all configuration changes already completed on all devices, and the corresponding rollback completion status is marked based on the verification results.

[0139] For example, the specific methods for restoring network services can be as follows: When the rollback completion status is "overall success", various types of business traffic are migrated to the pre-stored backup path in batches according to the order of high priority to low priority; when the rollback completion status is "overall failure", the rollback operation is no longer waited for and the link switch of all types of business is completed quickly according to the priority order.

[0140] For example, a core router replacement and cutover by a certain operator experienced a configuration error, involving four faulty devices: one core router and three downstream access switches, requiring rollback. The system split the rollback into four tasks and used multi-threaded parallel processing. The four task paths simultaneously retrieved backup sets from the local cache and simultaneously issued rollback commands to the four devices. Each device returned a confirmation message indicating successful configuration recovery, forming its own rollback execution result. The system performed atomic verification on the four confirmation messages. If all four devices executed without errors, the rollback completion status was determined as overall success. Subsequently, according to priority rules, high-level enterprise leased line services were first switched to the pre-stored backup link, followed by ordinary broadband services and network management services in sequence. The entire service recovery process took approximately 400 milliseconds. If one of the access switches reported rollback failure, the atomic verification mechanism triggered a full-device rollback reversal. The system directly skipped the configuration restoration step and switched all services to the backup path according to priority.

[0141] In this embodiment, multi-threaded parallel processing is used to complete the rollback operation of multiple devices simultaneously, abandoning the inefficient mode of single-device serial rollback, shortening the configuration recovery time of batch devices, and constraining the integrity of the entire batch rollback task through atomic verification to avoid the problem of network configuration disorder caused by partial device rollback success and failure of other devices. Combined with the orderly switching of pre-stored backup links based on service priorities, high-value services are given priority to ensure rapid recovery. The entire process from instruction issuance, result verification, and service switching compresses the fault interruption time and further improves the timeliness of fault recovery. At the same time, the rollback instructions issued in parallel according to the unified format backup set can be adapted to heterogeneous devices of different brands, continuously improving the cross-vendor unified rollback adaptation capability.

[0142] To better implement the above methods, embodiments of this application also provide a network cutover configuration processing device, which can be integrated into an electronic device, such as a server or terminal, and the terminal may include a tablet computer, a laptop computer, and / or a personal computer.

[0143] For example, see Figure 2 , Figure 2 This is a schematic diagram of the configuration processing device for network cutover provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the network cutover configuration processing device may include a backup module 201, a rehearsal module 202, a cutover module 203, a rollback module 204, and an archiving module 205, as follows: Backup module 201 is used to acquire basic configuration data, dynamic operation data and network topology relationship data of each device in the network to be cut over, and perform three-dimensional backup processing on the basic configuration data, the dynamic operation data and the network topology relationship data to obtain a backup set including basic configuration, dynamic configuration and context configuration; The pre-drill module 202 is used to construct a virtual network topology based on the network topology relationship data, configure virtual devices in the virtual network topology based on the backup set, obtain a network twin environment according to the constructed virtual network topology and the virtual devices, and perform a cutover pre-drill in the network twin environment to obtain the cutover pre-drill result. The cutover module 203 is used to send cutover configuration information to each device in the network to be cut over when the cutover pre-rehearsal result is that the cutover is successful, so that the device executes the network cutover process based on the cutover configuration information, and collects device operation data and service performance data during the execution of the network cutover process at a preset frequency. The rollback module 204 is used to perform fault detection on the device operation data and the service performance data, obtain fault detection results, and when the fault detection results indicate that there is a network fault, perform rollback processing according to the backup set to restore network services. The archiving module 205 is used to archive all configuration versions in the network cutover process after the network cutover process is completed, so as to obtain a configuration version file.

[0144] In practice, the above modules can be implemented as independent entities or combined in any way to be implemented as the same or several entities. For the specific implementation of the above modules, please refer to the previous method implementation examples, which will not be repeated here.

[0145] As can be seen from the above, this application embodiment collects three types of data: basic configuration, dynamic operation, and network topology, and completes a three-dimensional backup including basic, dynamic, and contextual configurations, generating a dedicated backup set. This breaks through the limitations of traditional single full configuration backup. Based on the contextual configuration and topology relationships, it locks various related and dependent configurations. During rollback, it can accurately retrieve the corresponding configuration content as needed, avoiding the problem of erroneous reset of normal business configurations caused by overall configuration overwrite. It improves the accuracy of configuration regression from the root of backup, and the data format of the unified structured storage of all configurations can adapt to the configuration conversion needs of different vendors' devices. Based on the topology, a virtual topology is built, and virtual devices are deployed using the backup set to build a network twin environment and conduct cutover rehearsals in advance. Before the cutover configuration is issued in the real network, the entire cutover process can be completely simulated in the virtual environment, identifying potential faults such as configuration conflicts and link anomalies in advance. This truly enables early prediction of actual faults and reduces the risk of failures in the live network. The probability of sudden failures is minimized. Formal cutover configurations are only issued after successful pre-operation verification. During the cutover, equipment operation and service performance data are continuously collected at a fixed frequency to achieve real-time monitoring of the cutover process, shortening fault detection time and providing real-time data support for rapid fault handling, thus improving fault recovery efficiency. After a fault occurs, the pre-generated standardized backup set is automatically invoked to perform a rollback, eliminating the inefficient traditional method of manually logging into devices, manually searching for configurations, and manually entering rollback commands. This significantly reduces rollback operation time and further optimizes fault recovery efficiency. The unified and standardized backup data format is compatible with the configuration logic of heterogeneous devices from multiple vendors, enabling unified rollback adaptation for different brands of devices. After the cutover, the entire lifecycle configuration version is archived to form a file. Subsequent maintenance or secondary fault rollbacks allow for quick retrieval of the corresponding historical configuration version, facilitating accurate selection of the rollback data source and further enhancing the accuracy of configuration regression.

[0146] In some embodiments, the network cutover configuration processing apparatus of the present invention can be implemented in a combination of hardware and software. As an example, the network cutover configuration processing apparatus of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the network cutover configuration processing method of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0147] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0148] An electronic device according to an embodiment of the present invention includes a processor and a memory, wherein the memory stores multiple instructions; the processor loads instructions from the memory to execute the steps in the network cutover configuration processing method of any of the above embodiments. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store a computer program; the processor is used to execute the network cutover configuration processing method shown in any embodiment of the present invention by calling the computer program.

[0149] In one alternative embodiment, an electronic device is provided, such as Figure 3 As shown, Figure 3 The illustrated electronic device 3000 includes a processor 3001 and a memory 3003. The processor 3001 and the memory 3003 are connected, for example, via a bus 3002. Optionally, the electronic device 3000 may further include a transceiver 3004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 3004 is not limited to one type, and the structure of the electronic device 3000 does not constitute a limitation on the embodiments of the present invention.

[0150] Processor 3001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 3001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0151] Bus 3002 may include a path for transmitting information between the aforementioned components. Bus 3002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 3002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus 3002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0152] The memory 3003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0153] The memory 3003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 3001. The processor 3001 executes the application code stored in the memory 3003 to implement the content shown in the foregoing method embodiments.

[0154] Among them, electronic devices can also be terminal devices, which can be any device that can install applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0155] It should be noted that, Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0156] An embodiment of the present invention provides a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the steps in the network cutover configuration processing method described above.

[0157] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0158] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the steps of the network cutover configuration processing method described above.

[0159] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0160] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the implementable architecture, functions, and operations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0161] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium that includes or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0162] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0163] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also include other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0164] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0165] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product in one or more computer-readable media, the computer-readable media including computer-readable program code.

[0166] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A configuration processing method for network cutover, characterized in that, include: Acquire the basic configuration data, dynamic operation data, and network topology relationship data of each device in the network to be cut over, and perform three-dimensional backup processing on the basic configuration data, the dynamic operation data, and the network topology relationship data to obtain a backup set including basic configuration, dynamic configuration, and context configuration; A virtual network topology is constructed based on the network topology relationship data. Virtual devices in the virtual network topology are configured based on the backup set. A network twin environment is obtained based on the constructed virtual network topology and the virtual devices. A cutover simulation is performed in the network twin environment to obtain the cutover simulation results. When the cutover simulation result is that the cutover is successful, cutover configuration information is sent to each device in the network to be cut over, so that the device executes the network cutover process based on the cutover configuration information, and collects device operation data and service performance data during the network cutover process at a preset frequency. Fault detection is performed on the device operation data and the service performance data to obtain fault detection results. When the fault detection results indicate that a network fault exists, a rollback process is performed based on the backup set to restore network services. Once the network cutover process is completed, all configuration versions in the network cutover process are archived to obtain a configuration version file.

2. The network cutover configuration processing method according to claim 1, characterized in that, The three-dimensional backup processing of the basic configuration data, the dynamic operation data, and the network topology relationship data yields a backup set including basic configuration, dynamic configuration, and context configuration, comprising: Get the cutover configuration command; The cutover configuration command is parsed to determine the configuration object and configuration parameters; Based on preset configuration semantic association information, semantic association processing is performed on the configuration object and the configuration parameters to obtain the direct dependency configuration corresponding to the configuration object; Based on the direct dependency configuration and the network topology relationship data, trace the indirect dependency configuration of the configuration object across devices; The context configuration is obtained by integrating the direct dependency configuration and the indirect dependency configuration, and the backup set is obtained by combining the context configuration with the basic configuration and the dynamic configuration.

3. The network cutover configuration processing method according to claim 1, characterized in that, Before sending the cutover configuration information to each device in the network to be cut over, the process also includes: Obtain standardized configuration commands; The standardized configuration command is parsed to obtain configuration semantic information, which includes configuration type, configuration object and parameter list. Based on a pre-built vendor feature library, the configuration semantic information is subjected to vendor feature adaptation processing to obtain a semantic model of the functional differences of the target device. Based on the manufacturer information of the target device, determine the corresponding manufacturer adaptation dictionary, and based on the manufacturer adaptation dictionary, convert the semantic model into the configuration command corresponding to the target manufacturer; The configuration commands corresponding to the target vendor are subjected to syntax validation to obtain a syntax validation result. If the syntax validation result is passed, the configuration commands corresponding to the target vendor are used as the cutover configuration information.

4. The network cutover configuration processing method according to claim 1, characterized in that, Before performing the cutover rehearsal in the network twin environment, the method further includes: According to a preset time interval, real-time status change data of the existing network is collected. The real-time status change data includes configuration change data, interface status data, and traffic fluctuation data. Based on the real-time status change data, incremental synchronization processing is performed on the network twin environment to update the changed parts of the network twin environment, resulting in an updated network twin environment. The consistency between the updated network twin environment and the existing network is verified from three dimensions: configuration consistency, state consistency, and traffic consistency, resulting in consistency verification results across multiple dimensions. When the consistency check result of any dimension is inconsistent, incremental synchronization processing is performed on the updated network twin environment until the consistency check results of all dimensions are consistent, and the target network twin environment is obtained. The target network twin environment is used to perform cutover rehearsal.

5. The network cutover configuration processing method according to claim 1, characterized in that, The step of performing fault detection on the equipment operation data and the service performance data to obtain fault detection results includes: Anomalies were identified in the device operation data and the service performance data, resulting in multiple abnormal events. Obtain the historical prior probability corresponding to each of the aforementioned abnormal events, and the fault condition probability when each of the aforementioned abnormal events occurs; Based on the CPU utilization, interface traffic, and memory usage of the device at the time of the abnormal event, calculate the real-time state weight coefficient corresponding to each abnormal event. Based on the historical prior probability, the fault condition probability, and the real-time state weight coefficient, the fault probability corresponding to each of the abnormal events is calculated by an improved Bayesian inference algorithm. A fault propagation path is constructed, and the fault detection result is obtained based on the fault propagation path and the fault probability corresponding to each of the abnormal events.

6. The network cutover configuration processing method according to claim 5, characterized in that, The process of constructing a fault propagation path and obtaining the fault detection result based on the fault propagation path and the fault probability corresponding to each of the abnormal events includes: Extract the event timestamps corresponding to all abnormal events, and generate an abnormal event time series based on the chronological order of the event timestamps; Based on the network topology data, construct a physical connection diagram and a logical connection diagram between all abnormal devices; Based on the time sequence of the abnormal events and the device connection relationships in the physical connection diagram and the logical connection diagram, a fault propagation path is constructed to allow the fault to propagate from the root device to other devices. Based on the fault propagation path and the fault probability corresponding to each abnormal event, the root cause device and the fault cause are determined, and the fault detection result is obtained by combining the root cause device and the fault cause.

7. The network cutover configuration processing method according to claim 1, characterized in that, The rollback process based on the backup set to restore network services includes: The backup set is processed in parallel using multiple threads to obtain the rollback execution results for each faulty device. Atomically verify the rollback execution results of all faulty devices to obtain the rollback completion status; Based on the rollback completion status and the preset service priority, the service path is switched to the pre-stored backup path to restore network services.

8. A network cutover configuration processing apparatus, characterized in that, include: The backup module is used to acquire the basic configuration data, dynamic operation data and network topology relationship data of each device in the network to be cut over, and to perform three-dimensional backup processing on the basic configuration data, the dynamic operation data and the network topology relationship data to obtain a backup set including basic configuration, dynamic configuration and context configuration. The pre-drill module is used to construct a virtual network topology based on the network topology relationship data, configure virtual devices in the virtual network topology based on the backup set, obtain a network twin environment according to the constructed virtual network topology and the virtual devices, and perform a cutover pre-drill in the network twin environment to obtain the cutover pre-drill result. The cutover module is used to send cutover configuration information to each device in the network to be cut over when the cutover pre-rehearsal result is that the cutover is successful, so that the device executes the network cutover process based on the cutover configuration information, and collects device operation data and service performance data during the network cutover process at a preset frequency. The rollback module is used to perform fault detection on the device operation data and the service performance data, obtain fault detection results, and when the fault detection results indicate that there is a network fault, perform rollback processing based on the backup set to restore network services. The archiving module is used to archive all configuration versions in the network cutover process after the network cutover process is completed, thereby obtaining a configuration version archive.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to perform the steps in the network cutover configuration processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the network cutover configuration processing method according to any one of claims 1 to 7.

Images