Network verification method, apparatus, device, storage medium, and program product

Abstract

The application discloses a network verification method and device, equipment, a storage medium and a program product. The method comprises the following steps: determining an abstract network element model based on an abstract network element function; wherein the abstract network element model is a network forwarding plane network element model; performing task arrangement based on a network verification task to obtain a reachable matrix; and performing network verification on the reachable matrix based on an instance of the abstract network element model to obtain a reachable path.

Description

Technical Field

[0001] This application relates to the field of data services, and in particular to a network authentication method, apparatus, device, storage medium, and program product. Background Technology

[0002] With the continuous deployment of services and new network elements, network logic becomes more complex, making network maintenance stability more dependent on the accuracy of manual business logic analysis. During network maintenance, the communication cost of analyzing business forwarding logic is high because maintenance personnel need to continuously follow up. There are also situations where maintenance personnel fail to analyze business logic properly or have oversights in work handover. As a result, network defects will be exposed during service launch and fault handling, causing damage to existing services. Meanwhile, network deployment costs restrict network development. With the continuous deployment of services and the sharing of different types of network elements, both old and new, the complexity of the network continues to increase, which becomes a major challenge in maintaining the stability of the network system. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a network verification method, apparatus, device, storage medium, and program product.

[0004] The network verification method provided in this application includes:

[0005] Based on the functions of abstract network elements, an abstract network element model is determined; wherein, the abstract network element model is the network element model of the network forwarding plane;

[0006] Based on the network verification task, task orchestration is performed to obtain the reachability matrix;

[0007] Based on an instance of the abstract network element model, network verification is performed on the reachability matrix to obtain reachable paths.

[0008] The network verification device provided in this application embodiment includes:

[0009] The determining unit is used to determine the abstract network element model based on the abstract network element function; wherein, the abstract network element model is the network element model of the network forwarding plane;

[0010] The orchestration unit is used to orchestrate tasks based on network verification tasks to obtain a reachability matrix.

[0011] The verification unit is used to perform network verification on the reachability matrix based on instances of the abstract network element model to obtain reachable paths.

[0012] The processing device provided in this application includes a processor and a memory. The memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute any of the above-described network verification methods.

[0013] The computer-readable storage medium provided in this application embodiment is used to store a computer program that causes a computer to execute any of the above-described network verification methods.

[0014] The computer program product provided in this application includes computer program instructions that cause a computer to execute any of the above-described network verification methods.

[0015] In the technical solution of this application embodiment, an abstract network element model is determined based on the abstract network element function, and task orchestration is performed based on the network verification task to obtain a reachability matrix. Then, network verification is performed on the reachability matrix based on instances of the abstract network element model to obtain reachable paths. The abstract network element model is a network element model of the network forwarding plane. Thus, by constructing a unified network element model of the network forwarding plane based on abstract network element functions, it helps to avoid differences in the implementation of various network functions by vendor equipment, improving model adaptability and scalability. Furthermore, by orchestrating and designing based on data center network verification tasks and using a unified abstract network element model to adapt to the network technologies used in data center network scenarios, it not only meets the needs of data center network verification and improves the accuracy and effectiveness of network verification, but also provides a reference for operation and maintenance personnel to proactively discover and resolve network faults, improving the efficiency of automated network operation and maintenance. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the network verification method provided in an embodiment of this application;

[0017] Figure 2 This is a schematic diagram of the architecture of the network verification model design for cloud data centers provided in the embodiments of this application;

[0018] Figure 3 This is a schematic diagram illustrating the principle of constructing an abstract network element interface model based on the portPBR model provided in this application embodiment;

[0019] Figure 4 This is a schematic diagram illustrating the principle of constructing an abstract network element model based on a Port-connected undirected graph and GRT / VRF routing leakage graphs, as provided in the embodiments of this application.

[0020] Figure 5a This is a schematic diagram illustrating the principle of network verification task orchestration based on graph structure provided in the embodiments of this application;

[0021] Figure 5b This is a directed schematic diagram of the paths between Port interfaces in the forwarding reachability matrix provided in this application embodiment;

[0022] Figure 6 This is a schematic diagram of the network verification device provided in the embodiments of this application;

[0023] Figure 7 This is a schematic diagram of the processing device provided in the embodiments of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0025] It should be noted that, in the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, in the embodiments of this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0026] In the description of the embodiments of this application, the term "correspondence" may indicate that there is a direct or indirect correspondence between two things, or that there is an association between two things, or that there is a relationship of instruction and being instructed, configuration and being configured, etc.

[0027] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0028] In recent years, with the rapid development of cloud computing, except for some dedicated network architectures such as supercomputing, the physical architecture of data centers has evolved from the traditional three-layer network architecture to the Clos-based Spine-Leaf network architecture. The flattened Spine-Leaf architecture has greatly simplified the physical architecture of the two and three layers of the network while improving the east-west throughput of the data center. However, with the continuous deployment of services and the deployment of new network elements, the network has become more complex. The deployment of overlay, underlay, host and container networks has reduced the overall maintainability of the system, making the stability of network maintenance more dependent on the accuracy of manual business logic analysis.

[0029] From the perspective of continuous business deployment, cloud-based business logic is complex and difficult to deploy according to standardized isolation methods for management networks and business networks, or for computing and storage. Non-standard deployments are likely to exist. During network maintenance, due to inadequate business understanding by operations personnel or oversights in work handover, defects in non-standard deployments, complex network policies for firewalls and other network elements, and omissions in the evolution of network architectures will be exposed during business launches and troubleshooting, causing damage to existing services.

[0030] From the perspective of deploying new network element devices, in order to achieve cloud virtualization and isolation at a lower cost, a wide variety of new network element devices such as Software Defined Networking (SDN) and white-box switches have emerged in the field. However, it is costly to independently implement a data center network with a unified and programmable interface. Therefore, the field often adopts the method of superimposing and integrating technical architectures to achieve iterative deployment. Moreover, due to the programmability and convenient service deployment of new network element devices, the business logic based on new network element devices changes rapidly. This requires operation and maintenance personnel to keep up with the changes, resulting in high communication costs for sorting out business logic.

[0031] From the perspective of actual network development, deployment cost has always been the fundamental problem restricting the unified development of networks. New network elements and protocols will continue to integrate and develop with the existing environment and protocols, increasing the complexity of network deployment and becoming a major difficulty in maintaining the stability of the network system.

[0032] To address the aforementioned issues, relevant technologies offer the following methods for effectively monitoring network or device status and promptly detecting network or device faults:

[0033] (1) Obtain a list of all switches and routers within a given network range, analyze the list of switches and routers to determine whether the current network is a Layer 2 subnet or a Layer 3 network, discover the network topology of all Layer 2 subnets through Spanning Tree Protocol (STP) data, discover the topology of Layer 3 networks through routing table data, merge the network topologies of all Layer 2 subnets or all Layer 3 network topologies to obtain the entire data center network topology, and effectively discover the defects in the data center network topology through this network topology.

[0034] (2) Initialize the root node of the tree diagram to obtain the starting node for generating the topology diagram. Based on the starting node, create a canvas in the browser to display scalable vector graphics. Obtain the node data of the next-level associated devices from the backend based on the node data. Calculate the X-axis and Y-axis offsets of the nodes in each layer of the canvas based on the node data. Construct a node offset table. Obtain the node position offset data from the node offset table and calculate the actual node position based on the unit length. Generate the topology diagram of the data center equipment. This topology diagram can effectively detect and isolate data center equipment faults. It has a simple structure and is easy to manage and maintain.

[0035] (3) Automatically discover newly launched cloud environment devices, as well as the configuration and status changes of cloud environment devices, and monitor the operating status of cloud environment devices. At the same time, manage device connection relationships, status visualization and device assets. This method can meet the management needs of multiple device types and also meet the different device discovery methods of different device types.

[0036] However, although the above methods have been successfully implemented in the corresponding application scenarios, network topology discovery methods tend to focus more on the second and third layer network topologies, or on the efficiency of automatic topology generation, without actually combining them with the business scenarios of cloud data centers. The data link layer and network layer of cloud data business topology tend to be simplified, while the complexity of business is realized by dividing the network plane, complex network policies, and virtualizing multiple network elements to realize business logic. The network physical topology of Spine-Leaf has little operational value for business-related operations in cloud data.

[0037] To address the aforementioned technical challenges, this application proposes a method for constructing a network verification model for cloud data centers, enabling autonomous discovery of service networks. First, a unified network forwarding plane network element model (abstract network element model) is constructed based on abstract network element functions. Then, the configurations of traditional network devices and new network element devices are mapped onto this unified abstract network element model. Based on this, the autonomous discovery capability of service networks in cloud data centers is built. Furthermore, by designing a cloud data center network verification system, the system enables automated analysis of complex services, enhances maintenance personnel's understanding of various complex network services, reduces maintenance errors, and improves work efficiency.

[0038] To facilitate understanding of the technical solutions of the embodiments of this application, the technical solutions of this application are described in detail below through specific embodiments. The above-mentioned related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0039] This application proposes a network verification method. Figure 1 This is a flowchart illustrating the network verification method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps:

[0040] Step 101: Determine the abstract network element model based on the abstract network element function.

[0041] Among them, the abstract network element model is the network element model of the network forwarding plane.

[0042] In this embodiment, the abstract network element model primarily targets the service network forwarding in cloud data centers, focusing on the forwarding plane of network element devices. Therefore, the abstract network element functions mainly include the functions of network element devices in the forwarding plane. These functions include the actual handling of traffic data by the network element device's interface and the virtual routing and forwarding functions. Examples include interface / device level access control lists (ACLs), policy-based routing (PBR), link aggregation technology for physical ports (phyPort) and logical ports (logicPort), and virtual routing and forwarding (VRF) technology. In other words, the abstract network element functions include network element interface functions and virtual routing and forwarding functions. The abstract network element interface model is determined by the network element interface functions, and the virtual routing and forwarding model is determined by the virtual routing and forwarding functions. Therefore, determining the abstract network element model based on the abstract network element functions can include determining the abstract network element interface model based on the network element interface functions, determining the virtual routing and forwarding model based on the virtual routing and forwarding functions, and determining the abstract network element model based on the abstract network element interface model and the virtual routing and forwarding model.

[0043] In some implementations, the abstract network element function includes network element interface function and virtual routing forwarding function; wherein, step 101 may specifically include:

[0044] Based on the atomic operations of data forwarding in the network element interface function, the policy routing model is determined; where atomic operations include access control list and policy routing operations.

[0045] Based on the policy routing model, determine the abstract network element interface model;

[0046] Based on the virtual routing forwarding function, determine the virtual routing forwarding model;

[0047] Based on the abstract network element interface model and the virtual routing forwarding model, the abstract network element model is determined.

[0048] Here, we can first define the atomic operation (atomicOperator) for data forwarding in the network element interface function, and build the portPBR model, i.e., the policy routing model, based on the atomic operation to meet the operation of various data center networks for service traffic. The policy routing model can meet the operation of interface / device level ACL and PBR. After building the policy routing model, we can determine the interface functions of the policy routing model: portPBRIn and portPBROut. Combined with the network element interface functions, we can build an abstract network element interface model, which includes logicPort, phyPort, portPBRIn, and portPBROut. At the same time, we can determine the virtual routing forwarding model based on the virtual routing forwarding function, which includes the routing forwarding table and routing leakage policy. After building the abstract network element interface model and the virtual routing forwarding model, we can associate the corresponding virtual routing forwarding model instance through the VRF field of the abstract network element interface model instance. Thus, we can build the abstract network element model based on the abstract network element interface model and the virtual routing forwarding model.

[0049] Here, atomic operations usually refer to indivisible operations, that is, the operation will not be interrupted by any other operation during its execution. For building a policy routing model based on atomic operations, atomic operations can be regarded as the basic steps in building the policy routing model. These steps are operations that must be executed in strict order and ensure the consistency of network state, including defining the physical or logical interface for PBR, and defining PBR policies including matching conditions and corresponding actions.

[0050] Here, in the process of constructing the abstract network element interface model, since the network interfaces of data centers mostly adopt link aggregation technology, logicPort and phyPort can be constructed in the abstract network element interface model. Among them, phyPort is a list of actual physical interfaces, which hides the physical aggregation implementation and focuses on the relevance between the logicPort interface and the business.

[0051] In some implementations, the abstract network element interface model is used to define the interface attributes in the abstract network element function, and the virtual routing forwarding model is used to define the virtual routing forwarding attributes in the abstract network element function; wherein, "determining the abstract network element model based on the abstract network element interface model and the virtual routing forwarding model" may specifically include:

[0052] By associating interface attributes with the control policies and link aggregation of the interface's inbound and / or outbound directions, the network element device function representation of the interface policy is obtained.

[0053] By associating the virtual routing forwarding attributes with the forwarding table, the network element device function representation of the routing forwarding policy is obtained;

[0054] By associating the virtual route forwarding attributes with the global routing table, the network element device function representation of the route leakage policy is obtained;

[0055] Based on the functional representations of network element devices according to interface policies, routing and forwarding policies, and routing leakage policies, an abstract network element model is determined.

[0056] Here, based on the abstract network element interface model, a virtual routing and forwarding model is introduced to further construct an abstract network element model with the cloud data center network as the whole. The abstract network element model includes interface attributes and virtual routing and forwarding attributes. Specifically, the complexity of data center networks is fully considered first. Based on interface attributes and virtual routing forwarding attributes, interface attributes are associated with control policies and link aggregation in the inbound and / or outbound directions of the interface to obtain the network element device function representation of the interface policy. Virtual routing forwarding attributes are associated with forwarding tables to obtain the network element device function representation of routing forwarding policies. Virtual routing forwarding attributes are associated with global routing tables (or other virtual routing forwarding) to obtain the network element device function representation of routing leakage policies. This allows various interface and device-level policies to be uniformly abstracted onto the interface and associated with network element functions. After obtaining the network element device function representations of interface policies, routing forwarding, and routing leakage, a unified abstract network element model can be constructed based on these abstract representations. The abstract network element model is based on the core functions of cloud data center network elements: forwarding and isolation, and is independent of the specific implementations of each vendor's equipment.

[0057] Specifically, an undirected graph of port connectivity can be constructed based on interface policies, and a Global Routing Table (GRT) and a VRF route leakage graph can be constructed based on routing forwarding policies and route leakage policies. This allows for the abstraction of the complex characteristics of cloud data center business logic based on the undirected graph of port connectivity and the GRT and VRF route leakage graphs, including network characteristics such as multi-network VRF plane isolation, direct-connected peer ports belonging to different VRF planes, and route leakage. Finally, a unified abstract network element model is constructed. The instances generated according to the abstract network element model based on the production network configuration can help operations and maintenance personnel automatically sort out the complex business logic in the existing data center network.

[0058] In network configuration and management, interface policies are typically used to control and manage a set of rules for traffic on specific ports or port groups, usually including access control policies, security policies, and traffic management policies. Routing and forwarding policies determine how data packets are forwarded from one network node to another, typically including forwarding tables, routing protocols, routing algorithms, and virtual routing forwarding. Route leakage policies allow the sharing of routing information between VRFs and GRTs, as well as between VRFs and other VRFs, to achieve network isolation and interoperability. VRF technology allows the creation of multiple logically isolated routing instances on the same physical router, each with its own independent routing table, achieving isolation of different network traffic while also enabling the exchange of routing information between different VRF instances.

[0059] Step 102: Perform task orchestration based on the network verification task to obtain the reachability matrix.

[0060] In this embodiment of the application, if the operation and maintenance personnel initiate network verification, they can generate a network verification task based on the network verification, and perform task orchestration based on the network verification task to obtain a reachability matrix, wherein the reachability matrix is ​​a forwarding reachability matrix used for network verification.

[0061] Here, after orchestrating network verification tasks, the tasks can be executed, and the results can be fed back to the operations and maintenance personnel. The methods for executing network verification tasks include Satisfiability Modulo Theories (SMT) coding execution, Header Space Analysis (HSA) mathematical modeling, and simulation data forwarding.

[0062] In some implementations, step 102 may specifically include:

[0063] Based on the network verification task, identify multiple host and / or container interfaces for network verification;

[0064] Task orchestration is performed based on multiple host and / or container interfaces to obtain an reachability matrix.

[0065] Here, based on the network verification task, the multiple host and / or container interfaces involved in the network verification can be determined. Then, based on the multiple host and / or container interfaces and the connection relationships between the multiple host and / or container interfaces, the task can be orchestrated to obtain the reachability matrix corresponding to the multiple host and / or container interfaces.

[0066] The reachability matrix refers to the matrix form used to describe the degree to which nodes in a directed graph can be reached after passing through a path of a certain length. The reachability matrix does not guarantee that all nodes are reachable, that is, it does not guarantee that all nodes are directly or indirectly connected.

[0067] In some implementations, "orchestrending tasks based on multiple host and / or container interfaces to obtain a reachability matrix" may specifically include:

[0068] Based on multiple host and / or container interfaces, determine the communication paths between multiple host and / or container interfaces;

[0069] A reachability matrix is ​​determined based on multiple host and / or container interfaces, and the communication paths between these interfaces.

[0070] Here, the communication paths between multiple host and / or container interfaces are first determined based on multiple host and / or container interfaces. Then, with multiple host and / or container interfaces as nodes and the communication paths between multiple host and / or container interfaces as edges, a reachability matrix is ​​constructed based on multiple nodes and the edges between multiple nodes. Since the communication paths between multiple host and / or container interfaces include two directions, outbound and inbound, the reachable paths to be verified by the network are directed paths, and the graph corresponding to the reachable paths is a directed graph.

[0071] Step 103: Based on an instance of the abstract network element model, perform network verification on the reachability matrix to obtain reachable paths.

[0072] In this embodiment of the application, since the abstract network element model abstracts the complex characteristics of cloud data center business logic, instances of the abstract network element model can provide a unified way to express different elements in the network and the connection relationships between elements. That is, instances of the abstract network element model can include forwarding paths corresponding to multiple host and / or container interfaces. Therefore, network verification of the reachability matrix can be performed based on the forwarding paths corresponding to multiple host and / or container interfaces in instances of the abstract network element model to obtain reachable paths.

[0073] In some implementations, step 103 may specifically include:

[0074] Determine the forwarding paths corresponding to multiple host and / or container interfaces in an instance of the abstract network element model;

[0075] Based on the forwarding path, the corresponding model instance in the reachability matrix is ​​traversed. If it is determined that there is a path in the reachability matrix that matches the forwarding path, then the matching path is determined as the path to be verified.

[0076] Based on the path to be verified, determine the reachable path.

[0077] Here, based on multiple host and / or container interfaces that require network verification, the forwarding paths corresponding to multiple host and / or container interfaces in the instance of the abstract network element model can be determined. Specifically, firstly, network configuration information related to multiple host and / or container interfaces in the instance is collected, and combined with the network topology, the location of multiple host and / or container interfaces in the network is analyzed and verified. This includes verifying whether multiple host and / or container interfaces are directly connected to other network elements, or through which intermediate network elements multiple host and / or container interfaces are reachable. Then, the forwarding paths corresponding to multiple host and / or container interfaces are calculated using network models or algorithms, or network probing techniques or tools are used to probe the paths corresponding to multiple host and / or container interfaces to determine the forwarding paths. After obtaining the forwarding paths corresponding to multiple host and / or container interfaces, the reachability matrix can be traversed based on the forwarding paths to search for whether there is a path in the reachability matrix that matches the forwarding path. If there is, the matched path is determined as the path to be verified. Since not all forwarding paths are reachable paths, after determining the path to be verified that matches the forwarding path, it is also necessary to determine whether the path to be verified is a reachable path.

[0078] In some implementations, "determining reachable paths based on paths to be verified" may specifically include:

[0079] Based on the path to be verified, a directed graph is constructed for the corresponding model instances in the reachability matrix to obtain the directed graph corresponding to the path to be verified.

[0080] If a directed graph is determined to be closed by a loop, then the path to be verified is determined to be a reachable path.

[0081] Here, to further determine whether the path to be verified that matches the forwarding path is a reachable path, a directed graph can be constructed and traversed on the corresponding model instance in the reachability matrix based on the path to be verified to obtain the directed graph corresponding to the path to be verified. Then, it is determined whether the directed graph is a closed loop. If the path corresponding to the directed graph starts from a certain vertex, goes through a series of edges, and finally returns to the vertex, then the path to be verified can be determined as a reachable path.

[0082] In some implementations, it may further include:

[0083] Based on the abstract network element model, network verification is performed on the reachability matrix to obtain unreachable paths;

[0084] Based on the unreachable path, identify the problematic interface corresponding to the unreachable path and feed back the relevant information of the problematic interface to the operation and maintenance team.

[0085] Here, during the network verification of the reachability matrix based on the forwarding paths corresponding to multiple host and / or container interfaces in the abstract network element model, unreachable paths in the reachability matrix are also identified. The unreachable matrix consists of unreachable paths corresponding to multiple host and / or container interfaces. The end node in the unreachable path is identified as the problem interface, and the relevant information of the problem interface is fed back to the operation and maintenance end so that the operation and maintenance personnel can repair the problem interface. This can provide a reference for the operation and maintenance personnel to solve network faults and improve the efficiency of automated network operation and maintenance.

[0086] In the technical solution of this application embodiment, an abstract network element model is determined based on the abstract network element function, and task orchestration is performed based on the network verification task to obtain a reachability matrix. Then, network verification is performed on the reachability matrix based on instances of the abstract network element model to obtain reachable paths. The abstract network element model is a network element model of the network forwarding plane. Thus, by constructing a unified network element model of the network forwarding plane based on abstract network element functions, it helps to avoid differences in the implementation of various network functions by vendor equipment, improving model adaptability and scalability. Furthermore, by orchestrating and designing based on data center network verification tasks and using a unified abstract network element model to adapt to the network technologies used in data center network scenarios, it not only meets the needs of data center network verification and improves the accuracy and effectiveness of network verification, but also provides a reference for operation and maintenance personnel to proactively discover and resolve network faults, improving the efficiency of automated network operation and maintenance.

[0087] This application also proposes a method for constructing a network verification model for cloud data centers. Figure 2 This is a schematic diagram of the architecture of the network verification model design for cloud data centers provided in the embodiments of this application, such as... Figure 2 As shown, the architecture mainly consists of two parts: the construction of the abstract network element model and the construction of the network verification system, specifically including:

[0088] Construction of Abstract Network Element Model

[0089] The abstract network element model is primarily designed for cloud data center service network forwarding. It focuses on the forwarding plane of network element devices, rather than their control plane, to avoid the differences in network function implementation across vendors and to ensure scalability. The abstract network element model is designed from two main aspects: adaptability and scalability.

[0090] First, for core network virtualization technologies that are fully adapted to data center networks, such as link aggregation, multi-network plane VRF partitioning, and interface / device level traffic PBR, an abstract network element interface model is designed, such as... Figure 3The diagram illustrates the principle of constructing an abstract network element interface model based on the portPBR model provided in this application embodiment. To ensure adaptability to traditional network devices, new network element devices, and host / container networks, the abstract network element interface model abstracts interface operations, innovatively creating portPBR and defining atomic operations to meet the manipulation of service traffic in various data center networks. It can satisfy interface / device-level ACL and policy routing PBR operations. Based on the current capabilities of network element devices, three types of operations are defined: permit, deny, and modNextHop, abstracting the operations of network element devices. Building upon the portPBR model, a Port model is further constructed. Since data center network interfaces often employ link clustering technology, corresponding logicPort and phyPort can be constructed. phyPort is a list of actual physical interfaces, shielding the physical aggregation implementation and focusing instead on the relevance between logicPort interfaces and services.

[0091] Secondly, based on the Port model, an abstract network element model is further constructed, taking the cloud data center network as a whole. Specifically, firstly, considering the complexity of the data center network, a tuple of {Port, VRF} is used as the foundation. Port is associated with interface policies, and VRF is associated with the FIB table. Various interfaces and device-level policies are uniformly abstracted onto the interface and associated with network element functions, thereby shielding the characteristics of vendor equipment. Secondly, based on the forwarding functions of cloud data center network element equipment: Port, Port policies, VRF routing forwarding, GRT, and VRF route leakage, a unified abstract network element model is constructed. This model is based on the core functions of data center network element equipment, namely isolation and forwarding, and is independent of the specific implementations of each vendor's equipment. Figure 4 The diagram illustrates the principle of constructing an abstract network element model based on a Port connectivity undirected graph and GRT / VRF routing leakage graphs, as provided in this application embodiment. By employing the point, line, and surface approach in a two-dimensional view, a two-dimensional view of network element functions is constructed, solving the model abstraction problem of VRF and Port link aggregation in network virtualization. This model, combining the Port connectivity undirected graph and GRT / VRF routing leakage graphs (i.e., points, lines, and surfaces in a two-dimensional view), effectively abstracts the complex characteristics of current cloud data center business logic, including multi-network VRF plane isolation, direct-connected peer ports belonging to different VRF planes, routing leakage, and other network characteristics. This model can help operations and maintenance personnel automatically sort out the complex business logic in existing data center networks.

[0092] The abstract network element model is adaptable to various network characteristics of data center network elements, and its scalability is mainly reflected in two aspects:

[0093] (1) The construction of the portPBR model can cope with complex traffic manipulation and can continuously meet the functional abstraction problem of new self-developed network elements.

[0094] (2) The abstract network element model takes {Port, VRF} as its core, does not depend on the IP network, and can be extended to SRv6, Ethernet and other networks in the future.

[0095] Network verification system construction

[0096] The construction of a network verification system mainly includes network verification task orchestration and network verification task execution. For network verification task execution, there are already a variety of solutions in the field. The core solutions include SMT coding execution, HSA mathematical modeling, and simulation data forwarding. Currently, there is a lack of orchestration design patterns for network verification tasks in cloud data centers.

[0097] Firstly, in network verification tasks, reachability verification is the most basic and important. However, in actual operation and maintenance, as the system maintenance progresses, network reachability verification and network-level high availability verification are difficult to guarantee. Reachability verification is often triggered by events or faults, and without task orchestration, it is difficult to understand the true network reachability. Therefore, this application embodiment combines host / container port interfaces for task orchestration, designing a graph-based configuration matching algorithm for network verification task orchestration, such as... Figure 5a The diagram shown is a schematic representation of the principle of network verification task orchestration based on graph structure provided in this application embodiment. The specific execution steps of the algorithm include:

[0098] (1) Take the communication paths between all Port interfaces of the host / container as a set S, and construct a forwarding reachability matrix based on the set S to generate a verification matrix. If the forwarding reachability graph corresponding to the forwarding reachability matrix is ​​connected, it means that the communication path satisfies connectivity.

[0099] (2) Perform reachability calculations on the forwarding reachability matrix. This involves taking all the Port interfaces of the host / container in the forwarding reachability matrix as a set P, and constructing directed graphs between the Port interfaces based on set P, both from source to destination and from destination to source, as follows: Figure 5b The diagram shown is a directed schematic of the paths between Port interfaces in the forwarding reachability matrix provided in this application embodiment. In this directed graph, Port_2 and Port_3 are the end nodes in the directed graph.

[0100] (3) Perform concatenated Port interface operations on the forwarding reachability matrix based on the directed graph, verify the reachability of the forwarding reachability matrix through instances of the abstract network element model, and provide possible path references in the forwarding reachability matrix, such as providing paths {Port_2, Port_5, Port_3} and {Port_2, Port_3}.

[0101] (4) After verifying the reachability of the forwarding reachability matrix, if the feedback indicates the presence of a problem node with an incomplete loop, then the path is actually unreachable. Figure 5b The presence of Port_2 and Port_3 nodes indicates that there are problems with the interfaces corresponding to Port_2 and Port_3, resulting in unreachability.

[0102] In the technical solution of this application embodiment, by constructing a unified abstract network element model based on abstract network element functions, the adaptability and scalability of the model can be improved, which helps to avoid the differences in the implementation of various network functions by vendor equipment. At the same time, by constructing a network verification system, orchestrating network verification tasks, and using abstract network element model instances to verify the reachability of the forwarding reachability matrix generated by the network verification task orchestration, it can not only meet the needs of network verification and improve the accuracy and effectiveness of network verification, but also provide a reference for operation and maintenance personnel to proactively discover and solve network fault problems, thereby improving the efficiency of automated network operation and maintenance.

[0103] This application also proposes a network verification device. Figure 6 This is a schematic diagram of the network verification device provided in the embodiments of this application, such as... Figure 6 As shown, the device includes:

[0104] The determining unit 601 is used to determine the abstract network element model based on the abstract network element function; wherein, the abstract network element model is the network element model of the network forwarding plane.

[0105] The orchestration unit 602 is used to orchestrate tasks based on network verification tasks to obtain a reachability matrix.

[0106] Verification unit 603 is used to perform network verification on the reachability matrix based on instances of the abstract network element model to obtain reachable paths.

[0107] In some implementations, the abstract network element function includes network element interface function and virtual routing forwarding function; the determining unit 601 is specifically used for: determining a policy routing model based on atomic operations of data forwarding in the network element interface function; wherein, atomic operations include access control list and policy routing operations; determining an abstract network element interface model based on the policy routing model; determining a virtual routing forwarding model based on the virtual routing forwarding function; and determining an abstract network element model based on the abstract network element interface model and the virtual routing forwarding model.

[0108] In some implementations, the abstract network element interface model is used to define interface attributes in the abstract network element function, and the virtual routing forwarding model is used to define virtual routing forwarding attributes in the abstract network element function. The determining unit 601 is further specifically used to: associate the interface attributes with the control policies and link aggregation of the interface's inbound and / or outbound directions to obtain the network element device function representation of the interface policy; associate the virtual routing forwarding attributes with the forwarding table to obtain the network element device function representation of the routing forwarding policy; associate the virtual routing forwarding attributes with the global routing table to obtain the network element device function representation of the routing leakage policy; and determine the abstract network element model based on the network element device function representation of the interface policy, the network element device function representation of the routing forwarding policy, and the network element device function representation of the routing leakage policy.

[0109] In some implementations, the orchestration unit 602 is specifically used to: determine multiple host and / or container interfaces for network verification based on the network verification task; and orchestrate the tasks based on the multiple host and / or container interfaces to obtain an reachability matrix.

[0110] In some implementations, the orchestration unit 602 is further specifically configured to: determine communication paths between multiple host and / or container interfaces based on multiple host and / or container interfaces; and determine an reachability matrix based on multiple host and / or container interfaces and the communication paths between multiple host and / or container interfaces.

[0111] In some implementations, the verification unit 603 is specifically used to: determine the forwarding paths corresponding to multiple host and / or container interfaces in an instance of the abstract network element model; traverse the corresponding model instances in the reachability matrix based on the forwarding paths, and if it is determined that there is a path in the reachability matrix that matches the forwarding path, then determine the matching path as the path to be verified; and determine the reachable path based on the path to be verified.

[0112] In some implementations, the verification unit 603 is also specifically used to: construct a directed graph for the corresponding model instance in the reachability matrix based on the path to be verified, and obtain the directed graph corresponding to the path to be verified; if the directed graph is determined to be closed, then the path to be verified is determined to be a reachable path.

[0113] In some implementations, the verification unit 603 is also specifically used to: perform network verification on the reachability matrix based on the abstract network element model to obtain unreachable paths.

[0114] In some embodiments, the device further includes: a feedback unit; wherein,

[0115] The feedback unit is used to identify the problematic interface corresponding to the unreachable path based on the unreachable path, and to feed back the relevant information of the problematic interface to the operation and maintenance end.

[0116] In the technical solution of this application embodiment, an abstract network element model is determined based on the abstract network element function, and task orchestration is performed based on the network verification task to obtain a reachability matrix. Then, network verification is performed on the reachability matrix based on instances of the abstract network element model to obtain reachable paths. The abstract network element model is a network element model of the network forwarding plane. Thus, by constructing a unified network element model of the network forwarding plane based on abstract network element functions, it helps to avoid differences in the implementation of various network functions by vendor equipment, improving model adaptability and scalability. Furthermore, by orchestrating and designing based on data center network verification tasks and using a unified abstract network element model to adapt to the network technologies used in data center network scenarios, it not only meets the needs of data center network verification and improves the accuracy and effectiveness of network verification, but also provides a reference for operation and maintenance personnel to proactively discover and resolve network faults, improving the efficiency of automated network operation and maintenance.

[0117] Those skilled in the art should understand that Figure 6 The functions of each unit in the network verification device shown can be understood by referring to the relevant descriptions of the aforementioned methods. Figure 6 The functions of each unit in the network verification device shown can be implemented by a program running on a processor or by specific logic circuits.

[0118] Figure 7 This is a schematic diagram of the processing device provided in an embodiment of this application. The processing device may be a terminal device or a network device. Figure 7 The processing device shown includes a processor 701, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0119] Optionally, such as Figure 7 As shown, the processing device may further include a memory 702. The processor 701 can retrieve and run computer programs from the memory 702 to implement the methods described in this embodiment.

[0120] The memory 702 can be a separate device independent of the processor 701, or it can be integrated into the processor 701.

[0121] Optionally, such as Figure 7 As shown, the processing device may also include a transceiver 703, which the processor 701 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0122] The transceiver 703 may include a transmitter and a receiver. The transceiver 703 may further include an antenna, which may be one or more.

[0123] The processing device may specifically be the network verification device of this application embodiment, and the processing device can implement the corresponding processes of the various methods implemented in this application embodiment. For the sake of brevity, it will not be described in detail here.

[0124] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0125] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0126] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0127] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to the processing device in this application embodiment, and the computer program causes the computer to execute the corresponding processes implemented by the various methods in this application embodiment; for brevity, further details are omitted here.

[0128] This application also provides a computer program product, including computer program instructions. This computer program product can be applied to the processing device in this application embodiment, and the computer program instructions cause the computer to execute the corresponding processes implemented by the various methods in this application embodiment; for brevity, further details are omitted here.

[0129] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0131] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0133] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0134] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0135] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A network verification method, characterized in that, The method includes: Based on abstract network element functions, an abstract network element model is determined; wherein, the abstract network element model is a network element model of the network forwarding plane; the abstract network element functions include network element interface functions and virtual routing forwarding functions; the abstract network element model is determined by the abstract network element interface model and the virtual routing forwarding model; the abstract network element interface model is determined by the network element interface functions, and the virtual routing forwarding model is determined by the virtual routing forwarding functions; the abstract network element interface model is used to define the interface attributes in the abstract network element functions, and the virtual routing forwarding model is used to define the virtual routing forwarding attributes in the abstract network element functions; Based on the network verification task, task orchestration is performed to obtain the reachability matrix; Based on an instance of the abstract network element model, network verification is performed on the reachability matrix to obtain reachable paths; The step of orchestrating tasks based on network verification tasks to obtain a reachability matrix includes: Based on the network verification task, multiple host and / or container interfaces for network verification are identified. Based on the connection relationships between the multiple host and / or container interfaces, task orchestration is performed to obtain the reachability matrix; The instance based on the abstract network element model performs network verification on the reachability matrix to obtain reachable paths, including: Determine the forwarding paths corresponding to multiple host and / or container interfaces in an instance of the abstract network element model; Based on the forwarding path, the corresponding model instances in the reachability matrix are traversed. If it is determined that there is a path in the reachability matrix that matches the forwarding path, then the matching path is determined as the path to be verified. If it is determined that the directed graph corresponding to the path to be verified is closed, then the path to be verified is determined to be a reachable path.

2. The method according to claim 1, characterized in that, The process of determining the abstract network element model based on the abstract network element function includes: Based on the atomic operations of data forwarding in the network element interface function, a policy routing model is determined; wherein, the atomic operations include access control list and policy routing operations; Based on the aforementioned policy routing model, the abstract network element interface model is determined; Based on the aforementioned virtual routing forwarding function, a virtual routing forwarding model is determined; The abstract network element model is determined based on the abstract network element interface model and the virtual routing forwarding model.

3. The method according to claim 2, characterized in that, The step of determining the abstract network element model based on the abstract network element interface model and the virtual routing and forwarding model includes: The interface attributes are associated with the interface's inbound and / or outbound control policies and link aggregation to obtain the network element device function representation of the interface policy. Associating the virtual routing forwarding attributes with the forwarding table yields a network element device functional representation of the routing forwarding policy; The virtual route forwarding attribute is associated with the global routing table to obtain the network element device function representation of the route leakage policy; Based on the network element device function representations of the interface policy, the routing and forwarding policy, and the routing leakage policy, the abstract network element model is determined.

4. The method according to claim 1, characterized in that, The process of orchestrating tasks based on the multiple host and / or container interfaces to obtain the reachability matrix includes: Based on the plurality of host and / or container interfaces, determine the communication path between the plurality of host and / or container interfaces; The reachability matrix is ​​determined based on the plurality of host and / or container interfaces and the communication paths between the plurality of host and / or container interfaces.

5. The method according to claim 1, characterized in that, The method further includes: Based on the path to be verified, a directed graph is constructed for the corresponding model instances in the reachability matrix to obtain the directed graph corresponding to the path to be verified. If the directed graph is determined to be closed, then the path to be verified is determined to be a reachable path.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Based on instances of the abstract network element model, network verification is performed on the reachability matrix to obtain unreachable paths; Based on the unreachable path, the problematic interface corresponding to the unreachable path is determined, and the relevant information of the problematic interface is fed back to the operation and maintenance end.

7. A network verification device, characterized in that, The device includes: A determining unit is used to determine an abstract network element model based on the abstract network element function; wherein, the abstract network element model is a network element model of the network forwarding plane; the abstract network element function includes network element interface function and virtual routing forwarding function; the abstract network element model is determined by the abstract network element interface model and the virtual routing forwarding model; the abstract network element interface model is determined by the network element interface function, and the virtual routing forwarding model is determined by the virtual routing forwarding function; the abstract network element interface model is used to define the interface attributes in the abstract network element function, and the virtual routing forwarding model is used to define the virtual routing forwarding attributes in the abstract network element function; The orchestration unit is used to orchestrate tasks based on network verification tasks to obtain a reachability matrix. The verification unit is used to perform network verification on the reachability matrix based on instances of the abstract network element model to obtain reachable paths; The orchestration unit is specifically used to determine multiple host and / or container interfaces for network verification based on the network verification task; and to orchestrate the task based on the connection relationship between the multiple host and / or container interfaces to obtain the reachability matrix. The verification unit is specifically used to determine the forwarding paths corresponding to multiple host and / or container interfaces in the instance of the abstract network element model; traverse the corresponding model instances in the reachability matrix based on the forwarding paths; if it is determined that there is a path in the reachability matrix that matches the forwarding path, then the matching path is determined as the path to be verified; if it is determined that the directed graph corresponding to the path to be verified is closed, then the path to be verified is determined as the reachable path.

8. A processing device, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 6.

Images