Network connectivity verification method, device, equipment, storage medium and program product

Abstract

This application provides a network connectivity verification method, apparatus, device, storage medium, and program product, which can be applied to the field of financial technology. The method includes: obtaining a device collection task list based on basic collection information of cross-vendor network devices pre-entered by a maintenance terminal; collecting configuration information of the cross-vendor network devices based on the collection task list to obtain raw private configuration information, translating the raw private configuration information into a universal format independent of the vendor's instruction set, and storing it in a database server; responding to a connectivity query request containing source and destination addresses, matching the corresponding end-to-end access path in a topology database based on the source and destination addresses, and retrieving standard configuration information in a universal format for the corresponding device from the database server; sequentially performing progressive verification on the standard configuration information to generate a verification report; and determining the network connectivity status from the source address to the destination address based on the verification report to generate a connectivity report.

Description

Technical Field

[0001] This application relates to the field of financial technology, specifically to a network device testing method, and more specifically to a network connectivity verification method, apparatus, device, storage medium, and program product. Background Technology

[0002] The network environment is a crucial foundation of modern information systems, composed of network devices from multiple vendors, models, and types, resulting in complex device configurations and numerous policies. In daily network operation and maintenance, troubleshooting, new service deployment, and environment setup, network connectivity verification and policy effectiveness checks are core tasks.

[0003] Currently, the industry generally relies on maintenance personnel to manually check configurations, debug each device individually, and judge fault points based on experience. This is inefficient due to significant differences in the technical capabilities of different personnel, and is prone to omissions and misjudgments. Although some equipment manufacturers provide their own knowledge bases or dedicated simulation tools, these are limited to a single brand or a single equipment type, and cannot be compatible with unified analysis across manufacturers and devices. They also make it difficult to achieve end-to-end policy verification and path analysis from the source to the destination. Summary of the Invention

[0004] In view of the above problems, embodiments of this application provide a network connectivity verification method, apparatus, device, storage medium, and program product.

[0005] According to a first aspect of this application, a network connectivity verification method is provided, comprising: configuring personalized collection parameters and cycles for cross-vendor network devices based on basic collection information pre-entered by a maintenance terminal to obtain a device collection task list; collecting configuration information from the cross-vendor network devices based on the collection task list to obtain original private configuration information, and converting the original private configuration information into a generic format independent of the vendor instruction set according to device type templates, and storing it in a database server; responding to a connectivity query request containing a source address and a destination address, matching the corresponding full-link access path in a topology database based on the source address and the destination address to generate a sequence of passing devices arranged in the access order of the full-link access path, and retrieving standard configuration information of the corresponding device in a generic format from the database server based on the sequence of passing devices; performing progressive verification on the standard configuration information in sequence to generate a verification report containing matching results and fault details, and determining the network connectivity status from the source address to the destination address based on the verification report to generate a connectivity report.

[0006] According to an embodiment of this application, based on the basic collection information of cross-vendor network devices pre-entered on the maintenance terminal, personalized collection parameters and cycles are configured for the cross-vendor network devices to obtain a device collection task list. This includes: parsing the basic collection information to obtain the access address, information collection username, and login password of the cross-vendor network devices filled in on the maintenance terminal. The cross-vendor network devices include at least one of routers, switches, firewalls, and load balancers; performing a first classification operation on the cross-vendor network devices according to their actual attributes to obtain a functional device group; performing a second classification operation on the functional device group according to the manufacturer and model to obtain a personalized device group; and performing personalized collection configuration on the personalized device group based on a preset default collection template or a custom device configuration collection command to obtain a device collection task list. The configured device information in the device collection task list includes at least one of the following: device information, collection parameters, and collection cycle.

[0007] According to an embodiment of this application, configuration information is collected from cross-vendor network devices based on a collection task list to obtain original private configuration information. This includes: starting a timed collection engine through a preset information collection server according to a preset collection period, so that the timed collection engine remotely logs into the cross-vendor network devices according to the login information or collection command in the collection task list, in order to capture the original private configuration information of the cross-vendor network devices.

[0008] According to an embodiment of this application, matching the corresponding end-to-end access path in the topology database based on the source address and the destination address includes: retrieving the network device segment affiliation corresponding to the source address and the destination address in the topology database; determining the starting and ending devices for connectivity verification based on the network device segment affiliation; and using the physical connection relationship or logical access relationship of the devices in the topology database that matches the starting device to the ending device as the end-to-end access path.

[0009] According to an embodiment of this application, based on the sequence of passing devices, standard configuration information in a general format for the corresponding devices is retrieved from a database server. This includes: retrieving configuration information in a general format for the corresponding network devices from the database server using the unique identifier of the devices in the sequence of passing devices as the search criteria, as a configuration dataset to be analyzed; filtering configuration information related to the connectivity of the source address and the destination address from the configuration dataset to be analyzed, obtaining relevant configuration information; performing deduplication processing on the relevant configuration analysis to obtain valid configuration information; and integrating the valid configuration information according to the device type to form standard configuration information corresponding to the source address and the destination address of each network device.

[0010] According to an embodiment of this application, the standard configuration information is sequentially verified to generate a verification report containing matching results and fault details. This includes: parsing and classifying the standard configuration information according to device type, and sequentially verifying address resolution information, routing entries, and access control rules according to network access logic to generate a verification report containing matching results and fault details.

[0011] According to an embodiment of this application, generating a verification report including matching results and fault details includes: classifying the matching results of each device at each level into two categories: matching or non-matching; if the matching result of a single device at a single level indicates a non-match, then terminating the verification of network devices of the same model as the single device at that single level, and marking the single level as a fault level; performing detailed tracing of network devices with non-matching results, recording the fault device name, fault level, specific fault configuration item, and fault cause as fault details; if the specific fault configuration item is an access control rule fault, then recording the current access control rule as the fault cause; and integrating the matching results and fault details of all network devices according to a preset three-layer hierarchical structure to generate a verification report.

[0012] According to an embodiment of this application, the network connectivity status from the source address to the target address is determined based on the verification report to generate a connectivity report. This includes: if the matching results of each layer and each device in the end-to-end access path are all matched, the network connectivity status indicates normal connectivity; if any mismatch exists, the network connectivity status indicates connectivity failure, and the network device whose matching result indicates a mismatch is identified as the fault point; combining the device manufacturer's general configuration commands, an executable repair suggestion is generated for the fault point, including the name of the device to be modified, the configuration command, the location of the configuration modification, and operation precautions; the end-to-end access path, network connectivity status, verification report, and repair suggestion are integrated to obtain a connectivity report.

[0013] According to a second aspect of this application, a network connectivity verification device is provided, comprising: a list determination module, configured to configure personalized collection parameters and cycles for cross-vendor network devices based on basic collection information of cross-vendor network devices pre-entered by a maintenance terminal, thereby obtaining a device collection task list; an information collection module, configured to collect configuration information of cross-vendor network devices based on the collection task list, obtain original private configuration information, and convert the original private configuration information into a general format that is independent of the vendor instruction set according to device type template classification, and store it in a database server; an information acquisition module, configured to respond to a connectivity query request containing a source address and a destination address, match the corresponding full-link access path in a topology database based on the source address and the destination address, generate a sequence of passing devices arranged in the access order of the full-link access path, and retrieve standard configuration information of the corresponding device in a general format from the database server based on the sequence of passing devices; and a progressive verification module, configured to perform progressive verification on the standard configuration information in sequence, generate a verification report containing matching results and fault details, determine the network connectivity status from the source address to the destination address based on the verification report, and generate a connectivity report.

[0014] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0016] According to a fifth aspect of this application, a computer program product is also provided, comprising a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 The illustrations depict application scenarios of network connectivity verification methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0019] Figure 2 A flowchart illustrating a network connectivity verification method according to an embodiment of this application is shown schematically.

[0020] Figure 3The diagram illustrates a data acquisition process in a network connectivity verification method according to an embodiment of this application.

[0021] Figure 4 This illustration schematically shows an operation diagram of obtaining standard configuration information in a network connectivity verification method according to an embodiment of this application;

[0022] Figure 5 This schematic diagram illustrates the structural block diagram of a network connectivity verification device according to an embodiment of the present application;

[0023] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a network connectivity verification method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0028] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0029] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all provide users with corresponding operation entry points for users to choose to agree to or reject the automated decision results; if the user chooses to reject, the process enters the expert decision-making process.

[0030] As the scale of core networks in the fintech sector continues to expand, cross-vendor, cross-regional, and multi-level network architectures are becoming increasingly common, highlighting the growing shortcomings of current technologies: First, they cannot uniformly collect and standardize the configurations of heterogeneous devices from multiple vendors, and incompatible configuration formats make end-to-end analysis difficult; second, they lack a mechanism to automatically generate access paths based on source and destination addresses and progressively verify them according to network logic, resulting in vague and inaccurate fault location; third, they can only complete configuration viewing and simple rule matching, and cannot automatically generate executable repair solutions, still requiring secondary manual analysis; fourth, collection, parsing, verification, and display are fragmented, failing to form an integrated automated verification system, which seriously affects the efficiency of network fault handling and business stability.

[0031] Figure 1 The diagram illustrates an application scenario for network connectivity verification according to an embodiment of this application. For example... Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send information, etc.

[0032] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal devices. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, and it can include, but is not limited to, applications, mini-programs, etc., installed on the terminal devices, and can also be in the form of web pages.

[0033] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data. The server can be the backend server of the aforementioned target application, used to provide backend services to the clients of the target application.

[0034] It should be noted that the network connectivity verification method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-103. Accordingly, the network connectivity verification device provided in this application embodiment can generally be set in server 105 and / or terminal devices 101-103.

[0035] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0036] Figure 2 A flowchart illustrating a network connectivity verification method according to an embodiment of this application is shown schematically. Figure 2 As shown, the network connectivity verification method 200 according to the embodiments of this application may include steps S210 to S240.

[0037] In step S210, based on the basic data collection information of cross-vendor network devices pre-entered by the maintenance terminal, personalized data collection parameters and cycles are configured for the cross-vendor network devices to obtain a list of device data collection tasks.

[0038] As an example, basic data collection information for cross-vendor network devices is entered into the maintenance terminal. Personalized data collection parameters and cycles are configured for the cross-vendor network devices. After submission, a standardized device data collection task list is generated as the input basis for information collection. Specifically, a bank's operations and maintenance personnel enter basic data collection information for routers from vendor A, switches from vendor B, and firewalls from vendor C into the maintenance terminal, select the corresponding vendor / type, and configure personalized data collection parameters and cycles for these cross-vendor network devices. Among them, the data collection cycle for the firewall from vendor C is configured to be 3:00 AM every day. After submission, a device data collection task list is generated.

[0039] In step S220, configuration information of cross-vendor network devices is collected based on the collection task list to obtain raw private configuration information. The raw private configuration information is then converted into a general format that is independent of the vendor instruction set according to the device type template and stored in the database server.

[0040] As an example, the information collection server collects configuration information from cross-vendor network devices based on the device collection task list. It converts the original private configuration information into a generic format that is independent of the vendor's instruction set, according to the device type template, and stores it in the database server. Specifically, the information collection server automatically collects the original configuration information of three devices based on the device collection task list. It organizes the routing entries of the router from vendor A, the access control rules of the switch from vendor B, and the private security policy instructions of the firewall from vendor C according to the templates of the router, switch, and firewall, respectively, translates them into a generic format that is independent of the vendor's instruction set, and stores them in the database server.

[0041] In step S230, in response to a connectivity query request containing source address and destination address, the corresponding full-link access path is matched in the topology database based on the source address and destination address to generate a sequence of passing devices arranged in the access order of the full-link access path, and based on the sequence of passing devices, the standard configuration information of the corresponding devices in a general format is retrieved from the database server.

[0042] As an example, the data analysis server receives a connectivity query request from a query terminal containing a source address_mask and a destination address_mask. Based on the source and destination addresses, it matches the corresponding physical and logical end-to-end access paths in the topology database and generates a sequence of devices along the path arranged in access order. This sequence serves as the input for the device range during policy verification. Specifically, the user initiates a query by entering the source address: 192.168.XX and the destination address: 192.168.XX in the query terminal. The data analysis server matches the end-to-end path in the topology database to a switch from vendor B, a router from vendor A, and a firewall from vendor C, generates a sequence of devices along the path, and retrieves standard configuration information in a common format for different devices from the database server.

[0043] In step S240, the standard configuration information is progressively verified in sequence to generate a verification report containing matching results and fault details. Based on the verification report, the network connectivity status from the source address to the target address is determined to generate a connectivity report.

[0044] As an example, the retrieved standard configuration information in a generic format is progressively verified sequentially, generating a verification report containing matching results and fault details. Based on the verification report, the network connectivity status from the source address to the destination address is determined to generate a connectivity report. Specifically, the retrieved standard configuration information in a generic format from vendor B's switch, vendor A's router, and vendor C's firewall is progressively verified sequentially. Following network access logic, the validity of the address resolution protocol is verified first, then the route reachability is verified, and finally the access control permission is verified. It is found that vendor C's firewall has not configured a security permission policy for the source and destination addresses, generating a connectivity report containing the faulty device, fault item, and fault cause.

[0045] Based on this, the solution addresses the technical challenges of using tools from a single vendor to achieve end-to-end analysis, the inconsistency in configuration information across different vendors' proprietary instruction sets leading to inconsistent formats and preventing direct cross-device rule verification, and the disconnect between collected data and actual verification requirements. This approach establishes a progressive verification system based on actual network access logic, performing address resolution, routing, and access control rule checks. This allows for tracing fault points and their specific causes, generating directly executable configuration repair suggestions, reducing operational complexity, and improving fault handling efficiency.

[0046] In this embodiment, based on the basic collection information of cross-vendor network devices pre-entered in the maintenance terminal, personalized collection parameters and cycles are configured for the cross-vendor network devices to obtain a device collection task list. This includes: parsing the basic collection information to obtain the access address, information collection username, and login password of the cross-vendor network devices filled in on the maintenance terminal. The cross-vendor network devices include at least one of routers, switches, firewalls, and load balancers; performing a first classification operation on the cross-vendor network devices according to their actual attributes to obtain a functional device group; performing a second classification operation on the functional device group according to the manufacturer and model to obtain a personalized device group; and performing personalized collection configuration on the personalized device group based on a preset default collection template or a custom device configuration collection command to obtain a device collection task list. The configured device information in the device collection task list includes at least one of the following: device information, collection parameters, and collection cycle.

[0047] As an example, in the maintenance terminal, fill in the access address, information collection username, and login password of the cross-vendor network devices to be collected. These cross-vendor network devices include routers, switches, firewalls, load balancers, and other types of cross-vendor devices. Based on the actual attributes of the devices, perform a first classification operation on the cross-vendor network devices to obtain functional device groups. Perform a second classification operation on the functional device groups according to manufacturer and model to obtain personalized device groups. Collection parameters can be selected from the system default collection template or custom device configuration collection commands to adapt to the personalized collection needs of different devices, resulting in a device collection task list. Configure the collection period for cross-vendor network devices, supporting customization by hour / day / week. After submitting all configuration information, the system automatically generates a device collection task list containing device information, collection parameters, and collection period.

[0048] In a more specific example, maintenance personnel enter basic data collection information for cross-vendor network devices into the maintenance terminal. This information is then parsed to obtain the access addresses, data collection usernames, and login passwords for the load balancer from vendor A and the switch from vendor B. The access address for the load balancer from vendor A is 172.16.XX, and the access address for the switch from vendor B is 192.168.XX. Based on the actual attributes of the devices, the cross-vendor network devices are first categorized, with the load balancer from vendor A placed in the load balancing function device group and the switch from vendor B placed in the switching function device group. A second categorization is then performed on each function device group according to vendor and model, with the load balancer from vendor A placed in the vendor A load balancer personalized device group and the switch from vendor B placed in the vendor B switch personalized device group. Personalized data collection configurations are then performed on these personalized device groups based on a preset default data collection template or a custom device configuration data collection command. A custom device configuration data collection command is used for the load balancer from vendor A, while a preset default data collection template is used for the switch from vendor B, and corresponding data collection periods are configured for each. After submission, a device data collection task list containing device information, data collection parameters, and data collection periods is generated.

[0049] Based on this, the technical problems of lacking a unified standard for entering basic information of cross-vendor devices, the inability of collection parameters to adapt to personalized needs, and the inflexibility of data updates due to fixed collection cycles are resolved. This results in a standardized basic data configuration process that supports information entry for multiple types of cross-vendor devices, balancing general and custom collection parameters. Flexible collection cycle configuration ensures timely updates of device configuration information, improving the efficiency and consistency of subsequent device configuration information collection.

[0050] Figure 3 The diagram illustrates a data acquisition process in a network connectivity verification method according to an embodiment of this application.

[0051] exist Figure 3 In the embodiment shown, configuration information of cross-vendor network devices is collected based on the collection task list to obtain the original private configuration information. This includes: starting a timed collection engine through a preset information collection server according to a preset collection period, so that the timed collection engine remotely logs into the cross-vendor network devices according to the login information or collection command in the collection task list, so as to capture the original private configuration information of the cross-vendor network devices.

[0052] As an example, configuration information is collected from cross-vendor network devices. The information collection server automatically starts the collection engine to execute collection tasks according to a preset collection cycle, or maintenance personnel manually start temporary collection tasks from the maintenance terminal and retrieve the device collection task list. Based on the login information and collection commands in the device collection task list, remote login is performed on cross-vendor devices and raw private configuration information is collected. The raw private configuration information is then initially classified according to device types such as routers, switches, and firewalls.

[0053] In a more specific example, the information collection server automatically starts the collection task at 3:00 AM every day according to the preset collection cycle, retrieves the collection task list including the load balancer of vendor A and the switch of vendor B, remotely logs into the two devices according to the account and password in the collection task list, and captures the original private configuration information of the two devices through the collection command.

[0054] Based on this, the technical problems of a single data collection task initiation method, low parsing efficiency due to the lack of preliminary classification of raw configuration information, and the inability to directly use cross-vendor proprietary commands for subsequent analysis are addressed. Thus, through a unified data collection server and a scheduled data collection engine, remote automated data collection from multiple vendors' devices is achieved, reducing manual intervention while ensuring stable, periodic execution of data collection tasks, thereby improving the efficiency of automatic data collection from cross-vendor network device configuration information.

[0055] In this embodiment, matching the corresponding end-to-end access path in the topology database based on the source address and the destination address includes: retrieving the network device segment affiliation corresponding to the source address and the destination address in the topology database; determining the starting and ending devices for connectivity verification based on the network device segment affiliation; and using the physical connection relationship or logical access relationship of the devices in the topology database that matches the starting device to the ending device as the end-to-end access path.

[0056] As an example, the acquisition of the end-to-end access path driven by source and destination addresses includes: the data analysis server receiving a connectivity query request from the query terminal, verifying whether the request contains the mandatory conditions of source address_mask and destination address_mask; if the verification passes, proceeding to the next step; if it fails, providing a prompt for completion; matching the network segment affiliation of the source and destination addresses, retrieving the network device network segment affiliation corresponding to the source and destination addresses in the topology database, and determining the starting and ending devices for connectivity verification; generating the end-to-end topology path, matching the end-to-end access path from the starting device to the ending device based on the pre-stored physical connection relationships and logical access relationships of the devices in the topology database, generating a sequence of devices along the path arranged in network access order and marking the device type, and using the physical connection relationship or logical access relationship of the devices as the end-to-end access path.

[0057] In a specific example, the data analysis server receives a query request, verifies that it contains a source address of 192.168.XX and a destination address of 21.8.XX, and the verification passes. The topology database is retrieved, showing that the source address belongs to a switch from vendor A and the destination address belongs to a router from vendor B. Based on the physical connections and logical access relationships (no detours) of "switches from vendor A, firewalls from vendor C, and routers from vendor B" in the topology database, a sequence of devices arranged in access order is generated, and the device types ("switches, firewalls, routers") are labeled. The matching physical connections or logical access relationships between different devices are used as the end-to-end access path.

[0058] Based on this, the technical issues of analysis errors caused by non-standard query request conditions, ambiguous source and destination address network segment attribution, and inaccurate paths caused by considering only physical connections and ignoring logical access in topology paths are addressed. Thus, by accurately locating and verifying the starting and ending devices through source and destination address network segment attribution matching, and combining this with the generation of a full-link path based on both physical and logical relationships, the consistency between the sequence of devices traversed and the actual network access path is ensured. The device scope for full-link rule verification is precisely defined, improving the accuracy and effectiveness of the overall verification process.

[0059] Figure 4 The illustration shows a schematic diagram of the operation of obtaining standard configuration information in the network connectivity verification method according to an embodiment of this application.

[0060] exist Figure 4 In the illustrated embodiment, based on the sequence of passing devices, standard configuration information in a general format for the corresponding devices is retrieved from the database server. This includes: retrieving configuration information in a general format for the corresponding network devices from the database server using the unique identifier of the device in the sequence of passing devices as the search criteria, as a configuration dataset to be analyzed; filtering configuration information related to the connectivity of the source address and destination address from the configuration dataset to be analyzed, obtaining relevant configuration information; performing deduplication processing on the relevant configuration analysis to obtain valid configuration information; and integrating the valid configuration information according to device type to form standard configuration information corresponding to the source address and destination address of each network device.

[0061] As an example, standard configuration information in a general format is retrieved from the database server. Using the unique identifier of the device in the sequence of traversed devices as the search condition, standard configuration information in a general format for the corresponding device is retrieved from the database server, forming a configuration dataset to be analyzed. Based on the source address_mask and destination address_mask in the query request, configuration information related to the connectivity of the source and destination addresses is filtered from the configuration dataset to be analyzed, and irrelevant device configuration items are excluded to obtain relevant configuration information. The filtered relevant configuration information is deduplicated, and duplicate rule entries are removed to obtain valid configuration information. The deduplicated valid configuration information is then integrated according to device type to form the source address and destination address standard configuration datasets for each device.

[0062] In a specific example, using the device addresses of switches from vendor A, firewalls from vendor B, and routers from vendor C as search criteria, standard configuration information in a common format for these three devices is retrieved from the database server, forming a configuration dataset to be analyzed. Based on the source address (192.168.XX) and destination address (21.8.XX), the dataset is filtered to extract the address resolution protocol table and VLAN configuration of the switches from vendor A, the security policies of the firewalls from vendor B, and the routing entries and address resolution protocol table of the routers from vendor C. Other VLAN configurations from vendor A and other external network routing configurations from vendor C are excluded. The filtered information is then deduplicated, removing duplicate address resolution protocol entries, and integrated according to the "switch, firewall, router" type to form the standard configuration information for the source and destination addresses of the three devices.

[0063] Based on this, the technical problems of low efficiency caused by the lack of clear identifiers in configuration information retrieval, interference from irrelevant configuration information with subsequent verification, and errors in verification results due to duplicate entries in configuration information are addressed. Thus, precise retrieval based on the unique device identifier improves the efficiency of configuration information acquisition; source and destination address association filtering eliminates irrelevant data, reducing the data processing volume for subsequent verification; and verification errors caused by irrelevant or duplicate configurations are avoided. The deduplicated and integrated dedicated configuration dataset improves the accuracy and relevance of rule verification.

[0064] In this embodiment, the standard configuration information is progressively verified in sequence to generate a verification report containing matching results and fault details. This includes: parsing and classifying the standard configuration information according to device type, and progressively verifying address resolution information, routing entries, and access control rules in sequence according to network access logic to generate a verification report containing matching results and fault details.

[0065] As an example, the system categorizes and resolves data by device type. Based on the source and destination address-specific configuration datasets, and according to the device type markers in the sequence of devices along the path, it matches the corresponding system resolution template for each device's specific configuration dataset. Routers are matched with Layer 3 network device templates, switches with Layer 2 network device templates, and firewalls with security device templates. The matched resolution templates are then applied to perform refined parsing of each device's specific configuration dataset. Following network access logic, address resolution information verification, routing entry verification, and access control rule verification are performed sequentially. After verification, a verification report is generated, containing the matching results of each step, as well as details of the faulty device, fault item, and fault cause.

[0066] In a specific example, the source address is 172.16.XX and the destination address is 192.168.XX. Based on the source and destination addresses, the system determines the devices along the path as follows: a load balancer from vendor A (172.16.XX), a core routing device from vendor B (10.0.XX), and an access switch from vendor C (192.168.XX). The system then retrieves the standardized configuration information of these three devices from the database server. After retrieving the standardized configuration information and categorizing it by device type, the system extracts the core configuration content of each device and sequentially verifies the address resolution information, routing entries, and access control rules. It checks the validity of each step and finally generates a verification report containing matching results and fault details.

[0067] Based on this, the technical problems of unclear fault location caused by the lack of a fixed logical order in network connectivity verification, chaotic verification levels, and the lack of a unified standard for access control rule judgment are addressed. A progressive verification logic based on address resolution information, routing entries, and access control rules is adopted, closely aligning with the actual transmission flow of network data. Each level of verification is based on the premise that the previous level has passed, accurately locating the level and specific device where the fault occurred. Verification efficiency is improved based on a unified access control rule judgment standard.

[0068] In this embodiment, generating a verification report that includes matching results and fault details includes: classifying the matching results of each device at each level into two categories: matching or non-matching; if the matching result of a single device at a single level indicates a non-match, then terminating the verification of network devices of the same model as the single device at that single level, and marking that single level as a fault level; performing detailed tracing of network devices whose matching results indicate a non-match, recording the fault device name, fault level, specific fault configuration item, and fault cause as fault details; if the specific fault configuration item is an access control rule fault, then recording the current access control rule as the fault cause; and integrating the matching results and fault details of all network devices according to a preset three-layer hierarchical structure to generate a verification report.

[0069] As an example, the verification results are initially categorized into two types: matching and non-matching, based on the verification results of each level and each device. If a verification at a certain level fails, subsequent verifications of the same device are terminated, and the fault level is marked. Detailed tracing is performed on the non-matching results, recording the faulty device name, fault level, specific fault configuration item, and fault cause. If the fault is related to access control rules, the specific content of the existing rules must also be recorded as the fault cause. Finally, according to the preset three-tiered hierarchical structure, the matching results and fault details of all devices are integrated to generate a verification report.

[0070] In a specific example, the results of matching address resolution information / routing entries / access control rules for vendor A's switch, matching address resolution protocol / routing entries but not access control rules for vendor B's firewall, and incomplete verification of vendor C's router are categorized as either matching or not matching. The fault level of vendor B's firewall is marked as the access control rule layer. For vendor B firewalls where the matching results indicate a mismatch, detailed tracing is performed. The faulty device is vendor B's firewall, the faulty configuration item is access control rules, and the fault is a rule allowing traffic from source address 192.168.XX to destination address 21.8.XX. The currently configured access control rules for this firewall are also recorded as detailed fault information. The system integrates the matching results of all devices with the above fault details according to the three-layer hierarchical structure of address resolution information, routing entries, and access control rules, and generates a unified verification report.

[0071] Based on this, the technical problems of ambiguous classification of verification results and lack of a unified structure in verification reports, which prevent maintenance personnel from quickly understanding fault conditions, are addressed. By classifying and marking fault levels in the equipment matching results, the distinguishability and readability of the verification results are improved. By tracing the source of information such as fault configuration items and fault causes, the accuracy and completeness of fault location are enhanced.

[0072] In this embodiment, the network connectivity status from the source address to the target address is determined based on the verification report to generate a connectivity report. This includes: if the matching results of each layer and each device in the end-to-end access path are all matched, the network connectivity status indicates normal connectivity; if any mismatch exists, the network connectivity status indicates connectivity failure, and the network device whose matching result indicates a mismatch is identified as the fault point; combined with the device manufacturer's general configuration commands, an executable repair suggestion is generated for the fault point, including the name of the device to be modified, the configuration command, the location of the configuration modification, and operation precautions; the end-to-end access path, network connectivity status, verification report, and repair suggestion are integrated to obtain the connectivity report.

[0073] As an example, network connectivity status is intelligently determined based on the verification report. If the verification results at all levels and on all devices across the entire link are matched, the network connectivity is considered normal. If any mismatch exists, the network connectivity is considered to have failed, and fault point information is associated. For the fault points in the verification report, combined with the device manufacturer's common configuration commands, directly executable repair suggestions are generated, including the name of the device to be modified, the configuration command, the location of the configuration modification, and operational precautions. The entire link access path, network connectivity status, verification report, and repair suggestions are integrated to form an integrated verification result dataset containing analysis, results, and repair, resulting in a connectivity report.

[0074] In a specific example, based on a mismatch in the verification report for Vendor B's firewall, the connectivity status is determined to be failed, and the fault point information of this device is associated. Combining Vendor B's common configuration commands, a repair suggestion is generated: the device to be modified is Vendor B's firewall, the configuration command is XXX, the configuration modification location is XXX, and the important note is to execute the save command after configuration to avoid configuration loss upon device restart. Integrating the end-to-end access path, connectivity failure status, verification report, and this repair suggestion, a connectivity report is obtained.

[0075] Based on this, the technical problems of lacking clear criteria for connectivity judgment and difficulties in integrating information from different stages of verification results are effectively solved. Connectivity judgment is conducted based on standardized verification reports, and directly executable repair commands are generated to improve the efficiency of fault location and repair.

[0076] Based on the above-described network connectivity verification method, embodiments of this application also provide a network connectivity verification device. The following will be combined with... Figure 5 The device is described in detail.

[0077] Figure 5 A schematic block diagram of a network connectivity verification device according to an embodiment of this application is shown.

[0078] like Figure 5 As shown, the network connectivity verification device 500 of this embodiment includes a list determination module 510, an information collection module 520, an information acquisition module 530, and a progressive verification module 540.

[0079] The list determination module 510 is used to configure personalized collection parameters and cycles for cross-vendor network devices based on the basic collection information of cross-vendor network devices pre-entered by the maintenance terminal, thereby obtaining a list of device collection tasks. In one embodiment, the list determination module 510 can be used to execute step S210 described above, which will not be repeated here.

[0080] The information acquisition module 520 is used to collect configuration information from cross-vendor network devices based on the collection task list, obtain raw private configuration information, and convert the raw private configuration information into a general format that is independent of the vendor's instruction set according to device type templates, and store it in the database server. In one embodiment, the information acquisition module 520 can be used to execute the step S220 described above, which will not be repeated here.

[0081] The information acquisition module 530 is used to respond to a connectivity query request containing a source address and a destination address, match the corresponding end-to-end access path in the topology database based on the source address and destination address, generate a sequence of passing devices arranged in the access order of the end-to-end access path, and retrieve standard configuration information of the corresponding devices in a general format from the database server based on the sequence of passing devices. In one embodiment, the information acquisition module 530 can be used to execute step S230 described above, which will not be repeated here.

[0082] The progressive verification module 540 is used to sequentially perform progressive verification on the standard configuration information, generate a verification report containing matching results and fault details, and determine the network connectivity status from the source address to the target address based on the verification report to generate a connectivity report. In one embodiment, the progressive verification module 540 can be used to execute step S240 described above, which will not be repeated here.

[0083] According to an embodiment of this application, the list determination module 510 configures personalized collection parameters and cycles for cross-vendor network devices based on the basic collection information of cross-vendor network devices pre-entered in the maintenance terminal, and obtains a device collection task list, including: parsing the basic collection information to obtain the access address, information collection username, and login password of the cross-vendor network devices filled in on the maintenance terminal, where the cross-vendor network devices include at least one of routers, switches, firewalls, and load balancers; performing a first classification operation on the cross-vendor network devices according to their actual attributes to obtain a functional device group; performing a second classification operation on the functional device group according to the manufacturer and model to obtain a personalized device group; and performing personalized collection configuration on the personalized device group based on a preset default collection template or a custom device configuration collection command to obtain a device collection task list, wherein the configured device information in the device collection task list includes at least one of device information, collection parameters, and collection cycle.

[0084] According to an embodiment of this application, the information acquisition module 520 acquires configuration information of cross-vendor network devices based on the acquisition task list to obtain original private configuration information, including: starting a timed acquisition engine through a preset information acquisition server according to a preset acquisition cycle, so that the timed acquisition engine remotely logs into the cross-vendor network devices according to the login information or acquisition command in the acquisition task list, so as to capture the original private configuration information of the cross-vendor network devices.

[0085] According to an embodiment of this application, the information acquisition module 530 matches the corresponding full-link access path in the topology database based on the source address and the destination address, including: retrieving the network device segment affiliation corresponding to the source address and the destination address in the topology database; determining the starting and ending devices for connectivity verification based on the network device segment affiliation; using the physical connection relationship or logical access relationship of the devices matching the starting device to the ending device in the topology database as the full-link access path; and retrieving standard configuration information in a general format for the corresponding devices from the database server based on the sequence of devices traversed, including: retrieving the configuration information in a general format for the corresponding network devices from the database server using the unique identifier of the devices in the sequence of devices traversed as the search condition, as the configuration dataset to be analyzed; filtering out configuration information related to the connectivity of the source address and the destination address from the configuration dataset to be analyzed, and obtaining relevant configuration information; performing deduplication processing on the relevant configuration information to obtain valid configuration information; and integrating the valid configuration information according to the device type to form standard configuration information corresponding to the source address and the destination address of each network device.

[0086] According to an embodiment of this application, the progressive verification module 540 sequentially performs progressive verification on the standard configuration information to generate a verification report containing matching results and fault details. This includes: parsing and classifying the standard configuration information according to device type, and sequentially performing progressive verification on address resolution information, routing entries, and access control rules according to network access logic to generate a verification report containing matching results and fault details; generating a verification report containing matching results and fault details includes: dividing the matching results of each device at each level into two categories: matching or non-matching; if the matching result of a single device at a single level indicates a non-match, then terminating the verification of network devices of the same model as the single device at that single level, and marking that single level as a fault level; performing detailed tracing of network devices indicating a non-match, recording the fault device name, fault level, specific fault configuration items, and fault cause as fault details, and if the specific fault... If the fault configuration item is an access control rule failure, the current access control rule is recorded as the cause of the failure. All network device matching results and fault details are integrated according to a preset three-layer hierarchical structure to generate a verification report. The verification report determines the network connectivity status from the source address to the target address, generating a connectivity report. This report includes: if all matching results at each level and on each device in the entire access path are matched, the network connectivity status indicates normal connectivity; if any mismatch exists, the network connectivity status indicates connectivity failure, and the network device with the mismatch is identified as the fault point. Combined with the device manufacturer's general configuration commands, executable repair suggestions are generated for the fault point. These suggestions include the name of the device to be modified, the configuration command, the location of the configuration modification, and operational precautions. The entire access path, network connectivity status, verification report, and repair suggestions are integrated to obtain a connectivity report.

[0087] According to embodiments of this application, any multiple modules among the list determination module 510, information acquisition module 520, information acquisition module 530, and progressive verification module 540 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the list determination module 510, information acquisition module 520, information acquisition module 530, and progressive verification module 540 can be at least partially implemented as hardware circuits, such as field-programmable gate arrays, programmable logic arrays, systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits, or other reasonable means of integrating or packaging circuits, or implemented in hardware or firmware, or in any one of software, hardware, and firmware implementations, or in a suitable combination of any of these. Alternatively, at least one of the list determination module 510, information collection module 520, information acquisition module 530, and progressive verification module 540 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0088] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a network connectivity verification method according to an embodiment of this application.

[0089] like Figure 6 As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory 602 or a program loaded from a storage portion 608 into a random access memory 603. The processor 601 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0090] Random access memory 603 stores various programs and data required for the operation of electronic device 600. Processor 601, read-only memory 602, and random access memory 603 are interconnected via bus 604. Processor 601 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 602 and / or random access memory 603. It should be noted that the programs may also be stored in one or more memories other than read-only memory 602 and random access memory 603. Processor 601 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0091] According to embodiments of this application, the electronic device 600 may further include an input / output interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card, such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0092] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0093] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 602 described above, and / or random access memory 603, and / or one or more memories other than read-only memory 602 and random access memory 603.

[0094] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0095] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0096] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by processor 601, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0097] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0099] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A network connectivity verification method, characterized in that, The method includes: Based on the basic data collection information of cross-vendor network devices pre-entered by the maintenance terminal, personalized data collection parameters and cycles are configured for the cross-vendor network devices to obtain a list of device data collection tasks. Based on the collection task list, configuration information is collected from the cross-vendor network devices to obtain raw private configuration information. The raw private configuration information is then categorized by device type template and converted into a general format that is independent of the vendor instruction set, and stored in the database server. In response to a connectivity query request containing a source address and a destination address, the system matches the corresponding end-to-end access path in the topology database based on the source address and the destination address to generate a sequence of passing devices arranged in the access order of the end-to-end access path. Based on the sequence of passing devices, the system retrieves the standard configuration information of the corresponding devices in a general format from the database server. The standard configuration information is sequentially verified to generate a verification report containing matching results and fault details. Based on the verification report, the network connectivity status from the source address to the target address is determined to generate a connectivity report.

2. The method according to claim 1, characterized in that, The process involves configuring personalized collection parameters and cycles for the cross-vendor network devices based on the basic collection information pre-entered by the maintenance terminal, resulting in a device collection task list, including: The basic collected information is parsed to obtain the access address, information collection username, and login password of the cross-vendor network device filled in on the maintenance terminal. The cross-vendor network device includes at least one of a router, switch, firewall, and load balancer. Based on the actual attributes of the devices, the cross-vendor network devices are first classified to obtain a functional device group; The functional device group is further classified according to manufacturer and model to obtain a personalized device group. Based on a preset default acquisition template or a custom device configuration acquisition command, the personalized device group is configured for personalized acquisition to obtain a device acquisition task list. The configuration device information in the device acquisition task list includes at least one of the following: device information, acquisition parameters, and acquisition cycle.

3. The method according to claim 1, characterized in that, The process of collecting configuration information from the cross-vendor network devices based on the collection task list to obtain original private configuration information includes: The preset information collection server starts the timed collection engine according to the preset collection cycle. The timed collection engine remotely logs into the cross-vendor network device according to the login information or collection command in the collection task list, so as to capture the original private configuration information of the cross-vendor network device.

4. The method according to claim 1, characterized in that, The step of matching the corresponding end-to-end access path in the topology library based on the source address and destination address includes: Retrieve the network device segment belonging to the source address and destination address in the topology database; The starting and ending devices for connectivity verification are determined based on the network segment affiliation of the network devices. The physical connection relationship or logical access relationship of the devices in the topology library that match the starting device to the ending device is used as the full-link access path.

5. The method according to claim 4, characterized in that, The step of retrieving standard configuration information in a common format from the database server based on the sequence of devices passing through includes: Using the unique identifier of the device in the sequence of passing devices as the search criteria, the configuration information of the corresponding network device in a general format is retrieved from the database server as the configuration dataset to be analyzed. The configuration information related to the connectivity of the source address and the destination address is filtered out from the configuration dataset to be analyzed to obtain the relevant configuration information; The relevant configuration analysis is deduplicated to obtain valid configuration information; The valid configuration information is integrated according to the device type to form standard configuration information corresponding to the source address and destination address of each network device.

6. The method according to claim 5, characterized in that, The standard configuration information is sequentially verified to generate a verification report containing matching results and fault details, including: The standard configuration information is parsed and categorized according to device type, and progressive verification of address resolution information, routing entries, and access control rules is performed in sequence according to network access logic to generate a verification report including matching results and fault details.

7. The method according to claim 6, characterized in that, The generated verification report includes matching results and fault details, including: The matching results of each device at each level are divided into two categories: matching or non-matching. If the matching result of a single device at a single level indicates a non-match, the verification of network devices of the same model as the single device in the single level is terminated, and the single level is marked as a fault level. For network devices whose matching results indicate a mismatch, perform detailed tracing and record the faulty device name, fault level, specific fault configuration item, and fault cause as fault details. If the specific fault configuration item is an access control rule fault, then record the current access control rule as the fault cause. The system integrates the matching results and fault details of all network devices according to a pre-defined three-tiered hierarchical structure to generate a verification report.

8. The method according to claim 1, characterized in that, The step of determining the network connectivity status from the source address to the target address based on the verification report, and generating a connectivity report, includes: If the matching results of each level and each device in the full-link access path are all matched, the network connectivity status indicates normal connectivity. If there is any mismatch, the network connectivity status indicates connectivity failure, and the network device whose matching result indicates a mismatch is taken as the fault point. Based on the equipment manufacturer's general configuration commands, an executable repair suggestion is generated for the fault point. The repair suggestion includes the name of the device to be modified, the configuration command, the location of the configuration modification, and operation precautions. The connectivity report is obtained by integrating the full-link access path, the network connectivity status, the verification report, and the repair suggestions.

9. A network connectivity verification device, characterized in that, The device includes: The list determination module is used to configure personalized collection parameters and cycles for the cross-vendor network devices based on the basic collection information of cross-vendor network devices pre-entered by the maintenance terminal, and obtain a list of device collection tasks. The information collection module is used to collect configuration information of the cross-vendor network devices based on the collection task list, obtain the original private configuration information, and convert the original private configuration information into a general format that is independent of the vendor instruction set according to the device type template, and store it in the database server. The information acquisition module is used to respond to a connectivity query request containing a source address and a destination address, match the corresponding full-link access path in the topology database based on the source address and the destination address, generate a sequence of passing devices arranged in the access order of the full-link access path, and retrieve the standard configuration information of the corresponding device in a general format from the database server based on the sequence of passing devices. The progressive verification module is used to perform progressive verification on the standard configuration information in sequence, generate a verification report containing matching results and fault details, determine the network connectivity status from the source address to the target address based on the verification report, and generate a connectivity report.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images