Network verification method and related equipment

Abstract

The invention discloses a network verification method and related equipment so as to provide an interpretable network verification result. The method comprises the following steps: acquiring a network intention, a first configuration file set and a first network topology of a network, wherein the first configuration file set comprises configuration files of a plurality of network devices in the network; performing simulation verification according to the network intention, the first configuration file set and the first network topology to obtain a first traceability graph, the first traceability graph comprising a basic node and a generation node, the basic node indicating configuration information of one of the plurality of network devices, the generation node indicates protocol event information generated based on the configuration information corresponding to the basic node, and the first traceability graph indicates whether the network intention is realized or not.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of network authentication technology, and in particular, to a network authentication method and related equipment. Background Art

[0002] The purpose of network verification is to verify the correctness, security, and performance of the network. Verifying the correctness of the network includes, for example, verifying whether there are routing loops or routing black holes in the network, and verifying whether the traffic between specified devices is reachable or whether the traffic between specified areas is isolated.

[0003] Common network verification includes data plane verification and configuration plane verification. Data plane verification mainly verifies network attributes such as reachability and isolation between nodes in the network based on information such as routing table items and access control lists (ACLs) collected on the device. Configuration plane verification does not require data plane information such as routing table items, and can quickly simulate network behavior based on physical topology and network device configuration information, or solve network attributes including reachability, isolation, loop / black hole existence, etc. without using simulation.

[0004] Current network verification only gives verification results of whether network properties are achieved, but lacks explanations of the causes of the verification results. Summary of the invention

[0005] The present application provides a network verification method and related equipment to solve the problem that current network verification lacks interpretability.

[0006] The first aspect provides a network verification method. The method can be applied to computing devices such as servers, computers, smart phones, tablets, smart wearable devices or car computers. Obtain the network intent, the first set of configuration files and the first network topology of the network, and then perform simulation verification based on the network intent, the first set of configuration files and the first network topology to obtain a first traceability diagram. Among them, the network intent defines the correct network behavior. The first set of configuration files includes configuration files of multiple network devices in the network. The first traceability diagram includes a basic node and a generation node, and the first traceability diagram indicates whether the network intent is realized. Among them, the basic node indicates the configuration information of a network device among multiple network devices, that is, the basic node is created according to the configuration in the configuration file. The generation node indicates the protocol event information generated based on the configuration information corresponding to the basic node, that is, the generation node is created based on the protocol event corresponding to the configuration in the configuration file.

[0007] When performing network simulation verification on the first configuration file set, a corresponding first traceability graph is generated. Since the protocol events corresponding to the generation nodes in the first traceability graph are generated based on the configuration information corresponding to the basic nodes, and whether the network intent can be realized is based on whether the protocol events are accurately realized, the first traceability graph can explain why the first configuration file and the network intent are realized, or why they are not realized, making the network status explainable.

[0008] In a possible implementation, when the first traceability graph indicates that the network intention is not realized, the wrong configuration in the first configuration file set is determined according to the first traceability graph. The basic nodes in the first traceability graph describe the configuration in the configuration file. When there is a configuration error in the configuration file, such as parameter configuration error, multiple configuration or missing configuration, the basic node corresponding to the wrong configuration does not exist in the first traceability graph, or is marked. Therefore, the corresponding wrong configuration node (the basic node indicating the configuration in the configuration file) can be determined from the first traceability graph, and then the configuration corresponding to the wrong configuration node is determined to be a wrong configuration, which can achieve accurate and rapid positioning of the wrong configuration.

[0009] In a possible implementation, the basic nodes of the first source traceability graph include an error configuration node, and the error configuration node includes a first error configuration node and / or a second error configuration node, and the first error configuration node indicates a configuration with an error configuration or a missing configuration of parameters in the first configuration file set. The second error configuration node is a basic node that does not exist in the second source traceability graph, and the configuration corresponding to the second error configuration node is a multi-configuration configuration, which obscures the correct protocol behavior and ultimately causes the network intention to fail to be realized. The second source traceability graph is a source traceability graph indicating that the network intention has been realized, that is, a correct source traceability graph. Determining the error configuration in the first configuration file set according to the first source traceability graph includes: determining that the configuration corresponding to the error configuration node is an error configuration. There is a one-to-one correspondence between the error configuration in the configuration file and the error configuration node in the first source traceability graph, so after determining the error configuration node in the first source traceability graph, the error configuration in the configuration file can be accurately determined according to the correspondence between the error configuration node and the error configuration.

[0010] In one possible implementation, the generation nodes of the first traceability graph include error generation nodes, which indicate unimplemented protocol events caused by incorrect configuration during the simulation verification process, or protocol events that lead to the failure to realize network intent. The first traceability graph is a visual traceability graph, which identifies error paths or error configuration nodes. The error paths include error configuration nodes and error generation nodes. Error configurations have corresponding basic nodes in the first traceability graph. Missing configurations, incorrect or over-configured parameters in the configuration file will cause the protocol behavior that depends on the basic node to fail to occur or fail to occur correctly. This can be reflected as an error generation node in the first traceability graph. Therefore, the error generation nodes corresponding to the unimplemented protocol events can be traced back to the error configuration nodes that caused these protocol events not to occur.

[0011] In a possible implementation, the misconfigured nodes in the first source tracing graph are determined based on the second source tracing graph. When the network intent is not realized, the generated source tracing graph is an incomplete error source tracing graph, and the second source tracing graph is a correct source tracing graph. The second source tracing graph is used as a reference for analysis and comparison with the incomplete error source tracing graph, and the inconsistent generation nodes and basic nodes can be determined. The first source tracing graph can be obtained by modifying the incomplete source tracing graph according to the inconsistent nodes. Thus, it is possible to determine from the first source tracing graph which basic nodes are normal, which basic nodes are misconfigured nodes, which generation nodes indicate protocol events that have occurred accurately, and which generation nodes indicate protocol events that have not occurred accurately. Furthermore, through the first source tracing graph, it is possible to explain why the network intent is not realized, and to quickly and accurately determine the misconfigured nodes.

[0012] In different situations, the source of the second traceability graph is different. For example, if the first traceability graph is obtained by verifying the updated configuration file due to the configuration file update, then the second traceability graph is obtained based on the configuration file before the update. Specifically, the second traceability graph is obtained by simulation verification based on the network intent, the second configuration file set and the first network topology, the second configuration file set includes configuration files of multiple network devices in the network, the first configuration file set includes a first configuration file of the first network device, the second configuration file set includes a second configuration file of the first network device, and the first configuration file is a configuration file used to replace the second configuration file.

[0013] For example, if there is a network device failure or a physical link failure in the network, the network topology will change and the forwarding path of the data packet will also be affected. In this case, the first traceability graph is obtained from the network topology and configuration file after the network failure, and the second traceability graph is obtained from the network topology and configuration file before the network failure. Specifically, the second traceability graph is obtained by simulation verification based on the network intent, the third configuration file set and the second network topology. The first configuration file set includes the configuration file of the second network device, the third configuration file set includes the configuration file of the third network device, the second network topology includes the second network device and the third network device, the first network topology includes the second network device but does not include the third network device, and the second network device is a backup device for the third network device.

[0014] In a possible implementation, when the first traceability graph indicates that the network intention is not realized, a fourth configuration file is obtained, and the fourth configuration file is used to replace the target configuration file in the first file set, and the target configuration file is a configuration file with an incorrect configuration. Further, after determining the incorrect configuration, the incorrect configuration in the target configuration file can be repaired to obtain the correct fourth configuration file.

[0015] In a possible implementation, the erroneous configuration is a configuration that is configured multiple times in the target configuration file, and obtaining the fourth configuration file includes: deleting the erroneous configuration and obtaining the fourth configuration file. That is, for a configuration that is configured multiple times and causes the network intention to fail to be realized, the erroneous configuration can be deleted so that the fourth configuration file obtained after modification is no longer affected by the erroneous configuration, thereby accurately realizing the network intention.

[0016] In one possible implementation, the erroneous configuration is a configuration that is missing or has mismatched parameters in the target configuration file, and obtaining the fourth configuration file includes: obtaining a reference configuration corresponding to the erroneous configuration from a reference configuration file, the reference configuration file is a configuration file that can realize the network intention, the target configuration file is a configuration file of the target network device, the reference configuration file is a configuration file of the main network device of the target network device, or the reference configuration file is a historical configuration file of the target network device; adding the reference configuration to the target configuration file to obtain the fourth configuration file. For configurations that are missing or have incorrect parameter configurations, they may not be deleted, but the correct reference configuration may be added to the target configuration file. When the correct reference configuration exists in the fourth configuration file, the corresponding protocol event may occur, so that the modified fourth configuration file can realize the network intention. The reference configuration can be obtained from an accurate reference configuration file. The reference configuration file is a configuration file that accurately realizes the network intention before the configuration file is updated or before the network topology changes, and can ensure the accuracy of the reference configuration.

[0017] In a possible implementation, simulation verification is performed according to the network intent, the fourth configuration file set and the first network topology, and the fourth configuration file set includes the fourth configuration file. After the target configuration file is repaired, the repaired fourth configuration file can be verified to ensure that the modified configuration file can accurately realize the network intent, thereby improving the stability of the network.

[0018] The second aspect provides a network verification device. The device includes an acquisition module and a processing module. Among them, the acquisition module is used to obtain the network intention, the first configuration file set and the first network topology of the network, and the first configuration file set includes configuration files of multiple network devices in the network. The processing module is used to perform simulation verification according to the network intention, the first configuration file set and the first network topology to obtain a first traceability diagram. The first traceability diagram includes a basic node and a generation node. The basic node indicates the configuration information of a network device among multiple network devices, and the generation node indicates the protocol event information generated based on the configuration information corresponding to the basic node. The first traceability diagram indicates whether the network intention is realized.

[0019] In a possible implementation manner, the processing module is configured to determine, according to the first tracing back graph, an erroneous configuration in the first set of configuration files when the first tracing back graph indicates that the network intention is not realized.

[0020] In a possible implementation, the basic nodes of the first traceability graph include an incorrect configuration node, the incorrect configuration node includes a first incorrect configuration node and / or a second incorrect configuration node, the first incorrect configuration node indicates a configuration in which a parameter in the first configuration file set is incorrectly configured or a configuration in which a configuration is missing, and the second incorrect configuration node is a basic node that does not exist in the second traceability graph, and the second traceability graph is a traceability graph indicating that the network intention has been realized. The processing module is used to determine that the configuration corresponding to the incorrect configuration node is an incorrect configuration.

[0021] In one possible implementation, the generation nodes of the first traceability graph include error generation nodes, which indicate unimplemented protocol events caused by incorrect configuration during the simulation verification process, or protocol events that result in the inability to achieve network intent. The first traceability graph is a visual traceability graph, which identifies error paths or error configuration nodes. The error paths include error configuration nodes and error generation nodes.

[0022] In a possible implementation manner, the misconfigured node in the first provenance graph is determined according to the second provenance graph.

[0023] In one possible implementation, the second traceability graph is obtained by simulation verification based on the network intent, the second configuration file set and the first network topology, the second configuration file set includes configuration files of multiple network devices in the network, the first configuration file set includes a first configuration file of the first network device, the second configuration file set includes a second configuration file of the first network device, and the first configuration file is a configuration file used to replace the second configuration file.

[0024] In a possible implementation, the second traceability graph is obtained by simulation verification based on the network intent, the third configuration file set and the second network topology, the first configuration file set includes the configuration file of the second network device, the third configuration file set includes the configuration file of the third network device, the second network topology includes the second network device and the third network device, the first network topology includes the second network device but does not include the third network device, and the second network device is a backup device of the third network device.

[0025] In a possible implementation, the processing module is used to obtain a fourth configuration file when the first tracing graph indicates that the network intention is not realized, and the fourth configuration file is used to replace the target configuration file in the first file set, and the target configuration file is a configuration file with an incorrect configuration.

[0026] In a possible implementation manner, the wrong configuration is a configuration that is multiple-configured in the target configuration file, and the processing module is used to delete the wrong configuration to obtain a fourth configuration file.

[0027] In a possible implementation, the wrong configuration is a configuration that is missing or parameter mismatched in the target configuration file, and the processing module is used to obtain a reference configuration corresponding to the wrong configuration from a reference configuration file, the reference configuration file is a configuration file that can realize the network intention, the target configuration file is a configuration file of the target network device, the reference configuration file is a configuration file of the main network device of the target network device, or the reference configuration file is a historical configuration file of the target network device. The processing module is used to add the reference configuration to the target configuration file to obtain a fourth configuration file.

[0028] In a possible implementation manner, the processing module is configured to perform simulation verification according to the network intent, a fourth configuration file set, and the first network topology, where the fourth configuration file set includes a fourth configuration file.

[0029] A third aspect provides a network verification device, which includes a processor and a memory, wherein the processor is coupled to the memory, and the processor is configured to execute the network verification method in the first aspect or any possible implementation of the first aspect based on instructions stored in the memory.

[0030] A fourth aspect provides a computer-readable storage medium, which includes instructions, and when the computer-readable storage medium is run on a computer, the computer executes the network verification method in the first aspect or any possible implementation of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A schematic diagram of the structure of a network verification system provided in an embodiment of the present application;

[0032] Figure 2 A schematic diagram of the input and output of the network verification system provided in an embodiment of the present application;

[0033] Figure 3 A schematic diagram of a network and related configuration provided in an embodiment of the present application;

[0034] Figure 4a A schematic diagram of a correct traceability diagram provided in an embodiment of the present application;

[0035] Figure 4b A schematic diagram of an error tracing diagram provided in an embodiment of the present application;

[0036] Figure 5 A schematic diagram of a traceability graph analysis and comparison scenario provided in an embodiment of the present application;

[0037] Figure 6 A schematic diagram of a modified traceability diagram provided in an embodiment of the present application;

[0038] Figure 7 A schematic diagram of providing repair suggestions to a user provided in an embodiment of the present application;

[0039] Figure 8 A flowchart of a network verification method provided in an embodiment of the present application;

[0040] Fig. 9 A schematic diagram of the structure of a network verification device provided in an embodiment of the present application;

[0041] Fig.10 A schematic diagram of the structure of a network verification device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] The embodiments of the present application provide a network verification method and related devices to make the cause of the network status explainable.

[0043] The following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the described embodiments are only embodiments of a part of the present application, rather than all embodiments. It is known to those skilled in the art that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0044] The terms "first", "second", etc. in the specification and claims of this application and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. In the description of this application, unless otherwise specified, the meaning of "plurality" refers to two or more.

[0045] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0046] In order to make the technical solution of the present application easier to understand, the relevant terms involved in the present application are explained below.

[0047] Network verification is used to verify the correctness, security, and performance of the network system. Common network verification technologies include data plane verification (Data Plane Verification) and configuration plane verification (Control Plane Verification). Data plane verification mainly verifies the reachability (Reachability), isolation (Isolation) and other characteristics between nodes in the network based on information such as routing table items and access control lists (ACL) collected on the device. Configuration plane verification does not require data plane information such as routing table items, and can quickly simulate network behavior based on physical topology and network device configuration, or solve properties including reachability, isolation, loop / black hole existence, etc. without using simulation.

[0048] Network intent, which can also be called network attribute, network policy or network specification, is the state or behavior that the network is expected to achieve, which defines the correct network behavior. For example, network intent includes at least one of the following: reachability or isolation between specified network devices, network loop-free, network black hole-free, etc.

[0049] Network simulation verification builds a virtual environment, generates the corresponding data plane by running the same network device firmware and configuration as the real network, and then verifies it using the data plane verification method. In order to improve the configuration verification speed, some verification methods based on graph algorithms have been proposed, such as abstract representation control (ARC) and multi-layer graph abstraction. When verifying the network intent, the verification method based on the graph algorithm abstracts the network configuration into a weighted directed graph. The forwarding path in the graph is consistent with the real network, and the minimum weighted path between the source and destination nodes in the graph is the real data forwarding path. By converting the verification of network intent into graph attribute verification on a weighted directed graph, the verification can be completed quickly using graph algorithms.

[0050] Distributed network architecture refers to an architecture in which the control plane is dispersed on each network device in the network. Network devices in a distributed network contain independent control planes and data planes. The control plane of the network device implements various network protocols based on configuration files, such as border gateway protocol (BGP), interior gateway protocol (IGP), multi-protocol label switching (MPLS), and segment routing (SR). The control plane manages the operation of these network protocols and provides the routing information necessary for the data plane of the network device to forward packets. In short, the control plane calculates routing information based on configuration files and network topology information, and the data plane forwards data packets based on the routing information.

[0051] Data plane verification verifies the consistency of packet forwarding behavior under the data plane with network intent by inputting network intent, data plane information (such as forwarding table or flow table) and network topology.

[0052] Control plane verification verifies the consistency of packet forwarding behavior with network intent under the data plane generated by network intent, control plane information (such as configuration files or software defined network (SDN) programs), and network topology by inputting information such as network intent.

[0053] In recent years, the development of the Internet has led to the emergence of more and more Internet services, such as cloud computing, the Internet of Things, and the Internet of Vehicles. Computer networks are also carrying more and more Internet services, which has led to the increasing scale and complexity of networks and made network management more difficult. If a network failure occurs in the network, it will affect the normal operation of the services it carries, bringing serious risks and losses. Therefore, it is particularly important to ensure the stability and reliability of the network.

[0054] In a distributed network architecture, the network behavior of network devices is implemented based on their configuration files. Misconfigurations in the configuration files of network devices can cause the behavior of network devices to violate the network intent, thus causing network failures. For example, the network intent is that the traffic between device A and device B is reachable, device C and device D are isolated, and the network has no loops or black holes, etc. However, due to misconfigurations, the traffic between node A and node B is unreachable, the traffic between device C and device D is reachable, and loops or routing black holes appear in the network (data packets cannot be accurately sent to the specified node).

[0055] Therefore, verifying the configuration file before a network failure occurs (for example, before deploying the configuration file for the network device, or before the potential misconfiguration in the configuration file deployed in the existing network is triggered) can reduce or avoid the occurrence of network failures. In a distributed network architecture, the configuration file can be verified through the control plane verification tool, that is, inputting information such as network intent, configuration file, and network topology, and verifying whether the network has achieved the network intent based on this information, thereby obtaining the corresponding verification result. If the verification result indicates that the network intent has been achieved, it can be considered that there is no configuration error in the configuration file; conversely, if the verification result indicates that the network intent has not been achieved, it can be considered that there is a configuration error in the configuration file.

[0056] Current control plane verification tools can only provide verification results of whether the network has achieved the network intent based on information such as configuration files and network topology, but lack explanations or descriptions of why the network has achieved the network intent, especially why the network has not achieved the network intent. When the verification results indicate that the network intent has not been achieved, it is impossible to further locate and repair the wrong configuration based on the verification results, resulting in low efficiency in mismatch repair.

[0057] In order to solve the problem that current network verification has poor explanation of the causes of network status, the present application provides the following embodiments.

[0058] like Figure 1 and Figure 2 As shown, Figure 1 A schematic diagram of the structure of a network verification system provided in an embodiment of the present application is provided. Figure 2 A schematic diagram of the input and output of the network verification system provided in an embodiment of the present application. The network verification system of this embodiment can be used to verify the configuration file before the configuration file is deployed, and can also verify the configuration file that has been deployed on the network. It can verify in advance whether there is an incorrect configuration in the configuration file before a network failure occurs, which can reduce the risk of network failure. The network verification system of this embodiment can also be used to verify the configuration file after a network failure, so as to quickly locate and repair the incorrect configuration in the configuration file and reduce the loss caused by the network failure.

[0059] Using the network verification system to verify the configuration file may include but is not limited to the following scenarios:

[0060] Scenario 1: A newly constructed network or a new network device is added to an existing network, and the configuration file for the first configuration of the network device in the network is verified.

[0061] Scenario 2: The configuration files of some or all network devices in the network are updated, and the updated configuration files are verified. The services carried by the network will change, and the configuration files need to be updated to meet the new business requirements. For example, the traffic between device A and device B was originally unreachable, and then the traffic between device A and device B is expected to be reachable, then the configuration files of the corresponding network devices need to be updated to make the traffic between device A and device B reachable. It should be noted that since the control plane of the distributed network architecture is scattered on various network devices in the network, and there are complex interactive relationships between network protocols and network devices, when the configuration files of some network devices in the network are updated, other configuration files that have not been updated may also need to be verified. For example, the updated configuration files and all unupdated configuration files in the network can be verified, that is, when the configuration files of network devices in the network are updated, the configuration files in the network are globally verified to ensure the accuracy and reliability of the network verification. Alternatively, the configuration files of the network devices affected by the updated configuration files in the updated configuration files and all unupdated configuration files in the network are verified, that is, when the configuration files of network devices in the network are updated, the configuration files affected by the update in the network are locally verified, thereby improving the verification efficiency.

[0062] Scenario three: the network topology changes, and the configuration files of the network devices corresponding to the changed network topology are verified on the network. The change in network topology may be the addition of a new physical link in the network. For example, a physical link directly connecting two devices that were not directly connected originally is added. The change in network topology may also be the reduction of network devices or physical links in the network. For example, a network device fails, or a physical link fails, etc. The change in network topology will cause some data planes to fail, so it is possible to verify whether the configuration files still meet the network intent under the changed network topology. The network device or physical link failure here may refer to a real failure. Of course, the network device or physical link failure here may also refer to a hypothetical failure, to verify whether the configuration files can still meet the network intent in the event that the network device or physical link may fail in the future. For example, assume that the reachability between specific network devices can always be established when any k physical links fail.

[0063] Scenario 4: Network maintenance: For configuration files that have been deployed on the network, the network verification system can also be used to verify them, dig out potential misconfigurations that may exist in the deployed configuration files, and prevent network failures from occurring.

[0064] The network verification system provided in this embodiment can simulate and verify the configuration files corresponding to various network protocols, such as network layer routing protocols such as BGP and its derivative protocols, IGP (for example, including open shortest path first (OSPF), intermediate system to intermediate system (IS-IS), routing information protocol (RIP), etc.), tunneling protocols such as SR and MPLS, and data link layer protocols such as virtual local area network (VLAN).

[0065] like Figure 1 and Figure 2 As shown, the input of the network verification system includes one or more network intentions, configuration files of multiple network devices in the network, and the network topology of the network. Optionally, the input of the network verification system also includes environmental information such as external routing announcements from external networks. The output of the network verification system includes a traceability diagram. Optionally, the traceability diagram output by the network verification system is a visual traceability diagram.

[0066] The network described in this embodiment may be a carrier network, a campus network, a government network, an enterprise network, a data center network, or a campus network, etc. The network device may be a router, a switch, or other devices, such as a firewall, a load balancing device, etc., which are not limited here.

[0067] Network intents may include but are not limited to the following types, for example, establishing a network connection between designated network devices, reachability or isolation between designated network devices / areas, no network loops, no network black holes, etc. When the network intent input into the network verification system is one, the network intent may be any of the above types of network intents. When the network intent input into the network verification system is multiple, the multiple network intents may include one or more of the above types of network intents. The number of network intents of a certain type in multiple network intents may be one or more. For example, among multiple network intents, the network intent of the reachability between designated network devices may include traffic reachability from device A to device B, traffic reachability from device C to device D, etc.

[0068] The configuration file input to the network verification system may include configuration files of all network devices in the network (the network corresponding to the input network topology). The configuration file input to the network verification system may also include configuration files of some network devices in the network. For example, the configuration file input to the network verification system is a configuration file of network devices in the network that participate in realizing the network intention. The network devices that participate in realizing the network intention include source network devices, destination network devices, and network devices in the forwarding path between the source network device and the destination network device.

[0069] The configuration file includes the basic configuration of the network device and the configuration of at least one network protocol. The basic configuration includes, for example, the name of the network device, the Internet Protocol (IP) address of the interface of the network device, and the IP address mask. The configurations of different network protocols are different. For example, the configuration of the BGP protocol includes the protocol name, the autonomous system number (AS-number), the device identifier (router-ID), the imported route, the IP address of the peer and its autonomous domain number, and the BGP route attributes, which are not listed here one by one. For example, the configuration of the OSPF protocol includes the area ID, the device identifier, the IP address and mask of the interface, which are not listed here one by one.

[0070] When the configuration file includes configurations of multiple network protocols, the configuration file may also include configurations indicating interactions between network protocols. Exemplarily, network devices in the same area use an IGP protocol (such as an OSPF protocol) to calculate routes. In order to achieve mutual access between two ASs, the BGP protocol may be configured between ASs, and BGP and IGP interaction may be configured on the AS edge network device, that is, the configuration file of the edge network device includes configurations for mutual introduction of BGP and OSPF, so that BGP can be used to efficiently transfer routes to other ASs, and routes outside the AS can be introduced into the IGP to achieve access outside the AS.

[0071] For example, Figure 3 As shown, Figure 3 The network includes directly connected routers A and B, and the network intends to make routers A and B reachable / establish a BGP connection. The configuration file (part) of router A is, for example:

[0072] #

[0073] SysName RouterA (name of router A)

[0074] #

[0075] Interface GE 0 / 0 / 0 (interface name)

[0076] IP address 192.16.1.1 255.255.255.0 (IP address and mask of interface GE 0 / 0 / 0)

[0077] #

[0078] Bgp100 (BGP100 process)

[0079] Router-ID 1.1.1.1 (router ID)

[0080] Peer 192.168.1.2as-number 100 (peer (router B) IP address and its AS number)

[0081] #

[0082] …

[0083] The configuration file (part) of router B is, for example:

[0084] #

[0085] SysName RouterB (name of router B)

[0086] #

[0087] Interface GE 0 / 0 / 0 (interface name)

[0088] IP address 192.168.1.2 255.255.255.0 (IP address and mask of interface GE 0 / 0 / 0)

[0089] #

[0090] Bgp100 (BGP100 process)

[0091] Router-ID 2.2.2.2 (Router ID)

[0092] Peer 192.168.1.1as-number 100 (peer (router A) IP address and its AS number)

[0093] Network 2.2.2.2 255.255.255.255 (introduced route)

[0094] #

[0095] Interface loopback0 (loopback interface)

[0096] IP address 2.2.2.2 255.255.255.255 (loopback interface IP address and mask)

[0097] #

[0098] …

[0099] Understandably, Figure 3 The network shown includes two network devices and adopts the simplest network topology. This is to make the technical solution of the present application concise and easy to understand. It should not be understood that the present application can only be based on Figure 1 The network implementation shown in the figure. In practice, the network has more network devices and the network topology is more complex. The network devices specified in the network intent can be connected through other network devices, and the specified network devices can be located in different AS domains. This solution is also applicable in these scenarios.

[0100] like Figure 1 As shown, the network verification system of this embodiment may include a simulation verification module, a traceability graph generation module and an interaction module.

[0101] The interaction module is used to obtain network intent, network topology, and configuration files, etc. For example, the interaction module obtains one or more network intents, a first network topology, and a first configuration file set. Among them, at least one of the network intent, network topology, and configuration file can be input by the user to the interaction module. Alternatively, the network topology and configuration file can also be stored in a storage system (not shown) in advance, and the interaction module obtains it from the storage system. Alternatively, the network verification system connects the network devices in the network with verification, and the interaction module can collect the network topology and configuration files from the network.

[0102] The simulation verification module performs simulation verification according to the first network topology of the network and the first network configuration file set to verify whether the network based on the first network configuration file set and the first network topology can realize each network intention. The first configuration file set includes configuration files of multiple network devices in the network corresponding to the first network topology. The first configuration file set may include configuration files of all network devices in the network corresponding to the first network topology. The first configuration file set may also include configuration files of some network devices in the network.

[0103] The simulation verification module models the control plane protocol behavior of the network device (such as protocol convergence behaviors such as route announcement, route selection, route aggregation, route redistribution and filtering) based on the control plane information such as the first network topology and the first configuration file set, and generates the forwarding table items (data planes) corresponding to the network device. In this embodiment, the data plane can be generated on demand. That is, there is no need to generate a full amount of data planes, but only generate data planes related to prefixes that the user cares about. The prefixes that the user cares about can be obtained from the network intent. Then the simulation verification module uses the forwarding table items of the network device to simulate the data packet forwarding behavior of the data plane according to each network intent, to verify whether the network correctly implements each network intent. Through the simulation verification module, it is possible to verify whether the first configuration file set has implemented the corresponding network intent, that is, whether the configuration file is accurate.

[0104] The traceability graph generation module generates a traceability graph during the simulation verification process of the simulation verification module. The traceability graph generation module can generate a corresponding traceability graph for the simulation verification process of each network intent. Among them, the traceability graph is used to explain why the first set of configuration files realizes the network intent or why it does not realize the network intent. Since the network intent is often verified on the data plane, when verifying the network intent, the process of generating the data plane according to the first set of configuration files and the first network topology does not need to be repeatedly modeled, that is, the protocol convergence behaviors such as routing announcements, routing selection and filtering in the control plane can be reused in the process of constructing traceability graphs corresponding to different network intents, thereby reducing the complexity and workload of simulation verification and improving the efficiency of simulation verification.

[0105] Specifically, the traceability graph in this embodiment can be a directed acyclic graph, and the traceability graph includes multiple nodes and directed edges. A directed edge connects two nodes with a causal relationship, and the directed edge points from the cause node to the result node. Among them, there can be multiple directed edges in the traceability graph starting from one node and pointing to other different nodes respectively, that is, there can be a node that is the cause node of multiple other nodes. There can also be multiple directed edges in the traceability graph starting from different other nodes and pointing to the same node, that is, there can be multiple nodes that are all cause nodes of a node, and multiple cause nodes are necessary but not sufficient conditions for the establishment (existence) of the result node. In the traceability graph, there are also nodes that are the result nodes of one or more nodes, and the cause nodes of another one or more nodes.

[0106] In this embodiment, the multiple nodes in the source tracing diagram may include two types: basic nodes and generated nodes. Among them, the basic node indicates the configuration information of a network device among multiple network devices. The basic node is a fact that already exists in the configuration file and the network topology before the source tracing diagram generation module performs simulation verification. The basic nodes are all cause nodes of the generated nodes connected to the basic nodes. The configuration information indicated by the basic node can be the configuration in the configuration file of a network device (also referred to as a command line), that is, the configuration information indicated by the basic node can come from the configuration file. The configuration information indicated by the basic node can also be a physical link between a network device and a directly connected network device, that is, the information indicated by the basic node can come from the first network topology. The source tracing diagram often includes multiple basic nodes, and the multiple basic nodes may include nodes composed of configurations from the configuration file, and may also include nodes composed of physical links from the first network topology.

[0107] The generation node indicates the protocol event information generated based on the configuration information and / or physical link corresponding to the basic node. Specifically, the protocol event information indicated by the generation node is the one that occurs during the simulation verification process according to the first configuration file set and the first network topology. The protocol event information indicated by the generation node is the event generated by the network protocol corresponding to the running configuration file during the simulation verification process, which may include protocol convergence event information and data packet forwarding event information. The event indicated by the generation node is a key event that affects whether the network intention can be realized. A generation node represents a phased event that has occurred or is expected to occur during the simulation verification process. For example, the generation node can represent the start of the protocol process, the release of the routing prefix, the receipt of the routing prefix released by other network devices, the introduction (import) of the route, the selection of the route, the sending of the data packet, and the receipt of the data packet from other network devices, etc. The protocol event information indicated by the generation node also includes the verification result information of whether the corresponding network intention is realized. When the traceability graph is complete, the traceability graph only includes a generation node indicating the verification result information, and it is the root node in the traceability graph.

[0108] By aggregating configuration information and protocol event information with causal relationships, they are represented as basic nodes and generation nodes in the traceability graph, and directed edges are used to connect the causal basic nodes with the generation nodes, and the generation nodes with the generation nodes, so as to obtain the traceability graph. If the protocol event corresponding to a certain generation node depends on the configuration information corresponding to one or more basic nodes and / or the occurrence of protocol events corresponding to one or more generation nodes, then the generation node has a causal relationship with all the basic nodes and / or generation nodes on which it depends. For example, the configuration file includes the configuration for starting (creating) a BGP process. During the simulation verification process, because the configuration for starting the BGP process in the configuration file simulates that the network device creates the corresponding BGP process, there is a causal relationship between the basic node corresponding to the configuration for starting the BGP process and the generation node corresponding to the creation of the BGP process.

[0109] Both protocol convergence and data packet forwarding require interaction and coordination between multiple network devices. Therefore, the traceability graph includes not only basic nodes and generation nodes corresponding to one network device, but also basic nodes and generation nodes corresponding to multiple network devices. Generation nodes and basic nodes can also include network device information to indicate which network device the node comes from. There can also be a causal relationship between basic nodes and generation nodes from different network devices. The basic node that has a causal relationship with the generation node can come from the configuration of the configuration file of the same network device, or from the configuration of the configuration files of multiple network devices. The generation node that has a causal relationship with the generation node can include protocol events generated from the same network device, or protocol events generated by other network devices.

[0110] The traceability diagram is an abstract representation of the simulation verification process, so the traceability diagram can explain why the network intention is realized or why it is not realized. Through the traceability diagram, we can know which protocol events occurred during the simulation verification process and which protocol events did not occur. The failure of key protocol events will lead to the failure to realize the network intention. Protocol events occur directly or indirectly based on the configuration in the configuration file, so the protocol events that did not occur can be traced back to the corresponding incorrect configuration. If the traceability diagram is a traceability diagram that realizes the network intention based on the first configuration file set and the first network topology, it means that the configuration used to realize the network intention in the configuration file is correct, there is no mismatch or omission, the traceability diagram is a complete diagram, the basic nodes and the generated nodes are correct and complete, and the traceability diagram can explain why the network intention can be realized. If the traceability diagram is a traceability diagram that does not realize the network intention based on the first configuration file set and the first network topology, the correct protocol event did not occur due to the incorrect configuration in the configuration file. In this case, the traceability diagram is an incomplete diagram.

[0111] For example, Figure 4a and Figure 4bAs shown, Figure 4a A schematic diagram of a correct traceability diagram provided in an embodiment of the present application, Figure 4b A schematic diagram of an error tracing diagram provided in an embodiment of the present application. Figure 4a The traceability diagram shown is based on Figure 3 The network topology and configuration files shown in the figure show that the network intention is that A is reachable to B (2.2.2.2). It can be understood that Figure 3 The network topology, configuration and parameters in the configuration file are examples for easy understanding of the solution. Due to the limited space of the image, Figure 4a and Figure 4b The provenance graph in can be considered as a local provenance graph. Figure 4a and Figure 4b The nodes in the traceability graph shown do not necessarily require these nodes to appear in the actual traceability graph, or only these nodes to appear. That is, in practice, the traceability graph may not need to appear. Figure 4a and Figure 4b All nodes shown in the diagram, and nodes with other meanings may also appear in the traceability diagram. The example in this embodiment takes the BGP protocol as an example, and this solution is also applicable to protocols such as IGP, SR, MPLS, and VLAN. Figure 4a In the traceability diagram shown, the square box represents the basic node, and the circular box represents the generated node. The shapes of the basic node and the generated node here are only examples and should not be understood as limitations on the present application. Figure 4a and Figure 4b In the basic node, "cfg" is the abbreviation of configuration, indicating that the configuration information indicated by the node comes from the configuration file, reality indicates that the information indicated by the node comes from the network topology, and event indicates a protocol event. Figure 4a The root node indicates that the network intent "A is reachable to B (2.2.2.2)" is realized. To realize this network intent, at least the following key protocol events need to be executed:

[0112] 1. Router B publishes the BGP route 2.2.2.2 255.255.255.255 (sometimes abbreviated as 2.2.2.2 / 32 in this application). The prerequisites for the occurrence of this protocol event include: a. The loopback interface in the configuration file of router B is configured with the IP address and prefix of 2.2.2.2 (Interface loopback0 IP address 2.2.2.2 255.255.255.255); b. The BGP process (Bgp100) is configured in the configuration file of router B; c. The command to introduce the route 2.2.2.2 255.255.255.255 is configured in the BGP process in the configuration file of router B (Network 2.2.2.2 255.255.255.255).

[0113] 2. Router B establishes a BGP peer relationship with Router A. The prerequisites for this protocol event to occur include: a. There is a physical link between Router A and Router B (Router A and Router B are directly connected in the network topology); b. The BGP process (Bgp100) is configured in Router A's configuration file; c. The IP address and AS domain of the peer (Router B) are configured in the BGP process in Router A's configuration file (Peer 192.168.1.2as-number 100), and the IP address and AS domain of the peer (Router A) are configured in the BGP process in Router B's configuration file (Peer 192.168.1.1as-number 100).

[0114] 3. Router B passes the 2.2.2.2 / 32 route to Router A through BGP. The prerequisites for this protocol event to occur include: a. Router A and Router B have established a peer relationship; b. Router B publishes the 2.2.2.2 / 32 BGP route.

[0115] 4. Router A receives the route to 2.2.2.2 / 32. The prerequisites for this protocol event to occur include: Router B passes the 2.2.2.2 / 32 route to Router A through BGP.

[0116] 5. Router A selects route 2.2.2.2 / 32, so Router A has a route to 2.2.2.2. The prerequisites for this protocol event to occur include: a. Router A introduces BGP protocol route 2.2.2.2 / 32; b. Other protocols do not have routes to 2.2.2.2, or the priority of this route is higher than that of other routes to 2.2.2.2, so Router A can select route 2.2.2.2 / 32.

[0117] 6. Router A is reachable to Router B (2.2.2.2). The prerequisites for this protocol event to occur include: a. There is a physical link between Router A and Router B; b. Router A has a route 2.2.2.2 / 32 to 2.2.2.2.

[0118] It can be seen that the ultimate realization of network intent depends on the correct occurrence of key protocol events, and the correct occurrence of key protocol events depends on the correct configuration in the configuration file.

[0119] Exemplarily, the process of generating a traceability graph is as follows:

[0120] The configuration file of Router B includes the configuration of "Interface loopback0 IP address 2.2.2.2255.255.255.255". The IP address and mask configured for the loopback interface of Router B can be considered as Router B configuring the direct route 2.2.2.2 / 32. Since the direct route has the highest priority in the route selection process, the direct route 2.2.2.2 / 32 will be added to the forwarding information base (FIB) of Router B. Therefore, the verification simulation module simulates Router B to generate the protocol event "Router B FIB has 2.2.2.2 / 32 route" according to the configuration. Accordingly, the traceability graph generation module creates the basic node 1 corresponding to the configuration "Interface loopback0 IP address 2.2.2.2255.255.255.255", and the generation node 1 corresponding to "Router B's FIB has 2.2.2.2 / 32 route", and connects the basic node 1 and the generation node 1 through a directed edge (from the basic node 1 to the generation node 1).

[0121] The configuration file of router B includes the BGP process configuration "BGP100". The simulation verification module simulates router B to generate a protocol event to establish a BGP process based on the configuration. Accordingly, the traceability graph generation module creates the basic node 2 corresponding to the configuration "BGP100" and the generation node 2 corresponding to the protocol event "establishing a BGP process", and connects the basic node 2 and the generation node 2 through a directed edge (from the basic node 2 to the generation node 2).

[0122] The configuration file of router B includes the configuration of the BGP process, which includes the configuration of the imported route "Network2.2.2.2 255.255.255.255", and because router B has established the BGP process, the route 2.2.2.2 / 32 exists in the FIB of router B. The simulation verification module simulates router B publishing the route 2.2.2.2 / 32 to BGP. Accordingly, the traceability graph generation module generates the basic node 3 according to the configuration "Network 2.2.2.2 255.255.255.255", and generates the corresponding generation node 3 according to the protocol event "Router B publishes the route 2.2.2.2 / 32 to BGP", and connects the basic node 3, the generation node 1, the generation node 2 and the generation node 3 through directed edges (the basic node 3 points to the generation node 3, the generation node 1 points to the generation node 3, and the generation node 1 points to the generation node 3). The principles for establishing other basic nodes and generating nodes in the traceability graph, as well as the principles for generating directed edges between nodes are similar to the above description and will not be elaborated here.

[0123] like Figure 4b As shown in the figure, when the configuration "Network2.2.2.2255.255.255.255" for introducing routes is missing in the BGP process of the configuration file of router B, the protocol event "Router B publishes the 2.2.2.2 / 32 route to BGP" cannot occur, and other events that depend on the protocol event "Router B publishes the 2.2.2.2 prefix to BGP" cannot occur either. The network intention cannot be achieved, and there is no corresponding generation node in the incomplete error tracing graph.

[0124] Optionally, in order to make the traceability graph of unrealized network intent more clearly and accurately explain the cause of unrealized network intent, the network verification system also includes a traceability graph differential analysis module. The traceability graph differential analysis module is used to perform differential analysis on the traceability graph that realizes the network intent (hereinafter referred to as the correct traceability graph) and the traceability graph that does not realize the network intent (hereinafter referred to as the wrong traceability graph), determine the inconsistent nodes and directed edges in the correct traceability graph and the wrong traceability graph, and modify the wrong traceability graph based on this to obtain a modified traceability graph. Inconsistent nodes and directed edges are marked in the modified traceability graph, so that the wrong basic nodes can be intuitively located through the modified traceability graph.

[0125] The correct traceability diagram can be obtained by the network verification system based on the configuration file and network topology before the network change, verifying the network intent that is the same as the incorrect traceability diagram. The correct traceability diagram can be obtained by the network verification system verifying the network topology and configuration file before the network change before the network change, and the traceability diagram differential analysis module can read the correct traceability diagram. The correct traceability diagram can also be obtained after the network changes, by inputting the network topology and configuration file before the change and the network topology and configuration file after the change into the network verification system respectively, and the network verification simulates and verifies the network topology and traceability diagram before and after the change and generates the corresponding traceability diagram. Then, when the changed configuration file and network topology cannot realize the network intent, the traceability diagram differential analysis module performs differential analysis on the correct traceability diagram before the network change and the incorrect traceability diagram after the network change. The network change can refer to the update of the network device configuration file in the network (the above situation two), or it can refer to the change of network topology (the above situation three).

[0126] For example, in the above scenario 2, the configuration file of at least one network device in the network is updated, and the first configuration file set includes the updated configuration file and the configuration files of all other network devices or part of the network devices in the network, and the network topology and network intent have not changed. Assuming that the network intent i is not realized due to an incorrect configuration in the updated configuration file, the traceability graph generation module generates an error traceability graph indicating that the network intent i is not realized. The process of generating a correct traceability graph is that the simulation verification module performs simulation verification according to one or more network intents, the second configuration file set and the first network topology, and the traceability graph generation module generates one or more correct traceability graphs corresponding to the network intent during the simulation verification process. The configuration files in the second configuration file set are the configuration files before the update. The traceability graph differential analysis module obtains the error traceability graph corresponding to the network intent i, and obtains the correct traceability graph corresponding to the network intent i from the correct traceability graph corresponding to one or more network intents, and then performs differential analysis on the correct traceability graph and the error traceability graph corresponding to the network intent i.

[0127] For example, in the above scenario three, when a failure occurs in the network (including a network device failure and a physical link failure between network devices), the network topology will change. In order to ensure the stability of the network, it is necessary that the network can still realize the network intention when a failure occurs in the network. Therefore, a primary and backup network device will be set in the network. When the primary network device fails or the physical link connected to the primary network device fails, the backup network device will be enabled. In order to ensure that the backup network device can also realize the network intention, it is necessary to verify based on the changed network topology. Before and after the network change, the network intention remains unchanged, the network topology changes, and the configuration file used changes. The network topology changes from the second network topology to the first network topology, the second network topology includes the nodes corresponding to the primary network device, and the first network topology includes the nodes corresponding to the backup network device but does not have the nodes corresponding to the primary network device. The third configuration file set before the network change can be the same as the first configuration file set after the network change, that is, the first configuration file set includes the configuration file of the primary network device (but it will not be used during the simulation verification process), and the third configuration file set can also be different from the first configuration file set, that is, the first configuration file set does not include the configuration file of the primary network device.

[0128] In this case, the process of generating a correct traceability graph is that the simulation verification module performs simulation verification according to one or more network intentions, the third configuration file set and the second network topology, and the traceability graph generation module generates one or more correct traceability graphs corresponding to the network intentions during the simulation verification process. The traceability graph differential analysis module obtains the wrong traceability graph corresponding to the network intention j, and obtains the correct traceability graph corresponding to the network intention j from the correct traceability graph corresponding to the one or more network intentions, and then performs differential analysis on the correct traceability graph and the wrong traceability graph corresponding to the network intention j.

[0129] Since protocol events occur directly or indirectly based on the configuration in the configuration file, one protocol event can be the basis for another protocol event. If there is an incorrect configuration in the configuration file, the incorrect configuration will cause the correct protocol event not to occur, which in turn will cause other protocol events that depend on the protocol event not to occur, ultimately resulting in the failure to achieve the network intent. Alternatively, the error event generated by the incorrect configuration masks the correct protocol event, resulting in the failure of the correct protocol event to take effect. For example, the network intent is that device X (source) → device Y → device Z (destination) is reachable. If the administrator mistakenly configures a higher priority static or direct route in the configuration file of device Y, causing device Y to not select the route of device Z, and then there is no route to device Z in the forwarding table entry that device Y does not have, then the data flow will terminate on device Y, or be mistakenly forwarded to other places instead of forwarded to device Z, resulting in the failure to achieve the network intent. Incorrect configuration can include parameter configuration errors, missing configurations, and multiple configurations. In the traceability graph, the incorrect protocol event that is not implemented lacks the corresponding generation node in the error traceability graph.

[0130] Therefore, by comparing the correct tracing diagram and the error tracing diagram, the inconsistent nodes in the correct tracing diagram and the error tracing diagram can be determined. Inconsistent nodes may include error generation nodes and wrong basic nodes. The error generation node is a node corresponding to the unimplemented protocol event caused by the wrong configuration during the simulation verification process. The error generation node may include a generation node that exists in the correct tracing diagram but does not exist in the error tracing diagram (hereinafter referred to as the first error generation node), and may also include a generation node that exists in the error tracing diagram but does not exist in the correct tracing diagram (hereinafter referred to as the second error generation node). Since the network topology represents the real network connection status, it belongs to environmental information, and the factor that affects whether the network intention is realized or not is the configuration file, therefore, the wrong basic node is also referred to as an error configuration node in this application, indicating the wrong configuration in the configuration file. In this embodiment, the basic node from the configuration file is also referred to as a configuration node. The error configuration node may include two categories, one is a configuration node that exists in the correct tracing diagram but does not exist in the error tracing diagram (hereinafter referred to as the first error configuration node), and the other is a configuration node that exists in the error tracing diagram but does not exist in the correct tracing diagram (hereinafter referred to as the second error configuration node). The first error configuration node indicates an error configuration or a missing configuration of a parameter configuration of a configuration file in the first configuration file set. The second error configuration node indicates an over-configuration configuration of a configuration file in the first configuration file set.

[0131] When modifying the error tracing graph, for the first error generating node / first error configuration node, the first error generating node / first error configuration node and its corresponding directed edges can be filled into the error tracing graph. In another implementation, the properties of the first error generating node / first error configuration node can also be modified and then filled into the error tracing graph, that is, the correct protocol behavior described by the first error generating node / first error configuration node is modified to an incorrect protocol behavior that makes it impossible to achieve the network intention. For example, in the correct tracing graph, the protocol event described by the first error generating node is "A has a route to 2.2.2.2", and after modifying its properties, it is "A does not have a route to 2.2.2.2"; the protocol event described by the first error generating node is "A is reachable to B (2.2.2.2)", and after modifying its properties, it is "A is unreachable to B (2.2.2.2)"; the first error configuration node is "B#network 2.2.2.2 / 32", and after modifying its properties, "B is missing#network 2.2.2.2 / 32". For the second error generating node and the second error configuring node, they may be retained.

[0132] For example, Figure 5 As shown, Figure 5 When the main network device RSG1 fails, the backup network device RSG2 cannot realize the network intention due to configuration errors. By performing differential comparison between the correct traceability diagram generated by simulating and verifying the network topology and configuration files before the failure and the error traceability diagram generated by simulating and verifying the network topology and configuration files after the network failure, the modified error traceability diagram can be obtained, and the error configuration node can be located, and then the configuration corresponding to the error configuration node can be determined to be an error configuration.

[0133] The modified error traceability graph is a traceability graph with a complete structure. The serially connected error configuration nodes and error generation nodes (including the root node, i.e., the generation node indicating that the network intention is not realized) in the modified error traceability graph can be determined as an error path. That is, the error path includes leaf nodes (error configuration nodes) and root nodes (error generation nodes indicating that the network intention is not realized), as well as intermediate nodes (error generation nodes) and directed edges connecting the leaf nodes and the root nodes. The error configuration nodes in the error path represent the error configuration that causes the network intention to fail to be realized. Therefore, the modified traceability graph can indicate which network devices have configuration files with error configurations. According to the error path, it can explain why the first configuration file set did not realize the network intention, and can also accurately locate the error configuration in the target configuration file (configuration file with error configuration), so as to facilitate the rapid repair of the error configuration.

[0134] Optionally, the traceability graph differential analysis module can mark the error path in the modified error traceability graph, or mark the error configuration node in the error path in the modified error traceability graph. Thus, when the modified traceability graph needs to be visualized later, the error path or the error configuration identifier in the error path can be visualized according to the mark.

[0135] Optionally, the interactive module can provide a user graphical interface, through which the user can input network topology, configuration files, network intent, etc. to the network verification system. After the network verification system completes the verification, the modified network traceability diagram can be displayed to the user through the user graphical interface. In the modified network traceability diagram in the user graphical interface, the error path or the incorrectly configured node in the error path is identified to prompt the user that there is an incorrect configuration in the configuration file, and the user can be informed of which specific configuration is wrong. Methods for identifying an error path or an incorrectly configured node in an error path include, but are not limited to, flashing, displaying different colors, fonts, sizes or shapes, or adding a prompt box next to the error path or the incorrectly configured node in the error path, or adding a prompt box next to the error path or the incorrectly configured node in the error path, etc.

[0136] For example, Figure 6 As shown, Figure 6 The traceability diagram in the figure is a visualized modified error traceability diagram, in which the error path is marked by a dotted box, which can intuitively explain to the user the cause of the failure to realize the network intention and the incorrect configuration that prevented the network intention from being realized.

[0137] In one possible implementation, the modified network traceability diagram can be directly displayed on the user graphical interface after the verification is completed. In another possible implementation, the modified network traceability diagram can also be displayed on the user graphical interface in response to the user's operation. Exemplarily, in a possible scenario, after the verification is completed, the user graphical interface displays the verification results of the unrealized network intentions, and the user can select one or more unrealized network intentions through the mouse, keyboard, touch, voice or gesture, and then the user graphical interface displays the corresponding modified traceability diagram.

[0138] Optionally, the user graphical interface may also display at least one of a traceability diagram for realizing the network intention, a correct traceability diagram, an incomplete error traceability diagram, and a verification result of whether the network intention is realized.

[0139] Optionally, the network verification system may further include a mismatch repair module. The mismatch repair module is used to determine a repair method for repairing the misconfiguration in the configuration file. When the misconfigured node in the error path is the second misconfigured node, the repair method may be to delete the misconfiguration corresponding to the misconfigured node in the target configuration file.

[0140] When the incorrect configuration node in the error path is the second incorrect configuration node, the repair method may be to add a reference configuration in the target configuration file. Optionally, in addition to adding the reference configuration in the target configuration file, the repair method may also delete the incorrect configuration corresponding to the incorrect configuration node in the target configuration file. Among them, the reference configuration can be obtained from the reference configuration file, and the configuration corresponding to the incorrect configuration node in the reference configuration file is used as the reference configuration. For example, if the incorrect configuration node is "B is missing network 2.2.2.2 / 32", then obtain the configuration "network 2.2.2.2255.255.255.255" from the reference configuration file as the reference configuration.

[0141] The reference configuration file is a configuration file that can realize the network intention. Hereinafter, the network device with incorrect configuration will be referred to as the target network device, and the configuration file of the target network device is the target configuration file. In different situations, the reference configuration file in this embodiment is different. In the above-mentioned situation two, that is, the situation of updating the configuration file of the target network device, the target configuration file is the configuration file updated by the target network device, and the reference configuration file is the historical configuration file of the target network device. The historical configuration file can be the configuration file to be replaced by this update, or it can be a configuration file of other versions before this update. In the above-mentioned situation three, that is, the situation where the main network device fails or the physical link connecting the main network device fails, the target configuration file is the configuration file of the slave network device (target network device) of the main network device, and the reference configuration file is the configuration file of the main network device.

[0142] In a possible implementation, the mismatch repair module may output a repair suggestion, which includes the above-mentioned repair method. The repair suggestion may be displayed in a user graphical interface to provide the user with modification ideas. For example, Figure 7 As shown, when the route "network 2.2.2.2 255.255.255.255" is introduced due to the missing configuration file, a configuration suggestion "add configuration 'network 2.2.2.2 255.255.255.255'" is provided. Optionally, the user graphical interface may also provide an automatic repair option. After the user inputs an instruction to agree to the automatic repair, the mismatch repair module may use the corresponding repair method to repair the target configuration file to obtain a fourth configuration file. For example, the mismatch repair module deletes the erroneous configuration in the target configuration file to obtain the fourth configuration file. Alternatively, the mismatch repair module adds a reference configuration to the target configuration file to obtain the fourth configuration file. Alternatively, the mismatch repair module adds a reference configuration and deletes the erroneous configuration in the target configuration file. Optionally, after obtaining the fourth configuration file, the fourth configuration file may also be displayed through the user graphical interface.

[0143] In another implementation, the repair suggestion may not be displayed through the user interface. After the mismatch repair module repairs the target configuration file to obtain the fourth configuration file, the fourth configuration file is displayed through the user graphical interface, and the user is asked through the user graphical interface whether to agree to the repair.

[0144] Optionally, after obtaining the fourth configuration file, the network verification system can also perform verification again. The network verification system performs simulation verification according to the network intent, the fourth configuration file set and the first network topology, and the fourth configuration file set includes the fourth configuration file to verify whether the fourth network configuration file can realize the network intent. The traceability graph generation module generates the corresponding traceability graph during simulation verification, which will not be repeated here.

[0145] During the re-verification, only the unrealized network intents may be verified, thereby improving the verification efficiency. Alternatively, all network intents may be re-verified to verify whether the fourth configuration file affects the realization of other network intents.

[0146] It can be understood that when there are multiple incorrect configurations in the configuration file, the traceability graph differential analysis module can determine multiple incorrect configuration nodes by analyzing and comparing the correct traceability graph and the incorrect traceability graph, and the mismatch repair module can obtain the repair method of each incorrect configuration from the corresponding reference configuration file based on the multiple incorrect configuration nodes. When there are multiple unrealized network intentions, they can be verified together after all incorrect configurations are repaired.

[0147] In one possible implementation, the network verification system can be deployed on a cloud server, and when a user needs to use the network verification system, the network verification system is called on a terminal device. In another possible implementation, the network verification system can be deployed on a terminal device, and the user uses the network verification system on the terminal device to verify the configuration file.

[0148] In this embodiment, a traceability graph is generated during the simulation verification process, and the traceability graph describes the configuration and network topology in the configuration file, as well as the protocol events generated based on the configuration file and the network topology, so that the traceability graph can explain which configurations exist and which protocol events occur, making it explainable whether the network intention is realized. When the network intention is not realized, by performing a differential comparison between the error traceability graph and the correct traceability graph, the wrong configuration node can be determined and the root cause can be located. Furthermore, after determining the wrong configuration, the repair method can be automatically determined based on the correct reference configuration file, so that the wrong configuration can be repaired quickly and accurately, improving the repair efficiency.

[0149] like Figure 8 As shown, Figure 8A flowchart of a network verification method provided in an embodiment of the present application. The execution subject of this embodiment can be a server, a computer, a tablet computer, a smart phone or other electronic device with computing power. This embodiment includes the following steps:

[0150] S801: Acquire a network intent, a first configuration file set, and a first network topology of a network, where the first configuration file set includes configuration files of multiple network devices in the network.

[0151] The meanings of the network intent, the first configuration file set, and the first network topology can be found in the above related descriptions and will not be repeated here.

[0152] S802: Perform simulation verification according to the network intent, the first configuration file set and the first network topology to obtain a first traceability graph, wherein the first traceability graph includes a basic node and a generation node, wherein the basic node indicates configuration information of a network device among multiple network devices, and the generation node indicates protocol event information generated based on the configuration information corresponding to the basic node, and the first traceability graph indicates whether the network intent is realized.

[0153] A simulation verification is performed according to the network intent, the first set of configuration files, and the first network topology, and a first traceability graph is obtained during the simulation verification process. In this embodiment, the first traceability graph may be a traceability graph corresponding to the realization of the network intent, that is, a correct traceability graph. The first traceability graph may also be a traceability graph corresponding to the unrealized network intent, that is, an error traceability graph. When the first traceability graph is an error traceability graph, the first traceability graph may be the incomplete error traceability graph mentioned above, or it may be the modified error traceability graph mentioned above.

[0154] When the network intention is not realized and the first traceability graph is a modified error traceability graph, the error configuration in the first configuration file set can be determined according to the first traceability graph. For determining the error configuration in the first configuration file set according to the first traceability graph (modified error traceability graph), please refer to the above related description, which will not be repeated here.

[0155] The first traceability graph can be visualized and displayed on a graphical user interface. The visualized first traceability graph can identify the error path or the misconfigured node in the error path, so that the user can intuitively determine the misconfiguration that causes the network intention to not be realized.

[0156] In this embodiment, the first traceability graph is obtained according to the second traceability graph, and the second traceability graph is the correct traceability graph described in the network verification system embodiment. The first traceability graph and the second traceability graph are traceability graphs corresponding to the same network intent. The second traceability graph is a traceability graph corresponding to the realization of the network intent, so the second traceability graph can be used as a reference to determine the inconsistent nodes in the error traceability graph, and the error traceability graph can be modified according to the inconsistent nodes to obtain the first traceability graph. Among them, the second traceability graph can be a traceability graph obtained based on the configuration file before the update when the configuration file is updated. The second traceability graph can also be a traceability graph obtained based on the changed network topology when the network topology changes. The specific method of obtaining the second traceability graph can refer to the method of obtaining the correct traceability graph described in the network verification system embodiment, which will not be repeated here.

[0157] Optionally, after determining the wrong configuration node according to the first traceability graph, the wrong configuration in the target configuration file with the wrong configuration may be further modified to obtain a fourth configuration file. The method for repairing the target configuration file to obtain the fourth configuration file can refer to the above description, which will not be repeated here.

[0158] Optionally, after obtaining the fourth configuration file, verification may be performed based on a fourth configuration file set including the fourth configuration file, the first network topology and the network intent to verify whether the network intent can be achieved based on the fourth configuration file, that is, whether the fourth configuration file is accurate.

[0159] In this embodiment, a traceability graph is generated during the simulation verification process, and the traceability graph describes the configuration and network topology in the configuration file, as well as the protocol events generated based on the configuration file and the network topology, so that the traceability graph can identify which protocol events occurred and which protocol events did not occur. When the network intent is not realized, the traceability graph can be used to trace the protocol events that did not occur until the incorrect configuration that caused the protocol events not to occur, which can explain why the network intent was not realized. When the network intent is not realized, the incorrect configuration node can be determined and the root cause can be located by differentially comparing the incorrect traceability graph and the correct traceability graph. Furthermore, after determining the incorrect configuration, the repair method can be automatically determined based on the correct reference configuration file, so that the incorrect configuration can be repaired quickly and accurately, thereby improving the repair efficiency.

[0160] Based on the same inventive concept, the present application also provides the following device embodiments. Fig. 9 As shown, Fig. 9 A schematic diagram of the structure of a network verification device provided in an embodiment of the present application. In this embodiment, the network verification device 900 includes an acquisition module 901 and a processing module 902 .

[0161] Among them, the acquisition module 901 is used to obtain the network intention, the first configuration file set and the first network topology of the network, and the first configuration file set includes the configuration files of multiple network devices in the network. The processing module 902 is used to perform simulation verification according to the network intention, the first configuration file set and the first network topology to obtain a first traceability diagram, and the first traceability diagram includes a basic node and a generation node. The basic node indicates the configuration information of a network device among multiple network devices, and the generation node indicates the protocol event information generated based on the configuration information corresponding to the basic node. The first traceability diagram indicates whether the network intention is realized.

[0162] In a possible implementation, the processing module 902 is configured to determine, according to the first tracing back graph, an erroneous configuration in the first set of configuration files when the first tracing back graph indicates that the network intention is not realized.

[0163] In a possible implementation, the basic nodes of the first traceability graph include an incorrect configuration node, the incorrect configuration node includes a first incorrect configuration node and / or a second incorrect configuration node, the first incorrect configuration node indicates a configuration in which a parameter in the first configuration file set is incorrectly configured or a configuration in which a configuration is missing, and the second incorrect configuration node is a basic node that does not exist in the second traceability graph, and the second traceability graph is a traceability graph indicating that the network intention has been realized. Processing module 902 is used to determine that the configuration corresponding to the incorrect configuration node is an incorrect configuration.

[0164] In one possible implementation, the generation nodes of the first traceability graph include error generation nodes, which indicate unimplemented protocol events caused by incorrect configuration during the simulation verification process, or protocol events that result in the inability to achieve network intent. The first traceability graph is a visual traceability graph, which identifies error paths or error configuration nodes. The error paths include error configuration nodes and error generation nodes.

[0165] In a possible implementation manner, the misconfigured node in the first provenance graph is determined according to the second provenance graph.

[0166] In one possible implementation, the second traceability graph is obtained by simulation verification based on the network intent, the second configuration file set and the first network topology, the second configuration file set includes configuration files of multiple network devices in the network, the first configuration file set includes a first configuration file of the first network device, the second configuration file set includes a second configuration file of the first network device, and the first configuration file is a configuration file used to replace the second configuration file.

[0167] In a possible implementation, the second traceability graph is obtained by simulation verification based on the network intent, the third configuration file set and the second network topology, the first configuration file set includes the configuration file of the second network device, the third configuration file set includes the configuration file of the third network device, the second network topology includes the second network device and the third network device, the first network topology includes the second network device but does not include the third network device, and the second network device is a backup device of the third network device.

[0168] In a possible implementation, the processing module 902 is used to obtain a fourth configuration file when the first tracing graph indicates that the network intention is not realized, and the fourth configuration file is used to replace the target configuration file in the first file set, and the target configuration file is a configuration file with an incorrect configuration.

[0169] In a possible implementation, the wrong configuration is a configuration that is multiple-configured in the target configuration file, and the processing module 902 is used to delete the wrong configuration and obtain a fourth configuration file.

[0170] In a possible implementation, the wrong configuration is a configuration that is missing or parameter mismatched in the target configuration file, and the processing module 902 is used to obtain a reference configuration corresponding to the wrong configuration from the reference configuration file, the reference configuration file is a configuration file that can realize the network intention, the target configuration file is a configuration file of the target network device, the reference configuration file is a configuration file of the main network device of the target network device, or the reference configuration file is a historical configuration file of the target network device. The processing module 902 is used to add the reference configuration to the target configuration file to obtain a fourth configuration file.

[0171] In a possible implementation, the processing module 902 is configured to perform simulation verification according to the network intent, a fourth configuration file set, and the first network topology, where the fourth configuration file set includes a fourth configuration file.

[0172] like Fig.10 As shown, Fig.10 A schematic diagram of the structure of a network verification device provided in an embodiment of the present application. In this embodiment, the network verification device can be a server, a server cluster, a computer, a tablet computer, a car computer, a smart phone, or other device with computing power.

[0173] The network authentication device 1000 includes a bus 1001, a processor 1002, a communication interface 1003, and a memory 1004. The processor 1002, the memory 1004, and the communication interface 1003 communicate with each other via the bus 1001.

[0174] The bus 1001 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 9 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0175] The processor 1002 may be any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0176] The memory 1004 may include a volatile memory, such as a random access memory (RAM). The memory 1004 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard drive (HDD), or a solid state drive (SSD).

[0177] The memory 1004 may be used to store software codes related to the network verification method, and the processor 1002 may execute the steps of the network verification method and may also schedule other units to implement corresponding functions.

[0178] It should be understood that the network verification device 1000 can be a centralized or distributed device, and the processor 1002 in the network verification device 1000 can be a hardware circuit (such as an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a general-purpose processor, a digital signal processor (DSP), a microprocessor or a microcontroller, etc.), or a combination of these hardware circuits. For example, the processor can be a hardware system with an instruction execution function, such as a CPU, DSP, etc., or a hardware system without an instruction execution function, such as an ASIC, FPGA, etc., or a combination of the above-mentioned hardware systems without an instruction execution function and hardware systems with an instruction execution function.

[0179] The present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a computer, the network verification method process of any of the above method embodiments is implemented.

[0180] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0181] The present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a computer, the network verification method process of any of the above method embodiments is implemented.

[0182] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0183] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical or other forms.

[0184] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0185] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0186] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of the present application can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A network verification method, characterized in that: The method comprises: Acquire a network intent, a first set of configuration files, and a first network topology of a network, wherein the first set of configuration files includes configuration files of a plurality of network devices in the network; Simulation verification is performed based on the network intent, the first configuration file set and the first network topology to obtain a first traceability graph, the first traceability graph includes a basic node and a generation node, the basic node indicates configuration information of one network device among the multiple network devices, the generation node indicates protocol event information generated based on the configuration information corresponding to the basic node, and the first traceability graph indicates whether the network intent is realized.

2. The method according to claim 1, characterized in that The method further comprises: When the first tracing back graph indicates that the network intention is not realized, an incorrect configuration in the first set of configuration files is determined according to the first tracing back graph.

3. The method according to claim 2, characterized in that The basic nodes of the first traceability graph include an incorrect configuration node, the incorrect configuration node includes a first incorrect configuration node and / or a second incorrect configuration node, the first incorrect configuration node indicates a configuration in which a parameter in the first configuration file set is incorrectly configured or a configuration in which a configuration is missing, the second incorrect configuration node is a basic node that does not exist in the second traceability graph, and the second traceability graph is a traceability graph indicating that the network intention has been realized; The determining, according to the first traceability graph, an incorrect configuration in the first set of configuration files includes: Determine that the configuration corresponding to the incorrectly configured node is the incorrect configuration.

4. The method according to claim 3, characterized in that The generation nodes of the first traceability graph include error generation nodes, and the error generation nodes indicate unimplemented protocol events caused by the incorrect configuration during the simulation verification process, or protocol events that cause the network intention to be unable to be realized. The first traceability graph is a visual traceability graph, and the error path or the error configuration node is identified in the first traceability graph. The error path includes the error configuration node and the error generation node.

5. The method according to claim 3 or 4, characterized in that: The incorrectly configured node in the first source tracing graph is determined according to the second source tracing graph.

6. The method according to any one of claims 3 to 5, characterized in that The second traceability graph is obtained by simulation verification based on the network intent, a second set of configuration files and the first network topology, the second set of configuration files includes configuration files of multiple network devices in the network, the first set of configuration files includes a first configuration file of a first network device, the second set of configuration files includes a second configuration file of the first network device, and the first configuration file is a configuration file used to replace the second configuration file.

7. The method according to any one of claims 3 to 5, characterized in that The second traceability graph is obtained by simulation verification based on the network intent, the third configuration file set and the second network topology, the first configuration file set includes the configuration file of the second network device, the third configuration file set includes the configuration file of the third network device, the second network topology includes the second network device and the third network device, the first network topology includes the second network device but does not include the third network device, and the second network device is a backup device of the third network device.

8. The method according to any one of claims 1 to 7, characterized in that The method further comprises: When the first tracing graph indicates that the network intention is not realized, a fourth configuration file is obtained, where the fourth configuration file is used to replace a target configuration file in the first file set, where the target configuration file is a configuration file with an incorrect configuration.

9. The method according to claim 8, characterized in that The erroneous configuration is a configuration that is multiple-configured in the target configuration file, and obtaining the fourth configuration file includes: The erroneous configuration is deleted to obtain the fourth configuration file.

10. The method according to claim 8, characterized in that The erroneous configuration is a configuration that is missing or has mismatched parameters in the target configuration file, and obtaining the fourth configuration file includes: Acquire a reference configuration corresponding to the erroneous configuration from a reference configuration file, where the reference configuration file is a configuration file capable of realizing the network intention, the target configuration file is a configuration file of a target network device, the reference configuration file is a configuration file of a primary network device of the target network device, or the reference configuration file is a historical configuration file of the target network device; The reference configuration is added to the target configuration file to obtain the fourth configuration file.

11. The method according to any one of claims 8 to 10, characterized in that The method further comprises: A simulation verification is performed according to the network intent, a fourth configuration file set and the first network topology, wherein the fourth configuration file set includes the fourth configuration file.

12. A network verification device, characterized in that: The device comprises: An acquisition module, configured to acquire a network intent, a first configuration file set, and a first network topology of the network, wherein the first configuration file set includes configuration files of a plurality of network devices in the network; A processing module is used to perform simulation verification according to the network intent, the first configuration file set and the first network topology to obtain a first traceability graph, wherein the first traceability graph includes a basic node and a generation node, the basic node indicates configuration information of a network device among the multiple network devices, and the generation node indicates protocol event information generated based on the configuration information corresponding to the basic node, and the first traceability graph indicates whether the network intent is realized.

13. The device according to claim 12, characterized in that The processing module is configured to determine, according to the first tracing back graph, an erroneous configuration in the first configuration file set when the first tracing back graph indicates that the network intention is not realized.

14. The device according to claim 12, characterized in that The basic nodes of the first traceability graph include an incorrect configuration node, the incorrect configuration node includes a first incorrect configuration node and / or a second incorrect configuration node, the first incorrect configuration node indicates a configuration in which a parameter in the first configuration file set is incorrectly configured or a configuration in which a configuration is missing, the second incorrect configuration node is a basic node that does not exist in the second traceability graph, and the second traceability graph is a traceability graph indicating that the network intention has been realized; The processing module is used to determine that the configuration corresponding to the incorrectly configured node is the incorrect configuration.

15. The device according to claim 14, characterized in that The generation nodes of the first traceability graph include error generation nodes, and the error generation nodes indicate unimplemented protocol events caused by the incorrect configuration during the simulation verification process, or protocol events that cause the network intention to be unable to be realized. The first traceability graph is a visual traceability graph, and the error path or the error configuration node is identified in the first traceability graph. The error path includes the error configuration node and the error generation node.

16. The device according to claim 14 or 15, characterized in that The incorrectly configured node in the first source tracing graph is determined according to the second source tracing graph.

17. The device according to any one of claims 14 to 16, characterized in that The second traceability graph is obtained by simulation verification based on the network intent, a second set of configuration files and the first network topology, the second set of configuration files includes configuration files of multiple network devices in the network, the first set of configuration files includes a first configuration file of a first network device, the second set of configuration files includes a second configuration file of the first network device, and the first configuration file is a configuration file used to replace the second configuration file.

18. The device according to any one of claims 14 to 16, characterized in that The second traceability graph is obtained by simulation verification based on the network intent, the third configuration file set and the second network topology, the first configuration file set includes the configuration file of the second network device, the third configuration file set includes the configuration file of the third network device, the second network topology includes the second network device and the third network device, the first network topology includes the second network device but does not include the third network device, and the second network device is a backup device of the third network device.

19. The device according to any one of claims 12 to 18, characterized in that The processing module is used to obtain a fourth configuration file when the first tracing graph indicates that the network intention is not realized, and the fourth configuration file is used to replace the target configuration file in the first file set, and the target configuration file is a configuration file with an incorrect configuration.

20. The device according to claim 19, characterized in that The incorrect configuration is a configuration that is multiple-configured in the target configuration file. The processing module is used to delete the erroneous configuration and obtain the fourth configuration file.

21. The device according to claim 19, characterized in that The incorrect configuration is a configuration that is missing or has mismatched parameters in the target configuration file. The processing module is configured to obtain a reference configuration corresponding to the erroneous configuration from a reference configuration file, wherein the reference configuration file is a configuration file capable of realizing the network intention, the target configuration file is a configuration file of a target network device, the reference configuration file is a configuration file of a primary network device of the target network device, or the reference configuration file is a historical configuration file of the target network device; The processing module is used to add the reference configuration to the target configuration file to obtain the fourth configuration file.

22. The device according to any one of claims 19 to 21, characterized in that The processing module is used to perform simulation verification according to the network intent, a fourth configuration file set and the first network topology, and the fourth configuration file set includes the fourth configuration file.

23. A network verification device, characterized in that: The device includes a processor and a memory, wherein the processor is coupled to the memory, and the processor is configured to execute the network authentication method according to any one of claims 1 to 11 based on instructions stored in the memory.

24. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises instructions, which, when the computer-readable storage medium is executed on a computer, causes the computer to execute the network authentication method according to any one of claims 1 to 11.

Images