Method, device and equipment for constructing topological graph of cloud equipment and storage medium

Abstract

The invention discloses a method, device and equipment for constructing a topological graph of upper cloud equipment and a storage medium, and relates to the technical field of networks, and the method comprises the steps: obtaining a first neighbor information set of an uplink port of the upper cloud equipment and a second neighbor information set of a downlink port of the upper cloud equipment; according to a home terminal device interface ID, an upstream device MAC address and an upstream device interface ID carried by the LLDP type information in the first neighbor information set, if the upstream device MAC address belongs to an upper cloud device MAC address, determining an uplink port direct connection relationship and generating first connection information to form first connection relationship information; according to field matching of the LLDP and IGMP type information in the second neighbor information set, judging a downlink port direct connection or non-direct connection relationship, correspondingly generating second connection information, and forming second connection relationship information; and finally, integrating the two types of information, and distinguishing direct connection equipment and non-direct connection equipment by using different visual identifiers to generate a topological graph. According to the method, the equipment connection state can be accurately presented, and powerful support is provided for network management and fault location.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a method, apparatus, device, and storage medium for constructing a topology map of cloud devices. Background Technology

[0002] With the accelerated pace of digital transformation, enterprise networks are expanding rapidly, and the number and types of network devices (including gateways, switches, and wireless controllers) are increasing significantly. Traditional local management models are no longer sufficient to meet the demands of efficient operation and maintenance. Therefore, centralized management of all network devices within an enterprise network via public cloud servers has become a mainstream trend. In this model, the network architecture typically adopts a design that separates service VLANs from management VLANs. All devices are uniformly connected to a preset management VLAN. After successfully migrating to the cloud, devices proactively report basic information such as their MAC address, IP address, operating status, and configuration parameters to the public cloud server. The public cloud server can view the status of online devices in real time, issue configuration commands, and achieve remote control of the enterprise network. The generation of interconnection topology between network devices is a core element in ensuring management efficiency, directly affecting the accuracy of operation and maintenance personnel's understanding of the network structure and fault location.

[0003] However, existing methods cannot accurately generate a complete topology map between cloud devices. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for constructing a topology map of cloud-connected devices, which can generate a complete topology map when there are non-cloud-connected devices among the cloud-connected devices.

[0005] To achieve the above objectives, this application adopts the following technical solution: Firstly, this application provides a method for constructing a cloud device topology diagram, including: Obtain the first neighbor information set generated by the uplink port of the cloud device and the second neighbor information set generated by the downlink port of the cloud device; Based on the first neighbor information set, determine the first connection relationship information of the cloud device uplink port. The first connection relationship information includes: first connection relationship and first connection information. Based on the second neighbor information set, the second connection relationship information of the downlink port of the cloud device is determined. The second connection relationship information includes: the second connection relationship and the second connection information. Based on the first connection relationship information and the second connection relationship information, a topology diagram between cloud devices is generated.

[0006] Optionally, determining the first connection relationship information of the uplink port of the cloud device based on the first neighbor information set includes: Based on the first device interface ID carried in the first type of information in the first neighbor information set, the second device MAC address carried in the first type of information in the first neighbor information set, and the second device interface ID carried in the first type of information in the first neighbor information set, the first connection relationship information of the uplink port of the cloud device is determined.

[0007] Optionally, determining the second connection relationship information of the downlink port of the cloud device based on the second neighbor information set includes: Obtain the first type of information from the second neighbor information set and obtain the second type of information from the second neighbor information set; Based on the first device interface ID, the second device MAC address, the first device interface ID, the second device MAC address, and the second device interface ID carried in the second type of information in the second neighbor information set, the second connection relationship information of the downlink port of the cloud device is determined.

[0008] Optionally, determining the first connection relationship information of the cloud device's uplink port based on the first device interface ID carried by the first type of information in the first neighbor information set, the second device MAC address carried by the first type of information in the first neighbor information set, and the second device interface ID carried by the first type of information in the first neighbor information set includes: When the MAC address of the second device carried by the first type of information in the first neighbor information set belongs to the MAC address of the cloud device, the first connection relationship of the cloud device's uplink port is determined to be a direct connection. The first connection information is determined based on the first device interface ID carried in the first type of information in the first neighbor information set, the second device MAC address carried in the first type of information in the first neighbor information set, and the second device interface ID carried in the first type of information in the first neighbor information set.

[0009] Optionally, determining the second connection relationship information of the downlink port of the cloud device based on the first device interface ID carried by the second type of information in the second neighbor information set, the second device MAC address carried by the second type of information in the second neighbor information set, the first device interface ID carried by the first type of information in the second neighbor information set, the second device MAC address carried by the first type of information in the second neighbor information set, and the second device interface ID carried by the first type of information in the second neighbor information set includes: When the MAC address of the second device carried by the second type of information in the second neighbor information set belongs to the MAC address of the cloud device, and there is information that the first device interface ID carried by the first type of information in the second neighbor information set is the same as the first device interface ID carried by the second type of information in the second neighbor information set, and the MAC address of the second device carried by the first type of information in the second neighbor information set is the same as the MAC address of the second device carried by the second type of information in the second neighbor information set, the second connection relationship of the downlink port of the cloud device is determined to be a direct connection; The second connection information is determined based on the first device interface ID carried in the first type of information in the second neighbor information set, the second device MAC address carried in the first type of information in the second neighbor information set, and the second device interface ID carried in the first type of information in the second neighbor information set. If there is no information where the first device interface ID carried by the first type of information in the second neighbor information set is the same as the first device interface ID carried by the second type of information in the second neighbor information set, and the second device MAC address carried by the first type of information in the second neighbor information set is the same as the second device MAC address carried by the second type of information in the second neighbor information set, then the second connection relationship of the downlink port of the cloud device is determined to be non-direct connection. The second connection information is determined based on the first device interface ID carried in the second type of information in the second neighbor information set, the second device MAC address carried in the second type of information in the second neighbor information set, and the second device uplink port ID corresponding to the second device MAC address carried in the second type of information in the second neighbor information set.

[0010] Optionally, the first type of information is the Link Layer Discovery Protocol Identifier (LLDP), and the second type of information is the Internet Group Management Protocol Identifier (IGMP).

[0011] Optionally, the topology diagram is displayed in the following ways: Cloud devices that are directly connected are marked with a first visual identifier, while cloud devices that are not directly connected are marked with a second visual identifier.

[0012] Secondly, this application provides an apparatus for constructing a cloud device topology map, comprising: The acquisition module is used to acquire the first neighbor information set generated by the uplink port of the cloud device and the second neighbor information set generated by the downlink port of the cloud device. The determination module is used to determine, based on the first neighbor information set, the first connection relationship information including: a first connection relationship and first connection information; and to determine, based on the second neighbor information set, the second connection relationship information including: a second connection relationship and second connection information. The generation module is used to generate a topology diagram between cloud devices based on the first connection relationship information and the second connection relationship information.

[0013] Thirdly, this application provides a computing device, including a memory and a processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of the first aspects.

[0014] Fourthly, this application provides a computer-readable storage medium for storing a computer program for performing the method as described in any one of the first aspects.

[0015] As can be seen from the above technical solution, this application has at least the following beneficial effects: First, by acquiring the neighbor information sets generated by the uplink and downlink ports of the cloud devices respectively, a comprehensive capture of the bidirectional connection relationship of the cloud devices is achieved, avoiding the topology omission problem that may be caused by collecting information in one direction, and laying a data foundation for the construction of a complete topology.

[0016] Secondly, differentiated connection relationship determination logic is adopted for uplink and downlink ports. The characteristics of LLDP and IGMP information are analyzed in combination. Uplink ports directly confirm direct connection relationship based on LLDP type information, while downlink ports distinguish between direct and non-direct connection relationship through matching and verification of LLDP and IGMP type information, thereby improving the accuracy of connection relationship determination.

[0017] Furthermore, by clearly displaying the directly connected and non-directly connected cloud devices through primary and secondary visual identifiers, the generated topology diagram is intuitive and clear, making it easier for operations and maintenance personnel to quickly understand the network architecture between devices, significantly reducing the complexity of network management and improving the efficiency of troubleshooting.

[0018] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0019] Figure 1 A schematic diagram illustrating an application scenario provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for constructing a cloud device topology diagram, provided in an embodiment of this application; Figure 3 A schematic diagram of an apparatus for constructing a cloud device topology map provided in an embodiment of this application; Figure 4 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0020] The terms “first” and “second” in this application are used to distinguish different objects, not to specify a particular order.

[0021] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0022] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the related technologies is given first: Cloud-connected devices refer to network devices that have successfully connected to a cloud server, can proactively report their own basic information, status information, and neighbor information to the cloud server, and can receive configuration instructions from the cloud server. These include gateways, switches, wireless controllers, etc.

[0023] Non-cloud devices refer to network devices that are not connected to cloud servers, cannot interact with cloud servers, and only have basic physical forwarding functions, such as old switches. Their existence is a key factor in the defects of traditional topology generation solutions.

[0024] Currently, the mainstream technical solutions for generating network device interconnection topologies using cloud servers mainly rely on two types of protocols: one is a neighbor information collection scheme based on the Link Layer Discovery Protocol Identifier (LLDP) (IEEE 802.1ab standard), and the other is a neighbor information reporting scheme based on proprietary protocols. The LLDP protocol scheme collects neighbor information such as the local device interface ID, the peer device MAC address, and the peer device interface ID through direct interaction of LLDP messages between devices. The devices then report this information to the cloud server, which determines the device interconnection status based on the information matching relationships. The proprietary protocol scheme, on the other hand, uses a communication protocol defined by the device manufacturer to collect and report neighbor information, and the cloud server also generates a topology map based on the reported data.

[0025] However, the aforementioned existing technologies have significant drawbacks in practical applications: On the one hand, if the LLDP protocol is adopted, since LLDP messages can only be transmitted between directly connected devices, when there are non-cloud-connected devices between two cloud-connected devices, such as old switches not connected to the public cloud, the LLDP messages will be blocked by the non-cloud-connected devices, causing the cloud server to be unable to obtain the neighbor association information of the two cloud-connected devices, and thus unable to generate a correct topology map; on the other hand, if a private protocol is adopted, although some private protocol messages can be physically forwarded through non-cloud-connected devices, allowing the cloud server to perceive the existence of non-directly connected cloud-connected devices, this solution cannot distinguish the connection type between devices, that is, it cannot determine whether two cloud-connected devices are directly connected or not, resulting in the generated topology map only showing the existence of connections between devices, and failing to reflect the real network hierarchy and physical link relationships, causing great trouble for subsequent network operation and maintenance and fault diagnosis.

[0026] In view of this, embodiments of this application provide a method for constructing a topology map of cloud-connected devices, which is executed by a cloud server. This application integrates the characteristics of the Link Layer Discovery Protocol Identifier (LLDP) and the Internet Group Management Protocol Identifier (IGMP) to construct a cloud-connected device topology generation scheme that uses dual-protocol collaborative judgment and visual annotation. This solves the problems in existing technologies where the topology is incomplete and connection types cannot be distinguished when there are non-cloud-connected devices among the cloud-connected devices.

[0027] To make the technical solution of this application clearer and easier to understand, the application scenarios of the technical solution of this application are described below with reference to the accompanying drawings. Figure 1 As shown in the figure, this figure is a schematic diagram of an application scenario provided by an embodiment of this application.

[0028] In this application scenario, the functions and cloud capabilities of various network devices are as follows: Gateways, as the core exit point between the enterprise network and the Internet, have cloud capabilities and can achieve bidirectional information and command interaction with cloud servers; Aggregation switches are responsible for aggregating access layer traffic and forwarding it upwards to the gateway. Some of these switches support cloud access and can interact with cloud servers to exchange neighbor information, while some older devices do not support cloud access and only have physical forwarding capabilities; Access switches provide network access services for various devices such as office computers and IoT terminals. Similar to aggregation switches, they are also divided into those that support cloud access and those that do not; Wireless controllers are cloud-enabled devices, mainly used to manage the wireless access points (APs) within the enterprise and can report their own and associated APs' operating status information to the cloud server.

[0029] In practical network operations and maintenance, enterprises need cloud servers to generate topology maps that cover all cloud-connected devices and clearly show whether the devices are directly or indirectly connected, as well as the locations of non-cloud-connected devices. This is to support network troubleshooting and device configuration distribution. However, traditional topology generation solutions cannot meet this requirement. If a traditional solution relying on the LLDP protocol is used, when there is a non-cloud-connected aggregation switch between the gateway and the cloud-connected aggregation switch (i.e., the network link is gateway, non-cloud-connected aggregation switch, cloud-connected aggregation switch), due to the inherent limitations of the LLDP protocol, its packets can only interact between directly connected devices and cannot penetrate non-cloud-connected devices for forwarding. In this case, although the gateway can detect the directly connected non-cloud-connected aggregation switch through the LLDP protocol, the non-cloud-connected aggregation switch cannot parse or forward LLDP packets, resulting in the inability to transmit neighbor information of the cloud-connected aggregation switch to the gateway, let alone report it to the public cloud server. Ultimately, the connection between the gateway and the cloud-connected aggregation switch will be directly broken in the topology map generated by the cloud server.

[0030] If a traditional solution based on a proprietary protocol is used, when there is a non-cloud-connected access switch between the upper-layer cloud aggregation switch and the lower-layer cloud access switch (i.e., a network link consisting of a cloud aggregation switch, a non-cloud-connected access switch, and a cloud access switch), the proprietary protocol can allow the cloud server to perceive the connection between the cloud aggregation switch and the cloud access switch through the physical forwarding function of the non-cloud-connected device. However, this protocol lacks a connection type marking method and cannot reflect the presence of a non-cloud-connected device in the reported neighbor information. This results in maintenance personnel only seeing the connection between the two in the topology diagram, but being unable to determine whether it is a direct connection without intermediate devices or an indirect connection through a non-cloud-connected access switch. Once data packet loss, latency, or other faults occur in this link, maintenance personnel cannot quickly locate the root cause of the fault. They cannot determine whether the forwarding anomaly is caused by a hardware failure of the non-cloud-connected access switch, nor can they rule out interface or configuration problems of the cloud-connected device itself, significantly prolonging the fault diagnosis cycle and affecting the normal operation of enterprise business.

[0031] The technical solution proposed in this application is intended to solve the problem of network topology generation in this type of layered architecture scenario.

[0032] To make the technical solution of this application clearer and easier to understand, the following application scenarios will describe a method for constructing a cloud device topology diagram provided by the embodiments of this application. For example... Figure 2 As shown, this figure is a flowchart of a method for constructing a cloud device topology map according to an embodiment of this application. The method includes: S201, The cloud server obtains the first neighbor information set generated by the uplink port of the cloud device and the second neighbor information set generated by the downlink port of the cloud device.

[0033] Uplink ports are used by cloud devices to connect to upstream devices, i.e., interfaces pointing to the network core layer, primarily enabling communication between the local device and the upper-layer network. Downlink ports are used by cloud devices to connect to downstream devices, i.e., interfaces pointing to the network access layer, primarily enabling communication between the local device and the lower-layer network. This functional division of interfaces allows the cloud server to analyze the upstream and downstream connections of devices according to the interface direction, effectively avoiding topology confusion caused by mixed information from a single interface.

[0034] Before the cloud server obtains the neighbor information set, the cloud-enabled device must first complete the standardized configuration to ensure that the subsequent information collection is compliant and effective. The core configuration process is as follows: Reporting Uplink Port ID: Cloud devices clearly identify their own unique uplink port and report this identifier to the cloud server. The cloud server can use this unique identifier to identify the interface type (uplink or downlink) to which the information subsequently reported by the device belongs.

[0035] Automatically enable LLDP functionality on all interfaces: Cloud devices automatically activate the LLDP protocol (IEEE 802.1ab) functionality on uplink and downlink ports, enabling them to have the basic ability to interact with directly connected devices to exchange neighbor information, providing protocol support for subsequent collection of direct connection relationship information.

[0036] Enable IGMP snooping in VLAN 1: Enable IGMP snooping in the default management VLAN (VLAN 1) on the cloud device. This allows the device to parse and record multicast message information, providing functional support for subsequent collection of non-directly connected information.

[0037] Special configuration for uplink ports of non-gateway cloud devices: For non-gateway cloud devices, two additional configurations are required: First, set its own uplink port as a multicast routing interface for VLAN 1 to ensure that IGMP messages can be transmitted normally to upstream devices; second, automatically issue access control list (ACL) rules for the uplink port to discard Internet Group Management Protocol (IGMP) Join messages sent by devices other than the local device to avoid external irrelevant messages interfering with the accuracy of information collection by the local device.

[0038] Non-gateway cloud devices periodically send IGMP Join messages: Non-gateway cloud devices will periodically send IGMP Join messages with a target multicast address of 239.1.1.1 from the uplink port. These messages will be forwarded by downstream devices (including non-cloud devices) and become the key trigger signal for subsequent collection of non-directly connected neighbor information.

[0039] After the basic configuration is completed, the cloud device uses LLDP and IGMP SNOOPING functions to collect differentiated information from the uplink and downlink ports respectively, generating corresponding neighbor information sets. The specific process is as follows: The uplink port generates the first neighbor information set: The uplink port of the local device and the downlink port of the upstream device periodically exchange LLDP messages because both have LLDP enabled. These messages contain key information such as the local device's interface ID, local device's MAC address, the peer device's MAC address, and the upstream device's interface ID. After parsing the LLDP messages received on the uplink port, the local device generates LLDP neighbor information entries in a fixed format. The entries are uniformly formatted as "[LLDP, local device interface ID, upstream device MAC address, upstream device interface ID]". Finally, the local device integrates all LLDP neighbor information entries generated on the uplink port to form a first neighbor information set containing only directly connected relationship information.

[0040] The downlink port generates a second neighbor information set: The local device's downlink port is used to connect to downstream devices. There are two connection scenarios: one is direct connection to the downstream device, and the other is connection to the downstream device via a device not connected to the cloud. Therefore, it is necessary to use the LLDP protocol in conjunction with the IGMP snooping function to achieve full coverage collection of both directly connected and non-directly connected neighbor information. If the downlink port of the local device is directly connected to the cloud device, the LLDP function of both interfaces is active. The format of the table entries generated after exchanging LLDP messages is the same as that of the uplink LLDP table entries, which is "[LLDP, local device interface ID, downstream device MAC address, downstream device interface ID]". This table entry is used to record the direct connection relationship between the local device and the downstream device.

[0041] If the local device's downlink port is directly connected to the cloud device, the downstream cloud device will send an IGMP Join message with a target multicast address of 239.1.1.1 to the local device's downlink port. If the local device's downlink port is not directly connected to the cloud device, the downstream cloud device's IGMP Join message with a target multicast address of 239.1.1.1 will be forwarded to the local device's downlink port via a non-cloud device. The local device parses the message using the IGMP SNOOPING function, generating an IGMP SNOOPING entry containing the multicast group address 239.1.1.1, the downstream device's interface ID, and the downstream device's MAC address. This entry is then converted into an IGMP neighbor information entry in a fixed format, with the entry content uniformly set to "[IGMP, local device interface ID, downstream device MAC address]". This entry is used to record the connection relationship between the local device and the downstream device.

[0042] Finally, the local device summarizes the LLDP and IGMP entries of the downlink port to form a second neighbor information set covering both direct and non-direct connection scenarios.

[0043] The cloud server uses the MQTT protocol for telemetry transmission via message queues to obtain the first neighbor information set and the second neighbor information set reported by the cloud devices, laying the data foundation for subsequent analysis of the connection relationship between devices and generation of network topology maps.

[0044] S202. The cloud server determines the first connection relationship information of the uplink port of the cloud device based on the first neighbor information set. The first connection relationship information includes: the first connection relationship and the first connection information.

[0045] Specifically, the first connection relationship information of the cloud device uplink port is determined based on the first device interface ID carried by the first type of information in the first neighbor information set, the second device MAC address carried by the first type of information in the first neighbor information set, and the second device interface ID carried by the first type of information in the first neighbor information set.

[0046] The first type of information is the Link Layer Discovery Protocol (LLDP) identifier.

[0047] The first device interface ID carried by the first type of information in the first neighbor information set refers to the unique identifier of the uplink port of the local device, which is used to locate the local interface to which the information belongs.

[0048] The second device MAC address carried in the first type of information in the first neighbor information set refers to the hardware address of the upstream device that is directly connected to the uplink port of this device, and is a unique identifier for identifying the upstream device.

[0049] The second device interface ID carried in the first type of information in the first neighbor information set refers to the interface identifier of the upstream device that is directly connected to the uplink port of this device, and is used to locate the specific connection interface of the upstream device.

[0050] The first connection relationship information includes the first connection relationship and the first connection information, which is a structured description of the uplink port connection status. The first connection relationship is a direct connection, and the first connection information is the device and interface details of the two connected parties.

[0051] When the MAC address of the second device carried by the first type of information in the first neighbor information set belongs to the MAC address of the cloud device, the first connection relationship of the cloud device uplink port is determined to be a direct connection; the first connection information is determined based on the first device interface ID carried by the first type of information in the first neighbor information set, the MAC address of the second device carried by the first type of information in the first neighbor information set, and the second device interface ID carried by the first type of information in the first neighbor information set.

[0052] When the cloud server analyzes the LLDP type information in the first neighbor information set, it first extracts the MAC address of the second device contained in the information, that is, the MAC address of the upstream device connected to the uplink port of the local device, and compares it with the cloud server's stored database of cloud device MAC addresses. If the MAC address belongs to a registered cloud device, it is directly determined that the first connection relationship between the local device's uplink port and the upstream device is a direct connection. Because the LLDP protocol can only exchange information between physically directly connected devices, the accuracy of the connection relationship is ensured.

[0053] Based on this, the cloud server further extracts the first device interface ID (local device interface ID), the second device MAC address (upstream device MAC address), and the second device interface ID (upstream device interface ID) from the LLDP type information. At the same time, it associates the MAC address that the local device has reported to the cloud server. Only after combining and integrating these four key fields—local device MAC address, local device interface ID, upstream device MAC address, and upstream device interface ID—can the complete first connection information be formed.

[0054] S203. The cloud server determines the second connection relationship information of the downlink port of the cloud device based on the second neighbor information set. The second connection relationship information includes: the second connection relationship and the second connection information.

[0055] Specifically, firstly, the cloud server obtains the first type of information from the second neighbor information set and then obtains the second type of information from the second neighbor information set.

[0056] The first type of information is the Link Layer Discovery Protocol (LLDP) identifier, and the second type of information is the Internet Group Management Protocol (IGMP) identifier.

[0057] Secondly, the cloud server determines the second connection relationship information of the downlink port of the cloud device based on the first device interface ID carried by the second type of information in the second neighbor information set, the second device MAC address carried by the second type of information in the second neighbor information set, the first device interface ID carried by the first type of information in the second neighbor information set, the second device MAC address carried by the first type of information in the second neighbor information set, and the second device interface ID carried by the first type of information in the second neighbor information set.

[0058] The second connection relationship information refers to the structured description of the connection status between the downlink port of the local device and the downstream device. It includes the second connection relationship (direct connection or non-direct connection) and the second connection information (key details such as the devices and interfaces of the connected parties). It serves as the basis for drawing downlink connections in the subsequent topology diagram.

[0059] When the MAC address of the second device carried by the second type of information in the second neighbor information set belongs to the MAC address of the cloud device, and there is information that the first device interface ID carried by the first type of information in the second neighbor information set is the same as the first device interface ID carried by the second type of information in the second neighbor information set, and the MAC address of the second device carried by the first type of information in the second neighbor information set is the same as the MAC address of the second device carried by the second type of information in the second neighbor information set, the second connection relationship of the downlink port of the cloud device is determined to be a direct connection.

[0060] When the MAC address of the downstream device recorded in the IGMP type information belongs to the cloud device in the second neighbor information set, and there is an LLDP type information, the local device interface ID and the downstream device MAC address recorded in the LLDP type information are consistent with the local device interface ID and the downstream device MAC address in the IGMP type information, it can be determined that the second connection relationship between the local device and the downstream device is a direct connection.

[0061] The second connection information is determined based on the first device interface ID carried in the first type of information in the second neighbor information set, the second device MAC address carried in the first type of information in the second neighbor information set, and the second device interface ID carried in the first type of information in the second neighbor information set.

[0062] The cloud server extracts the local device interface ID, downstream device MAC address, and downstream device interface ID from the LLDP type information in the second neighbor information set, and then associates them with the local device's own MAC address. After integrating these four types of information, a complete second connection information is formed.

[0063] If there is no information where the first device interface ID carried by the first type of information in the second neighbor information set is the same as the first device interface ID carried by the second type of information in the second neighbor information set, and the second device MAC address carried by the first type of information in the second neighbor information set is the same as the second device MAC address carried by the second type of information in the second neighbor information set, then the second connection relationship of the downlink port of the cloud device is determined to be non-direct connection.

[0064] When the downstream device of the IGMP type information record in the second neighbor information set is a cloud device, but no LLDP type information with the same local device interface ID and downstream device MAC address as the IGMP information can be found, the second connection relationship between the local device and the downstream device is determined to be non-direct connection.

[0065] The second connection information is determined based on the first device interface ID carried in the second type of information in the second neighbor information set, the second device MAC address carried in the second type of information in the second neighbor information set, and the second device uplink port ID corresponding to the second device MAC address carried in the second type of information in the second neighbor information set.

[0066] The cloud server extracts the local device interface ID and the downstream device MAC address from the IGMP type information of the second neighbor information set, and then associates them with the uplink port ID reported in advance by the downstream device. Since the downstream device is a cloud-connected device, its uplink port ID has been stored in the cloud server. After integrating these three types of information with the local device's own MAC address, the second connection information that records the details of the downlink port non-direct connection relationship is formed.

[0067] S204. The cloud server generates a topology diagram between cloud devices based on the first connection relationship information and the second connection relationship information.

[0068] The first connection relationship information records the direct connection details between each device's uplink port and the upstream device, while the second connection relationship information covers the direct / non-direct connection paths between the downlink port and the downstream device.

[0069] The cloud server indexes this information by device MAC address and automatically draws a hierarchical topology diagram of all cloud-connected devices by matching the association between different device interfaces and MAC addresses.

[0070] The topology diagram is displayed as follows: cloud devices that are directly connected are marked with a first visual identifier, and cloud devices that are not directly connected are marked with a second visual identifier.

[0071] The first visual identifier uses solid lines to mark directly connected cloud devices. For example, cloud device G and cloud device H are determined to be directly connected by LLDP. In the topology diagram, the corresponding interfaces of the two devices (G-2 and H-1) are connected by solid lines, which intuitively reflects the attribute of physical direct connection.

[0072] The second visual identifier uses dashed lines to mark cloud devices that are not directly connected. For example, cloud device A and cloud device E are determined to be not directly connected by IGMP. In the topology diagram, dashed lines connect interface A-1 of device A and interface E-1 of device E, clearly indicating the existence of an unconnected device in between.

[0073] Based on the above description, this application has the following beneficial effects: In this application, firstly, by acquiring the neighbor information sets generated by the uplink and downlink ports of the cloud device respectively, a comprehensive capture of the bidirectional connection relationship of the cloud device is achieved, avoiding the topology omission problem that may be caused by the collection of information in one direction, and laying a data foundation for the construction of a complete topology.

[0074] Secondly, differentiated connection relationship determination logic is adopted for uplink and downlink ports. The characteristics of two types of information, LLDP and IGMP, are analyzed. Uplink ports directly confirm direct connection relationships based on LLDP information, while downlink ports distinguish between direct and non-direct connection relationships through matching and verification of LLDP and IGMP information, thereby improving the accuracy of connection relationship determination.

[0075] Furthermore, by clearly displaying the directly connected and non-directly connected cloud devices through primary and secondary visual identifiers, the generated topology diagram is intuitive and clear, making it easy for operations and maintenance personnel to quickly understand the network architecture between devices, significantly reducing the complexity of network management and improving the efficiency of troubleshooting and network optimization.

[0076] The above text combined Figures 1 to 2 The method for constructing a cloud device topology diagram provided in the embodiments of this application has been described in detail. The apparatus and equipment provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0077] like Figure 3 As shown in the figure, this is a schematic diagram of an apparatus for constructing a cloud device topology map according to an embodiment of this application. The apparatus includes: The acquisition module 301 is used to acquire the first neighbor information set generated by the uplink port of the cloud device and the second neighbor information set generated by the downlink port of the cloud device; The determining module 302 is used to determine, based on the first neighbor information set, the first connection relationship information including: a first connection relationship and first connection information; and to determine, based on the second neighbor information set, the second connection relationship information including: a second connection relationship and second connection information. The generation module 303 is used to generate a topology diagram between cloud devices based on the first connection relationship information and the second connection relationship information.

[0078] Optionally, the determining module 302 is specifically used to determine the first connection relationship information of the uplink port of the cloud device based on the first device interface ID carried by the first type information in the first neighbor information set, the second device MAC address carried by the first type information in the first neighbor information set, and the second device interface ID carried by the first type information in the first neighbor information set.

[0079] Optionally, the acquisition module 301 is specifically used to acquire the first type of information in the second neighbor information set and to acquire the second type of information in the second neighbor information set; The determination module 302 is specifically used to determine the second connection relationship information of the downlink port of the cloud device based on the first device interface ID carried by the second type information in the second neighbor information set, the second device MAC address carried by the second type information in the second neighbor information set, the first device interface ID carried by the first type information in the second neighbor information set, the second device MAC address carried by the first type information in the second neighbor information set, and the second device interface ID carried by the first type information in the second neighbor information set.

[0080] Optionally, the determining module 302 is specifically used to determine that the first connection relationship of the uplink port of the cloud device is a direct connection when the MAC address of the second device carried by the first type information in the first neighbor information set belongs to the MAC address of the cloud device; and to determine the first connection information based on the first device interface ID carried by the first type information in the first neighbor information set, the MAC address of the second device carried by the first type information in the first neighbor information set, and the second device interface ID carried by the first type information in the first neighbor information set.

[0081] Optionally, the determining module 302 is specifically used to determine that the second connection relationship of the downlink port of the uplink device is a direct connection when the second device MAC address carried by the second type of information in the second neighbor information set belongs to the MAC address of the cloud device, and there is information that the first device interface ID carried by the first type of information in the second neighbor information set is the same as the first device interface ID carried by the second type of information in the second neighbor information set, and the second device MAC address carried by the first type of information in the second neighbor information set is the same as the second device MAC address carried by the second type of information in the second neighbor information set; based on the first device interface ID carried by the first type of information in the second neighbor information set, the second device MAC address carried by the first type of information in the second neighbor information set, and the first device interface ID carried by the first type of information in the second neighbor information set, the second device MAC address carried by the first type of information in the second neighbor information set, the second device interface ID carried by the first type of information in the second neighbor information set, and the second device MAC address carried by the first type of information in the second neighbor information set, the second device MAC address carried by the first type of information in the second neighbor information set, the second device interface ID ... The second device interface ID carried in the information is used to determine the second connection information; if there is no information where the first device interface ID carried in the first type of information in the second neighbor information set is the same as the first device interface ID carried in the second type of information in the second neighbor information set, and the second device MAC address carried in the first type of information in the second neighbor information set is the same as the second device MAC address carried in the second type of information in the second neighbor information set, the second connection relationship of the downlink port of the cloud device is determined to be non-direct connection; the second connection information is determined based on the first device interface ID carried in the second type of information in the second neighbor information set, the second device MAC address carried in the second type of information in the second neighbor information set, and the second device uplink port ID corresponding to the second device MAC address carried in the second type of information in the second neighbor information set.

[0082] Optionally, the generation module 303 is specifically used to mark cloud devices that are directly connected by a first visual identifier and to mark cloud devices that are not directly connected by a second visual identifier.

[0083] The apparatus for constructing a cloud device topology map according to the embodiments of this application can correspond to executing the method described in the embodiments of this application, and the other operations and / or functions of each module / unit of the apparatus for constructing a cloud device topology map are respectively for implementing Figure 2 For the sake of brevity, the corresponding processes of each method in the illustrated embodiments will not be described in detail here.

[0084] This application also provides a computing device. For example... Figure 4 As shown in the figure, this is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 700 includes a bus 701, a processor 702, a communication interface 703, and a memory 704. The processor 702, the memory 704, and the communication interface 703 communicate with each other via the bus 701.

[0085] The 701 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0086] The processor 702 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0087] The communication interface 703 is used for communication with external devices.

[0088] Memory 704 may include volatile memory, such as random access memory (RAM). Memory 704 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0089] The memory 704 stores executable code, and the processor 702 executes the executable code to perform the aforementioned method for constructing a cloud device topology map.

[0090] Specifically, in achieving Figure 3 In the case of the illustrated embodiment, and Figure 3 When the modules or units of the apparatus for constructing the cloud device topology described in the embodiment are implemented by software, the execution... Figure 3 The software or program code required for the functions of each module / unit can be partially or wholly stored in the memory 704. The processor 702 executes the program code corresponding to each unit stored in the memory 704, and executes the aforementioned method for constructing the cloud device topology map.

[0091] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center that includes one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform the above-described method for constructing a cloud device topology map.

[0092] This application also provides a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application are generated.

[0093] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0094] When the computer program product is executed by a computer, the computer performs any of the methods described above for constructing a cloud device topology map. The computer program product can be a software installation package; when any of the methods described above for constructing a cloud device topology map is required, the computer program product can be downloaded and executed on the computer.

[0095] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0096] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application.

Claims

1. A method for constructing a topology diagram of cloud-based devices, characterized in that, The method comprises: obtaining a first neighbor information set generated by an uplink port of a cloud device and obtaining a second neighbor information set generated by a downlink port of the cloud device; determining first connection relationship information of the uplink port of the cloud device according to the first neighbor information set, the first connection relationship information comprising: first connection relationship and first connection information; determining second connection relationship information of the downlink port of the cloud device according to the second neighbor information set, the second connection relationship information comprising: second connection relationship and second connection information; generating a topology graph between the cloud devices according to the first connection relationship information and the second connection relationship information.

2. The method of claim 1, wherein, The method comprises: determining the first connection relationship information of the uplink port of the cloud device according to the first device interface ID carried by the first type information in the first neighbor information set, the second device MAC address carried by the first type information in the first neighbor information set and the second device interface ID carried by the first type information in the first neighbor information set.

3. The method of claim 1, wherein, The method comprises: obtaining the first type information in the second neighbor information set and obtaining the second type information in the second neighbor information set; determining the second connection relationship information of the downlink port of the cloud device according to the first device interface ID carried by the second type information in the second neighbor information set, the second device MAC address carried by the second type information in the second neighbor information set, the first device interface ID carried by the first type information in the second neighbor information set, the second device MAC address carried by the first type information in the second neighbor information set and the second device interface ID carried by the first type information in the second neighbor information set.

4. The method of claim 2, wherein, The method comprises: when the second device MAC address carried by the first type information in the first neighbor information set belongs to the MAC address of the cloud device, determining that the first connection relationship of the uplink port of the cloud device is direct connection; determining the first connection information according to the first device interface ID carried by the first type information in the first neighbor information set, the second device MAC address carried by the first type information in the first neighbor information set and the second device interface ID carried by the first type information in the first neighbor information set.

5. The method of claim 3, wherein, The first device interface ID carried by the second type information in the second neighbor information set, the second device MAC address carried by the second type information in the second neighbor information set, the first device interface ID carried by the first type information in the second neighbor information set, the second device MAC address carried by the first type information in the second neighbor information set, and the second device interface ID carried by the first type information in the second neighbor information set are used to determine the second connection relationship information of the downlink port of the cloud device, and the second connection relationship information includes: When the second device MAC address carried by the second type information in the second neighbor information set belongs to the cloud device MAC address, and there is information that the first device interface ID carried by the first type information in the second neighbor information set is the same as the first device interface ID carried by the second type information in the second neighbor information set, and the second device MAC address carried by the first type information in the second neighbor information set is the same as the second device MAC address carried by the second type information in the second neighbor information set, it is determined that the second connection relationship of the downlink port of the cloud device is direct connection. The first device interface ID carried by the first type information in the second neighbor information set, the second device MAC address carried by the first type information in the second neighbor information set, and the second device interface ID carried by the first type information in the second neighbor information set are used to determine the second connection information. If there is no information that the first device interface ID carried by the first type information in the second neighbor information set is the same as the first device interface ID carried by the second type information in the second neighbor information set, and the second device MAC address carried by the first type information in the second neighbor information set is the same as the second device MAC address carried by the second type information in the second neighbor information set, it is determined that the second connection relationship of the downlink port of the cloud device is non-direct connection. The first device interface ID carried by the second type information in the second neighbor information set, the second device MAC address carried by the second type information in the second neighbor information set, and the second device MAC address corresponding to the second device uplink port ID carried by the second type information in the second neighbor information set are used to determine the second connection information.

6. The method of claim 1, wherein, The first type information is a link layer discovery protocol identifier (LLDP), and the second type information is an internet group management protocol identifier (IGMP).

7. The method of claim 1, wherein, The topology graph is displayed by the following method: The directly connected cloud devices are marked by a first visual identifier, and the non-directly connected cloud devices are marked by a second visual identifier.

8. An apparatus for constructing a topology graph of cloud devices, the apparatus comprising: The apparatus includes: An acquisition module is configured to acquire a first neighbor information set generated by a cloud device uplink port and a second neighbor information set generated by a cloud device downlink port. A determination module is configured to determine first connection relationship information of the cloud device uplink port according to the first neighbor information set, and determine second connection relationship information of the cloud device downlink port according to the second neighbor information set, wherein the first connection relationship information includes a first connection relationship and first connection information, and the second connection relationship information includes a second connection relationship and second connection information. The generating module is configured to generate a topology graph among the cloud devices according to the first connection relationship information and the second connection relationship information.

9. A computing device, comprising: comprising a memory and a processor: wherein the memory has stored therein one or more computer programs comprising instructions which, when executed by the processor, cause the computing device to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium is configured to store a computer program for performing the method of any one of claims 1 to 7.

Images