Method and system for changing access rights

Abstract

This application discloses a method and system for changing access permissions, relating to the field of computer technology. The method includes: after receiving a change request from a target account, obtaining a resource snapshot of the target network, wherein the change request is used to request changes to access permissions between nodes in the target network, and the resource snapshot indicates the topology and resource status of the target network; then, generating configuration instructions based on the change request and the resource snapshot, verifying the configuration instructions, and, if the verification is successful, configuring the nodes in the target network based on the configuration instructions to change the access permissions between the nodes in the target network. This solves the technical problem in related technologies where the access permission change process relies on manual configuration, achieving the technical effect of improving the efficiency of access permission changes.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and system for changing access permissions. Background Technology

[0002] In today's cloud computing, especially in private and hybrid cloud environments, the network, as the cornerstone carrying all business traffic, is increasingly complex and crucial in management. However, network change processes, whether enabling a new business access policy or adjusting firewall rules, typically require network engineers to manually log into multiple devices from different vendors and execute a series of complex command-line operations. This process is not only time-consuming and labor-intensive but also highly susceptible to business interruptions or security vulnerabilities due to human error (such as misconfiguration or overlooked devices). Summary of the Invention

[0003] This application provides a method and system for changing access permissions, so as to at least solve the problem that the process of changing access permissions in related technologies relies on manual configuration.

[0004] This application provides a method for changing access permissions, comprising: receiving a change request sent by a target account, wherein the change request is used to request a change in access permissions between nodes in a target network; obtaining a resource snapshot of the target network, wherein the resource snapshot is used to indicate the topology and resource status of the target network; generating a configuration instruction based on the change request and the resource snapshot, and verifying the configuration instruction; and, if the verification is successful, configuring the nodes in the target network based on the configuration instruction to change the access permissions between nodes in the target network.

[0005] This application also provides an access permission change system, comprising: a clarification specification module for receiving a change request sent by a target account, wherein the change request requests changes to access permissions between nodes in a target network; a snapshot construction module for receiving network status data of nodes in the target network collected by at least one agent, and generating a resource snapshot based on the network status, wherein each agent in the at least one agent is deployed in a different fault domain, and the resource snapshot indicates the topology and resource status of the target network; a planning decision module for determining a target forwarding path based on the change request and the resource snapshot, generating a configuration instruction based on the target forwarding path, and generating a decision directed acyclic graph after determining the target forwarding path, wherein the decision directed acyclic graph includes selected and unselected paths during the determination of the target forwarding path, and the reasons for the selection or non-selection of the path; and a fault verification module for generating at least one test case based on the configuration instruction, obtaining a test case set, and verifying the configuration instruction through the test case set to obtain a verification result of the configuration instruction, wherein if the configuration instruction passes verification, the network status of the target network is changed through the configuration instruction.

[0006] This application allows for the following: upon receiving a change request from a target account requesting a change in access permissions, the topology and resource status of the target network are obtained, resulting in a resource snapshot of the target network. Then, based on the change request and the resource snapshot, hierarchical planning is performed to accurately generate configuration instructions, which are then verified. If verification is successful, the nodes in the target network are configured based on the configuration instructions to achieve the change in access permissions.

[0007] Upon receiving a change request from the target account, the system proactively parses the semantics of the request and collects the target network's topology and resource status in real time. Based on this information, the change request is directly converted into configuration commands, eliminating the need for manual configuration using experience-based scripts. This automates the network change process, reduces reliance on the experience of operations personnel or senior experts, optimizes labor costs, and significantly improves the efficiency and agility of network changes. Furthermore, configuration commands are validated before being sent to the target network. Only after successful validation are the commands sent to configure nodes within the target network. This proactive risk control mechanism for network changes allows for early detection and mitigation of potential risks, largely preventing service interruptions caused by configuration errors, resource conflicts, or redundancy failures. This ensures the target network remains stable during dynamic changes, improving network availability. Therefore, this system effectively addresses the technical problem of relying on manual configuration for access permission changes in related technologies, significantly improving the efficiency of access permission changes. Attached Figure Description

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

[0009] Figure 1 This is a hardware structure block diagram of the method for changing access permissions according to an embodiment of this application;

[0010] Figure 2 This is a flowchart of a method for changing access permissions according to an embodiment of this application;

[0011] Figure 3 This is a flowchart modified according to the intent of the embodiments of this application;

[0012] Figure 4 This is a flowchart of hierarchical decision-making according to an embodiment of this application;

[0013] Figure 5 This is a network architecture diagram according to an embodiment of this application;

[0014] Figure 6 This is a structural block diagram of a system for changing access permissions according to an embodiment of this application;

[0015] Figure 7 This is an architecture diagram of an intent-driven cloud network orchestration and self-healing system according to an embodiment of this application.

[0016] Figure 8 This is a structural block diagram of an access permission changing device according to an embodiment of this application. Detailed Implementation

[0017] In today's cloud computing, especially private and hybrid cloud environments, the network, as the cornerstone carrying all business traffic, is facing increasing complexity and importance in its management. With the rapid expansion of business scale, the microservice-based application architecture, and the growing demand for multi-tenant isolation, network operation and maintenance models are also facing severe challenges.

[0018] Traditional network management systems primarily focus on device-level monitoring and alarms, providing basic information such as network topology, device status, and interface traffic. However, they lack an understanding of business logic and cannot directly link business requirements with underlying network configurations to automatically configure the network based on those requirements. While script-based configuration management tools can batch distribute network configurations by writing scripts or status files, they still require operations personnel to precisely define each step based on business needs. Lacking an understanding of these business needs, they cannot automatically configure the network based on those needs.

[0019] Furthermore, early software-defined network controllers achieved network programmability by separating the control plane from the data plane. This enabled the controller to automatically issue flow tables based on topology changes, perform simple path switching, or load balancing, supporting automation to some extent. However, its automation capabilities were limited to network layer operations and still lacked an understanding of business requirements, failing to automatically configure the network according to those requirements.

[0020] In summary, network change processes (such as access permission changes) still heavily rely on manual intervention. Related systems cannot automatically configure the network based on business needs, requiring engineers to manually execute a series of complex commands based on business intent. This is not only time-consuming and labor-intensive but also highly susceptible to business interruptions or security vulnerabilities due to human error (such as configuration errors or missing devices). Therefore, to address the problems existing in related technologies, this application proposes a method and system for changing access permissions. Based on an understanding of business needs and modeling of network resources, it automatically generates configuration instructions that meet business requirements, thereby automating the access permission change process.

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0022] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0023] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of the access permission change method according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the image. A processor 102 (which may include, but is not limited to, a central processing unit (CPU), microprocessor (MCU), or programmable logic device (FPGA), etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0025] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the access permission change method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0026] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0027] The embodiments of this application provide a method for changing access permissions. The method is described in detail below in conjunction with the execution flow of the method for changing access permissions.

[0028] The following explains the English abbreviations that appear in this application:

[0029] ACL: Access Control List.

[0030] ARP: Address Resolution Protocol.

[0031] BGP: Border Gateway Protocol.

[0032] CMP: Cloud Management Platform.

[0033] CSP: Constraint Satisfaction Problem.

[0034] DAG: Directed Acyclic Graph.

[0035] GRE: Generic Routing Encapsulation.

[0036] HA: High Availability.

[0037] IaaS: Infrastructure as a Service.

[0038] IP: Internet Protocol.

[0039] IT: Information Technology.

[0040] LLDP: Link Layer Discovery Protocol.

[0041] NFV: Network Functions Virtualization.

[0042] NLP: Natural Language Processing.

[0043] SDN: Software Defined Networking.

[0044] VLAN: Virtual Local Area Network.

[0045] VNI: VXLAN Network Identifier.

[0046] VPC: Virtual Private Cloud.

[0047] VXLAN: Virtual Extensible LAN.

[0048] The following explains the technical terms used in the embodiments of this application:

[0049] A cloud management platform (CMP) is a centralized software system used for the unified management, orchestration, monitoring, and billing of computing, storage, network, and other cloud service resources in public, private, or hybrid clouds. It serves as a unified interface between operations personnel, business users, and the underlying cloud infrastructure. In this embodiment, the CMP refers to the entry point for intents; users initiate change requests through it, and the system then uses the CMP to call the core orchestration layer for intelligent processing.

[0050] Infrastructure as a Service (IaaS) is one of the three major service models of cloud computing. It primarily provides users with on-demand, rentable underlying IT infrastructure resources, including computing (virtual machines), storage (block storage, object storage), and networking (IP, bandwidth, VPC), allowing users to install operating systems, middleware, and applications on these resources. In this embodiment, IaaS is the execution layer for network configuration. After the CMP calls the core orchestration layer to intelligently process change requests and generate configuration instructions (such as ACLs and routes), these instructions are distributed to real virtual or physical devices through the network controller or virtual switch of the IaaS layer to take effect.

[0051] Cloud networking refers to the logical and physical network architecture that provides network connectivity, isolation, security control, and traffic scheduling for virtualized resources (such as virtual machines, containers, and cloud storage) in a cloud computing environment. Through technologies such as Software-Defined Networking (SDN), Network Functions Virtualization (NFV), and virtual tunnels (such as VXLAN and GRE), cloud networking transcends the boundaries of traditional physical networks, dynamically constructing elastic network topologies across physical servers, data centers, and even clouds. In this embodiment, cloud networking is a core component of Infrastructure as a Service (IaaS), consisting of virtual network devices (such as virtual switches and virtual firewalls), logical tunnels (such as VXLAN), tenant isolation domains (VPCs), network address pools, security groups, routing tables, etc., running on top of underlying hardware such as physical servers and smart network interface cards (NICs).

[0052] The orchestration layer is the core module for intelligent decision-making and collaborative control in cloud computing and network automation architectures, located between the upper-layer business intent entry point (such as the cloud management platform CMP) and the lower-layer infrastructure execution layer (such as IaaS network controllers and virtual switches). It does not directly forward data traffic or provide underlying resources; instead, it is responsible for transforming ambiguous business requirements (i.e., intents) into precise, secure, verifiable, and rollbackable underlying resource configuration instructions, and coordinating multiple systems to complete end-to-end automated execution.

[0053] Automated orchestration refers to the end-to-end collaborative operation in complex IT or network environments, based on preset rules or intelligent decisions, which automatically completes the process from demand input to resource configuration, policy distribution, status verification, and anomaly repair.

[0054] A fault domain refers to a set of devices, links, or resources in a network or system that may fail simultaneously due to sharing the same physical or logical single point of failure risk. In the embodiments of this application, a fault domain is a set of network entities with shared risk attributes, such as devices sharing the same power supply, the same rack, the same uplink switch, or the same physical optical fiber.

[0055] This embodiment provides a method for changing access permissions. Figure 2 This is a flowchart of a method for changing access permissions according to an embodiment of this application, such as... Figure 2 As shown, this method is applied to the core orchestration layer between the cloud management platform and Infrastructure as a Service, and includes the following steps:

[0056] Step S202: Receive a change request sent by the target account, wherein the change request is used to request changes to the access permissions between nodes in the target network;

[0057] The target account mentioned above can be the identity subject that initiates the network change request. This identity subject can be an end user with system privileges (such as a cloud platform tenant), a service account used by an upper-level management system (such as a work order system or DevOps pipeline), or an automation tool with automatic triggering capabilities.

[0058] The aforementioned change request can be a semantic instruction requesting changes to network access control policies, such as granting access permissions between server A and server B, or prohibiting server A from accessing server B. This change request is typically initiated by the target account and expresses the target account's actual business needs or intentions; it can be expressed in natural language or in the form of a structured form.

[0059] The target network mentioned above can be the network environment involved in the change request, which can be a private cloud network, a hybrid cloud network, or a logical network domain within a data center. The target network includes multiple gateway nodes (i.e., nodes), which can be logical or physical entities participating in network communication within the target network. In this embodiment, the nodes in the target network can be endpoints or intermediate forwarding units with access control, such as physical switches, servers, firewalls, virtual switches, routers, VXLAN gateways, etc.

[0060] In the application embodiment, after the network administrator initiates a network change request (i.e., change request) through the target account (such as an end user or an upper management system), the core orchestration layer (hereinafter referred to as the orchestration layer) receives the change request sent by the target account and then automatically orchestrates the change request.

[0061] Step S204: Obtain a resource snapshot of the target network, wherein the resource snapshot is used to indicate the topology and resource status of the target network;

[0062] The aforementioned resource snapshot can be the result of a structured modeling of relevant network entities and logical connections in the target network. This resource snapshot can be represented by a directed weighted topology graph. This topology graph consists of multiple topology points and topology edges. Each topology point represents a network entity in the target network (such as a virtual machine, firewall, switch, etc.), and each topology edge represents a logical or physical communication link between two network entities. Furthermore, each topology point and / or topology edge can also include the attribute information and resource status of the corresponding network entity or communication link.

[0063] In this embodiment of the application, after receiving a change request sent by the target account, the orchestration layer automatically obtains the topology and resource status of the target network and obtains a resource snapshot of the target network at the current moment, thereby providing a network status benchmark for the change of access permissions.

[0064] Optionally, obtaining a resource snapshot of the target network includes: receiving network status of nodes in the target network collected by at least one agent, wherein each agent in the at least one agent is deployed in a different fault domain; generating a resource snapshot based on the network status, wherein the resource snapshot includes a topology map describing the network architecture of the target network, the topology map including multiple topology points and multiple topology edges, the topology points being set with the identity identifier, node type and fault domain to which the topology point belongs, and the topology edges connecting two topology points being set with the link attribute information between the two topology points.

[0065] The aforementioned agent can be a data collection program deployed at the edge of each physical or logical node in the target network. It typically runs as a container on compute nodes or bypasses network device management ports, thereby enabling real-time collection and forwarding of data such as network traffic, system logs, and performance metrics. In this embodiment, the agent can be a distributed sensing node deployed at the edge of each fault domain in the target network. Through local sensing, collection, and preprocessing, it provides the system with real-time network status data. Furthermore, by deploying the agent within different faults, it ensures that the collected information inherently carries fault domain attributes, enabling the system to accurately perceive the distribution of each physical and logical risk unit in the network.

[0066] The aforementioned fault domain can be a set of network entities (such as nodes or links) that share the same single point of failure risk at the physical or logical level. When this single point fails due to the risk, multiple network entities in the set of network entities will become unavailable simultaneously. In the embodiments of this application, the fault domain can be a structured risk unit automatically constructed based on the agent deployment topology to characterize the correlation of node failures.

[0067] In this embodiment, after the orchestration layer receives a change request from the target account, the central orchestrator of the orchestration layer automatically sends snapshot collection instructions to all agents in the relevant areas. At this time, each agent receives the snapshot collection instruction and collects the latest topology data in parallel from switches, controllers, and servers within its area. This includes Link Layer Discovery Protocol (LLDP) neighbor information from switches, Address Resolution Protocol (ARP) cache from servers, port status of virtual switches, and Border Gateway Protocol (BGP) routing tables from routers. Subsequently, each agent cleans the collected data locally, checking the bidirectionality of links (i.e., if A considers B a neighbor, B must also consider A a neighbor), verifying resource pool boundaries, etc. For unstable link data, such as a link whose state changes between connected and disconnected, the agent does not discard the link data directly but marks it as "temporarily unavailable" to avoid the risk of such changes. Then, the central orchestrator receives the cleaned data from each agent and aggregates it to generate a global resource snapshot (i.e., a resource snapshot of the target network) with a generation time and validity period, along with a corresponding version number.

[0068] For example, a global resource snapshot can be a global, attributed topology graph. The nodes (topology points) in the graph represent gateway nodes such as physical switches, virtual routers, firewalls, or servers. Each node also has corresponding attribute labels, such as the gateway node's identifier (ID), the fault domain to which it belongs, the node type (e.g., role), and the manufacturer and version number of the devices on the gateway node. The edges (topology edges) represent physical links or logical tunnels (e.g., VXLAN tunnels). Each edge contains attribute information such as its corresponding source node, destination node, link bandwidth capacity, transmission latency, link status, and the protocol type used for data transmission, thus supporting the system to quickly perform path search and connectivity analysis.

[0069] Meanwhile, to efficiently manage massive amounts of discrete resources (such as IP addresses, MAC addresses, VLAN IDs, etc.), a global resource index structure independent of the topology map can be built in the resource snapshot. For example, by using a compressed prefix tree, the allocated IP addresses of the entire network can be managed efficiently, and IP address space allocation and conflict detection can be performed. The longest prefix matching can be completed in O(k) time complexity (k is the address length), quickly determining whether an IP address has been occupied or whether two subnets have an inclusion relationship. By using a range tree, the usage of continuous numerical resources such as VLAN IDs or port numbers can be managed efficiently, which can be used to quickly find free continuous ranges, avoid fragmented resource allocation, and quickly locate range overlap conflicts.

[0070] Furthermore, to quickly analyze the impact of various resources, a constrained inverted index can be built in the resource snapshot. This establishes a connection between each resource (including gateway node resources, link resources, etc.) and the configured service intents. Using resources as keys and the service intents using those resources as key-value pairs, an inverted index is created from "resource" to "service intent." This allows for rapid identification of which services depend on a resource when it changes, fails, or is under maintenance, enabling second-level impact analysis, avoiding a full network traversal, and supporting intelligent decision-making and security self-healing. For example, the index item Switch-A->{Intent-1, Intent-5} indicates that switch A carries the service intent... Figure 1 and business intention Figure 5 The business it represents.

[0071] Through the above operations, by deploying at least one lightweight data collection agent in the target network, upon receiving a change request from the target account, a structured topology map with attribute information is constructed based on the data collected by each agent. A global resource snapshot is obtained, and a corresponding version number is generated to mark the construction time and validity period of the global resource snapshot. This achieves highly available data collection of network topology and resource status, improving the completeness and accuracy of network status awareness and providing quantitative basis for intelligent path selection and root cause analysis. Simultaneously, by distributing the agents across multiple fault domains, each agent is placed in a different physical risk unit, avoiding single-point blind spots caused by centralized data collection. Furthermore, by binding precise timestamps to each version of the resource snapshot, the system can strictly distinguish network topology, IP allocation, ACL rules, and fault domain status at different points in time, ensuring that all calculations are based on the same static snapshot view. This effectively avoids state drift caused by concurrent changes or network jitter, helping maintenance personnel quickly restore historical network status and accurately locate the time window when changes caused problems during troubleshooting.

[0072] Step S206: Generate configuration instructions based on the change request and resource snapshot, and verify the configuration instructions;

[0073] The aforementioned configuration commands can be a set of low-level operation commands for network nodes in the target network, representing the final implementation of business intent in the physical network. These configuration commands include the gateway node's identity identifier, corresponding parameter configurations, and the order in which commands are executed.

[0074] In this embodiment, the orchestration layer uses the received change request and the obtained resource snapshot as input for automated orchestration. Through precise analysis and hierarchical planning, it automatically generates configuration instructions corresponding to the change request and verifies the availability and compliance of the configuration instructions. This pre-verification method ensures the accuracy of the change process and enables automated changes to access permissions.

[0075] Step S208: If the verification is successful, configure the nodes in the target network based on the configuration instructions to change the access permissions between the nodes in the target network.

[0076] Through the above steps, after receiving the change request sent by the target account to request changes to access permissions, the topology and resource status of the target network are obtained, and a resource snapshot of the target network is obtained. Then, based on the change request and the resource snapshot, hierarchical planning is performed to accurately generate configuration instructions, and the configuration instructions are verified. If the verification is successful, the nodes in the target network are configured based on the configuration instructions to realize the change of access permissions.

[0077] Upon receiving a change request from the target account, the system proactively parses the semantics of the request and collects the target network's topology and resource status in real time. Based on this information, the change request is directly converted into configuration commands, eliminating the need for manual configuration using experience-based scripts. This automates the network change process, reduces reliance on the experience of operations personnel or senior experts, optimizes labor costs, and significantly improves the efficiency and agility of network changes. Furthermore, configuration commands are validated before being sent to the target network. Only after successful validation are the commands sent to configure nodes within the target network. This proactive risk control mechanism for network changes allows for early detection and mitigation of potential risks, largely preventing service interruptions caused by configuration errors, resource conflicts, or redundancy failures. This ensures the target network remains stable during dynamic changes, improving network availability. Therefore, this solution addresses the technical problem of relying on manual configuration for access permission changes in related technologies, achieving automated access permission changes and improving both efficiency and accuracy.

[0078] As an optional implementation, generating configuration instructions based on change requests and resource snapshots includes: mapping entities in the change request to corresponding target slots according to a slot table; determining a confidence vector for the target slot, wherein the confidence vector includes at least one of the following: matching degree and completeness, the matching degree being used to indicate the degree of matching between the entity and the target slot, and the completeness being used to indicate whether the entity on the target slot is missing; and generating configuration instructions based on the confidence vector and resource snapshots.

[0079] The aforementioned slot table can be a structured semantic template maintained internally by the system. This slot table is pre-set by the system for business intents, defining the names, data types, constraint rules, default values, and semantic descriptions of all semantic slots necessary for the business intent, used to structurally express change requests. The slot table stores information in key-value pairs, such as {Source:"10.1.0.0 / 16", Dest:"10.2.0.0 / 16", App:"ERP"}.

[0080] The aforementioned target slots can be predefined semantic fields or parameter positions used to express a complete business intent. Each target slot represents a semantic dimension that must be filled, used to structurally describe the components of the business intent. The slot table includes at least one target slot.

[0081] The entities mentioned above can be specific objects or parameter values ​​identified from the change request, and are the original semantic components that constitute the change request. For example, if the change request is "Please allow the financial system to access the core database", the entities in the change request would be "financial system", "database", "access", etc.

[0082] The aforementioned confidence vector can be a multi-dimensional quantitative indicator used to evaluate the reliability of the filling result for each target slot. In this embodiment, the vector includes two dimensions: matching degree and completeness. A lower value in either dimension indicates that the target slot is associated with a lower confidence level, and the reliability of its filling result is lower. The matching degree represents the semantic similarity between the expected semantic type of the target slot and the entity mapped to the target slot; a higher matching degree indicates a more accurate mapping of the entity to the target slot. The completeness indicates whether the target slot has been effectively filled and whether there are any missing values; a higher completeness indicates a more complete filling within the target slot.

[0083] For example, if the user inputs a change request of "Please allow the financial system to access the core database", and the slot table includes slots such as "Source", "Destination", "Protocol", "Port Range", and "Policy" (i.e., target slots), after receiving the change request, the orchestration layer identifies it through the natural language processing component. At this time, "financial system" is identified and mapped to virtual machine cluster A (containing the IP address range 192.168.10.0 / 24) in CMDB (Configuration Management Database), and "core database" is mapped to physical server B (containing IP addresses 172.16.20.10 and 172.16.20.11). The "Access" action is parsed as an allowed policy action, and this information is populated into a structured slot table, resulting in {Source:"192.168.10.0 / 24", Destination:"172.16.20.10, 172.16.20.11", Protocol:"Any", Port:"Any", Policy:"Allow"}. Since the user did not specify a specific protocol and port, the completeness of the target slots "Protocol Type" and "Port Range" is low, resulting in a low confidence level. Furthermore, since the target slot "Destination Endpoint" has two possibilities, the candidate with the highest matching probability is generally selected for calculation. If the highest probability matching probability is still below a preset threshold, or if there are several candidates with extremely close probabilities that prevent the system from making a unique determination, it indicates that the matching probability of that target slot is low, resulting in a low confidence level. It should be noted that the above judgment method is only described as a preferred embodiment, and the specific judgment method is not limited here.

[0084] In this embodiment, fuzzy change requests are structured into business intent fields using a slot table, and the reliability of semantic filling in each field is quantified using a confidence vector. Based on the filling status of each field, combined with the network topology, resource usage, and fault domain constraints in the resource snapshot, usable configuration instructions are generated. This ensures the accuracy and security of configuration generation at both the semantic and physical levels, enabling automated network configuration based on business needs. It avoids the problem of network configuration relying on manual parsing due to the network management system's lack of understanding of business intent, effectively improving the intelligence and automation level of network operation and maintenance.

[0085] Optionally, generating configuration instructions based on confidence vectors and resource snapshots includes: determining whether entities on the target slot need correction based on confidence vectors; if correction is required, sending a target prompt message, wherein the target prompt message instructs the target account to confirm the entities on the target slot; generating a target network configuration in a preset format based on the target account's response to the target prompt message; and generating configuration instructions based on the target network configuration and resource snapshots.

[0086] The aforementioned target prompt message can be an interactive question automatically generated by the system based on the entity in the change request and the confidence vector of the target slot, used to guide the user (i.e. the target account) to clarify the semantically ambiguous business intent.

[0087] If an entity is missing in the "Port Range" target slot, a fill-in-the-blank question template can be retrieved to generate a target prompt message such as "Please provide the specific port number you need to access." Or, if there are two possibilities in the "Destination Endpoint" target slot, a selective question template can be retrieved to generate a target prompt message such as "There are two core databases. Do you need to access core database 1 (172.16.20.10) or core database 2 (172.16.20.11)?" Or, if an entity in the "Policy Action" target slot is detected to conflict with an existing rule, the conflicting existing rule can be extracted as context to generate a judgmental target prompt message, such as "A violation of security rule X has been detected. Do you want to continue applying for special security approval?"

[0088] The aforementioned target network configuration can be a standard and clear intent object formed based on the explicit parameter values ​​confirmed by the user and the mapped slot table. This target network configuration serves as the basis for subsequent hierarchical planning of the orchestration layer and the generation of configuration instructions.

[0089] In this embodiment of the application, before automated orchestration, the uncertainty of the filling entities in each target slot is quantified by confidence vector, the ambiguity of business intent is identified, and then an automatic clarification mechanism is triggered based on the confidence vector to actively interact with the user for confirmation. Through multiple rounds of interaction, the ambiguity of each point is semantically clarified, generating a structured and unambiguous target configuration instruction, which is used as the input basis for subsequent automated orchestration and resource allocation. The configuration instruction is generated in combination with the resource snapshot of the target network.

[0090] Through the above operations, abnormal or low-confidence entities are automatically identified based on the entity confidence level of the target slot mapped entity, and prompts and correction processes are automatically triggered. This effectively avoids configuration risks caused by incorrect or inaccurate information, improves the accuracy of understanding business intent and the accuracy of final network configuration, enhances the automation and intelligence level of the network configuration process, and ensures network security and stability.

[0091] As an optional implementation, determining whether an entity in a target slot needs correction based on the confidence vector includes at least one of the following: determining that the entity in the target slot needs correction when the confidence vector of the target slot is less than a confidence threshold; determining that the entity in the target slot needs correction when the confidence vector of the target slot is greater than or equal to the confidence threshold, but the entity in the target slot conflicts with historical access permissions in the target network; wherein, a confidence vector less than the threshold includes a matching degree less than a matching degree threshold and / or a completeness less than a completeness threshold, and a confidence vector greater than or equal to the confidence threshold includes a matching degree greater than or equal to the matching degree threshold and a completeness greater than or equal to the completeness threshold.

[0092] In this embodiment of the application, when the confidence vector is lower than a preset threshold, including when the matching degree is lower than the matching degree threshold (e.g., "financial system" is misidentified as 192.168.10.0 / 24, but the system verifies that it should actually be 192.168.11.0 / 24, the matching degree is only 0.65), or when the integrity is lower than the integrity threshold (e.g., the user does not specify a port, the integrity is 0.2), even if the change request entered by the user seems complete, the system will still consider the intent information in the business intent (i.e., change request) to be insufficient, and determine it to be in an untrustworthy state, requiring correction and clarification. Furthermore, if the confidence vector reaches or exceeds the threshold, but after query verification, it is found that the slot entity conflicts with existing network policies (e.g., although the user intent "allow 192.168.10.0 / 24 to access 172.16.20.10" is semantically clear, the verification shows that the target IP has been marked as "prohibited from external access" by the "high priority security policy"), then even if the confidence level meets the standard, the system will still determine that the business intent has a hidden conflict and needs to trigger a clarification mechanism to remind the user.

[0093] Through the above operations, entity ambiguity is avoided by judging confidence thresholds, the accuracy of intent understanding is improved, and the risk of misconfiguration is reduced. At the same time, the introduction of intent self-contradiction detection and implicit conflict analysis enables the system to discover potential contradictions from a global perspective through a preset rule base, realize global policy consistency verification, and provide a solid foundation for the accurate generation of configuration instructions in the future.

[0094] It should be noted that the above method for determining whether an entity needs to be corrected is only a preferred embodiment. The specific determination method can be set according to the actual application scenario, and no specific restrictions are imposed here.

[0095] In one exemplary embodiment, Figure 3 This is a flowchart modified according to the intent of the embodiments of this application, such as... Figure 3 As shown, the specific process includes:

[0096] S301, Receive change request sent by target account;

[0097] S302, call the natural language parsing component to parse the change request, identify the information (i.e., entities) representing the user's intent in the change request, and fill the corresponding information into each slot (i.e., target slot) in the slot table;

[0098] S303 associates a confidence vector (i.e., confidence score) with the filling result (i.e., entity) of each slot, which contains two dimensions: [matching degree, completeness];

[0099] S304, determine whether the filling result of each slot is accurate: if there is a missing slot (i.e., the completeness is less than the completeness threshold), or there are multiple candidate options in the slot (i.e., the matching degree is less than the matching degree threshold), then determine that the confidence of the slot is lower than the preset threshold.

[0100] S305, if the confidence level of the slot is higher than or equal to the preset threshold, the built-in rule engine will continue to perform logical verification on the content in the slot to determine whether the change request conflicts with the existing rules (i.e., semantic conflict).

[0101] S306. If the confidence level of a slot is determined to be lower than a preset threshold, or if the change request conflicts with existing rules, a clarification process is triggered. A specific clarification question (i.e., a target prompt message) is generated based on the content of the slot and / or existing rules and fed back to the user. The content of the slot is then corrected and clarified based on the user's confirmation and supplementary information.

[0102] S307, when it is determined that the change request does not conflict with existing rules, or after the user confirms and supplements the information, automatically generates a clear, conflict-free, and structured intent (i.e., target network configuration), digitally signs the content of the intent, and assigns the intent a unique intent version number.

[0103] As an optional implementation, generating configuration instructions based on the target network configuration and resource snapshots includes: determining the target network architecture that matches the target network configuration in a preset network architecture; determining the target forwarding path based on the resource snapshots and the target network architecture; and generating configuration instructions based on the target forwarding path.

[0104] The aforementioned preset network architecture can be a set of typical network deployment templates pre-configured within the system, where each template can correspond to a common business scenario. For example, for cross-data center interconnection business scenarios, a "VXLAN+BGPEVPN" network architecture can be preset; for high-throughput business scenarios within the same data center, a "VLAN pass-through" network architecture can be preset.

[0105] The aforementioned target network architecture can be a network deployment template that is automatically matched and determined based on the semantic features in the target network configuration to suit the business scenario of the network change request.

[0106] The aforementioned target forwarding path can be the optimal data flow route from the source endpoint to the destination endpoint that satisfies business intent and network constraints, in order to implement changes in access permissions. This path includes intermediate devices (such as switches, firewalls, and gateways) and links (such as VXLAN tunnels and physical optical fibers).

[0107] In this embodiment, firstly, among a variety of preset standard network architecture templates, the most suitable network architecture model is matched based on the semantic features of the target network configuration (such as whether high availability is required, whether it crosses subnets, protocol type, etc.), so that the change process can flexibly adapt to different network environments and enhance the scalability and adaptability of the network system. Then, combined with the accurate real-time network status in the resource snapshot, one or more forwarding paths are calculated under the premise of meeting the architecture constraints. The calculated logical path is then mapped to the underlying configuration instruction set (i.e. configuration instructions) of the target network. This achieves adaptive conversion from business intent to device executable instructions without manual intervention, ensuring the standardization and consistency of the configuration process, reducing configuration errors and conflicts, improving the automation of network device deployment and maintenance, and enhancing network security and stability.

[0108] Optionally, determining the target forwarding path based on the resource snapshot and the target network architecture includes: determining the node type of at least one node that the forwarding path needs to pass through based on the target network architecture, and the sorting of the node types; parsing candidate forwarding paths from the resource snapshot based on the node types and the sorting of the node types to obtain a set of candidate forwarding paths; and determining the target forwarding path from the set of candidate forwarding paths based on preset conditions.

[0109] The above node types can be a standardized classification of the functional roles of gateway nodes in the target network. Typical node types include: source node, target node, routing node, firewall, switching node, etc.

[0110] The node type ordering mentioned above can be based on the order of node types that the path must traverse according to the target network architecture, reflecting the constraints of business logic on traffic flow. For example, in a high-availability access scenario, traffic must pass through the firewall for policy checks and then be forwarded by the router; it cannot be bypassed. The corresponding node type order is: source node → firewall → router node → destination node. In a cross-data center interconnection scenario, traffic must traverse the data center through a VXLAN tunnel, requiring BGP route synchronization. The corresponding node type order is: source node → tunnel endpoint → router node → tunnel endpoint → destination node, etc.

[0111] The aforementioned candidate forwarding paths can be one or more feasible paths determined by the system based on the topology and architecture constraints of the target network, and these paths can meet the forwarding requirements of service traffic.

[0112] In this embodiment, when determining the target forwarding path, the system first derives the node types that the traffic must pass through in sequence based on the preset network architecture matched by the target network configuration (i.e., the target network architecture), and obtains the node type sorting. Then, based on the real-time status of the target network shown in the resource snapshot, all feasible paths that conform to the order and connection relationship of the node types are accurately matched to form a candidate forwarding path set. Subsequently, the candidate forwarding paths in the candidate forwarding path set are filtered and sorted according to preset conditions to eliminate risky or illegal paths. Finally, one or more optimal paths that meet the business intent are selected as the target forwarding path, providing a decision basis for generating accurate configuration instructions in the future. This enables the system to dynamically adjust the forwarding path and configuration instructions according to the real-time snapshot of network resources, improving the network's responsiveness to topology changes, resource changes, etc., and enhancing the flexibility and robustness of network configuration.

[0113] As an optional implementation, resolving candidate forwarding paths from a resource snapshot based on node type and node type sorting includes: matching nodes in the resource snapshot according to node type to determine candidate nodes that match the node type, thus obtaining a candidate node set; traversing the candidate node set based on node type sorting to generate multiple forwarding paths; determining invalid paths from the multiple forwarding paths based on the topology and resource status recorded in the resource snapshot, wherein invalid paths include at least one of the following: forwarding paths where the links between nodes are shown as abnormal in the topology, and forwarding paths where the resource status shows a conflict between the resources allocated in the target network and the resources required by the path; and determining the forwarding paths other than invalid paths from the multiple forwarding paths as candidate forwarding paths.

[0114] For example, an improved K-shortest path algorithm can be used to parse candidate forwarding paths. The specific process is as follows:

[0115] S1 reads a predefined set of logical network element types (i.e. node types) from the target network architecture. This set can contain one or more network function roles, such as source node, destination node, firewall, intermediate node, etc.

[0116] S2, using the set of logical network element types as the filtering condition, traverse all nodes in the topology map displayed by the resource snapshot, filter out nodes that meet the matching conditions of each functional role, and obtain the candidate node set of each functional role.

[0117] S3 generates a path skeleton template based on the order of the functional roles in the logical network element type set, such as source node → firewall → destination node, etc.

[0118] S4, constrained by the order of each functional role, employs a depth-first search or graph traversal algorithm, starting from the first-level candidate node set and expanding sequentially layer by layer. Only paths connecting to the next role set nodes are allowed to extend until a complete end-to-end path satisfying the role sequence is generated, forming multiple forwarding paths, such as:

[0119] First layer: Select any node from the set of candidate nodes corresponding to the source node as the starting point;

[0120] Second layer: Search for nodes that belong to the firewall type among the neighbors of this node;

[0121] The third layer: From the neighbors of the firewall node selected in the previous layer, find the node that belongs to the destination node type;

[0122] S5 combines the real-time topology status and resource allocation information recorded in the resource snapshot to verify the validity of each candidate path, automatically identify and eliminate invalid paths, and determine the remaining paths after invalid paths are identified as candidate forwarding paths.

[0123] The methods for filtering invalid paths include, but are not limited to:

[0124] (1) If the link between any adjacent nodes in the path is interrupted, not established, or temporarily unavailable in the topology graph, then the path is invalid.

[0125] (2) If the critical resources required by the path (such as IP address, VLAN ID, port range, etc.) are partially or completely occupied by other services in the resource snapshot, or if the critical resources are beyond the available range, then the path is invalid.

[0126] (3) If the nodes traversed by the path do not meet the protocol or performance requirements, then the path is invalid.

[0127] It should be noted that when it is confirmed that critical resources are occupied, we can first try to traverse the unoccupied nodes based on the best matching principle. In the remaining free space of the resource pool, we can prioritize finding a continuous free resource block with a capacity that meets the business needs and a size that is closest to the current request and reallocate it. Then, we can filter for failed paths to match possible forwarding paths to the maximum extent. At the same time, we can avoid over-splitting large, complete continuous resources, thereby minimizing the fragmentation of the network resource pool and improving the overall resource utilization.

[0128] By performing the above operations and combining resource snapshots to determine the optimal target forwarding path, we can accurately match the path that meets business needs. This helps to rationally allocate network resources, optimize traffic forwarding, and avoid path failures caused by link failures or instability. It enables accurate and efficient generation of intent-driven paths in large-scale heterogeneous networks, while reducing the risk of configuration errors caused by human neglect of resource status or link anomalies, thus improving network stability and reliability.

[0129] As an optional implementation, the target forwarding path is determined from the candidate forwarding path set according to preset conditions, including: determining the N shortest candidate forwarding paths in the candidate forwarding path set as the target forwarding path, where N is an integer greater than 0; or, determining the N candidate forwarding paths that occupy the least resources in the candidate forwarding path set as the target forwarding path, where N is an integer greater than 0; wherein, when N is greater than 1, the fault domain isolation requirements are met among the N candidate forwarding paths.

[0130] In this application embodiment, the optimization objective is to minimize the number of hops or the end-to-end latency. The N shortest paths from the candidate forwarding path set are selected as target forwarding paths, thereby ensuring forwarding efficiency and response speed. Alternatively, the optimization objective is to minimize resource consumption. The network resources consumed by each path are comprehensively evaluated, and the N paths with the least resource consumption are selected from the candidate forwarding path set, thereby improving network resource utilization, reducing configuration conflict risks, and extending the system's scalability cycle. Simultaneously, for service intents requiring multiple target forwarding paths, such as high availability intents, fault domain isolation constraints are enforced between multiple target forwarding paths: any node (including switches, routers, firewalls, etc.) traversed by any two target forwarding paths belongs to different fault domain identifiers. This ensures complete decoupling of single-point-of-failure risks at the physical layer, so that even if a fault occurs in one fault domain, other paths remain available, ensuring uninterrupted service and improving network availability and fault tolerance.

[0131] As an optional implementation, generating configuration instructions based on the target forwarding path includes: generating at least one access control rule according to the target forwarding path and the target network configuration; determining the unoccupied access control rule identifiers of each node in the access control list of at least one node included in the target forwarding path to obtain at least one target access control rule identifier; establishing a target mapping relationship between at least one access control rule and at least one target access control rule identifier; and generating configuration instructions based on the target mapping relationship.

[0132] The access control rules mentioned above can be structured policy entries that allow or deny data packets in the target network. Each access control policy includes a unique identifier, action, priority, effective time, associated audit tag and reference count, and is centrally managed in the form of access control lists (ACLs) in firewalls, security groups, ACL-enabled switches or virtual network devices to achieve fine-grained network access control and policy isolation.

[0133] In this embodiment, the system dynamically generates one or more structured access control rules based on the node sequence of nodes traversed in the target forwarding path and the access semantics defined in the target network configuration. Each rule includes source / destination IP, protocol, port, and allow / deny actions. Simultaneously, at each node involved in the target forwarding path, the system scans and identifies unallocated, allocable rule identifiers by reading the node's current Access Control List (ACL) status, forming a set of available target access control rule identifiers. Furthermore, the system establishes a precise mapping relationship between the generated access control rules and the identified target access control rule identifiers, binding each access control rule to a specific identifier on the corresponding node. This ensures the policy is locatable on the device side, and configuration instructions are automatically generated based on this mapping relationship. Optionally, the configuration instructions may also carry the intent version number of the target network configuration as a basis for subsequent tracing.

[0134] By performing the above operations, rule number conflicts can be avoided, ensuring that the configuration rules distributed to each node correspond one-to-one with the actual access control requirements. This facilitates subsequent rule tracking, maintenance, and modification, improves the maintainability and scalability of network management, and achieves efficient utilization of ACL resources, enhancing configuration consistency and accuracy. Furthermore, the entire process requires no manual intervention, reducing the labor costs and error risks associated with manual configuration.

[0135] As an optional implementation, after determining the target forwarding path based on the resource snapshot and the target network architecture, the method further includes: generating a decision directed acyclic graph, wherein the decision directed acyclic graph includes the paths selected and not selected during the determination of the target forwarding path, and the reasons for the paths being selected or not selected.

[0136] The aforementioned Decision Directed Acyclic Graph (DAG) can be a structured graph model that records the logic of path selection. It comprehensively preserves all excluded paths and their reasons for exclusion, as well as selected paths and their reasons for selection. Each decision node in the graph represents a key judgment point in the path selection process, such as "choosing path P1 instead of P2 because P2 crosses the same fault domain" or "excluding path P3 because its required VNI resources are already occupied." Each directed edge represents a causal relationship, pointing to the constraints, resource status, topology attributes, or business strategies upon which the decision is based (such as "violation of fault domain isolation principle," "insufficient bandwidth," "ACL ID conflict," "not meeting HA redundancy requirements," etc.). For example, when exploring forward in the resource snapshot and verifying the generated path A, it checks whether the remaining bandwidth of path A meets the requirements. If it does not, the algorithm automatically filters out this path and records the reason for abandonment in the decision DAG: 'Path A: Constraint (insufficient bandwidth) - Selection (abandoning path A) - Cost (blocking)'.

[0137] Optionally, if all possible paths generated are filtered out due to certain constraints, and no candidate forwarding path is included in the candidate forwarding path set, the final output of the system will no longer be a complete and usable business forwarding path, but a complete "troubleshooting evidence chain" (i.e., decision DAG) to provide feedback to the operations and maintenance personnel on the specific reasons for troubleshooting or resource expansion.

[0138] In this embodiment, the entire decision-making process is recorded in a traceable manner by using the entire reasoning logic of the directed acyclic graph structured target forwarding path selection process. This provides maintenance personnel with a transparent and interpretable basis for path selection, thus solving the trust crisis caused by the black-box decision-making of traditional automated systems.

[0139] As an optional implementation, Figure 4 This is a flowchart of hierarchical decision-making according to an embodiment of this application, such as... Figure 4 As shown, the specific decision-making process is as follows:

[0140] S401, Logic skeleton generation:

[0141] Based on the features (i.e. semantic features) of the intent template (i.e. target network configuration), select the planning skeleton (i.e. target network architecture).

[0142] S402, Physical Resource Mapping:

[0143] Based on the planned skeleton, the end-to-end forwarding path is calculated. Due to the existence of fault domain constraints, an improved K-shortest path algorithm is used to eliminate path combinations (i.e., candidate forwarding paths) that share the same physical risk group (i.e., belong to the same fault domain). At the same time, specific resources (IP, VLAN, etc.) are allocated on the resource snapshot using interval tree algorithm. When it is detected that the resource requested by the user overlaps with the existing service, the interval tree algorithm will immediately return the ID of the conflicting node and try to find an alternative interval in the idle pool to perform "minimum fragmentation reselection".

[0144] S403, Decision Record:

[0145] If a forwarding path is found to be unable to satisfy all constraints (e.g., bandwidth resources are exhausted), the system will not report an error directly. Instead, it will record the forwarding path in the decision DAG, such as "failed path: constraint (insufficient bandwidth) - selection (abandon path A) - cost (blocking)", and then output a planning product (i.e. decision DAG) with the state to be verified, along with a complete chain of decision evidence.

[0146] As an optional implementation, verifying the configuration instructions includes: generating at least one test case based on the configuration instructions to obtain a test case set, wherein the test case set includes positive examples and negative examples, positive examples are test cases used to verify inter-node interoperability, and negative examples are test cases used to verify inter-node isolation; verifying the configuration instructions through the test case set to obtain the verification result of the configuration instructions.

[0147] The aforementioned test cases can be network behavior probing specifications with explicit inputs and expected outputs. They can include multi-dimensional combinations such as different protocol types, different port numbers, and different packet sizes to cover various possible communication scenarios. These test cases can include positive and / or negative examples. Positive examples can involve sending a specific type of data packet between node pairs configured to allow communication, which is expected to successfully reach the other end. Negative examples can involve sending data packets between node pairs configured to prohibit communication, which is expected to be blocked by firewalls, ACLs, or related security policies.

[0148] In this embodiment, before issuing the configuration command, the configuration command is first abstracted into a set of structured test cases based on the network topology, access control rules, and connectivity policies defined in the configuration command. This results in a minimum coverage test set, and each test case in the set is verified to cover the most logical paths with the fewest probes. This test case set consists of positive and negative examples. Positive examples verify expected reachability, while negative examples verify expected unreachability. Each test case encapsulates a clear source / destination address, protocol type, port number, probe method, and judgment threshold.

[0149] Through the above operations, operations and maintenance personnel can identify potential risks before changes are made, effectively discover interoperability and isolation issues in configurations, and avoid configuration errors from impacting the production environment. This abandons the high-risk model of traditional configuration taking effect immediately and then troubleshooting errors, achieving pre-verification, semantic alignment, and behavioral verifiability of network changes, significantly improving the security and controllability of network management. Simultaneously, by automatically generating test cases and automatically verifying configuration commands, the workload of manual review and testing is reduced, thereby significantly lowering the risk of network failures due to configuration errors. This significantly improves the standardization and automation of network configuration, effectively reducing the probability of human error, improving operational efficiency, and providing strong support for stable network operation.

[0150] Optionally, the configuration instructions are verified using a set of test cases to obtain the verification results of the configuration instructions, including: constructing a digital twin network of the target network based on resource snapshots; injecting faults into the digital twin network to obtain a faulty network; and running each test case in the set of test cases in the digital twin network and the faulty network respectively to obtain the verification results of the configuration instructions.

[0151] The aforementioned digital twin network can be a logical simulation model that is completely consistent with the physical network in terms of topology, resources, policies, and fault domain structure. This simulation model can be built based on resource snapshots and is essentially a computable, inferable, and isolable virtual network copy. It is used for formal verification and fault scenario simulation before configuration is issued and is the core technology carrier for realizing intent-driven, closed-loop self-healing.

[0152] The aforementioned faulty network can be a logical network variant formed in a digital twin network by automatically injecting one or more faults with operational significance based on fault domain topology analysis. This variant simulates abnormal network states in real-world scenarios. The automatically injected faults are strongly correlated with the network's physical / logical coupling, and the faulty network only modifies the fault-related network states on top of the digital twin network, leaving other configurations unchanged. For example, the injected faults in this faulty network can be generated based on a reliability threshold. A higher reliability threshold results in more complex and realistic fault simulations. For instance, if the reliability threshold is 0.999, only a single node or link fault scenario is derived and simulated; if the reliability threshold is 0.99999, a more severe concurrent two-point fault scenario is derived and simulated.

[0153] In this embodiment, based on the latest collected resource snapshot, a digital twin network completely consistent with the physical network structure, policies, and resources is constructed in memory as a high-fidelity simulation environment. Then, based on the predefined fault domain information in the topology, key nodes and links are automatically identified, and typical network fault scenarios (such as core switch power failure, VXLAN tunnel interruption, BGP session failure, and risk points of shared primary and backup paths) are intelligently injected to generate multiple fault network variants, simulating single-point and compound faults in real operation and maintenance. Then, all positive examples (verifying whether the path should be reachable) and negative examples (verifying whether the path should be blocked) in the test case set are executed in parallel in the original digital twin network and each fault network to obtain the verification results of the configuration instructions. The verification results can be a detailed report, including indicators such as positive example pass rate, negative example interception rate, and fault failover success rate.

[0154] By running test cases in both the digital twin network and the faulty network, the effectiveness and robustness of configuration commands under various scenarios (including anomalies and boundary conditions) can be verified through the above operations. This allows the system to meticulously track network state changes after the execution of configuration commands, facilitating the location and repair of potential defects, improving the reliability and security of configuration, and achieving preliminary confirmation of the reliability, robustness, and high availability of configuration commands under fault conditions.

[0155] As an optional implementation, each test case in the test case set is run in the digital twin network and the faulty network respectively to obtain the verification result of the configuration instruction, including at least one of the following: if at least one test case fails to run in the digital twin network, it is determined that the configuration instruction verification has failed; if at least one test case fails to run in the faulty network, it is determined that the configuration instruction verification has failed.

[0156] As an optional implementation, the above method further includes: if the configuration instruction verification fails, obtaining a negative example that fails to run in the digital twin network and / or the faulty network to obtain at least one target negative example, wherein the digital twin network is a network constructed based on resource snapshots, the faulty network is a network generated after fault injection into the digital twin network, and the negative example is a test case generated based on network configuration instructions to verify the isolation between nodes; determining the node that failed in the target network based on at least one target negative example to obtain the fault point; generating a target repair strategy for the fault point based on the fault point; and repairing the fault point through the target repair strategy.

[0157] The aforementioned target negative example can be a negative example that explicitly triggers verification failure in a digital twin network or a faulty network, and its failure path includes the precise network node and configuration item that caused the policy to fail;

[0158] The aforementioned fault points can be specific configuration errors in the target network that cause the target negative instance to fail, such as a certain ACL rule, a certain routing entry, or a certain VXLAN policy on a certain device.

[0159] The aforementioned target repair strategy can be a set of configuration modification instructions that are automatically generated to correct fault points, and can be used to accurately repair fault points.

[0160] In this embodiment, if any test case fails verification (i.e., fails to run) in the digital twin network or faulty network, a negative example of the failed test is obtained. Then, by analyzing the failure path trajectory of the negative example (i.e., the sequence of nodes the data packet passes through from source to destination and where it is incorrectly allowed), and combining this with the policy graph in the digital twin network (such as ACL matching rules, security group binding relationships, and routing priorities), reverse tracing is performed. For example, if the negative example shows "The financial subnet can access the database master node," the system will locate the intermediate firewall device and check its ACL rules for specific configuration errors such as mismatched "allow" entries, incorrect rule priorities, or unsynchronized security groups. This accurately pinpoints the fault as a configuration error in a specific ACL rule with the ID "ACL-5002" on a particular firewall, rather than a network-wide policy failure. Based on the fault point and the identified fault type, if the fault point is identified as a repairable fault or a software fault, a target repair policy is automatically generated to achieve precise repair of the fault point. If the fault is identified as an unrepairable fault or a hardware failure, the system will trigger a manual alarm and automatically notify the network administrator to repair the fault.

[0161] Through the above operations, the specific fault nodes in the target network that cause the configuration command verification to fail can be quickly and accurately identified, reducing the time and misjudgment rate of manual troubleshooting. This helps to promote the transformation of network operation and maintenance from passive response to proactive prevention and self-healing, avoids business interruption and data loss, ensures the continuous and stable operation of the network system, greatly improves the level of intelligent operation and maintenance, and enhances the overall reliability and service availability of the network.

[0162] Optionally, generating a target repair strategy for the fault point based on the fault point includes: determining the target cause of the fault point's failure based on the decision directed acyclic graph; determining at least one candidate repair strategy based on the target cause in a preset rule base and / or historical cases; analyzing the degree of influence of the at least one candidate repair strategy on the target network in multiple dimensions to obtain the score of each candidate repair strategy among the at least one candidate repair strategy; and determining the candidate repair strategy with the highest score as the target repair strategy.

[0163] In this embodiment, the system determines the target cause of the failure based on the reasoning chain in the decision directed acyclic graph. For example, when the failure point is located as "ACL-5002 rule of firewall F-03 allows unauthorized access", the system will traverse the decision DAG in reverse to trace the source of the rule's generation, thereby accurately identifying the target cause of the failure and transforming the phenomenon-level failure into a logical root cause, thus achieving interpretability and structure in failure attribution. Then, based on the determined target cause, matching candidate repair strategies are selected from the historical case library or the preset rule library. Each candidate repair strategy is analyzed from multiple dimensions (such as impact, number of changes, risk level, consistency guarantee, rollbackability, etc.) to determine the score of each candidate repair strategy. The candidate repair strategy with the highest score is then determined as the target repair strategy for the failure point and used to repair the failure point.

[0164] Through the above operations and the analysis of the directed acyclic graph of decisions, the target cause of the fault point was accurately located, avoiding the traditional experience-based and blind troubleshooting, which greatly improved the accuracy of fault location and repair efficiency. At the same time, through intelligent decision-making and multi-dimensional evaluation, an efficient and accurate solution for the repair of network fault points was provided, which significantly improved the efficiency and effectiveness of fault handling, reduced operation and maintenance costs, and ensured the stable and reliable operation of the network.

[0165] As an optional implementation, after repairing the fault point through the target repair strategy, the above method further includes: verifying the configuration instructions through a set of test cases, wherein the set of test cases includes at least one test case generated based on the configuration instructions; and configuring the nodes in the target network through the configuration instructions if the configuration instructions are verified to be valid.

[0166] In this embodiment, the system reuses the test case set (including positive examples for verifying interoperability and negative examples for verifying isolation) initially generated to verify the original network configuration instructions. It performs secondary verification of the repaired configuration in a digital twin and faulty network environment that is completely consistent with the one before the repair. When all test cases pass (i.e. all accessible paths are still reachable, all isolated areas are still isolated, and all redundancy mechanisms are still effective), the system determines that the fault repair of the target network is successful. Then, the system issues configuration instructions to configure the nodes in the target network and realize the automatic change of access control permissions.

[0167] Through the above operations, an intelligent closed loop of the network change process is achieved, which significantly reduces the risk of secondary failures in network changes and avoids the problem of continued errors after repair in traditional automated systems. It not only ensures the consistency between network status and business intent, but also ensures the traceability of the repair process and the confirmability of the results by reusing the same verification system. This upgrades network self-healing from relying on human experience to evidence-driven precise repair, thereby improving network stability.

[0168] As an optional implementation, the embodiments of this application can be run in Figure 5 In the network architecture shown, such as Figure 5 As shown, the network architecture mainly includes: a cloud management platform, a core orchestration layer, and Infrastructure as a Service (IaaS). Among them, the core orchestration layer, as an intelligent network middleware between the cloud management platform and the IaaS network control layer, plays the role of supporting business logic upwards and shielding the complexity of heterogeneous network devices downwards.

[0169] Optionally, the core orchestration layer of this application adopts a hybrid architecture of "centralized control plane + distributed execution / verification agent". Specifically:

[0170] The control plane is the brain of the core orchestration layer, responsible for global state management, complex logical reasoning, and decision-making. It does not directly participate in traffic forwarding in the data plane, but rather drives network changes by maintaining the overall network logic model and state machine. The control plane maintains the lifecycle of each user request, from intent input, plan generation, verification and execution to final archiving. Each stage corresponds to a node in the state machine, ensuring that any failure in a long-term network change process is traceable and rollbackable. Simultaneously, the control plane also deploys a planning and solving engine, which, based on graph theory algorithms and constraint satisfaction problem solvers, calculates the optimal path and resource allocation scheme to satisfy user intents in complex network topologies.

[0171] Agents are the tentacles of the core orchestration layer, deployed as lightweight containers or processes on every compute cluster, data center, or network function virtualization node. To ensure zero disruption to the host machine, agent design follows these principles:

[0172] Without modifying the host machine's kernel module or taking over the host machine's physical network card driver, it performs read-only data collection and restricted fault injection through standard operating system interfaces or network device management interfaces.

[0173] It periodically probes the network adjacency relationships, interface status, routing table entries, and flow table information of the virtual switch at the node it is located, and after preprocessing (denoising and aggregation) locally, it sends them back to the control plane in the form of versioned snapshots.

[0174] When a verification task is received from the control plane, link packet loss, port down events, or specific probe messages can be simulated in an isolated sandbox environment to verify the network's disaster recovery capabilities and connectivity.

[0175] As an optional implementation, taking a change request of "Please allow the financial system to access the core database" as an example, the steps for automating the network change process in the above control plane are described in detail:

[0176] S501, upon receiving a change request from an enterprise application administrator via a web interface, invokes its built-in natural language processing engine to perform entity recognition on the input text. Specifically, "financial system" is identified and mapped to virtual machine cluster A (containing the IP address range 192.168.10.0 / 24) in the CMDB (Configuration Management Database), and "core database" is mapped to physical server B (containing IP addresses 172.16.20.10 and 172.16.20.11). "Access" is parsed as an "Allow" policy action, and the identified entity information is populated into a structured intent slot table (i.e., the slot table), resulting in {Source: "192.168.10.0 / 24", Destination: "172.16.20.10, 172.16.20.11", Protocol: "Any", Port: "Any", Policy: "Allow"}.

[0177] Because the system detected that the user had not specified a specific protocol and port, these two slots (i.e., the target slots) were missing, resulting in a low confidence level. The system automatically generated a clarifying question: "Which protocols and ports do you want the financial system to access the database through? For example, is it MySQL's port 3306?". Simultaneously, since the request mentioned "high availability," the system asked: "What level of high availability do you require: primary / standby failover or dual-active load balancing?" The administrator selected "TCP protocol, port 3306" on the interface and then selected "primary / standby failover."

[0178] Meanwhile, during the review of the global security policy, a high-priority rule was found: "Any system outside the database management zone is prohibited from directly accessing the core database master node (172.16.20.10)," which conflicts with the current change request. At this point, a feedback message is sent again: "Security policy conflict detected. It is recommended to redirect access to the database proxy or standby node. Do you accept this suggestion and continue?". After administrator confirmation, the intent is modified to only access the standby node. Thus, a clear, conflict-free, and structured intent (i.e., the target network configuration) is generated and assigned a unique version number.

[0179] S502, before planning change requests, deploys control plane commands on agents in each rack and computing cluster to collect the network status of their environment in parallel, including LLDP neighbor information of switches, ARP cache of servers, port status of vSwitch and BGP routing tables of routers.

[0180] The system receives and aggregates data reported by all agents, constructing a global, attribute-based topology graph. Nodes (topology points) in the graph include not only device ID, device role, device vendor, and device version number, but also their respective "fault domain" (e.g., devices powered by the same UPS are labeled with the same fault domain ID). Edges (topology edges) contain information such as the source node, destination node, bandwidth, transmission latency, link status, and the protocol type used for data transmission. Simultaneously, a compressed prefix tree is used to record all allocated IP addresses across the network, and a range tree is used to record the usage of resources such as VLANs, VXLAN, and VNIs. This complete network model is also saved as a versioned resource snapshot.

[0181] S503, calculated based on frozen intents and resource snapshots:

[0182] The analysis determined that access control across virtualization platforms and physical servers was required. Since the source and destination were not on the same Layer 2 network, the system chose "through Layer 3 routing and adding policies on the core firewall" as the logical framework.

[0183] Using an improved K-shortest path algorithm, the forwarding path from virtual machine cluster A to physical server B is calculated. Due to the requirement for "high availability" and "master-slave failover," the algorithm strictly avoids links or devices sharing the same "failure domain ID" when selecting paths. Ultimately, it plans a primary path and a backup path, with the two paths passing through different aggregation switches and firewall devices.

[0184] Next, query the firewall's ACL resource pool, select an unused ACL ID, and add a rule on the firewall to generate configuration instructions;

[0185] In addition, every step of the planning process is recorded. For example, a node might record "Choose path P1 because it has the lowest latency," while its sibling node might record "Abandon path P3 because the switch SW-Core-1 it passes through shares the same fault domain as the main path." This ultimately generates a complete, traceable planning scheme (i.e., a decision DAG), which includes which specific ACLs and static routes need to be configured on which interfaces of which devices.

[0186] S504, before issuing configuration commands, compiles the intent into a series of verification assertions and automatically generates verification test cases:

[0187] Example: The TCP port 3306 from 192.168.10.5 (a VM in the financial system) to 172.16.20.11 (a backup node of the database) should be "reachable";

[0188] Negative example: TCP port 3306 from 192.168.10.5 to 172.16.20.10 (database master node) should be "unreachable";

[0189] Negative example: TCP port 3306 from 192.168.10.5 to any non-database server (such as 10.0.0.1) should be "unreachable" to prevent the policy from being too broad;

[0190] Load resource snapshots and planned change sets into memory, construct a digital twin network, and simulate the forwarding path of data packets conforming to the above use cases in the twin network using formal verification methods; if the results show that all positive and negative examples meet expectations, the verification is considered successful.

[0191] In addition, for high availability, the core switch on the main path can be simulated to lose power in the digital twin and reachability can be recalculated; if the network status is found to converge within a few seconds, traffic is automatically switched to the backup path, and the connectivity of the backup node to access the database is still maintained, then the verification is confirmed to be successful.

[0192] S505 If, during digital twin verification, a fault is found in the simulated main switch and the backup route does not take effect, a counterexample of "high availability verification failed" is obtained, and the counterexample trajectory shows that the priority (Metric) of the backup route is set incorrectly, and is higher than that of the main route;

[0193] At this point, the system automatically retrieves the repair template and generates a "patch plan": modifying the priority value of the backup route. This plan is encapsulated into a transaction, and a corresponding rollback instruction is generated. After a successful pre-check in `Dry-run` mode, the system applies the patch to the digital twin model and triggers secondary verification.

[0194] If the secondary verification passes, the complete and corrected configuration instructions (including the correct configuration of ACLs and two routes) will be sent sequentially to the actual firewall and router. After the sending is completed, the driver agent will initiate a lightweight probe packet in the real network for final confirmation. Once confirmed, the change session will be closed.

[0195] In S506, all data from the entire session, from intent input to successful execution, including clarifying questions and answers, decision DAGs, verification counterexamples, and fixes, is packaged and archived, abstracted into a reusable "three-tier architecture access template." Future similar requests can directly invoke this template, significantly reducing planning and verification time.

[0196] The above implementation methods not only avoid the risks of manual configuration such as misoperation, missing rules, and policy conflicts, but also compress the complex process that originally required engineers to manually log in to multiple devices from multiple vendors and execute a series of complex command-line operations, which originally took several days, into an automated change process that takes minutes. Through a closed-loop management mechanism of intent parsing, intelligent planning, digital twin verification, and transactional distribution, the automated change of access control permissions is realized, which greatly improves the efficiency and agility of network changes.

[0197] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0198] The embodiments of this application also provide an access permission change system, which is used to implement the above embodiments and preferred embodiments, and will not be repeated hereafter.

[0199] Figure 6 This is a structural block diagram of a system for changing access permissions according to an embodiment of this application, such as... Figure 6 As shown, the system is deployed in, for example Figure 5The control plane shown includes: a specification clarification module for receiving change requests sent by the target account, wherein the change request is for requesting changes to access permissions between nodes in the target network; a resource snapshot construction module for receiving network status of nodes in the target network collected by at least one agent, wherein each agent in the at least one agent is deployed in a different fault domain; and generating a resource snapshot based on the network status, wherein the resource snapshot includes a topology map describing the network architecture of the target network, the topology map including multiple topology points and multiple topology edges, the topology points being set with the identity identifier, node type, and fault domain to which the topology point belongs, and the topology edges connecting two topology points being set with... The system includes: a link attribute information between two topology points; a planning and decision module, used to determine the target forwarding path based on change requests and resource snapshots, generate configuration instructions based on the target forwarding path, and generate a decision-oriented directed acyclic graph (DAG) after determining the target forwarding path. The decision-oriented DAG includes the selected and unselected paths during the determination of the target forwarding path, as well as the reasons for the selection or non-selection of the paths; and a fault verification module, used to generate at least one test case based on the configuration instructions, obtain a test case set, and verify the configuration instructions using the test case set to obtain the verification result of the configuration instructions. If the configuration instructions pass the verification, the network state of the target network is changed using the configuration instructions.

[0200] As an optional implementation, the above-mentioned clarification specification module is further configured to: map the entities in the change request to the corresponding target slots according to the slot table; determine the confidence vector of the target slot, the confidence vector including at least one of the following: matching degree and completeness, the matching degree is used to indicate the degree of matching between the entity and the target slot, and the completeness is used to indicate whether the entity on the target slot is missing; and generate a target network configuration in a preset format based on the confidence vector.

[0201] As an optional implementation, the system further includes: an optimization self-healing module, used to obtain negative examples of failures in the digital twin network and / or faulty network when the configuration instruction verification fails, to obtain at least one target negative example, and to determine the faulty node in the target network based on the at least one target negative example, to obtain the fault point; to generate a target repair strategy for the fault point based on the fault point; and to repair the fault point through the target repair strategy, wherein the digital twin network is a network constructed based on resource snapshots, the faulty network is a network generated after fault injection into the digital twin network, and the negative example is a test case generated based on network configuration instructions to verify the isolation between nodes.

[0202] As an optional implementation, Figure 7 This is an architecture diagram of an intent-driven cloud network orchestration and self-healing system according to embodiments of this application, such as... Figure 7As shown, the system is mainly divided into five core modules: intent clarification and normalization module, resource snapshot and constraint graph construction module, hierarchical planning and interpretable decision-making module, automatic verification and fault injection module, and closed-loop optimization and self-healing orchestration module. Among them:

[0203] The intent clarification and normalization module (i.e., the clarification and normalization module) is a semantic gateway for human-computer interaction. Its core responsibility is to transform ambiguous natural language or non-standardized work order requirements (i.e., change requests) into a structured intent model (i.e., target network configuration) that the system can understand and compute.

[0204] Internally, the module maintains a slot table specific to the network domain. For example, for a "communication" intent, the slots that must be filled (i.e., the target slots) include "source endpoint," "destination endpoint," "protocol type," and "port range." When a user inputs a request, the natural language processing component attempts to extract entities and fill these slots. Simultaneously, to quantify uncertainty, the system associates a confidence vector with the filling result for each slot. This vector contains two dimensions: [matching degree, completeness]. If the user inputs "allow the web server to access the database," the system identifies that "web server" corresponds to several subnets, but "database" may have two clusters (primary and backup). In this case, the uniqueness confidence of the "destination endpoint" slot is low.

[0205] Before the intent is issued, the module also uses its built-in rule engine to perform logical validation on the slot content (i.e., the entities within the target slot). For example, if a user simultaneously requests "A and B are completely isolated" and "A accesses B through port 80", the rule table will immediately identify the semantic conflict between "isolation" and "interoperability". In addition, the module is also responsible for checking for implicit conflicts in the intent, such as whether the IP address range requested by the tenant overlaps with the existing management network segment, or whether the requested bandwidth quota exceeds the tenant's total quota limit.

[0206] When a slot is detected to be missing (e.g., no port is specified) or the confidence level is lower than a preset threshold, the module will not guess the user's intention. Instead, it will generate a minimal set of clarification questions (i.e., target prompt messages) based on a decision tree, such as "We have detected that you have two database clusters (production / test). Which one are you referring to?" This interactive clarification mechanism explicitly quantifies and eliminates the ambiguity of natural language at the entry point, preventing subsequent planning from being based on incorrect assumptions and thus reducing the risk of changes.

[0207] The Resource Snapshot and Constraint Graph Construction Module (i.e., the Snapshot Construction Module) is responsible for integrating fragmented resource information from the physical and virtual worlds into a unified logical model capable of mathematical reasoning.

[0208] Network topology is modeled using directed weighted graphs from graph theory, where nodes (topology points) represent physical switches, virtual routers, firewalls, or servers; edges (topology edges) represent physical links or logical tunnels (such as VXLAN tunnels). Each node and edge is accompanied by rich attribute labels, including fault domain identifiers (used to determine whether devices share power or racks), bandwidth capacity, VLAN / VNI pools, etc. This graph structure supports rapid path search and connectivity analysis by the system.

[0209] Meanwhile, to efficiently manage massive amounts of discrete resources (such as IP addresses, MAC addresses, and VLAN IDs), the module introduces advanced data structures. For IP address management, a compressed prefix tree is used. This structure allows the system to complete the longest prefix match in O(k) time complexity (where k is the address length), quickly determining whether an IP address is already occupied or whether two subnets have an inclusion relationship. For continuous numerical resources such as VLAN IDs or port numbers, a range tree is used. This enables the system to quickly find free continuous ranges, avoid fragmented resource allocation, and quickly locate range overlap conflicts.

[0210] Furthermore, to support rapid impact surface analysis, the system establishes an inverted index from "resource" to "intent". For example, the index entry Switch-A->{Intent-1, Intent-5} indicates that switch A carries an intent. Figure 1 Harmony Figure 5 When Switch-A malfunctions or requires maintenance, the system can immediately determine which business intents will be affected by looking up a table, without having to traverse tens of thousands of intent records across the entire network. This design reduces the complexity of large-scale resource checks from a full traversal to local computation of the affected subgraph, greatly improving system performance.

[0211] The hierarchical planning and interpretable decision module (i.e., the planning decision module) is the core computing engine of the system, responsible for transforming standardized intentions into specific network configuration instructions. In this application, to ensure the quality and maintainability of the planning, this module adopts a hierarchical solution and a full-link decision recording mechanism.

[0212] The layered solution employs a two-stage strategy. The first stage is logical skeleton generation. In this stage, the system does not focus on specific IP addresses or port numbers, but rather determines the macroscopic network architecture. For example, it determines whether the tenant's network model is a VPC isolation model or a flattened Layer 2 model, whether the egress strategy is centralized NAT or distributed floating IP, and the redundancy level (such as "dual-active" or "primary / backup"). The output of this stage is a logical topology template (i.e., the target network architecture). The second stage is physical resource mapping. Based on the logical skeleton, the system performs specific resource allocation on frozen resource snapshots. This includes selecting conflict-free network segments from the address pool using a range tree algorithm, and calculating physical forwarding paths (i.e., candidate forwarding paths) based on Dijkstra's algorithm or the K-shortest path algorithm. During path calculation, fault domain constraints are strictly followed to ensure that the primary / backup path (i.e., the target forwarding path) does not pass through the same physical risk point (such as a core switch).

[0213] The end-to-end decision recording mechanism addresses the issue of unreliability in the "black box" decisions of AI or automated systems by maintaining a directed acyclic graph (DAG). Each step in the planning process is recorded as a node. For example, node A records "choosing path P1," its parent node B records "because path P2 has insufficient bandwidth (evidence: interface utilization > 90%)," and its parent node C records "because path P3 violates isolation constraints (evidence: Intent-ID-101 requires isolation)," and so on. This structure makes the planning result not just a set of configurations, but a complete "reasoning report." Operations personnel can trace why the system allocated a particular IP address and why it followed a specific path, thus achieving explainable network operations.

[0214] The automatic verification and fault injection module (i.e., the fault verification module) is responsible for objectively verifying the network status before changes are implemented or after a fault occurs, ensuring that actual behavior matches intentions. Figure 1 To.

[0215] The module compiles abstract intents into an executable set of verification tasks. For interoperability intents, it generates positive reachability test cases (such as Ping tests and TCP port connections); for isolation intents, it generates negative unreachability test cases (ensuring that Ping fails). This verification task not only verifies connectivity between two points but also includes path compliance checks (such as whether traffic passes through a specified firewall). Utilizing the aforementioned constraint inverted index, it generates a minimum coverage test set to cover the most logical paths with the fewest probes.

[0216] Simultaneously, during the verification process, a virtual network model is first constructed in memory using the collected snapshot data to obtain a digital twin model. This digital twin model then simulates the transmission of data packets in the network using formal verification methods (such as header space analysis). Afterward, if the digital twin verification passes, the agent will perform low-frequency probe packet transmission in the real network. The system simultaneously monitors the probe results; if it detects a "should be connected but not" or "should be disconnected but not," it immediately determines the verification as failed and captures the routing table and flow table states at that moment as evidence.

[0217] Furthermore, for high availability purposes, simply verifying the current state is insufficient. The module automatically derives a fault scenario graph (i.e., a faulty network) based on the topology, simulating scenarios such as "core switch A power failure," "fiber optic L1 disconnection," and "tunnel endpoint VTEP failure." For each fault scenario, a restricted recalculation is performed in the digital twin model, assuming the component fails and recalculating the reachability of the remaining topology. If a critical business path is interrupted under a fault scenario and there is no alternative path, the system will issue a high availability risk warning, not just a current connectivity report.

[0218] The closed-loop optimization and self-healing orchestration module (i.e., the optimization and self-healing module) is responsible for transforming the problems discovered during verification into executable repair solutions.

[0219] When verification fails, the module utilizes negative example traces (such as packets being dropped in Switch-C) and, combined with the context in the decision DAG, searches for solutions (i.e., candidate repair strategies) in the built-in rule base (i.e., the preset rule base) and the historical case vector index. If the negative example indicates that it is due to ACL rule blocking, the repair template retrieved by the system may be to correct the ACL entry; or if the negative example indicates that it is due to a routing black hole, the template may be to reroute or restart the BGP session.

[0220] Since there is usually more than one remediation plan generated, the module will use a multi-objective sorting function to evaluate the candidate plans. The evaluation dimensions include: impact (i.e. whether the remediation operation will affect other unrelated tenants), change volume (i.e. how many instructions need to be issued), risk level (i.e. whether the operation involves core layer devices), etc.; and then select the plan with the highest comprehensive score to generate a patch plan (i.e. target remediation strategy). The execution of the patch plan is encapsulated as an atomic transaction.

[0221] In addition, the module will automatically generate a corresponding rollback plan before deployment. During execution, if an anomaly or secondary verification fails, a rollback will be triggered immediately to restore the network state to the last known good state recorded in the snapshot, ensuring that the self-healing operation will not cause a larger failure.

[0222] Optionally, in order to ensure the high performance and stability of large-scale systems, the architecture design of this system strictly follows the principle of decoupling data paths and control paths.

[0223] Optionally, as a core component of cloud infrastructure, this system must possess extremely high fault tolerance and stability, including:

[0224] Split-brain and Concurrency Contention Handling: In multi-tenant concurrent change scenarios, resource contention may occur (e.g., two tenants simultaneously requesting the same IP segment). Therefore, the system implements optimistic concurrency control at the tenant domain level, maintaining a version number for each tenant's configuration. Simultaneously, when committing a change transaction, the system compares the current snapshot version with the version used during planning. If it detects a shift in the underlying topology (e.g., a port became invalid during planning), the commit will fail, and the system will automatically trigger a baseline re-implementation process, replaying the planning logic on the new snapshot to ensure that configurations are not forcibly implemented on outdated views.

[0225] Network Jitter and Verification Storm Suppression: Network jitter can lead to a surge in alarms and verification requests, creating a storm. Therefore, the system categorizes verification tasks into three levels: critical path, high priority, and normal. When system load is high, verification of the critical path is prioritized. Simultaneously, for low-risk repetitive verification requests (such as multiple ping checks on the same link within one minute), the system performs downsampling or direct deduplication, reusing the most recent verification result. Furthermore, when the control plane is unreachable, the agent writes logs to a local circular buffer. This ensures that after communication is restored, the agent does not dump all logs at once, but first sends a digest. The control center then retrieves key evidence as needed based on the digest, avoiding bandwidth congestion.

[0226] Service unavailability: If the central database or message queue fails, the agent automatically switches to local snapshot mode, maintaining basic connectivity monitoring and read-only verification functions, but not accepting new change commands. New state change data is placed in the local persistent queue, with each message having an expiration time. Once the service is restored, these messages are replayed in the transaction sequence. If a message has expired (indicating the state may have changed again), it is discarded and a full synchronization is triggered. If data corruption is detected during recovery, the system automatically rolls back to the most recent consistency checkpoint and alerts for manual intervention.

[0227] Optionally, the system design considers a smooth transition from traditional operations and maintenance (O&M) to intelligent O&M. Initially, during deployment, the system can function as a passive observer. It connects to the network, generates planning suggestions and verification reports, but does not directly distribute configurations. O&M personnel can review the reports to confirm the accuracy of the system's judgments. The system's complete mechanism (planning, verification, and self-healing) can run in an offline environment or a small-scale sandbox. This allows users to conduct full-process rehearsals in a "shadow network" before major changes go live. It also supports gradually enabling automatic execution by tenant or network region, achieving canary deployments.

[0228] Secondly, in order to quantify the system's performance, the following core metrics were defined:

[0229] Planning convergence complexity: measures the number of computational steps required to translate intent into configuration. The optimization goal is to make it linear or near-linear (rather than exponential) with network size.

[0230] Resource conflict rate: The frequency of resource contention during the statistical planning phase, used to optimize the interval tree allocation algorithm.

[0231] Incremental patch size: Measures the granularity of self-healing repairs. The smaller the metric, the more precise the repair and the less disruption to the system.

[0232] Verification coverage: The calculation formula is "(number of covered constraints × number of covered fault scenarios) / total number of logical paths". This indicator directly reflects the security level of the network.

[0233] Minimalism of counterexamples: This measures whether the counterexample path is concise enough. Ideally, a counterexample should only contain the necessary nodes that lead to the error, making it easy to locate the problem quickly.

[0234] Closed-loop iteration count: The number of "plan-execute-verify" cycles required from problem discovery to successful verification. Ideally, it should be 1 time; multiple iterations indicate that the fix has side effects.

[0235] Rollback success rate: The probability of successfully restoring to the previous stable state when a change fails, with a target of 100%.

[0236] For a description of the features in the embodiment corresponding to the access permission change system, please refer to the relevant description in the embodiment corresponding to the access permission change method, which will not be repeated here.

[0237] Embodiments of this application also provide an access permission changing device for implementing the above embodiments and preferred embodiments, which will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0238] Figure 8 This is a structural block diagram of an access permission changing device according to an embodiment of this application, such as... Figure 8 As shown, the device includes: a receiving module 802, used to receive a change request sent by a target account, wherein the change request is used to request changes to access permissions between nodes in the target network; an acquisition module 804, used to acquire a resource snapshot of the target network, wherein the resource snapshot is used to indicate the topology and resource status of the target network; a generation module 806, used to generate configuration instructions based on the change request and the resource snapshot, and to verify the configuration instructions; and a configuration module 808, used to configure the nodes in the target network based on the configuration instructions, in order to change the access permissions between nodes in the target network, if the verification is successful.

[0239] In an exemplary embodiment, the apparatus is further configured to map entities in a change request to multiple parameter fields of a preset configuration template; determine the confidence vector of each parameter field in the multiple parameter fields based on the entities mapped to the multiple parameter fields, thereby obtaining multiple confidence vectors, wherein the confidence vectors include matching degree and completeness, the matching degree being used to indicate the degree of matching between the entity and the parameter field, and the completeness being used to indicate whether the entity in the parameter field is missing; and modify the change request according to the multiple confidence vectors to generate a target network configuration.

[0240] In an exemplary embodiment, the above-described apparatus is further configured to map entities in a change request to corresponding target slots according to a slot table; determine a confidence vector for the target slot, wherein the confidence vector includes at least one of the following: matching degree and completeness, the matching degree being used to indicate the degree of matching between the entity and the target slot, and the completeness being used to indicate whether the entity on the target slot is missing; and generate configuration instructions based on the confidence vector and resource snapshots.

[0241] In an exemplary embodiment, the above-described apparatus is further configured to determine whether an entity on a target slot needs correction based on a confidence vector; if correction is determined to be required, send a target prompt message, wherein the target prompt message instructs a target account to confirm the entity on the target slot; generate a target network configuration in a preset format based on the target account's response to the target prompt message; and generate configuration instructions based on the target network configuration and resource snapshots.

[0242] In one exemplary embodiment, the above-described apparatus is further configured to perform at least one of the following: determining that an entity in the target slot needs correction when the confidence vector of the target slot is less than a confidence threshold; determining that an entity in the target slot needs correction when the confidence vector of the target slot is greater than or equal to the confidence threshold, but the entity in the target slot conflicts with historical access permissions in the target network; wherein, a confidence vector less than the threshold includes a matching degree less than a matching degree threshold and / or a completeness less than a completeness threshold, and a confidence vector greater than or equal to the confidence threshold includes a matching degree greater than or equal to the matching degree threshold and a completeness greater than or equal to the completeness threshold.

[0243] In an exemplary embodiment, the above-described apparatus is further configured to determine a target network architecture that matches the target network configuration in a preset network architecture; determine a target forwarding path based on a resource snapshot and the target network architecture; and generate configuration instructions based on the target forwarding path.

[0244] In an exemplary embodiment, the above-described apparatus is further configured to determine the node type of at least one node that the forwarding path needs to pass through, and the sorting of the node types, based on the target network architecture; to parse candidate forwarding paths from a resource snapshot according to the node types and the sorting of the node types, thereby obtaining a set of candidate forwarding paths; and to determine the target forwarding path from the set of candidate forwarding paths according to preset conditions.

[0245] In an exemplary embodiment, the apparatus is further configured to perform matching in the resource snapshot according to the node type, determine candidate nodes that match the node type, and obtain a candidate node set; traverse the candidate node set according to the sorting of node types to generate multiple forwarding paths; determine invalid paths among the multiple forwarding paths based on the topology and resource status recorded in the resource snapshot, wherein invalid paths include at least one of the following: forwarding paths where the links between nodes are shown as abnormal in the topology, and forwarding paths where the resource status shows that the resources allocated in the target network conflict with the resources required by the path; and determine the forwarding paths other than invalid paths among the multiple forwarding paths as candidate forwarding paths.

[0246] In an exemplary embodiment, the above-described apparatus is further configured to determine the N shortest candidate forwarding paths in the candidate forwarding path set as the target forwarding path, where N is an integer greater than 0; or, to determine the N candidate forwarding paths that occupy the least resources in the candidate forwarding path set as the target forwarding path, where N is an integer greater than 0; wherein, when N is greater than 1, the fault domain isolation requirements are met among the forwarding paths in the N candidate forwarding paths.

[0247] In an exemplary embodiment, the apparatus is further configured to generate at least one access control rule based on the target forwarding path and the target network configuration; determine the unoccupied access control rule identifiers of each node in the access control list of at least one node included in the target forwarding path to obtain at least one target access control rule identifier; establish a target mapping relationship between at least one access control rule and at least one target access control rule identifier; and generate configuration instructions based on the target mapping relationship.

[0248] In an exemplary embodiment, the above-described apparatus is further configured to generate a decision directed acyclic graph after determining the target forwarding path based on the resource snapshot and the target network architecture, wherein the decision directed acyclic graph includes paths selected and not selected during the determination of the target forwarding path, and the reasons for the paths being selected or not selected.

[0249] In an exemplary embodiment, the apparatus is further configured to receive network status of nodes in a target network collected by at least one agent, wherein each agent in the at least one agent is deployed in a different fault domain; generate a resource snapshot based on the network status, wherein the resource snapshot includes a topology map describing the network architecture of the target network, the topology map including multiple topology points and multiple topology edges, the topology points being configured with the identity identifier, node type and fault domain of the node represented by the topology point, and the topology edges connecting two topology points being configured with link attribute information between the two topology points.

[0250] In an exemplary embodiment, the above-described apparatus is further configured to generate at least one test case based on the configuration instruction to obtain a test case set, wherein the test case set includes positive examples and negative examples, the positive examples being test cases used to verify inter-node interoperability, and the negative examples being test cases used to verify inter-node isolation; the configuration instruction is verified through the test case set to obtain the verification result of the configuration instruction.

[0251] In an exemplary embodiment, the above-described apparatus is further configured to construct a digital twin network of the target network based on a resource snapshot; inject faults into the digital twin network to obtain a faulty network; and run each test case in the test case set in the digital twin network and the faulty network respectively to obtain the verification results of the configuration instructions.

[0252] In one exemplary embodiment, the above-described apparatus is further configured to perform at least one of the following: determining that the configuration instruction verification failed when at least one test case fails to run in the digital twin network; determining that the configuration instruction verification failed when at least one test case fails to run in the faulty network.

[0253] In an exemplary embodiment, the apparatus is further configured to, in the event that the configuration instruction verification fails, obtain a negative example of failure in the digital twin network and / or the faulty network, and obtain at least one target negative example, wherein the digital twin network is a network constructed based on a resource snapshot, the faulty network is a network generated after fault injection into the digital twin network, and the negative example is a test case generated based on the network configuration instruction to verify the isolation between nodes; determine the node that has failed in the target network based on the at least one target negative example, and obtain the fault point; generate a target repair strategy for the fault point based on the fault point; and repair the fault point through the target repair strategy.

[0254] In an exemplary embodiment, the apparatus is further configured to determine the target cause of the failure at the fault point based on the decision directed acyclic graph; determine at least one candidate repair strategy based on the target cause in a preset rule base and / or historical cases; analyze the degree of influence of the at least one candidate repair strategy on the target network in multiple dimensions, and obtain the score of each candidate repair strategy among the at least one candidate repair strategy; and determine the candidate repair strategy with the highest score as the target repair strategy.

[0255] In an exemplary embodiment, the above-described apparatus is further configured to verify the configuration instructions by means of a set of test cases after the fault point has been repaired by the target repair strategy, wherein the set of test cases includes at least one test case generated based on the configuration instructions; and if the configuration instructions are verified to be valid, the nodes in the target network are configured by means of the configuration instructions.

[0256] For a description of the features in the embodiment corresponding to the access permission changing device, please refer to the relevant description in the embodiment corresponding to the access permission changing method, which will not be repeated here.

[0257] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described methods for changing access permissions.

[0258] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described methods for changing access permissions when run.

[0259] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0260] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for changing access permissions.

[0261] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described methods for changing access permissions.

[0262] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0263] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0264] The above provides a detailed description of a method and system for changing access permissions provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method of changing access rights, characterized by, include: Receive a change request sent by the target account, wherein the change request is used to request a change in access permissions between nodes in the target network; Obtain a resource snapshot of the target network, wherein the resource snapshot is used to indicate the topology and resource status of the target network; Based on the change request and the resource snapshot, a configuration instruction is generated, and the configuration instruction is verified. If the verification is successful, the nodes in the target network are configured based on the configuration instructions to change the access permissions between the nodes in the target network.

2. The access right change method according to Claim 1, wherein Based on the change request and the resource snapshot, configuration instructions are generated, including: Map the entities in the change request to the corresponding target slots according to the slot table; Determine the confidence vector of the target slot, wherein the confidence vector includes at least one of the following: matching degree and completeness, wherein the matching degree is used to represent the degree of matching between the entity and the target slot, and the completeness is used to represent whether the entity in the target slot is missing; The configuration instructions are generated based on the confidence vector and the resource snapshot.

3. The access right change method according to Claim 2, wherein The configuration instructions are generated based on the confidence vector and the resource snapshot, including: Based on the confidence vector, determine whether the entity in the target slot needs to be corrected; If it is determined that correction is needed, a target prompt message is sent, wherein the target prompt message instructs the target account to confirm the entity on the target slot; Based on the target account's response to the target prompt message, a target network configuration in a preset format is generated; Configuration instructions are generated based on the target network configuration and the resource snapshot.

4. The method for changing access permissions according to claim 3, characterized in that, Determining whether an entity in the target slot needs correction based on the confidence vector includes at least one of the following: If the confidence vector of the target slot is less than the confidence threshold, it is determined that the entity in the target slot needs to be corrected. If the confidence vector of the target slot is greater than or equal to the confidence threshold, but the entity on the target slot conflicts with the historical access permissions in the target network, it is determined that the entity on the target slot needs to be corrected. Wherein, the confidence vector being less than a threshold includes the matching degree being less than the matching degree threshold, and / or the completeness being less than the completeness threshold; the confidence vector being greater than or equal to the confidence threshold includes the matching degree being greater than or equal to the matching degree threshold, and the completeness being greater than or equal to the completeness threshold.

5. The method for changing access permissions according to claim 3, characterized in that, Based on the target network configuration and the resource snapshot, configuration instructions are generated, including: Determine the target network architecture that matches the target network configuration within the preset network architecture; Determine the target forwarding path based on the resource snapshot and the target network architecture; The configuration instructions are generated based on the target forwarding path.

6. The method for changing access permissions according to claim 5, characterized in that, Determining the target forwarding path based on the resource snapshot and the target network architecture includes: Based on the target network architecture, determine the node type of at least one node that the forwarding path needs to pass through, and the order of the node types; Based on the node type and the sorting of the node types, candidate forwarding paths are parsed from the resource snapshot to obtain a set of candidate forwarding paths; The target forwarding path is determined from the set of candidate forwarding paths according to preset conditions.

7. The method for changing access permissions according to claim 6, characterized in that, Candidate forwarding paths are resolved from the resource snapshot based on the node type and the sorting of the node types, including: Based on the node type, a matching process is performed in the resource snapshot to determine candidate nodes that match the node type, thus obtaining a candidate node set. Based on the sorting of the node types, the candidate node set is traversed to generate multiple forwarding paths; Based on the topology and resource status recorded in the resource snapshot, invalid paths are determined among the multiple forwarding paths. The invalid paths include at least one of the following: forwarding paths where the links between nodes are shown as abnormal in the topology, and forwarding paths where the resource status shows that the resources allocated in the target network conflict with the resources required by the path. The forwarding paths other than the invalid paths among the multiple forwarding paths are determined as the candidate forwarding paths.

8. The method for changing access permissions according to claim 6, characterized in that, The target forwarding path is determined from the set of candidate forwarding paths according to preset conditions, including: The N shortest candidate forwarding paths in the candidate forwarding path set are determined as the target forwarding path, where N is an integer greater than 0; or, The N candidate forwarding paths that occupy the least resources in the candidate forwarding path set are determined as the target forwarding path, where N is an integer greater than 0; Where N is greater than 1, the fault domain isolation requirements are met among the N candidate forwarding paths.

9. The method for changing access permissions according to claim 5, characterized in that, The configuration instruction is generated based on the target forwarding path, including: Generate at least one access control rule based on the target forwarding path and the target network configuration; In the access control list of at least one node included in the target forwarding path, determine the unoccupied access control rule identifiers of each node in the at least one node to obtain at least one target access control rule identifier. Establish a target mapping relationship between the at least one access control rule and the at least one target access control rule identifier; The configuration instructions are generated based on the target mapping relationship.

10. The method for changing access permissions according to claim 5, characterized in that, After determining the target forwarding path based on the resource snapshot and the target network architecture, the method further includes: Generate a directed acyclic graph of decisions, wherein the directed acyclic graph of decisions includes selected and unselected paths in the process of determining the target forwarding path, and the reasons for the selection or non-selection of the path.

11. The method for changing access permissions according to claim 1, characterized in that, Obtaining a resource snapshot of the target network includes: Receive network status of nodes in the target network collected by at least one agent, wherein each agent in the at least one agent is deployed in a different fault domain; The resource snapshot is generated based on the network status. The resource snapshot includes a topology map describing the network architecture of the target network. The topology map includes multiple topology points and multiple topology edges. The topology points are configured with the identity identifier, node type, and fault domain of the node represented by the topology point. The topology edges connecting two topology points are configured with the link attribute information between the two topology points.

12. The method for changing access permissions according to claim 1, characterized in that, Verification of the configuration instructions includes: At least one test case is generated based on the configuration instructions to obtain a test case set, wherein the test case set includes positive examples and negative examples, the positive examples are test cases used to verify the interoperability between nodes, and the negative examples are test cases used to verify the isolation between nodes; The configuration instructions are verified using the set of test cases to obtain the verification results.

13. The method for changing access permissions according to claim 12, characterized in that, The configuration instructions are verified using the set of test cases to obtain the verification results, including: Construct a digital twin network of the target network based on the resource snapshot; Fault injection is performed on the digital twin network to obtain a faulty network; Each test case in the test case set is run in the digital twin network and the faulty network respectively to obtain the verification results of the configuration instructions.

14. The method for changing access permissions according to claim 13, characterized in that, Each test case in the test case set is run in the digital twin network and the faulty network respectively to obtain the verification result of the configuration instruction, including at least one of the following: If at least one test case fails to run in the digital twin network, it is determined that the configuration instruction verification has failed. If at least one test case fails to run in the faulty network, it is determined that the configuration instruction verification has failed.

15. The method for changing access permissions according to claim 1, characterized in that, The method further includes: If the configuration instruction verification fails, obtain a negative example that fails to run in the digital twin network and / or faulty network, and obtain at least one target negative example, wherein the digital twin network is a network built based on the resource snapshot, the faulty network is a network generated after fault injection into the digital twin network, and the negative example is a test case generated based on the network configuration instruction to verify the isolation between nodes. Based on the at least one target negative example, the node that has failed in the target network is determined to be the fault point; Generate a target repair strategy for the fault point based on the fault point; The fault point is repaired using the target repair strategy.

16. The method for changing access permissions according to claim 15, characterized in that, Based on the fault point, a target repair strategy for the fault point is generated, including: The target cause of the failure at the fault point is determined based on the decision directed acyclic graph; Based on the target cause, at least one candidate repair strategy is determined from the preset rule base and / or historical cases; Analyze the impact of the at least one candidate repair strategy on the target network in multiple dimensions, and obtain the score of each candidate repair strategy among the at least one candidate repair strategy; The candidate repair strategy with the highest score is determined as the target repair strategy.

17. The method for changing access permissions according to claim 15, characterized in that, After repairing the fault point using the target repair strategy, the method further includes: The configuration instructions are verified using a set of test cases, wherein the set of test cases includes at least one test case generated based on the configuration instructions. If the configuration command is verified successfully, the nodes in the target network are configured using the configuration command.

18. A system for changing access permissions, characterized in that, include: The clarification specification module is used to receive change requests sent by the target account, wherein the change request is used to request changes to the access permissions between nodes in the target network; A snapshot building module is used to receive network status of nodes in the target network collected by at least one agent, and generate a resource snapshot based on the network status, wherein each agent in the at least one agent is deployed in a different fault domain, and the resource snapshot is used to indicate the topology and resource status of the target network. The planning and decision module is used to determine the target forwarding path based on the change request and the resource snapshot, generate configuration instructions based on the target forwarding path, and generate a decision directed acyclic graph after determining the target forwarding path. The decision directed acyclic graph includes the paths selected and not selected during the process of determining the target forwarding path, as well as the reasons for the paths being selected or not selected. The fault verification module is used to generate at least one test case based on the configuration instruction, obtain a test case set, and verify the configuration instruction through the test case set to obtain the verification result of the configuration instruction. If the configuration instruction passes the verification, the network state of the target network is changed through the configuration instruction.

19. The access permission change system according to claim 18, characterized in that, The clarification specification module is also used for: Map the entities in the change request to the corresponding target slots according to the slot table; Determine the confidence vector of the target slot, the confidence vector including at least one of the following: matching degree and completeness, the matching degree being used to represent the degree of matching between the entity and the target slot, and the completeness being used to represent whether the entity in the target slot is missing; A target network configuration in a preset format is generated based on the confidence vector.

20. The access permission modification system according to claim 18, characterized in that, The system also includes: The self-healing module is optimized to obtain at least one target negative example of failure in the digital twin network and / or faulty network when the configuration instruction verification fails. Based on this target negative example, the module identifies the faulty node in the target network, thus obtaining the fault point. A target repair strategy is generated based on the fault point. The fault point is then repaired using the target repair strategy. The digital twin network is constructed based on the resource snapshot, the faulty network is generated after fault injection into the digital twin network, and the negative example is a test case generated based on network configuration instructions to verify the isolation between nodes.

Images