Network rule verification methods, apparatus, computer equipment, readable storage media, and program products

Abstract

This application relates to a method, apparatus, computer device, computer-readable storage medium, and computer program product for network rule verification. The method includes: obtaining full data from a Neutron database; extracting service tables and data tables from the full data; determining target nodes from the service tables and establishing a mapping relationship based on configuration information in the target nodes and the data tables; extracting a set of configuration information corresponding to the target nodes from the mapping relationship; sending the set of configuration information to the target nodes to instruct them to collect an actual set of rules; generating an expected set of rules based on the set of configuration information; and comparing the actual set of rules with the expected set of rules to obtain at least one of hit rules, residual rules, or missing rules. This method enables efficient and timely detection and handling of network problems by periodically collecting and comparing network rules.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a network rules reconciliation method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] OpenStack is an open-source virtualization and cloud computing application platform that includes multiple fundamental component modules such as computing, storage, and networking. Among them, the Neutron networking module provides OpenStack with the functions of creating, managing, isolating, and connecting virtual networks. Neutron typically uses various network rules to implement these network functions. When a physical cluster meets conditions such as a small physical machine cluster size, a small number of virtual machine services, and infrequent physical machine deployment changes, the network rules within the cluster will be relatively stable, and the service availability of the cluster will be high. Even if rule gaps occur, manual intervention to repair them is a feasible solution.

[0003] However, as the physical machine cluster size increases, the number of virtual machine services increases, network functions iterate and are continuously deployed and upgraded in the production environment, physical machines in the production environment restart, OpenStack becomes unresponsive due to excessive service load, and message queues experience message loss, the cluster may experience various types of missing or residual network rules. This can lead to network service interruptions or incomplete functionality on one or more virtual machines. The Neutron module, by design, only issues rule creation commands during resource creation and full refresh phases, lacking a mechanism for reconfirming rules. Businesses can only manually check and intervene when functional problems occur, a passive approach that consumes significant manpower and time. Summary of the Invention

[0004] Therefore, it is necessary to provide a network rule confirmation method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can automatically reconfirm the rules in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a network rule confirmation method, applied to a data distribution node, including:

[0006] Retrieve the full data from the Neutron database;

[0007] Extract service tables and data tables from the full dataset;

[0008] The target node is determined from the service table, and a mapping relationship is established based on the target node and the configuration information in the data table;

[0009] Extract the configuration information set corresponding to the target node from the mapping relationship, send the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generate the expected rule set based on the configuration information set; compare the actual rule set and the expected rule set to obtain at least one of the following: hit rule, residual rule, or missing rule.

[0010] In one embodiment, obtaining the full data from the Neutron database includes:

[0011] Retrieve full data from the Neutron database at preset intervals;

[0012] Determining the target node from the service table includes:

[0013] All nodes in the service table are used as target nodes.

[0014] In one embodiment, determining the target node from the service table includes:

[0015] Receive a single-node rule confirmation request triggered by a user, the single-node rule confirmation request carrying a node identifier; determine the target node from the service table based on the node identifier.

[0016] In one embodiment, establishing the mapping relationship based on the target node and the configuration information in the data table includes:

[0017] A hash mapping relationship is generated by using the target node as the key and the configuration information corresponding to the target node in the data table as the value.

[0018] Secondly, this application also provides a network rule confirmation method, applied to a data receiving node, including:

[0019] The receiving data distribution node sends a set of configuration information corresponding to the receiving data node. The set of configuration information is extracted by the data distribution node from the mapping relationship. The mapping relationship is established by the data distribution node based on the target node and the configuration information in the data table after determining the target node from the service table. The service table and the data table are extracted by the data distribution node from the full data. The full data is obtained by the data distribution node from the Neutron database.

[0020] Collect the actual set of rules on the data receiving node;

[0021] A set of expected rules is generated based on the aforementioned set of configuration information.

[0022] By comparing the actual rule set and the expected rule set, at least one of the following is obtained: a hit rule, a residual rule, or a missing rule.

[0023] In one embodiment, generating the comparison result includes:

[0024] The rules that intersect in the actual rule set and the expected rule set are combined to form a rule hit set; the rules that exist in the actual rule set but not in the expected rule set are combined to form a rule residue set; and the rules that exist in the expected rule set but not in the actual rule set are combined to form a rule missing set.

[0025] Thirdly, this application also provides a network rule confirmation device, applied to a data distribution node, comprising:

[0026] The retrieval module is used to retrieve the full data from the Neutron database;

[0027] The extraction module extracts service tables and data tables from the full dataset;

[0028] The mapping module determines the target node from the service table and establishes a mapping relationship based on the target node and the configuration information in the data table;

[0029] The sending module extracts the configuration information set corresponding to the target node from the mapping relationship, sends the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generates an expected rule set based on the configuration information set; and compares the actual rule set and the expected rule set to obtain at least one of the following: hit rules, residual rules, or missing rules.

[0030] Fourthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in the first or second aspect.

[0031] Fifthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps described in the first or second aspect.

[0032] Sixthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps described in the first or second aspect.

[0033] The aforementioned network rule confirmation method, apparatus, computer equipment, computer-readable storage medium, and computer program product first obtain full data from the Neutron database; then, extract service tables and data tables from the full data; next, determine target nodes from the service tables and establish a mapping relationship based on the configuration information in the target nodes and the data tables; finally, extract the configuration information set corresponding to the target nodes from the mapping relationship, and send the configuration information set to the target nodes to instruct them to collect the actual rule set on the target nodes; generate an expected rule set based on the configuration information set; and compare the actual rule set and the expected rule set to obtain at least one of hit rules, residual rules, or missing rules. By periodically collecting and comparing network rules, network problems can be efficiently and promptly identified and addressed. Attached Figure Description

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

[0035] Figure 1 This is a flowchart illustrating the data distribution node in a network rule confirmation method in one embodiment;

[0036] Figure 2 This is a schematic diagram illustrating data serialization and deserialization in one embodiment;

[0037] Figure 3 This is a schematic diagram illustrating the acquisition of full data in one embodiment;

[0038] Figure 4 This is a schematic diagram illustrating mapping in one embodiment;

[0039] Figure 5 This is a flowchart illustrating the data receiving node in a network rule confirmation method in one embodiment;

[0040] Figure 6 This is a schematic diagram illustrating the comparison of the actual rule set and the expected rule set in one embodiment;

[0041] Figure 7 This is a schematic diagram of a network rule confirmation system in one embodiment;

[0042] Figure 8 This is a structural block diagram of a network rule confirmation device in one embodiment;

[0043] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0045] In one embodiment, such as Figure 1 As shown, a network rule confirmation method is provided, applied to a data distribution node. In this embodiment, the method includes the following steps:

[0046] Step 102: Retrieve all data from the Neutron database;

[0047] The Neutron database is the part of the Neutron network service component in the OpenStack cloud computing platform used to store network status information.

[0048] The "full data" refers to all network status information. Optionally, the network status information can include: Network: Virtual network information, including network type, segment ID, etc. Subnet: Subnet information, including IP address range, gateway, DNS server, etc. Port: Virtual machine network interface information, including MAC address, IP address, network to which it belongs, etc. Router: Virtual router information, including routing table, namespace, iptables rules, etc.

[0049] For example, all network status information can be retrieved from the Neutron database.

[0050] Step 104: Extract the service table and data table from the full data;

[0051] Optionally, the service table can be an agents table, where the agents table in the Neutron database is used to store information related to Neutron agents. These agents are key components in the Neutron architecture, responsible for performing specific network operations on the host.

[0052] Optionally, the data table can be a ports table, a VPC (Virtual Private Cloud) table, etc. Among them, in the Neutron database, the ports table is a key data table used to store information related to virtual machine network interfaces (ports). The VPC table is used to manage the private cloud.

[0053] For example, extract the agents and ports tables from all network status information.

[0054] Step 106: Determine the target node from the service table, and establish a mapping relationship based on the target node and the configuration information in the data table;

[0055] The target node is the node that needs network status information.

[0056] Optionally, the configuration information in the data table can be the port number from the ports table.

[0057] For example, the node that needs network status information is determined from the agents table as the target node, and the name of the target node in the agents table and the port number of the target node in the ports table are mapped to establish a mapping relationship.

[0058] Step 108: Extract the configuration information set corresponding to the target node from the mapping relationship, and send the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generate an expected rule set based on the configuration information set; compare the actual rule set and the expected rule set to obtain at least one of the following: hit rules, residual rules, or missing rules.

[0059] Optionally, the configuration information set can be information from tables such as ports table and VPC table corresponding to each node.

[0060] Optional, such as Figure 2 As shown, data distribution between nodes can be achieved using a point-to-point RPC (Remote Procedure Call) approach. Each data receiving node starts an RPC server, and the data distributing node starts an RPC client for each data receiving node, sending data related to the destination node through the corresponding client. In practice, for ease of data transmission, serialization and deserialization are required before distribution and after reception. Serialization formats can include JSON, protobuf, etc. For the Go programming language, the specific data type can be converted to an interface type at the data distribution end, then further converted to a byte type, and then reverse-converted at the data receiving end and type asserted back to the specific data type.

[0061] For example, information from tables such as ports and VPC corresponding to the target node is extracted from the mapping relationship. The information from the ports and VPC tables is serialized. The serialized information is sent to the RPC server of the target node using an RPC client to instruct the target node to collect the actual rule set on the target node. An expected rule set is generated based on the configuration information set. The actual rule set and the expected rule set are compared to obtain at least one of the following: hit rules, residual rules, or missing rules.

[0062] The aforementioned network rule confirmation method, apparatus, computer equipment, computer-readable storage medium, and computer program product first obtain full data from the Neutron database; then, extract service tables and data tables from the full data; next, determine target nodes from the service tables and establish a mapping relationship based on the configuration information in the target nodes and the data tables; finally, extract the configuration information set corresponding to the target nodes from the mapping relationship, and send the configuration information set to the target nodes to instruct them to collect the actual rule set on the target nodes; generate an expected rule set based on the configuration information set; and compare the actual rule set and the expected rule set to obtain at least one of hit rules, residual rules, or missing rules. By periodically collecting and comparing network rules, network problems can be efficiently and promptly identified and addressed.

[0063] In one exemplary embodiment, such as Figure 3 As shown, obtaining full data from the Neutron database includes: obtaining full data from the Neutron database at preset intervals;

[0064] Determining the target node from the service table includes: taking all nodes in the service table as the target node.

[0065] In this context, a node is actually a host.

[0066] Optionally, the preset duration can be 1 hour.

[0067] Optionally, data can be retrieved from the Neutron database by setting a timer to trigger automatically, or by manually accessing data from a specific host or all hosts through a RESTful API.

[0068] For example, a timed trigger can be set up to retrieve the data of all nodes in the Neutron database every hour as the current real-time data.

[0069] In this embodiment, data from the Neutron database is retrieved at predetermined intervals for subsequent comparison, which can periodically check whether there are missing or residual network rules.

[0070] In one exemplary embodiment, such as Figure 3 As shown, determining the target node from the service table includes:

[0071] Receive a single-node rule confirmation request triggered by a user, the single-node rule confirmation request carrying a node identifier; determine the target node from the service table based on the node identifier.

[0072] Optionally, the node rule confirmation request triggered by the user may not be a single node, but may be multiple nodes or all nodes.

[0073] For example, a user-triggered single-node rule confirmation request is received through a RESTful API interface, the single-node rule confirmation request carrying a node identifier; the target node is determined from the service table based on the node identifier.

[0074] In this embodiment, the data acquisition method can support the needs of scenarios such as human intervention and emergency inspection.

[0075] In an exemplary embodiment, establishing a mapping relationship based on the target node and the configuration information in the data table includes:

[0076] A hash mapping relationship is generated by using the target node as the key and the configuration information corresponding to the target node in the data table as the value.

[0077] Optional, such as Figure 4 As shown, taking the `ports` table in Neutron as an example, the `ports` table records network port information on each node. This information is used to establish a mapping between ports and hostnames. More complex tables, such as the `vpc` table in Neutron, first require establishing a mapping between ports and VPCs, and then combining this with the mapping between ports and hostnames to calculate the mapping between hostnames and VPCs. It's important to note that this mapping can be one-to-many or even many-to-many, but through the methods described above, we can ultimately obtain the mapping between a single host and all types of data.

[0078] For example, a hash mapping relationship is generated by using the hostname of the target node as the key and the port number corresponding to the target node in the ports table as the value.

[0079] In this embodiment, by associating node names with ports, the data required by each node is sent to the corresponding node, instead of sending all data to all target nodes without processing, which can reduce the amount of data transmission in subsequent steps.

[0080] In one embodiment, such as Figure 5 As shown, a network rule confirmation method is provided, applied to a data receiving node. In this embodiment, the method includes the following steps:

[0081] Step 202: Receive the configuration information set corresponding to the data receiving node sent by the data distribution node. The configuration information set is extracted by the data distribution node from the mapping relationship. The mapping relationship is established by the data distribution node based on the target node and the configuration information in the data table after determining the target node from the service table. The service table and the data table are extracted by the data distribution node from the full data. The full data is obtained by the data distribution node from the Neutron database.

[0082] Optionally, the corresponding configuration information set can be received through an RPC server.

[0083] For example, the serialized information of the configuration information set corresponding to the data receiving node sent by the data distribution node is received by the RPC server and deserialized. The configuration information set is extracted by the data distribution node from the mapping relationship. The mapping relationship is established by the data distribution node based on the target node and the configuration information in the data table after determining the target node from the service table. The service table and the data table are extracted by the data distribution node from the full data. The full data is obtained by the data distribution node from the Neutron database.

[0084] Step 204: Collect the actual rule set on the data receiving node;

[0085] Among them, the actual rule set is the set of actual network rules.

[0086] For example, all network rules on the data receiving node are collected to form an actual rule set.

[0087] For example, taking Open vSwitch flow table rules as an example, first execute the command "ovs-ofctl dump-flows br-int table=0 --no-stat --names" to obtain the rules of the br-int bridge with table=0, and put the obtained rules into the actual rule set.

[0088] Step 206: Generate a set of expected rules based on the configuration information set;

[0089] The expected rule set is a collection of all network rules extracted from the configuration information set.

[0090] Optionally, generating the expected rules on the host requires querying the distributed data using different filtering conditions. Since the same query condition may be used multiple times, to reduce data traversal operations, this step requires first traversing the received data and pre-establishing a mapping relationship between the received data pointers based on the filtering conditions to be used later. This way, in subsequent queries, the required data can be quickly retrieved without traversing the entire data table, reducing the query time for generating the expected rules and contributing to ensuring data real-time performance.

[0091] For example, the configuration information set is traversed and an index is built. All network rules in the configuration information set are collected through the index to form the expected rule set.

[0092] For example, for each port of device type virtual machine, a flow table will be generated in table=0 of br-int bridge. For example, for a port corresponding to a virtual machine whose first ten digits are xxxxxxxx-xx, it is expected that a flow table rule of priority=10,arp,in_port="qvoxxxxxxxx-xx" actions=resubmit(,24) will be generated, and the generated rule will be put into the expected rule set.

[0093] Step 208: Compare the actual rule set and the expected rule set to obtain at least one of the hit rules, residual rules, or missing rules.

[0094] The comparison between the actual rule set and the expected rule set involves comparing the overlapping and different parts of the two sets.

[0095] For example, by comparing the actual rule set and the expected rule set, one or more of the following can be obtained: the hit rule set, the residual rule set, or the missing rule set.

[0096] In one exemplary embodiment, such as Figure 6 As shown, the generation of the comparison results includes:

[0097] The rules that intersect in the actual rule set and the expected rule set are combined to form a rule hit set; the rules that exist in the actual rule set but not in the expected rule set are combined to form a rule residue set; and the rules that exist in the expected rule set but not in the actual rule set are combined to form a rule missing set.

[0098] For example, the rules that intersect in the actual rule set and the expected rule set are combined to form the rule hit set; the rules that exist in the actual rule set but do not exist in the expected rule set are combined to form the rule residue set; and the rules that exist in the expected rule set but do not exist in the actual rule set are combined to form the rule missing set.

[0099] Furthermore, based on the comparison results, the system performs result reporting, result recording, and rule repair operations. Result Reporting: An interface for acquiring monitoring data is provided externally. Prometheus monitoring periodically accesses the monitoring data interface to retrieve brief comparison results, and then triggers alarms to alert relevant personnel. For example, the reported data includes the total number of residual rules and the total number of missing rules. An alarm is triggered when the total number of residual or missing rules reaches a threshold. Result Recording: Detailed comparison results are persistently stored locally in files. After observing alarm information, relevant personnel can focus on comparison results of interest through local files. Compared to report comparison results, recording comparison results can specify which rules are missing or residual. These records can help technical personnel analyze whether systemic vulnerabilities exist. Rule Repair: Based on the difference between actual and expected rules, the system can choose to automatically complete missing rules and delete residual rules, or manually confirm and repair rules of higher importance.

[0100] In one exemplary embodiment, such as Figure 7 As shown, a network rule verification method is applied to a system consisting of data distribution nodes and data receiving nodes. There can be one data distribution node and multiple data receiving nodes. The Neutron database can be deployed on the data distribution node, which also deploys a distributor and an RPC client. Each data receiving node deploys an RPC client, a receiver, and a comparator. For ease of explanation, the RPC client deployed on the data distribution node is referred to as the distribution-side RPC client, and the RPC client deployed on the data receiving node is referred to as the receiving-side RPC client. The above network rule verification method includes the following steps:

[0101] The distributor retrieves full data from the Neutron database; extracts service tables and data tables from the full data; determines target nodes from the service tables, and establishes a mapping relationship based on the configuration information of the target nodes and the data tables; extracts the configuration information set corresponding to the target nodes from the mapping relationship, and sends the configuration information set to the target nodes among multiple data distribution nodes through the distribution-side RPC client. The receiving-side RPC client deployed in the target nodes receives the configuration information set and transmits it to the comparator through the receiver. The comparator collects the actual rule set on the target nodes; generates an expected rule set based on the configuration information set; compares the actual rule set and the expected rule set to obtain a comparison result, which includes at least one of hit rules, residual rules, or missing rules; the comparison result can be processed as follows: recording, top-level, and rule repair. The detailed implementation process of the data distribution nodes and target nodes performing this step is described in the aforementioned embodiments and will not be repeated here.

[0102] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0103] In one exemplary embodiment, such as Figure 8 As shown, a network rule confirmation device is provided, applied to a data distribution node, including: an acquisition module, an extraction module, a mapping module, and a sending module, wherein:

[0104] The retrieval module is used to retrieve the full data from the Neutron database;

[0105] The extraction module extracts service tables and data tables from the full dataset;

[0106] The mapping module determines the target node from the service table and establishes a mapping relationship based on the target node and the configuration information in the data table;

[0107] The sending module extracts the configuration information set corresponding to the target node from the mapping relationship, sends the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generates an expected rule set based on the configuration information set; and compares the actual rule set and the expected rule set to obtain at least one of the following: hit rules, residual rules, or missing rules.

[0108] In one exemplary embodiment, the acquisition module is further configured to: acquire full data from the Neutron database at preset intervals;

[0109] Determining the target node from the service table includes: taking all nodes in the service table as the target node.

[0110] In one exemplary embodiment, the acquisition module is further configured to:

[0111] Receive a single-node rule confirmation request triggered by a user, the single-node rule confirmation request carrying a node identifier; determine the target node from the service table based on the node identifier.

[0112] In one exemplary embodiment, the mapping module is further configured to:

[0113] A hash mapping relationship is generated by using the target node as the key and the configuration information corresponding to the target node in the data table as the value.

[0114] Each module in the aforementioned network rule confirmation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0115] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores all data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a network rule verification method.

[0116] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0117] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0118] Retrieve the full data from the Neutron database;

[0119] Extract service tables and data tables from the full dataset;

[0120] The target node is determined from the service table, and a mapping relationship is established based on the target node and the configuration information in the data table;

[0121] Extract the configuration information set corresponding to the target node from the mapping relationship, send the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generate the expected rule set based on the configuration information set; compare the actual rule set and the expected rule set to obtain at least one of the following: hit rule, residual rule, or missing rule.

[0122] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0123] Retrieve full data from the Neutron database at preset intervals;

[0124] Determining the target node from the service table includes:

[0125] All nodes in the service table are used as target nodes.

[0126] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0127] Receive a single-node rule confirmation request triggered by a user, the single-node rule confirmation request carrying a node identifier; determine the target node from the service table based on the node identifier.

[0128] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0129] A hash mapping relationship is generated by using the target node as the key and the configuration information corresponding to the target node in the data table as the value.

[0130] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0131] Retrieve the full data from the Neutron database;

[0132] Extract service tables and data tables from the full dataset;

[0133] The target node is determined from the service table, and a mapping relationship is established based on the target node and the configuration information in the data table;

[0134] Extract the configuration information set corresponding to the target node from the mapping relationship, send the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generate the expected rule set based on the configuration information set; compare the actual rule set and the expected rule set to obtain at least one of the following: hit rule, residual rule, or missing rule.

[0135] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0136] Retrieve full data from the Neutron database at preset intervals;

[0137] Determining the target node from the service table includes:

[0138] All nodes in the service table are used as target nodes.

[0139] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0140] Receive a single-node rule confirmation request triggered by a user, the single-node rule confirmation request carrying a node identifier; determine the target node from the service table based on the node identifier.

[0141] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0142] A hash mapping relationship is generated by using the target node as the key and the configuration information corresponding to the target node in the data table as the value.

[0143] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0144] Retrieve the full data from the Neutron database;

[0145] Extract service tables and data tables from the full dataset;

[0146] The target node is determined from the service table, and a mapping relationship is established based on the target node and the configuration information in the data table;

[0147] Extract the configuration information set corresponding to the target node from the mapping relationship, send the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generate the expected rule set based on the configuration information set; compare the actual rule set and the expected rule set to obtain at least one of the following: hit rule, residual rule, or missing rule.

[0148] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0149] Retrieve full data from the Neutron database at preset intervals;

[0150] Determining the target node from the service table includes:

[0151] All nodes in the service table are used as target nodes.

[0152] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0153] Receive a single-node rule confirmation request triggered by a user, the single-node rule confirmation request carrying a node identifier; determine the target node from the service table based on the node identifier.

[0154] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0155] A hash mapping relationship is generated by using the target node as the key and the configuration information corresponding to the target node in the data table as the value.

[0156] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0157] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0158] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for confirming network rules, characterized in that, Applied to a data distribution node, the method includes: Retrieve the full data from the Neutron database; Extract service tables and data tables from the full dataset; the service table is the agents table, and the data table is either the ports table or the VPC table. The target node is determined from the service table, and the target node is used as the key. The configuration information corresponding to the target node in the data table is used as the value to generate a hash mapping relationship. Extract the configuration information set corresponding to the target node from the mapping relationship, and send the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generate an expected rule set based on the configuration information set; compare the actual rule set and the expected rule set to obtain at least one of the following: hit rules, residual rules, or missing rules; Generate comparison results, including: The rules that intersect in the actual rule set and the expected rule set are combined to form a rule hit set; the rules that exist in the actual rule set but not in the expected rule set are combined to form a rule residue set; and the rules that exist in the expected rule set but not in the actual rule set are combined to form a rule missing set.

2. The method according to claim 1, characterized in that, The process of obtaining full data from the Neutron database includes: Retrieve full data from the Neutron database at preset intervals; Determining the target node from the service table includes: All nodes in the service table are used as target nodes.

3. The method according to claim 1, characterized in that, Determining the target node from the service table includes: Receive a single-node rule confirmation request triggered by a user, the single-node rule confirmation request carrying a node identifier; determine the target node from the service table based on the node identifier.

4. A method for confirming network rules, characterized in that, Applied to a data receiving node, the method includes: The system receives a set of configuration information corresponding to the data receiving node sent by the data distribution node. This set of configuration information is extracted by the data distribution node from a hash mapping relationship. The hash mapping relationship is generated by the data distribution node determining the target node from the service table, using the target node as the key, and the configuration information corresponding to the target node in the data table as the value. The service table and the data table are extracted by the data distribution node from the full dataset, which is obtained from the Neutron database. The service table is the `agents` table, and the data table is either the `ports` table or the `VPC` table. Collect the actual set of rules on the data receiving node; A set of expected rules is generated based on the aforementioned set of configuration information. By comparing the actual rule set and the expected rule set, at least one of the hit rule, residual rule, or missing rule is obtained; Generate comparison results, including: The rules that intersect in the actual rule set and the expected rule set are combined to form a rule hit set; the rules that exist in the actual rule set but not in the expected rule set are combined to form a rule residue set; and the rules that exist in the expected rule set but not in the actual rule set are combined to form a rule missing set.

5. A network rule confirmation device, characterized in that, The device, applied to a data distribution node, includes: The retrieval module is used to retrieve the full data from the Neutron database; The extraction module extracts a service table and a data table from the full dataset; the service table is the agents table, and the data table is either the ports table or the VPC table. The mapping module determines the target node from the service table, uses the target node as the key, and uses the configuration information corresponding to the target node in the data table as the value to generate a hash mapping relationship; The sending module extracts the configuration information set corresponding to the target node from the mapping relationship, sends the configuration information set to the target node to instruct the target node to collect the actual rule set on the target node; generates an expected rule set based on the configuration information set; and compares the actual rule set and the expected rule set to obtain at least one of the following: hit rules, residual rules, or missing rules. Generate comparison results, including: The rules that intersect in the actual rule set and the expected rule set are combined to form a rule hit set; the rules that exist in the actual rule set but not in the expected rule set are combined to form a rule residue set; and the rules that exist in the expected rule set but not in the actual rule set are combined to form a rule missing set.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images