A method, system, and medium for automatic configuration of a switch

Abstract

The present application relates to the field of electric communication technology, and more particularly to a switch automatic configuration method, system and medium. The method comprises the following steps: obtaining switch resource configuration data, and performing semantic enhancement topology graph modeling to obtain a network environment digital twin model; based on the network environment digital twin model and a preset configuration management database, configuration instruction analysis is performed to obtain an intent configuration semantic set; based on the configuration strategy path of the intent configuration semantic set, multi-vendor semantic mapping arrangement is performed to obtain a native configuration command set; identity path integrity audit is performed on each configuration command in the native configuration command set to obtain a verified signed command set; the verified signed command set is uploaded to a switch management platform to execute the command; real-time behavior state data of the switch is obtained, and semantic deviation calculation is performed to obtain a configuration result report. The present application helps to improve the effectiveness and adaptability of switch configuration.

Description

Technical Field

[0001] This invention relates to the field of telecommunications technology, and in particular to an automatic configuration method, system and medium for a switch. Background Technology

[0002] As a key component of network equipment, switches undertake important functions such as network data forwarding, path selection, and access control. To ensure the stable operation and efficient communication of the network system, each switch needs to be configured with appropriate parameters, including but not limited to port allocation, VLAN segmentation, IP address allocation, routing policy settings, security policy activation, and device identification information entry. In actual deployment, due to the complexity of network topology, the variety of equipment, and diverse service requirements, manual configuration is not only inefficient but also prone to configuration errors, conflicts, or omissions, severely restricting network deployment efficiency and stability.

[0003] Traditional switch configuration methods primarily rely on manual operation. Network administrators log into each switch individually via a control terminal and manually enter configuration commands based on a pre-designed network plan. In large-scale network scenarios, hundreds of switches need to be configured one by one, which is time-consuming, labor-intensive, and severely delays network construction. Manually entering commands is also susceptible to the influence of the operator's experience level and execution habits. Different administrators may produce inconsistent command styles or misunderstandings of parameters, leading to inconsistent configuration results and increasing the difficulty of subsequent maintenance. Summary of the Invention

[0004] Therefore, it is necessary for the present invention to provide an automatic configuration method, system and medium for switches to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, an automatic configuration method for a switch includes the following steps:

[0006] Step S1: Obtain switch resource configuration data, and perform semantically enhanced topology graph modeling based on the switch resource configuration data to obtain a digital twin model of the network environment;

[0007] Step S2: Based on the network environment digital twin model and the preset configuration management database, perform network configuration context reasoning to obtain the network configuration intent graph; parse the network configuration intent graph for configuration instructions, and perform executable configuration semantic mapping on the instruction parsing results to obtain the intent configuration semantic set;

[0008] Step S3: Based on the configuration strategy path of the intent configuration semantic set, perform intermediate configuration strategy set transformation to obtain intermediate configuration topology matrix, and perform multi-vendor semantic mapping orchestration on intermediate configuration topology matrix to obtain native configuration command set;

[0009] Step S4: Perform minimum trust unit verification on each configuration command in the original configuration command set to obtain a fine-grained permission verification command set; perform identity path integrity auditing based on the fine-grained permission verification command set to obtain a verified signature command set;

[0010] Step S5: Upload the verified signature command set to the switch management platform to execute the command; obtain the switch's real-time behavior status data, perform semantic deviation calculation on the switch's real-time behavior status data and intent configuration semantic set, and obtain a configuration result report.

[0011] This invention achieves unified modeling of complex network structures and heterogeneous switching devices by constructing a semantically enhanced topology graph and establishing a digital twin model of the network environment. This enables configuration operations to have global visibility and contextual understanding capabilities, effectively avoiding configuration path errors and redundant command issuance caused by insufficient topology understanding in traditional methods. Furthermore, a configuration management database is introduced for semantic-level reasoning, forming a network configuration intent graph. This transforms the configuration process from a simple stacking of commands to intent-driven, high-level semantic manipulation, thereby improving configuration accuracy and policy consistency. Through executable configuration semantic mapping, a standardized intent configuration semantic set is constructed, effectively solving problems such as inconsistent command styles and significant misunderstandings in traditional configuration, providing a semantically unified foundation for subsequent cross-vendor command generation. Utilizing an intermediate configuration topology matrix as a transitional structure not only ensures the logical correctness of policy paths but also achieves dynamic adaptation of command styles between device manufacturers through multi-vendor semantic mapping orchestration. This significantly improves the compatibility and portability of command generation, solving the problem of configuration failures caused by semantic inconsistencies in the management of multiple brand devices. Fine-grained permission verification is performed using the smallest trust unit. When evaluating the tripartite constraints of operation role matching, command scope overlap, and command sensitivity coefficient, the operation role mapping vector, nested scope tree, and sensitivity coefficient calculation model can accurately identify and block potentially risky commands in advance, improving the security level of configuration execution. The combination of setting security level labels and command operation strength for sensitivity coefficient evaluation effectively distinguishes between high-risk commands such as ACL and NAT changes and low-risk commands such as writing descriptive information, improving the accuracy of permission auditing. By setting a 30-minute context backtracking window and tracing the execution context and identity behavior trajectory of commands, accurate identification of abnormal operators can be achieved. Setting the identity node continuity tolerance threshold to 1 balances the differentiation effect between minor behavioral fluctuations and malicious jumps, while limiting the link tracing depth to 5 avoids the risk of misjudgment due to lengthy paths, thereby enhancing the timeliness and accuracy of identity behavior auditing. After completing command identity path binding and signature encryption, the system verifies the execution sequence dependencies of configuration commands. This ensures that configuration tasks are executed in the predetermined order of dependencies, preventing network function interruptions due to incorrect ordering and ensuring that the command set has structural consistency and dependency closure. Finally, by aligning and analyzing the real-time behavior status of the switch with the configuration semantics, a semantic deviation quantification model is constructed between the behavior state tensor and the expected configuration matrix. This model can evaluate the degree of configuration implementation from multiple dimensions, such as target miss rate, policy offset, and operation sequence perturbation. Setting a 5-second threshold for behavior response offset helps distinguish between normal network transmission delays and configuration execution lags, ensuring the sensitivity of deviation detection while reducing false alarms. Finally, by generating a configuration result report, the system provides a basis for subsequent network maintenance, achieving closed-loop verification and continuous optimization of configuration effectiveness.

[0012] Optionally, step S1 specifically includes:

[0013] Step S11: Obtain the device resource table and link connection table of the switch to be configured, extract the device identifier, port configuration, interface status, connection topology, VLAN division items and existing access control policies, and construct the switch resource configuration data;

[0014] Step S12: Extract semantic entities and identify topological relationships from switch resource configuration data. Use device type, interface category, and protocol support capabilities as semantic tags to construct a set of semantically labeled nodes and an initial connection relationship edge set, and generate a prototype semantically labeled topological graph.

[0015] Step S13: Enhance the topology structure based on the semantic annotation topology graph prototype, embed port configuration features in nodes, embed interface status features in edges, and link and merge the subdomain topology in VLAN division with the backbone topology of the semantic annotation topology graph prototype in a subgraph embedding manner to obtain a resource semantic enhancement topology graph.

[0016] Step S14: Perform structural normalization on the resource semantic enhancement topology graph to obtain the tensor representation enhancement graph;

[0017] Step S15: Perform network environment simulation modeling based on the tensor representation augmented graph to obtain a digital twin model of the network environment.

[0018] This invention systematically abstracts device and link information by constructing a switch resource configuration data system, achieving structured and unified modeling of the switch resource status to be configured, ensuring a complete data foundation for subsequent processing. In the semantic entity extraction stage, device type, interface category, and protocol support capabilities are introduced as semantic tags, making the semantic roles of each device in the topology more explicit, facilitating subsequent intent recognition and path reasoning. By constructing a semantically annotated topology graph prototype, a graph structure representation driven by semantic attributes is established, enhancing the semantic association capabilities in topology modeling. Furthermore, during the topology enhancement process, port configuration features and interface status features are embedded into the node and edge structures, enabling the topology graph to not only contain connectivity information but also reflect operational characteristics such as port connectivity and interface speed, providing fundamental support for network status awareness and dynamic adaptation. In addition, a subgraph embedding strategy is used to integrate the subdomain topology structure formed by VLAN partitioning into the backbone topology, preserving not only the local connection relationships within VLANs but also achieving multi-layered nested modeling of the overall network logical structure, improving the model's expressiveness in multi-domain scenarios. Structural normalization is performed on the generated resource semantic enhancement topology graph, unifying heterogeneous structures into tensor form. Node vectors are uniformly represented as configuration state feature matrices of dimension (1×128), and edge vectors are uniformly represented as interface interaction feature matrices of dimension (1×64). This ensures the model has good computational adaptability and input format consistency, providing a parallelizable processing structure for subsequent network simulation modeling. In the final constructed digital twin model of the network environment, all switch entities and their connections are represented as tensor structures, and dynamic evolution deduction can be performed in conjunction with real-time operating parameters, effectively improving the accuracy and timeliness of network configuration scheme derivation and supporting semantic mapping of subsequent complex configuration intentions. Through the above modeling strategies and parameter settings, such as limiting the node state embedding dimension to 128, computational overhead can be controlled while expressing information integrity, ensuring scalability and real-time response capabilities even in large-scale network structures.

[0019] Optionally, step S13 specifically includes:

[0020] Step S131: Extract the port configuration parameters of each device node in the semantic annotation topology graph prototype from the switch resource configuration data, construct node feature vectors, and add the node feature vectors to the representation tensor of the device nodes in a matrix embedding manner to obtain the port configuration enhanced node set;

[0021] Step S132: Extract the interface state parameters corresponding to each connection edge in the semantic annotation topology graph prototype in the switch resource configuration data, construct the edge weight vector, and embed the edge weight vector into the representation tensor of each connection edge in the weight tensor encoding method to obtain the interface state enhanced edge set.

[0022] Step S133: Traverse the VLAN segmentation items in the switch resource configuration data, extract the ports, device nodes and connection relationships associated with the VLAN segmentation items, and thus construct a local subdomain topology map;

[0023] Step S134: Map the local subdomain topology graph to the semantically labeled topology graph prototype in the form of subgraph embedding, and establish the boundary connection path between subdomain graph nodes and device nodes to obtain the linkage fusion topology structure graph.

[0024] Step S135: Merge the port configuration enhancement node set, the interface status enhancement edge set, and the linkage fusion topology diagram to obtain the resource semantic enhancement topology diagram.

[0025] This invention achieves integrated modeling of resource topology and operational parameters by embedding port configuration parameters and interface status parameters from switch resource configuration data into the representation tensors of nodes and edges in the topology graph. This transforms the network structure from a simple connectivity relationship into one with fine-grained operational characteristics that can be used for subsequent configuration decisions. When embedding node feature vectors into device node tensors in a matrix manner, a dimension of (1×128) is chosen to accommodate multiple dimensions such as port speed, status flags, and port type, ensuring descriptive capability without dimensional redundancy. The edge weight tensor encoding dimension is set to (1×64), suitable for representing key communication attributes such as interface connectivity, bandwidth utilization, and error rate, providing a reliable basis for configuration path evaluation. During the VLAN subgraph construction and embedding process, local subdomain topologies are established by extracting VLAN-belonging ports and device nodes, and cross-domain boundary mappings are established by embedding them into the backbone topology, effectively enhancing the graph structure's ability to express logically isolated structures. The subgraph embedding strategy adopts a boundary connection path mapping method, which can accurately identify the port correspondence between subdomain topologies and the main topology, improving the adaptability of the network topology in multi-tenant environments. The final fused resource semantic enhancement topology graph possesses both structural integrity and state representation capabilities, laying a solid foundation for configuration strategy path reasoning and behavior deviation detection.

[0026] Optionally, the network configuration context reasoning in step S2 specifically involves:

[0027] Historical configuration instances, policy templates, device behavior logs, and anomaly repair records are extracted from the preset configuration management database as ontology layers. The configuration rule ontology graph is constructed by modeling the correlation between the configuration semantic roles in the historical configuration instances and the policy templates.

[0028] The nodes in the digital twin model of the network environment are mapped to the configuration rule ontology graph. The semantic role labels of the nodes in the configuration rule ontology graph are extracted and the entity matching degree is evaluated, thereby constructing a configuration context entity alignment matrix.

[0029] By combining the obtained network operation and maintenance task scenarios with labeled intent targets, and by identifying subgraph regions in the configuration rule ontology graph that are related to the current intent target, a configuration intent path graph is constructed.

[0030] Perform semantic consistency and conflict detection on each path in the configuration intent path graph, and retain the configuration paths that pass the constraint verification to form a set of context-valid configuration paths;

[0031] Cluster and compress structurally similar paths in the set of legal configuration paths in the context, extract common semantic substructures and operation units, and generate a logical configuration unit graph.

[0032] By combining the configuration context entity alignment matrix and the logical configuration unit graph, semantic translation and encapsulation are performed to obtain the network configuration intent graph.

[0033] This invention integrates historical configuration instances, policy templates, and operation and maintenance log data into a unified configuration rule ontology graph. This structures the configuration knowledge implicit in multi-source data into a traceable and matchable semantic hierarchy, improving the systematicity and accuracy of configuration reasoning. Specifically, the correlation between configuration semantic roles and policy templates is modeled using a normalized score based on co-occurrence frequency (with a value range of 0-1), facilitating subsequent semantic path quantification analysis. In configuration context alignment, an alignment matrix is ​​constructed through cross-comparison of entity role tags and node attributes. The matrix dimension is n×m (n is the number of nodes in the environment model, and m is the number of role tags in the ontology graph). This not only supports fine-grained matching but also filters highly correlated semantic points through alignment scores, improving path construction efficiency. During intent path extraction, the semantic subgraph is retrieved by looking up the target tags in the operation and maintenance scenario, effectively reducing the search space and reasoning complexity. Semantic consistency detection of configuration paths uses a preset conflict rule table for judgment; retaining paths with a pass rate exceeding 85% ensures that configuration operations do not generate policy contradictions. Clustering compression employs a structural similarity threshold of 0.75 for merging, effectively extracting highly reusable substructures and improving the density of configuration semantic expression. Finally, a network configuration intent graph is jointly generated by a context alignment matrix and a general configuration graph, achieving dual-layer alignment of structure and semantics, and providing stable and accurate input for automatic configuration.

[0034] Optionally, the configuration instruction parsing in step S2 is specifically as follows:

[0035] Based on the path structure in the network configuration intent graph, the node sequence in each legal configuration path is sequentially structured and transformed into a triplet of operation target-scope-control condition, thereby obtaining a set of configuration operation unit sequences.

[0036] Semantically match the triples in the configuration operation unit sequence set with the control command templates in the configuration management database to generate an initial command template matching set;

[0037] The variable parameter bits existing in the initial instruction template matching set are bound and filled, and context parameters are injected according to the node attributes in the digital twin model of the network environment to obtain a structured configuration instruction set;

[0038] For each instruction in the structured configuration instruction set, semantic format transcribing is performed according to the syntax specifications of device brand and model in the configuration management database to generate a candidate set of executable commands;

[0039] Based on the candidate set of executable commands, configuration rule constraints are verified, and command fragments that do not meet the constraints are filtered out to obtain a set of structurally valid configuration commands.

[0040] Semantic disambiguation and conflict detection are performed on command entries in the structured legal configuration command set. The command sorting is optimized according to the dependency order, and duplicate configurations are removed to generate an intent configuration semantic set.

[0041] This invention constructs an executable sequence of configuration operation units by transforming the path structure in the configuration intent graph into a sequence of triplets consisting of operation targets, scopes, and control conditions, thereby enhancing the structural expression and context awareness of configuration logic. The triplet format makes the target node and control premise of each configuration operation clear and unambiguous, providing semantic support for subsequent template matching. During the matching phase, a control instruction template set from the configuration management database is introduced, and a similarity threshold of 0.7 is set to ensure that the matching results are both comprehensive and controllable against the risk of mismatches. In the parameter injection phase, attributes such as port numbers, IP segments, and VLAN numbers of nodes in the digital twin model are read and injected into variable bits according to field mapping, ensuring the consistency of the instruction context. In the semantic format transcribing phase, a dedicated syntax conversion table is used for different device brands and models to adapt to the syntax differences of mainstream devices. The transcribing logic supports switching between CLI style and structured command mode, enhancing cross-vendor adaptability. In the configuration rule constraint verification, rule items based on device configuration restrictions (such as interface reuse conflicts and ACL policy order dependencies) are introduced to effectively filter out illegal command entries and improve configuration security. The semantic disambiguation stage uses the semantic correlation threshold (set to 0.6) between the operation intent label and the parameter to assist in the determination, ensuring that the instructions do not produce ambiguity or execution conflicts. It also completes the ordering of commands and the deduplication of redundant instructions through the topology dependency sequence graph, so that the final generated intent configuration semantic set has consistency, efficiency and executability, laying a rigorous data and semantic foundation for the automatic configuration of the switch.

[0042] Optionally, step S3 specifically includes:

[0043] Step S31: Extract configuration paths from the intent configuration semantic set, parse them into configuration target pairs and path attribute constraints, and generate a structured configuration path set;

[0044] Step S32: Segment each path in the structured configuration path set according to the operation semantics to generate a policy behavior fragment table;

[0045] Step S33: Construct a node feature matrix based on the configuration semantic tags, dependency order, and resource constraints of the configuration fragments in the policy behavior fragment table, and associate nodes with the device interconnection topology of the network environment digital twin model to generate an intermediate configuration topology matrix;

[0046] Step S34: Using a preset multi-vendor configuration semantic dictionary, perform command feature template matching on the semantic vectors of each node in the intermediate configuration topology matrix to construct a vendor semantic mapping matrix;

[0047] Step S35: Based on the manufacturer semantic mapping matrix, the matched command feature templates are fused with the configuration semantic tags to reconstruct the configuration command fragments, and then integrated according to the device brand to obtain a set of configuration command fragments;

[0048] Step S36: Organize the configuration command fragment set in order, perform dependency verification and semantic consistency checks, arrange the configuration commands of each manufacturer's devices according to the execution order and logical grouping method, and generate the native configuration command set.

[0049] This invention parses the path structure of the intent configuration semantic set into configuration target pairs and attribute constraint information, forming a structured configuration path set. This enables explicit modeling of configuration logic and target association resolution, facilitating path controllability and execution verification. By segmenting the operational semantics of the configuration path into a policy behavior fragment table, the granularity of configuration targets is refined, facilitating subsequent policy reconstruction and command matching. When constructing the node feature matrix, configuration semantic tags, dependency order, and resource constraint parameters (such as ACL priority and port reuse restrictions) are introduced and combined with the topological connection relationship of the digital twin model to generate an intermediate configuration topology matrix that accurately reflects the network state and configuration logic. This intermediate configuration topology matrix provides contextual structure support for subsequent command semantic mapping. A vendor semantic mapping matrix is ​​established using a multi-vendor configuration semantic dictionary, with a matching confidence threshold of 0.75 to improve the accuracy and adaptability of command template matching. During command reconstruction, fusing command templates with semantic tags preserves the operational purpose and syntactic features, improving the semantic clarity and syntactic integrity of configuration instructions. Furthermore, device brand classification ensures syntactic compatibility of configuration fragments. During the orchestration phase, a sequence adjustment and dependency verification mechanism is introduced to automatically adjust the instruction sequence according to the topological order in the policy behavior graph to avoid configuration dependency errors. At the same time, semantic consistency checks are performed to eliminate instruction ambiguity and logical redundancy, ultimately generating a set of native configuration commands that can be directly issued and are structurally ordered, providing a standardized and highly reliable execution foundation for automated configuration deployment.

[0050] Optionally, step S4 specifically includes:

[0051] Step S41: Perform minimum trust unit division and tag extraction on each command in the native configuration command set to obtain a trust unit tag set;

[0052] Step S42: Map the trust unit tag set to the preset permission policy graph, perform ternary constraint judgment based on the operation role, command scope and device sensitivity level, and generate a fine-grained permission verification command set;

[0053] Step S43: Set the context backtracking window size to 30 minutes, backtrack and record the execution context during the command generation and distribution process for the command entries in the fine-grained permission verification command set, and generate an identity behavior context sequence;

[0054] Step S44: Construct an identity link graph using the identity behavior context sequence, and perform integrity tracing on each identity node in the identity link graph. Set the identity node continuity tolerance threshold to 1 and the deepest link tracing level to 5 to remove abnormal identity nodes and generate an audit-passed command identity path set.

[0055] Step S45: Bind the audit pass command identity path set with the fine-grained permission verification command set, and sign and encrypt each binding result to generate an identity binding signature command object set;

[0056] Step S46: Perform sequence dependency verification on the identity-bound signature command object set to generate a verified signature command set.

[0057] This invention divides the native configuration command set into minimum trust units, enabling each command to be parsed with fine granularity without sacrificing semantic integrity. This minimizes the security audit of operational units and enhances the controllability and verifiability of command behavior. After the extracted trust unit tags are mapped to the permission policy graph, a ternary constraint judgment mechanism based on operation role, command scope, and device sensitivity level is introduced. This effectively prevents high-privilege commands from being misused by low-privilege roles, ensuring consistency across multiple security policies. Setting the context backtracking window to 30 minutes covers the continuous operation cycle of most configuration tasks, facilitating the tracing of the context state of configuration commands during generation and distribution, and improving the accuracy of behavior chain reconstruction. By constructing an identity chain graph and setting the identity continuity tolerance threshold to 1 and the tracking depth to 5, it can tolerate a single discontinuous switch and effectively eliminate unauthorized identity paths, thereby achieving highly reliable auditing of command responsibility attribution. Command identity path binding and signature encryption encapsulation provide a verifiable identity integrity mechanism for the command execution process, avoiding the risks of identity forgery and man-in-the-middle tampering. Finally, a sequence dependency verification step is introduced. Under the dual protection of command sequence relationship and identity consistency, only command entries that satisfy context dependency and signature link closure are retained, fundamentally ensuring that the generated commands are auditable, trustworthy, and verifiable, providing strong support for secure configuration in the network environment.

[0058] Optionally, the semantic deviation calculation in step S5 is specifically as follows:

[0059] Extract switch behavior features from real-time switch behavior status data and construct a behavior status feature tensor.

[0060] By using historical configuration instances, timestamps, operation targets, and expected states are embedded into each configuration semantic item in the intent configuration semantic set to construct the expected configuration semantic matrix;

[0061] Align the behavior state feature tensor with the desired configuration semantic matrix, perform semantic path mapping, and obtain the behavior semantic alignment matrix;

[0062] Based on the behavioral semantic alignment matrix, the semantic offsets of each operation dimension, including the configuration target miss rate, policy execution offset, and operation order perturbation rate, are calculated and fused into a semantic deviation index vector.

[0063] The semantic deviation index vector is mapped to each configuration semantic item in the intent configuration semantic set, and the execution deviation, timing delay and policy deviation of each configuration semantic item are associated to generate a configuration result report.

[0064] This invention extracts behavioral features from real-time switch behavior status data and constructs a behavioral status feature tensor, providing a quantifiable and traceable basis for configuration behavior, which helps to accurately capture the dynamic response relationship between behavior and intent. Based on this, historical configuration instances are used to embed timestamps, operation targets, and expected states into the semantics of intent configuration. The constructed expected configuration semantic matrix ensures a clear reference standard during semantic alignment, avoiding alignment deviations caused by target ambiguity. Performing semantic path mapping between the behavioral status tensor and the expected semantic matrix systematically restores the semantic association between behavior and expected configuration paths, and a structured comparison of behavioral states and configuration intents is achieved by constructing a behavioral semantic alignment matrix. By extracting three indicators from the semantic alignment matrix—configuration target miss rate, policy execution offset, and operation sequence disturbance rate—it covers three key dimensions: target matching, execution process, and operation sequence. The constructed semantic deviation indicator vector is highly expressive; in particular, the miss rate reflects configuration coverage, the offset quantifies behavioral accuracy, and the disturbance rate reflects execution consistency. The fusion of these three indicators forms a complete deviation description. Finally, mapping this indicator back to each configuration semantic item and generating a configuration result report helps to provide execution feedback and deviation explanation for each configuration item, improves the visualization of the network configuration process and the ability to trace anomalies, thereby achieving closed-loop verification of intent-driven configuration.

[0065] Optionally, this specification also provides an automatic switch configuration system for executing the automatic switch configuration method described above, the automatic switch configuration system comprising:

[0066] The topology modeling module is used to acquire switch resource configuration data and perform semantically enhanced topology modeling based on the switch resource configuration data to obtain a digital twin model of the network environment.

[0067] The configuration instruction parsing module is used to perform network configuration context reasoning based on the network environment digital twin model and the preset configuration management database to obtain a network configuration intent graph; it parses the network configuration intent graph into configuration instructions and performs executable configuration semantic mapping on the instruction parsing results to obtain an intent configuration semantic set.

[0068] The vendor semantic orchestration module is used to transform the intermediate configuration policy set based on the configuration policy path of the intent configuration semantic set to obtain the intermediate configuration topology matrix, and to perform multi-vendor semantic mapping orchestration on the intermediate configuration topology matrix to obtain the native configuration command set.

[0069] The minimum trust unit verification module is used to perform minimum trust unit verification on each configuration command in the original configuration command set to obtain a fine-grained permission verification command set; based on the fine-grained permission verification command set, identity path integrity audit is performed to obtain a verified signature command set;

[0070] The semantic deviation calculation module is used to upload the verified signature command set to the switch management platform to execute commands; obtain the real-time behavior status data of the switch; perform semantic deviation calculation on the real-time behavior status data of the switch and the semantic set of intent configuration; and obtain a configuration result report.

[0071] The automatic switch configuration system of the present invention can implement any of the automatic switch configuration methods of the present invention. It is used to coordinate the operation and signal transmission media between various modules to complete the automatic switch configuration method. The internal modules of the system cooperate with each other, thereby improving the effectiveness and adaptability of switch configuration.

[0072] Optionally, this specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements the automatic switch configuration method described above. Attached Figure Description

[0073] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0074] Figure 1 This is a flowchart illustrating the steps of the automatic configuration method for switches of the present invention.

[0075] Figure 2 This is a detailed flowchart of step S1 in the present invention;

[0076] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0077] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0078] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0079] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0080] To achieve the above objectives, please refer to Figures 1 to 2 This invention provides an automatic configuration method for a switch, the method comprising the following steps:

[0081] Step S1: Obtain switch resource configuration data, and perform semantically enhanced topology graph modeling based on the switch resource configuration data to obtain a digital twin model of the network environment;

[0082] In this embodiment, resource configuration data from multiple core and aggregation switches are collected in parallel using SNMP and Netconf protocols. This includes port connectivity status, VLAN configuration, ACL rules, STP information, and running session entries. After standardizing the data, an initial topology edge information set <device ID, interface ID, interface status, VLAN, adjacent device ID, interface speed> is constructed in six-tuple form. Combined with the switch logical partition and physical location mapping table, a switch-level resource semantic tag set is established. Subsequently, a semantically enhanced topology graph G = (V, E, A) is constructed, where V is the set of switching nodes, E is the set of connection edges, and A is a node attribute matrix. Each row in the attribute matrix represents a switch's device type, role identifier (e.g., Core, Distribution, Access), vendor information, and current configuration status, forming a tensor A with N×8 dimensions. This semantic topology graph is persistently stored in a graph view database (e.g., Neo4j) and, combined with network simulation parameters (e.g., port speed, interface latency, hop count, etc.) as environment variables, a corresponding digital twin network environment is constructed. This digital twin network supports functions such as topology visualization, configuration status replay, and virtual verification of traffic paths, providing dynamic support for subsequent configuration inference.

[0083] Step S2: Based on the network environment digital twin model and the preset configuration management database, perform network configuration context reasoning to obtain the network configuration intent graph; parse the network configuration intent graph for configuration instructions, and perform executable configuration semantic mapping on the instruction parsing results to obtain the intent configuration semantic set;

[0084] In this embodiment, for the constructed digital twin network environment, a pre-established configuration management database (CMDB) is used. This database includes policy templates for typical business scenarios, historical configuration execution paths, configuration semantic dictionaries, and other information. The system uses a rule graph-driven approach to perform configuration context reasoning on the digital twin graph. The rule graph consists of triples: <semantic node, triggering condition, reasoning target>, such as <core switch, accessing Layer 3 service VLAN, requiring DHCP relay and policy routing to be enabled>. The reasoning process generates a configuration intent graph, with relationships defined between nodes using "configuration dependency," "upstream / downstream order," and "configuration domain boundary." The graph uses an adjacency list structure, where each node contains fields such as configuration name, execution priority, configuration scope, and dependency number. After exporting the configuration targets of each node in the intent graph, instruction parsing and semantic mapping are performed. In the instruction parsing stage, multi-field matching rules are used to extract device vendor-neutral instruction tuples, such as:<enable,vlan100,allowtcpport80,fromzoneXtozoneY> Then it is mapped to the intent configuration semantic set S, where S is a set of five tuples: <policy type, scope, security level, configuration strength, priority identifier>, which serves as structured input for subsequent policy mapping.

[0085] Step S3: Based on the configuration strategy path of the intent configuration semantic set, perform intermediate configuration strategy set transformation to obtain intermediate configuration topology matrix, and perform multi-vendor semantic mapping orchestration on intermediate configuration topology matrix to obtain native configuration command set;

[0086] In this embodiment, after the intent configuration semantic set S is imported into the policy path engine, the policy topology path is constructed according to the hierarchical priority of the configuration policies. Assuming the input intent contains four types of configuration policies: VLAN isolation, access control, QoS rate limiting, and dynamic routing enablement, a separate semantic path matrix M is established for each type of policy, with dimensions n×n, where n is the number of network devices. The path matrix M(i,j) represents the policy propagation dependency weight between device i and device j. For example, in the VLAN policy path matrix, an edge weight of 1 indicates no cross-interference in configuration, and an edge weight of 0 indicates a conflicting path that needs to be avoided. All path matrices are merged to form an intermediate configuration topology matrix T. Each unit in matrix T is semantically mapped to generate an intermediate configuration unit <target device, mapping semantics, configuration path index, semantic strength, application order>. To adapt to devices from multiple vendors, this configuration unit is sent to the semantic dictionary matching module, which uses a preset semantic mapping table (containing command mapping rules from mainstream vendors such as Cisco, Huawei, and H3C) for instruction conversion. Example of command templates: Cisco format: interface GigabitEthernet0 / 1\nswitchportaccessvlan100\nipaccess-group10in; Huawei format: interface GigabitEthernet0 / 1\nportdefaultvlan100\ntraffic-filterinboundacl3000; All generated native configuration command sets are encapsulated in JSON format and retain the intent tracking label field.

[0087] Step S4: Perform minimum trust unit verification on each configuration command in the original configuration command set to obtain a fine-grained permission verification command set; perform identity path integrity auditing based on the fine-grained permission verification command set to obtain a verified signature command set;

[0088] In this embodiment, for each native configuration command, the system performs a minimum trust unit verification before issuing it. The minimum trust unit is defined as <operator ID, configuration domain, timestamp, permission level>. The system compares the configuration domain involved in the command (such as interface control, VLAN operation, security rules, etc.) with the identity and role of the current operator to generate a permission verification vector P = [p1, p2, ... pn], where pi ∈ {0, 1} indicates whether the corresponding configuration passes the verification. Commands that fail the verification are blocked and recorded. For configuration commands that have passed the permission verification, the system further performs identity path integrity auditing. The system constructs an identity transfer graph H from the audit link records. Each edge in the graph represents a configuration execution link (such as "Operation and Maintenance Application → Audit Approval → Security Confirmation → Device Execution"). The path nodes contain the operator ID, approval role, approval timestamp, and approval result signature. The system traverses the graph to confirm the closure and legality of the path and injects a digital signature (using the SM2 national cryptographic signature method) into each legal path, finally generating a set of verified signature commands. The signature command uses an ASN.1 encoding structure and embeds a signature tag to support accountability and traceability.

[0089] Step S5: Upload the verified signature command set to the switch management platform to execute the command; obtain the switch's real-time behavior status data, perform semantic deviation calculation on the switch's real-time behavior status data and intent configuration semantic set, and obtain a configuration result report.

[0090] In this embodiment, the verified signature configuration command set is uploaded to the target device for configuration and deployment via a switch management platform (such as a control center based on a RESTful API). During deployment, the system monitors switch status changes in real time, collecting operational data including interface status changes, VLAN entry updates, ACL matching counter changes, CPU load, and memory usage, forming a real-time behavioral status dataset B. B is an array of structures, each containing the fields <configuration item ID, status flag, change time, current value, baseline value>. Subsequently, the behavioral status dataset B is compared with the intent configuration semantic set S to construct an alignment vector pair D = {(Si,Bi)}, where each comparison unit corresponds to an intent semantic item and an actual status item. A preset semantic matching function F(Si,Bi) is used to calculate the deviation score. The deviation function can be defined using a weighted vector difference, for example: Score = w1 * |S.priority - B.priority_flag| + w2 * |S.policy_type - B.applied_policy| + ... The final configuration result report R is generated, which includes: configuration success rate, semantic deviation distribution map, deviation severity level markings (divided into three categories: completely consistent, minor deviation, and critical deviation), and suggested operation feedback. This report is graphically displayed by the operations and maintenance platform and supports exporting to PDF for auditing purposes.

[0091] Optionally, step S1 specifically includes:

[0092] Step S11: Obtain the device resource table and link connection table of the switch to be configured, extract the device identifier, port configuration, interface status, connection topology, VLAN division items and existing access control policies, and construct the switch resource configuration data;

[0093] In this embodiment, during the automatic configuration preparation phase of the enterprise data center switches, information is retrieved from the switches to be configured using both SNMP and Netconf protocols in parallel, obtaining the device resource table and link connection table respectively. The device resource table is in CSV format, with fields including: device ID, device type (core, aggregation, access), management IP, port number, port speed, supported protocols (such as STP, LLDP, LACP), and ACL application status. The link connection table is represented in matrix form with an n×n dimension, representing the physical link relationships between n switches, with a value of 1 indicating a connection and 0 indicating no connection. When extracting port configuration information, each port status is represented as a five-tuple: <port ID, speed, status, VLAN ID, bound ACL ID>. All information is standardized and summarized into a structured JSON document to construct a unified switch resource configuration dataset. This dataset is used for subsequent graph structure construction, ensuring that device attributes, connection topology, and policy relationships are fully expressed in the same structure, forming the basic input for semantic modeling.

[0094] Step S12: Extract semantic entities and identify topological relationships from switch resource configuration data. Use device type, interface category, and protocol support capabilities as semantic tags to construct a set of semantically labeled nodes and an initial connection relationship edge set, and generate a prototype semantically labeled topological graph.

[0095] In this embodiment, semantic entity extraction and topology relationship identification are performed on the collected switch resource configuration data. Semantic entities are extracted from the fields using three core tags: device layer tags (e.g., device role, manufacturer model), interface layer tags (e.g., interface type, physical / logical port), and protocol capability tags (e.g., whether STP, VTP, LACP, etc. are supported). Each switch node is constructed as a node data structure <Device ID, Role Type, Number of Interfaces, Protocol Capability Vector>, which serves as an element of the semantically labeled node set. Topology edges are constructed based on a link connection table, with each edge defined as <Starting Device ID, Target Device ID, Connection Port Pair, Bandwidth Index, Link Stability Coefficient>, forming an initial set of connection edges. The node set and edge set are organized in a graph structure, generating a semantically labeled topology graph prototype G = (V, E), where V represents the node set and E represents the connection edge. The graph structure is persistently stored in a graph database (e.g., Neo4j) in the backend and supports visual access for identifying potential dependencies in configuration paths between multiple devices.

[0096] Step S13: Enhance the topology structure based on the semantic annotation topology graph prototype, embed port configuration features in nodes, embed interface status features in edges, and link and merge the subdomain topology in VLAN division with the backbone topology of the semantic annotation topology graph prototype in a subgraph embedding manner to obtain a resource semantic enhancement topology graph.

[0097] In this embodiment, structural enhancements are performed on the prototype topology graph. Enhancement methods include feature embedding of nodes and edges, and topology fusion. Specifically, each switching node embeds a port configuration feature tensor T_port, with dimensions m×5, where m is the number of ports on the node, and the five dimensions correspond to port number, speed, operating mode, bound VLAN, and ACL binding status. Topology edges embed an interface state tensor T_link, a two-dimensional matrix where each row represents a pair of connected interfaces, with fields including physical status (up / down), link quality (bit error rate), and negotiation mode (auto / manual). Furthermore, to support the topology expression of VLAN logical partitioning, the connection of each VLAN subdomain is considered as a subgraph G_vlan = (Vv, Ev), where Vv is the port node involved in the VLAN, and Ev is the logical connection edge. These subgraphs are integrated into the backbone topology graph through embedding, and bound by cross-node identifiers, achieving the fusion of the VLAN logical structure and the physical connection graph. After fusion, a resource semantic enhancement topology graph G′ is obtained, where nodes and edges carry embedding vectors, supporting semantic search and policy mapping.

[0098] Step S14: Perform structural normalization on the resource semantic enhancement topology graph to obtain the tensor representation enhancement graph;

[0099] In this embodiment, the resource semantic enhancement topology graph G′ undergoes structural normalization processing, unifying the shapes of various feature tensors and generating a tensor representation enhancement graph. The node attribute tensor A is defined as an N×d matrix, where N is the number of nodes and d is the merged semantic dimension (such as role code, number of ports, protocol capability value, average port rate, etc.), and after normalization, its range falls within the [0,1] interval. The edge weight tensor B is defined as an N×N matrix, where B[i][j] is the connection strength between i and j, and its value is determined by the weighted sum of link bandwidth, physical state, and bit error rate. The weight combination is as follows: W = 0.5 × bandwidth factor + 0.3 × state value + 0.2 × reciprocal of bit error rate. To ensure the integrity of the VLAN subgraph embedding, a logical domain mapping matrix L is also established, with a structure of N×k, where k is the number of VLANs. L[i][k] = 1 indicates that node i belongs to VLAN k, and L[i][k] = 0 otherwise. The three types of tensors (A, B, L) mentioned above together constitute the final tensor enhancement map, which is used as the input carrier for subsequent network simulation modeling.

[0100] Step S15: Perform network environment simulation modeling based on the tensor representation augmented graph to obtain a digital twin model of the network environment.

[0101] In this embodiment, digital twin modeling of the network environment is performed based on the constructed tensor-enhanced graph. This simulation model based on a dynamic graph neural network is designed with a three-layer structure: the bottom layer is the physical structure layer, which uses structural tensors... Characterize the link connection relationship between devices, combined with The VLAN segmentation boundary tensor represents the segmentation and constraint of the switching and broadcast domains, restoring network physical topology connectivity; the middle layer is the behavior response layer, which utilizes node attribute tensors. The model embeds features such as device type, interface capabilities, and CPU utilization, and associates them with a historical behavior state database. It models the state transition of each node under specific configurations (e.g., port state switching, load adjustment, policy refresh). The top layer is the intent mapping layer, which sets a configuration target intent set I = {i1,i2,...,i_k}. By constructing an intent propagation path graph between A and B, the configuration semantics are projected onto the topology evolution space. The overall network behavior trend under intent configuration is deduced through a dynamic evolution sequence G(t), forming a digital twin model of the network environment with predictable capabilities. The model uses a state transformation tensor S(t), defined as an N×p time series matrix, recording the state change vector of each node at time t, where p is the state dimension (e.g., interface state, power state, QoS change indicators). External events can be injected, such as simulating a VLAN change under a configuration command, to observe the chain reaction of changes in S(t). Simulation results are output in the form of a graph comparison, verifying the configuration propagation path, policy implementation boundaries, and network stability, providing real-time support for configuration path generation. The simulation step size Δt can be configured throughout the simulation process, typically set to 5 seconds.

[0102] Optionally, step S13 specifically includes:

[0103] Step S131: Extract the port configuration parameters of each device node in the semantic annotation topology graph prototype from the switch resource configuration data, construct node feature vectors, and add the node feature vectors to the representation tensor of the device nodes in a matrix embedding manner to obtain the port configuration enhanced node set;

[0104] In this embodiment, each device node in the semantically labeled topology prototype is matched and queried in the switch resource configuration data to extract its corresponding port configuration parameters, including interface speed (e.g., 1Gbps / 10Gbps), port status (enabled / disabled), PoE power supply capability (Yes / No), MTU value, duplex mode, etc. The above configuration items are constructed into a node feature vector with dimension d=6. Map v_i to node attribute tensors using matrix embedding. In this context, n represents the total number of nodes, ultimately forming a node set with enhanced port configuration. This node tensor will then be used in the graph neural processing structure for node representation propagation and context structure inference, enabling explicit expression of configuration features at the node level.

[0105] Step S132: Extract the interface state parameters corresponding to each connection edge in the semantic annotation topology graph prototype in the switch resource configuration data, construct the edge weight vector, and embed the edge weight vector into the representation tensor of each connection edge in the weight tensor encoding method to obtain the interface state enhanced edge set.

[0106] In this embodiment, for each connection edge in the semantically labeled topology graph prototype, the associated interface status parameters are retrieved from the switch resource configuration data, including link activation status (up / down), link quality indicators (packet loss rate, latency), negotiation protocol type (such as LACP, STP), link load value, error frame count, etc. This status information is then constructed into an edge weight vector of dimension w=5. Using weight tensors The corresponding values ​​are encoded into the edge tensor, ensuring that the state characteristics of each connection edge in terms of physical structure can be used for subsequent structural evolution and anomaly detection simulation. This edge weight embedding method enables dynamic modeling of connection characteristics and is particularly suitable for twin-network scenarios with link fault tolerance and self-healing response.

[0107] Step S133: Traverse the VLAN segmentation items in the switch resource configuration data, extract the ports, device nodes and connection relationships associated with the VLAN segmentation items, and thus construct a local subdomain topology map;

[0108] In this embodiment, the VLAN partitioning entries in the switch resource configuration data are traversed one by one. The VLAN ID, port number, device identifier, and interconnection relationships of each VLAN entry are extracted. Based on their logical partitioning attributes, device ports and links with the same VLAN ID are extracted to construct a local subdomain topology graph. Each subdomain topology graph can be represented as a triple G_v = (N_v, E_v, A_v), where N_v represents the set of device nodes within the VLAN, E_v represents the set of link edges within it, and A_v is a node attribute subtensor. For network structures with mutually exclusive VLAN partitioning principles, each subgraph contains only non-overlapping broadcast domain elements, ensuring local isolation and structural integrity, which is beneficial for semantic modeling at the subdomain granularity.

[0109] Step S134: Map the local subdomain topology graph to the semantically labeled topology graph prototype in the form of subgraph embedding, and establish the boundary connection path between subdomain graph nodes and device nodes to obtain the linkage fusion topology structure graph.

[0110] In this embodiment, each completed local subdomain topology graph is injected into the original semantically annotated topology graph prototype via subgraph embedding. By identifying subgraph access nodes in the main graph and constructing boundary connection paths for these nodes—that is, adding cross-graph connection edges between the subgraph and the main graph—a bridge connection is formed between subgraph node N_v and main graph device node N_p. This process is represented as a cross-domain edge set in the graph data structure. Add the operation and update the structure connection tensor. Where m is the number of nodes in the subgraph and n is the number of nodes in the main graph, the semantic-level fusion and linkage between the subdomain and the main topology is realized, and the boundary relationship basis is provided for subsequent complex configuration strategy mapping.

[0111] Step S135: Merge the port configuration enhancement node set, the interface status enhancement edge set, and the linkage fusion topology diagram to obtain the resource semantic enhancement topology diagram.

[0112] In this embodiment, the completed port configuration enhancement node set will be used. Interface State Enhancement Side Set and the topology connection tensor after linkage and fusion A unified integration process is performed to generate a resource semantically enhanced topology graph. This graph structure is represented by a triple G = (N, E, F), where N is the complete set of nodes including both the main graph and subgraph nodes, E is the set of all structural edges, and F represents the joint feature embedding set of nodes and edges. The integrated graph not only possesses physical connectivity and configuration state information but also embeds logical partitioning and semantic annotation capabilities, allowing it to be directly used as input to subsequent graph structure encoders to support network intent mapping, behavior prediction, and configuration reasoning tasks.

[0113] Optionally, the network configuration context reasoning in step S2 specifically involves:

[0114] Historical configuration instances, policy templates, device behavior logs, and anomaly repair records are extracted from the preset configuration management database as ontology layers. The configuration rule ontology graph is constructed by modeling the correlation between the configuration semantic roles in the historical configuration instances and the policy templates.

[0115] In this embodiment, when constructing the configuration rule ontology graph, 3,000 configuration instances and 800 policy templates from the past two years are first extracted from the configuration management database. These are then combined with six types of device log behavior tags and 300 anomaly repair records to construct a semantic hierarchical ontology structure. Nodes in the ontology graph are named according to their configuration semantic roles, such as "Access Control Settings," "VLAN Partitioning Instructions," and "Authentication Behavior Responses." Edges represent the sequential dependencies and constraint logic between roles in the policy templates. Edge weights are assigned based on the co-occurrence frequency of roles, and a structural graph is established using configuration field consistency and behavior triggering dependencies, resulting in an ontology graph with a clear rule hierarchy and well-defined node roles.

[0116] The nodes in the digital twin model of the network environment are mapped to the configuration rule ontology graph. The semantic role labels of the nodes in the configuration rule ontology graph are extracted and the entity matching degree is evaluated, thereby constructing a configuration context entity alignment matrix.

[0117] In this embodiment, entities representing network nodes such as switches, ports, and VLANs in the digital twin model are mapped to the configuration rule ontology graph. Semantic descriptions of entities are established using triples of "type label + interface category + protocol capability," and the semantic similarity between the current node and ontology nodes is compared using Jaccard label overlap to generate a |V|×|E| dimensional entity alignment matrix (where V is the number of twin nodes and E is the number of ontology nodes). The alignment threshold is set to 0.6; entities below this threshold are considered semantically anonymized and awaiting completion. The system retains the alignment confidence vector for reference during subsequent configuration path filtering.

[0118] By combining the obtained network operation and maintenance task scenarios with labeled intent targets, and by identifying subgraph regions in the configuration rule ontology graph that are related to the current intent target, a configuration intent path graph is constructed.

[0119] In this embodiment, the operation and maintenance instruction input data from the network management platform is structured and parsed. The parsed data sources include task description text entered by the administrator on the web interface, automated task template scheduling records, and alarm log information reported by the security monitoring module. This data is uniformly mapped to a set of task semantic units and categorized and labeled according to task semantic types (such as isolation, protection, recovery, and optimization). Taking "Implementing access control isolation for terminal devices with abnormal access behavior" as an example, the keywords "abnormal access behavior," "terminal device," "access control," and "isolation" are extracted using a natural language parsing component. Combined with the platform's device identification interface, the unique identifier ID and port information of the target device are queried to establish a semantic entity for the target device. Subsequently, an intent graph target structure based on the configuration target is constructed. A preliminary expression is given using a triple form: <target entity, configuration behavior, expected state>, for example, <Device #192.168.0.45, set VLAN policy, transfer to isolation domain VLAN100>. This triple is embedded into the task target intent graph, forming a semantic graph structure where nodes represent the target device, configuration behavior, and expected state. Nodes in the intent graph are connected by policy-driven edges, such as "requires execution," "depends on," and "triggered by," forming a structured configuration-driven semantic graph. Edges in the intent graph are represented using 6-dimensional semantic vector encoding, recording the causal logic of edge operations (such as sequence, condition, and constraint). For example, for a batch isolation configuration task of a switch, "high-risk port isolation" and "service migration without interruption" from the task scenario description are read as intent targets. Based on subgraph regions with associated semantic tags in the configuration rule ontology graph, an intent path graph is formed. The path graph structure consists of configuration semantic role nodes, with edges representing role order or conditional relationships. In this example, a path containing four key configuration nodes—"port shutdown → authentication reset → new VLAN migration → port recovery"—is extracted, with a length of 4. All paths are stored as path vector sequences to support subsequent consistency verification.

[0120] Perform semantic consistency and conflict detection on each path in the configuration intent path graph, and retain the configuration paths that pass the constraint verification to form a set of context-valid configuration paths;

[0121] In this embodiment, the path structure in the configuration intent path diagram is validated line by line by checking for parameter overlap, behavioral conflicts, or resource contention between configuration roles within the path. Specifically, three types of semantic rule checks are performed on each path: role mutual exclusion check, parameter dependency consistency check, and behavior timing deadlock avoidance check. If a path meets all constraints, it is retained and included in the set of valid paths. In this task, seven context-consistent and conflict-free paths are ultimately selected from the 12 initially extracted paths as the set of valid paths. The path structure is stored in the path template library as the basis for subsequent structure compression.

[0122] Cluster and compress structurally similar paths in the set of legal configuration paths in the context, extract common semantic substructures and operation units, and generate a logical configuration unit graph.

[0123] In this embodiment, paths with a length greater than 3 in the set of valid context configuration paths are compared for structural similarity. Edit distance is evaluated on the node sequences within the paths, and the clustering similarity threshold is set to 0.85. Similar paths are aggregated, and their common semantic role substructures are extracted to form a logical configuration subgraph. Two structurally similar paths, "Port Disable → Access Control Update → VLAN Isolation Reconstruction" and "Port Disable → Authentication Identifier Update → VLAN Isolation Reconstruction," are extracted in this way and collectively extracted as a template node group in the logical configuration unit graph. Placeholders are set for the configurable fields within this group to improve configuration reusability.

[0124] By combining the configuration context entity alignment matrix and the logical configuration unit graph, semantic translation and encapsulation are performed to obtain the network configuration intent graph.

[0125] In this embodiment, the role mapping results of device nodes in the configuration rule ontology are fused with logical operation units by combining the configuration context entity alignment matrix and the logical configuration unit graph. A semantic translation mechanism is employed to replace general placeholders in the logical configuration unit graph with specific device parameters, such as replacing "<port number>" with "GigabitEthernet0 / 2", generating a customized configuration intent graph. This graph is a directed graph structure consisting of N=47 configuration role nodes and E=53 behaviors and dependency edges, possessing cross-template and cross-device executable configuration expression capabilities, and supporting subsequent semantic mapping to vendor commands.

[0126] Optionally, the configuration instruction parsing in step S2 is specifically as follows:

[0127] Based on the path structure in the network configuration intent graph, the node sequence in each legal configuration path is sequentially structured and transformed into a triplet of operation target-scope-control condition, thereby obtaining a set of configuration operation unit sequences.

[0128] In this embodiment, a set of legal configuration paths that have passed constraint validation is extracted from the network configuration intent graph. Each path is expanded according to the node connection order, and the dependencies between device nodes, policy nodes, and operation nodes are recorded. Taking the path "Access Switch A → Port 1 → Enable ACL → Set VLAN Isolation Policy" as an example, it is decomposed into triples in the form of <Enable ACL, Port 1, Unconditional> and <Set VLAN 100, Port 1, ACL Enabled>, forming a triple sequence of "Operation Target-Scope-Control Condition", which is recorded as a structured configuration operation unit. This triple sequence set serves as the input basis for subsequent configuration template matching.

[0129] Semantically match the triples in the configuration operation unit sequence set with the control command templates in the configuration management database to generate an initial command template matching set;

[0130] In this embodiment, a preset configuration template index table in the configuration management database is invoked to extract semantic keywords from each triple in the configuration operation unit sequence and retrieve the most similar template command. Taking the triple <Enable ACL, Port 1, No Condition> as an example, the matching template commands are "access-list{ACL_ID}permitanyany" and "interface{IF_NAME}ipa ccess-group{ACL_ID}in", forming the initial instruction template matching set. Template similarity is filtered using the structure tree label similarity rate (Thre hold > 0.8) to ensure accurate matching.

[0131] The variable parameter bits existing in the initial instruction template matching set are bound and filled, and context parameters are injected according to the node attributes in the digital twin model of the network environment to obtain a structured configuration instruction set;

[0132] In this embodiment, the node attribute tensor is read from the network environment digital twin model. The actual interface name of port 1 is extracted as "GigabitEthernet0 / 1" and the ACL number is "ACL101". After injecting parameters, the structured configuration instructions are obtained as "interface GigabitEthernet0 / 1" and "ipaccess-groupACL101in". During the parameter injection process, it is necessary to ensure that the fields in the attribute tensor (such as interface name and ACL number) have been bound through the entity alignment step to ensure context consistency.

[0133] For each instruction in the structured configuration instruction set, semantic format transcribing is performed according to the syntax specifications of device brand and model in the configuration management database to generate a candidate set of executable commands;

[0134] In this embodiment, after generating a structured instruction set, the corresponding brand syntax template is retrieved from the configuration management database based on the device model identification result, and the original instructions are semantically transcribed. For example, for a device with the model number "Huawei S5731", "ipaccess-group" is transcribed into "traffic-filter" format, while the interface declaration format is adapted to "interfaceGigabitEthernet t0 / 1undoshutdown", thus obtaining a candidate set of executable commands. The transcription logic is driven by a rule table and supports brands such as Cisco, Huawei, and H3C.

[0135] Based on the candidate set of executable commands, configuration rule constraints are verified, and command fragments that do not meet the constraints are filtered out to obtain a set of structurally valid configuration commands.

[0136] In this embodiment, configuration rule constraint verification is performed on each command in the candidate command set, and the rule engine is invoked to check whether the semantic context conforms to the policy logic. For example, the ACL object definition must be completed before setting the ACL. If the order is reversed or key instructions are missing, it is determined to be illegal and is removed. This rule verification uses a logical template tree to judge the configuration semantic constraints, and finally outputs a set of configuration commands with a valid structure.

[0137] Semantic disambiguation and conflict detection are performed on command entries in the structured legal configuration command set. The command sorting is optimized according to the dependency order, and duplicate configurations are removed to generate an intent configuration semantic set.

[0138] In this embodiment, semantic disambiguation and conflict detection are performed on the legally configured command set. If multiple ACL bindings are declared on the same port, or if there are overlapping VLAN partitioning commands, semantic analysis is performed to remove redundancy. The remaining command set is sorted according to the dependency graph, ensuring that commands such as "interface" appear first, followed by "ACL reference". A configuration dependency chain is established using a DAG graph structure, and the execution is sorted according to topological order, ultimately generating a sequentially arranged, semantically unambiguous, and structurally complete intent configuration semantic set. This semantic set will serve as the basis for subsequent command generation and permission verification.

[0139] Optionally, step S3 specifically includes:

[0140] Step S31: Extract configuration paths from the intent configuration semantic set, parse them into configuration target pairs and path attribute constraints, and generate a structured configuration path set;

[0141] In this embodiment, legitimate configuration paths are extracted from the intent configuration semantic set. Each path consists of a set of semantic nodes, where nodes represent configuration targets and edges represent dependencies and constraints. For example, from the path "Enable VLAN isolation → ACL matching rule setting → Bind port", target pairs <VLAN isolation, ACL binding> and <ACL binding, port application> are extracted and their path attributes are labeled as "sequential dependency" and "resource sharing". These path target pairs and path attributes are combined to construct a structured configuration path set, represented in the form of triples <target A, target B, constraint type>, forming a structured path tensor P_{i,j,k}, where i represents the target start point, j is the end point, and k is the constraint type number.

[0142] Step S32: Segment each path in the structured configuration path set according to the operation semantics to generate a policy behavior fragment table;

[0143] In this embodiment, after forming the path set, each path is segmented according to semantic boundaries. Taking the path "interface configuration → IP address setting → ACL binding → QoS policy application" as an example, it is divided into three segments: "basic interface setting segment", "access control policy segment", and "quality of service assurance segment". Boundary identification is performed based on node labels and context resource usage relationships, and a policy behavior segment table is constructed to record the configuration targets contained in each segment and their sequential position in the path, represented as a two-dimensional structured behavior table: rows represent path numbers, columns are configuration segment indices, and each item is the sequence of configuration targets within the segment.

[0144] Step S33: Construct a node feature matrix based on the configuration semantic tags, dependency order, and resource constraints of the configuration fragments in the policy behavior fragment table, and associate nodes with the device interconnection topology of the network environment digital twin model to generate an intermediate configuration topology matrix;

[0145] In this embodiment, based on the policy behavior fragment table, configuration targets are extracted from each configuration fragment. Tag attributes from the intent semantic set are called, and the semantic tags are converted into vector representations to construct a configuration target feature matrix F_{m,n}, where m is the number of configuration nodes and n is the feature dimension (such as type, priority, resource dependency, etc.). Simultaneously, combined with the network environment digital twin model, the current network topology graph T_{i,j} is extracted, where nodes represent device ports and edges represent physical or virtual connections. By mapping configuration targets to device locations, the feature matrix is ​​projected onto the topology graph nodes to form an intermediate configuration topology matrix C_{i,j,n}, where i,j represent device nodes and n represents the configuration semantic vector dimension.

[0146] Step S34: Using a preset multi-vendor configuration semantic dictionary, perform command feature template matching on the semantic vectors of each node in the intermediate configuration topology matrix to construct a vendor semantic mapping matrix;

[0147] In this embodiment, after obtaining the intermediate topology matrix, a multi-vendor configuration semantic dictionary is introduced, containing keyword indexes, semantic attribute tables, and command template feature tables for each vendor's configuration target. For the semantic vector of each configuration node, keywords such as "ipaccess-group" and "traffic-filter" are extracted, and semantic nearest neighbor matching is performed in the dictionary. Each match returns the vendor command feature template index and mapping similarity, forming a vendor semantic mapping matrix M_{i,j,k}, where i is the configuration node, j is the vendor command template number, and k is the semantic matching score (0~1). Items with a matching score greater than 0.75 are considered usable mappings.

[0148] Step S35: Based on the manufacturer semantic mapping matrix, the matched command feature templates are fused with the configuration semantic tags to reconstruct the configuration command fragments, and then integrated according to the device brand to obtain a set of configuration command fragments;

[0149] In this embodiment, based on the aforementioned semantic mapping matrix, a semantic fusion operation is performed on each successfully matched command template, merging the original semantic tag information of the configuration node with the structural instruction framework in the vendor command template. For example, for the semantic tag "restrict IP range access", the Cisco template "access-list101denyip10.0.0.00.255.255.255any" is matched. The variable parameters are replaced with the context value "10.20.30.0 / 24" extracted from the intent semantics and bound to the actual device, such as "GigabitEthernet0 / 2", to construct a configuration command fragment. All generated fragments are clustered by device brand and integrated into a configuration command fragment set, denoted as S_{b,k}, where b is the brand number and k is the corresponding command sequence.

[0150] Step S36: Organize the configuration command fragment set in order, perform dependency verification and semantic consistency checks, arrange the configuration commands of each manufacturer's devices according to the execution order and logical grouping method, and generate the native configuration command set.

[0151] In this embodiment, each set of configuration command fragments is sorted according to semantic segment dependency order and resource consumption logic to construct a complete command execution sequence. The sorting rules are based on the topology dependency graph and behavior priority matrix, ensuring that commands such as "define ACL" precede "apply ACL". For example, for H3C brand devices, the command order should be "aclnumber3000→ruledeny→interfaceGig abitEthernet1 / 0 / 1→packet-filter3000inbound". Semantic consistency checks are performed during sorting to eliminate commands with conflicts or redundant settings, such as "duplicate VLAN declaration" and "inconsistent IP segment binding", ultimately forming a native configuration command set categorized by device. This command set has brand syntax consistency, logical unambiguity, and contextual integrity, and can be directly submitted to the device execution engine.

[0152] Of particular importance is that the refactoring configuration command fragment in step S35 is as follows:

[0153] Based on the successfully matched node pairs in the manufacturer's semantic mapping matrix, extract the configuration semantic tags corresponding to the command feature template and construct a semantic fusion mapping table;

[0154] In this embodiment, successfully matched node pairs are selected from the established vendor semantic mapping matrix M_{i,j,k}, where i represents the index of the configuration target semantic node, j represents the command template number, and k is the matching similarity score. For node pairs with a matching score higher than a set threshold (e.g., 0.75), the system extracts their command feature templates and the semantic label information they represent, such as "ACL creation," "bandwidth limitation," or "interface binding." Then, these configuration semantic labels are fused with the target semantic nodes corresponding to the original intent semantic set to construct a semantic fusion mapping table E_{i,j,l}, where l is the fusion label dimension, including attributes such as the original semantic label, vendor command label, and matching template number. For example, if the semantic label corresponding to a Cisco template "access-list101permitipan yany" is "access control allow," then this record will be written into the semantic fusion mapping table as a complete fusion entry.

[0155] Extract the entity parameters from the corresponding policy behavior fragment of each mapping record in the semantic fusion mapping table, and fill them into the parameter slot of the command feature template to obtain the intermediate configuration command fragment.

[0156] In this embodiment, based on the semantic fusion mapping table, each fusion record is traversed to find the associated policy behavior fragment and extract its entity parameters. For example, for the "ACL rule binding" behavior fragment, the target IP range "192.168.10.0 / 24", protocol type "TCP", and source interface "GigabitEthernet0 / 1" are extracted as entity parameters. These parameters are then filled into the parameter slots of the corresponding command template in the mapping table. During this process, according to the placeholder rules in the template structure, such as "access-list<number>permit<protocol><source address><destination address>", each placeholder is replaced with an entity parameter to obtain the intermediate configuration command fragment. For example, "access-list101permittcp192.168.10.00.0.0.255any" is a complete intermediate command fragment. The system stores all completed command fragments in the form of triples <device node ID, command fragment string, source semantic tag> as a sequence structure Cn,tC_{n,t}Cn,t, where n is the command sequence number and t is the field type, including brand, template number, original intent source, etc.

[0157] The intermediate configuration command fragments are categorized and organized according to the device brand field to build a manufacturer configuration command fragment index table.

[0158] In this embodiment, all intermediate configuration command fragments are categorized according to their device brand field, constructing a manufacturer configuration command fragment index table. The system establishes brand command grouping areas based on device brand identifier fields, such as "Cisco," "H3C," and "Huawei," and assigns each command fragment to its corresponding index area according to the brand information of its device. In the index table, the record structure is I_{b,m}, where b represents the manufacturer code and m represents the index number of the command entry under that brand. Each index entry includes the following fields: command fragment content, command template number, semantic source path, target device interface identifier, and dependency configuration relationship. Through this index table, the system can achieve brand command batch scheduling, template backtracking analysis, and cross-brand semantic consistency verification, laying the data structure foundation for subsequent generation of executable configuration sets.

[0159] Optionally, step S4 specifically includes:

[0160] Step S41: Perform minimum trust unit division and tag extraction on each command in the native configuration command set to obtain a trust unit tag set;

[0161] In this embodiment, semantic analysis is performed on each command in the native configuration command set, dividing it into minimal semantic units based on the operation target and control boundary. For example, a configuration command "interfaceGigabitEthernet0 / 1\nipaddress10.0.0.1255.255.255.0" is divided into two minimal trust units: an interface control unit and an address setting unit. Each unit is tagged using a configuration semantic dictionary, such as "interface enabled" or "address configured," generating a trust unit tag set T_{i,j}, where i represents the command number and j represents the tag type, including fields such as operation type, resource scope, and device impact level. The tag set data structure is a multidimensional array, with each unit recording the specific semantic unit of the command fragment and its security impact scope.

[0162] Step S42: Map the trust unit tag set to the preset permission policy graph, perform ternary constraint judgment based on the operation role, command scope and device sensitivity level, and generate a fine-grained permission verification command set;

[0163] In this embodiment, the tag set is mapped one by one to the permission policy graph structure P_{r,s,d}, where r is the operation role (e.g., network administrator, security auditor), s is the command scope (e.g., interface level, global level), and d is the device sensitivity level (1 – high sensitivity, 2 – medium sensitivity, 3 – low sensitivity). During the mapping process, the correspondence between tags and nodes in the policy graph is retrieved, and the legality of the role-resource-level triplet is matched. For example, for the tag "interface configuration", if the role is "ordinary maintenance personnel" and the scope is "physical port", and the target device is marked as high sensitivity, it is marked as a permission conflict and is not written into the verification set; if it is legal, it is included in the fine-grained permission verification command set A_{i,r,s,d}.

[0164] Step S43: Set the context backtracking window size to 30 minutes, backtrack and record the execution context during the command generation and distribution process for the command entries in the fine-grained permission verification command set, and generate an identity behavior context sequence;

[0165] In this embodiment, after the fine-grained permission verification command set is established, a context backtracking window is set to 30 minutes. The context execution sequence of command distribution is backtracked from the configuration log, and the work order number that triggered the command, the instruction issuer, the operation terminal IP, and the device execution log are extracted to form an identity behavior context sequence structure U_{i,t,k}, where t is the event timestamp and k is the context type (such as role declaration, IP address, device feedback). These sequences are used for the subsequent construction of the identity behavior graph.

[0166] Step S44: Construct an identity link graph using the identity behavior context sequence, and perform integrity tracing on each identity node in the identity link graph. Set the identity node continuity tolerance threshold to 1 and the deepest link tracing level to 5 to remove abnormal identity nodes and generate an audit-passed command identity path set.

[0167] In this embodiment, an identity link graph G = (V, E) is constructed based on the identity behavior context sequence, where V is the set of identity nodes, such as user ID, terminal MAC, and access password; and E is the identity behavior relationship, such as "issue-response" and "issue-execute". Starting from each command, a maximum of 5 layers of paths are traced back along the identity link. The identity continuity tolerance threshold is set to 1, meaning that if more than one node of a continuous identity link is broken, it is considered an abnormal link and is removed. The set of retained paths constitutes the audit-passed command identity path set S_{i, p}, where p is the valid identity link identifier.

[0168] Step S45: Bind the audit pass command identity path set with the fine-grained permission verification command set, and sign and encrypt each binding result to generate an identity binding signature command object set;

[0169] In this embodiment, the audit pass command identity path set is bound one-to-one with the fine-grained permission verification command set. Each binding pair includes an identity path identifier, a command sequence number, and the original command string. The SM2 encryption standard is used to sign each binding result, and the identity path and command content hash are signed using a private key and encrypted and encapsulated into an identity binding signed command object set Z_{i,h,sig}, where h is the content digest value and sig is the signature field.

[0170] Step S46: Perform sequence dependency verification on the identity-bound signature command object set to generate a verified signature command set.

[0171] In this embodiment, the identity-bound signature command object set undergoes dependency checks according to the original command execution order. A command dependency matrix D_{i,j} represents the configuration dependencies between commands. If any unmet dependencies exist (e.g., an address is set even though the interface is not enabled), the command group is removed from the object set. The final filtered object set is organized into a verified signature command set F_{i,sig}, where each record can be traced back to its generator, authorizer, and final executor, providing comprehensive data link support for subsequent auditing and tracing.

[0172] Of particular importance is the specific determination of the ternary constraint in step S42:

[0173] Based on the operation keywords extracted from the trust unit tags, construct an operation role mapping vector, match it with the role nodes in the preset permission policy graph, and calculate the role matching score;

[0174] In this embodiment, the trust unit tag is extracted from each configuration command. The tag content contains operation keywords, such as "enable", "set-vlan", "shutdown", "iproute", etc. A preset operation role mapping table is consulted based on the operation keyword, and each keyword is converted into a corresponding role matching vector R_{i}=\{r_1,r_2,...,r_n\}, where each r_k represents the keyword's suitability score for the k-th role (such as network administrator, security administrator, general operations and maintenance personnel). For example, the keyword "set-vlan" has a network administrator matching score of 0.95 and a general operations and maintenance personnel score of 0.4. This vector is then matched with the role node weight vector in the permission policy graph using cosine similarity to obtain the role matching score S_r=cos(R_i,P_r), where the matching score is expressed as a floating-point number from 0.0 to 1.0 to indicate the strength of the match.

[0175] Based on the configuration target field and operation scope in the trust unit label, construct a command scope nesting relationship tree and map it to the permission policy graph, and evaluate the scope boundary overlap.

[0176] In this embodiment, configuration target and operation scope information, such as "interfaceGigabitEthernet0 / 1" and "accessvlan100", is extracted from the trust unit label to construct a command scope nesting relationship tree. The top-level node represents device-level commands, the middle layer represents interface-level or service-level commands, and the bottom layer represents field-level operations. This tree structure is represented using a nested vector form T_{s} = \{L1:[device],L2:[interface0 / 1],L3:[vlan100]\}. The overlap between this structure and the scope nodes in the permission policy graph is compared, and the ratio of the number of overlapping nodes to the total number of layers is used as the scope boundary overlap degree S_s. For example, if a command touches two of the three layers, then S_s = 2 / 3 ≈ 0.667.

[0177] Based on the operation role mapping vector, the device node is located in the switch resource configuration data, the security level label and command operation strength are extracted, and the command sensitivity coefficient is evaluated based on the security level label and command operation strength.

[0178] In this embodiment, based on the dominant role in the role mapping vector, a matching device node is searched in the switch's resource configuration data table to extract its currently configured security level label (such as "high sensitivity", "medium sensitivity", "low sensitivity"). Simultaneously, the operational intensity involved in the command is analyzed. Operational intensity is calculated by combining the degree of command modification and the scope of resource impact, set as a floating-point value in the range of 0–1. For example, the operational intensity of the "shutdowninterface" command can reach 0.95, belonging to the high-risk level. Based on the device security level label L_d and the command operational intensity I_o, the command sensitivity coefficient S_m = f(L_d, I_o) is calculated using an empirical parameter weighting formula. A high-sensitivity + high-intensity operation will output a sensitivity coefficient close to 1.0.

[0179] By integrating the results of the role matching score, scope boundary overlap, and command sensitivity coefficient, a joint decision logic is executed to obtain a fine-grained set of permission verification commands.

[0180] In this embodiment, three parameters—role matching score S_r, scope boundary overlap S_s, and command sensitivity coefficient S_m—are fused to set a joint constraint threshold. For example, if S_r ≥ 0.8, S_s ≥ 0.6, and S_m ≤ 0.7, the command is determined to comply with the permission specifications and can be included in the fine-grained permission verification command set; otherwise, it is marked as a permission risk command. The generated permission command set structure is A_{i} = \{cmd_i,S_r,S_s,S_m,decision\}, where decision ∈ {pass,alert}, which clarifies the permission compliance status of each command and serves as the basic data input for subsequent auditing processes.

[0181] Optionally, the semantic deviation calculation in step S5 is specifically as follows:

[0182] Extract switch behavior features from real-time switch behavior status data and construct a behavior status feature tensor.

[0183] In this embodiment, behavioral state features are extracted by real-time monitoring of switch behavior log data, flow table changes, interface online / offline status, and ARP and MAC entry update behavior, and a unified behavioral state feature tensor is constructed. This tensor adopts a three-dimensional structure. Where N represents the number of monitored switches, M represents the behavioral dimension (such as "port on / off status", "VLAN switching", "routing table synchronization", "ACL loading status", etc.), and T is the time step. Each element t_{n,m,t} of the tensor represents the state value of the nth switch at time t in the mth behavioral dimension. The state value is normalized to between 0 and 1 using standardization rules, such as "port active" being marked as 1 and "routing not updated" being marked as 0.

[0184] By using historical configuration instances, timestamps, operation targets, and expected states are embedded into each configuration semantic item in the intent configuration semantic set to construct the expected configuration semantic matrix;

[0185] In this embodiment, based on historical configuration instance records, each configuration semantic item in the intended configuration semantic set is extracted, including the operation command, target interface or network segment, target status (such as "enabled", "blocked", "rate limit"), and specific issuance time, to construct the desired configuration semantic matrix. Where P represents the number of configuration semantic items, and K represents the dimensional features of each semantic item, such as: timestamp (accurate to the second), operation target ID (e.g., interface number), operation type encoding, status label encoding, etc. Each line e_p represents a structured representation of a configuration semantic item. For example, e_p = (2025-05-26 12:30:01, GE0 / 1, shutdown, passive) is mapped to (125631, 11, 4, 2).

[0186] Align the behavior state feature tensor with the desired configuration semantic matrix, perform semantic path mapping, and obtain the behavior semantic alignment matrix;

[0187] In this embodiment, the behavior state feature tensor and the expected configuration semantic matrix are aligned according to the target device and interface. After alignment, state behavior segments with corresponding semantic paths within the same time window are extracted, and a behavior semantic alignment matrix is ​​established. This indicates the actual status response of each configuration semantic item under each behavioral dimension. For example, if the behavioral dimension is "interface closed", a value of 1 should be triggered on the target port. If the alignment fails (e.g., no behavioral status response is detected on the target port), it is marked as a 0 response and included in the count of missed items.

[0188] Based on the behavioral semantic alignment matrix, the semantic offsets of each operation dimension, including the configuration target miss rate, policy execution offset, and operation order perturbation rate, are calculated and fused into a semantic deviation index vector.

[0189] In this embodiment, after obtaining the behavioral semantic alignment matrix, semantic deviation analysis is performed on each semantic item under the operational dimension, calculating three indicators: configuration target miss rate (behavioral dimension misalignment rate), policy execution offset (the proportion of time offset in behavioral response, where offset exceeding 5 seconds is considered significant offset), and operation order disturbance rate (the proportion of misalignment between behavioral response and semantic item issuance order, where the maximum allowable misalignment index between two configurations is set to 1). These three indicators are calculated as vectors. Finally, they are merged into a semantic bias index vector. Used to precisely quantify the degree of deviation for each configuration semantic item.

[0190] The semantic deviation index vector is mapped to each configuration semantic item in the intent configuration semantic set, and the execution deviation, timing delay and policy deviation of each configuration semantic item are associated to generate a configuration result report.

[0191] In this embodiment, each semantic deviation index vector is mapped and associated with the original intent configuration semantic set to obtain a structured configuration result report. The report structure is tabular data, with each row containing: configuration item identifier, target device, operation time, target behavior, actual response status, miss rate, execution offset, sequence disturbance, and comprehensive deviation score. For example, the deviation score of a certain "shutdownG E0 / 1" command is 0.85, indicating that there is a significant timing misalignment of the behavior, and it will be recorded as a potential configuration failure for subsequent operation and maintenance backtracking.

[0192] Optionally, this specification also provides an automatic switch configuration system for executing the automatic switch configuration method described above, the automatic switch configuration system comprising:

[0193] The topology modeling module is used to acquire switch resource configuration data and perform semantically enhanced topology modeling based on the switch resource configuration data to obtain a digital twin model of the network environment.

[0194] The configuration instruction parsing module is used to perform network configuration context reasoning based on the network environment digital twin model and the preset configuration management database to obtain a network configuration intent graph; it parses the network configuration intent graph into configuration instructions and performs executable configuration semantic mapping on the instruction parsing results to obtain an intent configuration semantic set.

[0195] The vendor semantic orchestration module is used to transform the intermediate configuration policy set based on the configuration policy path of the intent configuration semantic set to obtain the intermediate configuration topology matrix, and to perform multi-vendor semantic mapping orchestration on the intermediate configuration topology matrix to obtain the native configuration command set.

[0196] The minimum trust unit verification module is used to perform minimum trust unit verification on each configuration command in the original configuration command set to obtain a fine-grained permission verification command set; based on the fine-grained permission verification command set, identity path integrity audit is performed to obtain a verified signature command set;

[0197] The semantic deviation calculation module is used to upload the verified signature command set to the switch management platform to execute commands; obtain the real-time behavior status data of the switch; perform semantic deviation calculation on the real-time behavior status data of the switch and the semantic set of intent configuration; and obtain a configuration result report.

[0198] Optionally, this specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements the automatic switch configuration method described above.

[0199] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0200] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. An automatic configuration method for a switch, characterized in that, Includes the following steps: Step S1: Obtain switch resource configuration data, and perform semantically enhanced topology graph modeling based on the switch resource configuration data to obtain a digital twin model of the network environment; Step S2: Based on the network environment digital twin model and the preset configuration management database, perform network configuration context reasoning to obtain the network configuration intent graph; parse the network configuration intent graph for configuration instructions, and perform executable configuration semantic mapping on the instruction parsing results to obtain the intent configuration semantic set; Step S3 is as follows: Step S31: Extract configuration strategy paths from the intent configuration semantic set, parse them into configuration target pairs and path attribute constraints, and generate a structured configuration path set; Step S32: Segment each path in the structured configuration path set according to the operation semantics to generate a policy behavior fragment table; Step S33: Construct a node feature matrix based on the configuration semantic tags, dependency order, and resource constraints of the configuration fragments in the policy behavior fragment table, and associate nodes with the device interconnection topology of the network environment digital twin model to generate an intermediate configuration topology matrix; Step S34: Using a preset multi-vendor configuration semantic dictionary, perform command feature template matching on the semantic vectors of each node in the intermediate configuration topology matrix to construct a vendor semantic mapping matrix; Step S35: Based on the manufacturer semantic mapping matrix, the matched command feature templates are fused with the configuration semantic tags to reconstruct the configuration command fragments, and then integrated according to the device brand to obtain a set of configuration command fragments; Step S36: Perform sequential organization, dependency verification, and semantic consistency checks on the configuration command fragment set, and arrange the configuration commands of each vendor's devices according to the execution order and logical grouping method to generate the native configuration command set; Step S4: Perform minimum trust unit verification on each configuration command in the original configuration command set to obtain a fine-grained permission verification command set; Based on the fine-grained permission verification command set, an identity path integrity audit is performed to obtain the verified signature command set; Step S5: Upload the verified signature command set to the switch management platform to execute the command; obtain the switch's real-time behavior status data, perform semantic deviation calculation on the switch's real-time behavior status data and intent configuration semantic set, and obtain a configuration result report.

2. The automatic configuration method for a switch according to claim 1, characterized in that, Step S1 is as follows: Step S11: Obtain the device resource table and link connection table of the switch to be configured, extract the device identifier, port configuration, interface status, connection topology, VLAN division items and existing access control policies, and construct the switch resource configuration data; Step S12: Extract semantic entities and identify topological relationships from switch resource configuration data. Use device type, interface category, and protocol support capabilities as semantic tags to construct a set of semantically labeled nodes and an initial connection relationship edge set, and generate a prototype semantically labeled topological graph. Step S13: Enhance the topology structure based on the semantic annotation topology graph prototype, embed port configuration features in nodes, embed interface status features in edges, and link and merge the subdomain topology in VLAN division with the backbone topology of the semantic annotation topology graph prototype in a subgraph embedding manner to obtain a resource semantic enhancement topology graph. Step S14: Perform structural normalization on the resource semantic enhancement topology graph to obtain the tensor representation enhancement graph; Step S15: Perform network environment simulation modeling based on the tensor representation augmented graph to obtain a digital twin model of the network environment.

3. The automatic configuration method for a switch according to claim 2, characterized in that, Step S13 is as follows: Step S131: Extract the port configuration parameters of each device node in the semantic annotation topology graph prototype from the switch resource configuration data, construct node feature vectors, and add the node feature vectors to the representation tensor of the device nodes in a matrix embedding manner to obtain the port configuration enhanced node set; Step S132: Extract the interface state parameters corresponding to each connection edge in the semantic annotation topology graph prototype in the switch resource configuration data, construct the edge weight vector, and embed the edge weight vector into the representation tensor of each connection edge in the weight tensor encoding method to obtain the interface state enhanced edge set. Step S133: Traverse the VLAN segmentation items in the switch resource configuration data, extract the ports, device nodes and connection relationships associated with the VLAN segmentation items, and thus construct a local subdomain topology map; Step S134: Map the local subdomain topology graph to the semantically labeled topology graph prototype in the form of subgraph embedding, and establish the boundary connection path between subdomain graph nodes and device nodes to obtain the linkage fusion topology structure graph. Step S135: Merge the port configuration enhancement node set, the interface status enhancement edge set, and the linkage fusion topology diagram to obtain the resource semantic enhancement topology diagram.

4. The automatic configuration method for a switch according to claim 1, characterized in that, The network configuration context reasoning in step S2 is as follows: Historical configuration instances, policy templates, device behavior logs, and anomaly repair records are extracted from the preset configuration management database as ontology layers. The configuration rule ontology graph is constructed by modeling the correlation between the configuration semantic roles in the historical configuration instances and the policy templates. The nodes in the digital twin model of the network environment are mapped to the configuration rule ontology graph. The semantic role labels of the nodes in the configuration rule ontology graph are extracted and the entity matching degree is evaluated, thereby constructing a configuration context entity alignment matrix. By combining the obtained network operation and maintenance task scenarios with labeled intent targets, and by identifying subgraph regions in the configuration rule ontology graph that are related to the current intent target, a configuration intent path graph is constructed. Perform semantic consistency and conflict detection on each path in the configuration intent path graph, and retain the configuration paths that pass the constraint verification to form a set of context-valid configuration paths; Cluster and compress structurally similar paths in the set of legal configuration paths in the context, extract common semantic substructures and operation units, and generate a logical configuration unit graph. By combining the configuration context entity alignment matrix and the logical configuration unit graph, semantic translation and encapsulation are performed to obtain the network configuration intent graph.

5. The automatic configuration method for a switch according to claim 1, characterized in that, Step S2, which involves parsing configuration instructions from the network configuration intent graph and mapping the parsing results to executable configuration semantics, specifically includes: Based on the path structure in the network configuration intent graph, the node sequence in each legal configuration path is expanded sequentially and transformed into a triplet of operation target-scope-control condition, thereby obtaining a set of configuration operation unit sequences. Semantically match the triples in the configuration operation unit sequence set with the control command templates in the configuration management database to generate an initial command template matching set; The variable parameter bits existing in the initial instruction template matching set are bound and filled, and context parameters are injected according to the node attributes in the digital twin model of the network environment to obtain a structured configuration instruction set; For each instruction in the structured configuration instruction set, semantic format transcribing is performed according to the syntax specifications of device brand and model in the configuration management database to generate a candidate set of executable commands; Based on the candidate set of executable commands, configuration rule constraints are verified, and command fragments that do not meet the constraints are filtered out to obtain a set of structurally valid configuration commands. Semantic disambiguation and conflict detection are performed on command entries in the structured legal configuration command set. The command sorting is optimized according to the dependency order, and duplicate configurations are removed to generate an intent configuration semantic set.

6. The automatic configuration method for a switch according to claim 1, characterized in that, Step S4 is as follows: Step S41: Perform minimum trust unit division and tag extraction on each command in the native configuration command set to obtain a trust unit tag set; Step S42: Map the trust unit tag set to the preset permission policy graph, perform ternary constraint judgment based on the operation role, command scope and device sensitivity level, and generate a fine-grained permission verification command set; Step S43: Set the context backtracking window size to 30 minutes, backtrack the execution context of the command generation and distribution process for the command entries in the fine-grained permission verification command set, and generate an identity behavior context sequence; Step S44: Construct an identity link graph using the identity behavior context sequence, and perform integrity tracing on each identity node in the identity link graph. Set the identity node continuity tolerance threshold to 1 and the deepest link tracing level to 5 to remove abnormal identity nodes and generate an audit-passed command identity path set. Step S45: Bind the audit pass command identity path set with the fine-grained permission verification command set, and sign and encrypt each binding result to generate an identity binding signature command object set; Step S46: Perform sequence dependency verification on the identity-bound signature command object set to generate a verified signature command set.

7. The automatic configuration method for a switch according to claim 1, characterized in that, The semantic bias calculation in step S5 is as follows: Extract switch behavior features from real-time switch behavior status data and construct a behavior status feature tensor. By using historical configuration instances, timestamps, operation targets, and expected states are embedded into each configuration semantic item in the intent configuration semantic set to construct the expected configuration semantic matrix; Align the behavior state feature tensor with the desired configuration semantic matrix, perform semantic path mapping, and obtain the behavior semantic alignment matrix; Based on the behavioral semantic alignment matrix, the semantic offsets of each operation dimension, including the configuration target miss rate, policy execution offset, and operation order perturbation rate, are calculated and fused into a semantic deviation index vector. The semantic deviation index vector is mapped to each configuration semantic item in the intent configuration semantic set, and the execution deviation, timing delay and policy deviation of each configuration semantic item are associated to generate a configuration result report.

8. An automatic configuration system for a switch, characterized in that, For performing the automatic switch configuration method as described in claim 1, the automatic switch configuration system includes: The topology modeling module is used to acquire switch resource configuration data and perform semantically enhanced topology modeling based on the switch resource configuration data to obtain a digital twin model of the network environment. The configuration instruction parsing module is used to perform network configuration context reasoning based on the network environment digital twin model and the preset configuration management database to obtain a network configuration intent graph; it parses the network configuration intent graph into configuration instructions and performs executable configuration semantic mapping on the instruction parsing results to obtain an intent configuration semantic set. The vendor semantic orchestration module is used to transform the intermediate configuration policy set based on the configuration policy path of the intent configuration semantic set to obtain the intermediate configuration topology matrix, and to perform multi-vendor semantic mapping orchestration on the intermediate configuration topology matrix to obtain the native configuration command set. The minimum trust unit verification module is used to perform minimum trust unit verification on each configuration command in the original configuration command set to obtain a fine-grained permission verification command set; based on the fine-grained permission verification command set, identity path integrity audit is performed to obtain a verified signature command set; The semantic deviation calculation module is used to upload the verified signature command set to the switch management platform to execute commands; obtain the real-time behavior status data of the switch; perform semantic deviation calculation on the real-time behavior status data of the switch and the semantic set of intent configuration; and obtain a configuration result report.

9. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed, implements the automatic configuration method for the switch as described in any one of claims 1-7.

Images