WO2020135575A1 - 一种获取网络拓扑的系统、方法和服务器 - Google Patents

一种获取网络拓扑的系统、方法和服务器 Download PDF

Info

Publication number
WO2020135575A1
WO2020135575A1 PCT/CN2019/128659 CN2019128659W WO2020135575A1 WO 2020135575 A1 WO2020135575 A1 WO 2020135575A1 CN 2019128659 W CN2019128659 W CN 2019128659W WO 2020135575 A1 WO2020135575 A1 WO 2020135575A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
server
network
topology
topology information
Prior art date
Application number
PCT/CN2019/128659
Other languages
English (en)
French (fr)
Inventor
王世超
丁杰
崔丕锁
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to EP19905178.0A priority Critical patent/EP3905590A4/en
Publication of WO2020135575A1 publication Critical patent/WO2020135575A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks

Definitions

  • the present disclosure relates to, but not limited to, computer network technology, and in particular, to a system, method, and server for acquiring network topology.
  • Link Layer Discovery Protocol (LLDP, Link Discovery, Protocol), Cisco Discovery Protocol (CDP, Cisco Discovery Protocol), and Simple Network Management Protocol (SNMP, Simple Network Management Protocol) are used in related technologies.
  • LLDP Link Layer Discovery Protocol
  • CDP Cisco Discovery Protocol
  • SNMP Simple Network Management Protocol
  • the LLDP protocol is the IEEE802.1AB standard, which stipulates that the device periodically sends LLDP messages to surrounding devices.
  • the LLDP message carries configuration information, device capabilities, system names and descriptions, port names and descriptions, etc.
  • CDP and LLDP are similar, but CDP is a private protocol, which is lighter than LLDP and can carry private information.
  • the SNMP protocol uses the Transmission Control Protocol/Internet Interconnection Protocol (TCP/IP) family to manage network devices on the Internet and provides a set of basic operations for monitoring and maintaining network devices.
  • TCP/IP Transmission Control Protocol/Internet Interconnection Protocol
  • the present disclosure provides a system, method, and server for acquiring network topology, capable of acquiring complete network topology information.
  • An embodiment of the present disclosure provides a system for acquiring a network topology, including: a server as a control node and at least one server as a computing node.
  • the control node includes: a first acquisition unit, a client module, and a management module, wherein the first acquisition unit is configured to acquire any or any combination of the following topology information: topology information of the virtual network inside the server where it is located, and the server where it is located.
  • the topology information between the network device and the network device and the topology information between the network device and the network device is configured to obtain the corresponding topology information from the first acquisition unit in the server where it is located according to the call from the management module;
  • the management module is configured to make a network topology based on the obtained topology information.
  • the computing node includes: a second acquisition unit and a client module, wherein the second acquisition unit is configured to acquire any or any combination of the following topology information: topology information of the virtual network inside the server where it is located; server and network equipment where it is located Topology information between; the client module is configured to obtain the corresponding topology information from the second acquisition unit in the server where it is located according to the call from the control node and output it to the control node.
  • the second acquisition unit is configured to acquire any or any combination of the following topology information: topology information of the virtual network inside the server where it is located; server and network equipment where it is located Topology information between; the client module is configured to obtain the corresponding topology information from the second acquisition unit in the server where it is located according to the call from the control node and output it to the control node.
  • An embodiment of the present disclosure also provides a server, including: an acquisition module and a client module, wherein the acquisition module is configured to acquire virtual network topology information inside the server where it is located, and/or acquire the server and network where it is located Topology information between devices; the client module is configured to obtain corresponding topology information from the acquisition module according to the call from the management module.
  • the acquisition module includes a first acquisition module and a second acquisition module, where the first acquisition module is configured to acquire virtual network topology information inside the server where it is located; the second acquisition module is It is configured to obtain topology information between the server where it is located and the network device.
  • the server further includes: a management module
  • the acquisition module further includes: a third acquisition module, wherein the third acquisition module is configured to acquire the topology between the network device and the network device Information; the management module is configured to make a network topology based on the obtained topology information.
  • An embodiment of the present disclosure also provides a method for acquiring a network topology, including: acquiring virtual network topology information inside the server, topology information between the server and network device, and topology information between the network device and network device; And the network topology is made based on the obtained topology information of any one or any combination of the following: virtual network topology information inside the server, topology information between the server and the network device, and topology information between the network device and the network device.
  • An embodiment of the present disclosure also provides a computer-readable storage medium that stores computer-executable instructions, which when executed by a processor, are used to perform any of the foregoing to obtain a network topology method.
  • An embodiment of the present disclosure also provides an electronic device for acquiring a network topology, including a processor and a memory, wherein the memory stores a computer program executable on the processor, and the computer program is executed by the processor Is used to perform any of the above steps of the method for acquiring the network topology.
  • FIG. 1 is a schematic diagram of a system for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 2 is a schematic diagram of a complete network topology diagram obtained by a virtual data center through the system for obtaining a network topology according to an embodiment of the present disclosure
  • FIG. 3 is a schematic diagram of a first acquisition module in a system for acquiring network topology according to an embodiment of the present disclosure
  • FIG. 4 is a schematic diagram of a second acquisition module in a system for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 5 is a schematic diagram of a third acquisition module in a system for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 6 is a schematic diagram of a management module in a system for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 7 is a schematic diagram of a client module in a system for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 8 is a schematic flowchart of a method for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 9 is a schematic diagram of a method for acquiring a network topology according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic diagram of a topology output according to an embodiment of the present disclosure.
  • FIG. 11 is a schematic flowchart of a method for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 12 is a schematic diagram of topology output according to an embodiment of the present disclosure.
  • FIG. 13 is a schematic flowchart of a method for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 14 is a schematic diagram of a topology output according to an embodiment of the present disclosure.
  • 15 is a schematic flowchart of a method for acquiring a network topology according to an embodiment of the present disclosure
  • 16 is a schematic flowchart of a method for acquiring a network topology according to an embodiment of the present disclosure
  • FIG. 17 is a schematic diagram of a topology output according to an embodiment of the present disclosure.
  • FIG. 18 is a schematic flowchart of a method for acquiring a network topology according to an embodiment of the present disclosure.
  • LLDP messages and CDP messages are sent and received on network devices.
  • login to these network devices is not allowed.
  • the present invention People have found that in the data center environment, the server can see the connection to the network equipment. Therefore, the network equipment connected to the network card can be obtained on the server to improve the efficiency of network problem location.
  • the present disclosure also uses SNMP to obtain connection relationships between network devices, which provides a guarantee for drawing a complete data center network topology.
  • FIG. 1 is a schematic diagram of the composition of a system for obtaining a network topology of the present disclosure.
  • the system includes at least: a server as a control node and at least one server as a computing node.
  • the control node includes: a first acquisition unit, a client module and a management module, wherein,
  • the first acquiring unit is configured to acquire any or any combination of the following topology information: virtual network topology information within the server where it is located, topology information between the server where it is located and the network device, and topology between the network device and the network device information;
  • the client module is configured to acquire corresponding topology information from the first acquiring unit in the server where it is located according to the call from the management module;
  • the management module is configured to make a network topology based on the obtained topology information.
  • the first acquiring unit may include: a first acquiring module, a second acquiring module, and a third acquiring module, wherein,
  • the first obtaining module is configured to obtain virtual network topology information inside the server where it is located;
  • the second acquisition module is configured to acquire topology information between the server and the network device where it is located;
  • the third acquisition module is configured to acquire topology information between the network device and the network device.
  • the computing node includes: a second acquisition unit and a client module, where,
  • the second obtaining unit is configured to obtain any or any combination of the following topology information: topology information of the virtual network inside the server where it is located and topology information between the server and the network device where it is located;
  • the client module is configured to acquire corresponding topology information from the second acquisition unit of the computing node where it is located according to the call from the control node and output it to the control node.
  • the second acquiring unit may include: a first acquiring module and a second acquiring module, wherein,
  • the first obtaining module is configured to obtain virtual network topology information inside the server where it is located;
  • the second acquisition module is configured to acquire topology information between the server where it is located and the network device.
  • the client module is further configured to: according to a call from the user, obtain corresponding topology information from each unit that obtains topology information on the server where it is located. More specifically, the client module located on the server as the control node is specifically configured to: according to a request from the user, obtain corresponding topology information from the first acquisition unit of the control node where it is located, so as to initiate the requesting user Obtain the network topology of the server. For the client module located on the server as the computing node, it is specifically configured to: according to the request from the user, obtain the corresponding topology information from the second obtaining unit of the computing node where it is located, so that the user who initiated the request can obtain the network of the server Topology.
  • the virtual network topology information inside the server includes: topology information between the virtual machine inside the server and the virtual network device, and topology information between the virtual network device inside the server and the virtual network device.
  • the topology information between the server and the network device includes: topology information between each network card of the physical server and the network device.
  • the topology information between the network device and the network device includes: topology information between the physical network device and the physical network device.
  • control node may include two or more, which are respectively set as a main control node and one or more standby control nodes.
  • the working mode of the master control node and the standby control node can be the master and standby mode. If the master device has a serious work abnormality, such as: some important modules or a large number of modules appear inactive (INACTIVE) state, it will trigger the slave master control node Switch to the active and standby control node.
  • a serious work abnormality such as: some important modules or a large number of modules appear inactive (INACTIVE) state
  • FIG. 2 is a schematic diagram of a complete network topology diagram obtained by a virtual data center of the present disclosure through the system for obtaining a network topology of the present disclosure.
  • the network topology between network devices including The connection between the level switches, etc.
  • the connection between the server network card and the network device including the connection between the physical network card and the network device on the server, etc.
  • enp4s0f1, enp7s0f0 and other fields indicate the physical network card Name; and, the internal virtual network topology of the server, including, for example, the connection relationship between the virtual switch and the virtual router, the connection relationship between the virtual switch and the dynamic host configuration protocol (DHCP) server, and the connection relationship between the virtual switch and the virtual machine.
  • DHCP dynamic host configuration protocol
  • the system for obtaining a network topology when obtaining the network topology, not only the network topology between physical devices but also the network topology of the virtual network inside the server; and, when obtaining the virtual network topology inside the server, not only The connection relationship between the virtual machine and the virtual switch is obtained, and the connection relationship between the virtual network device and the virtual switch is also obtained. That is to say, through the system for obtaining network topology provided by the present disclosure, complete network topology information is obtained.
  • the first acquisition module at least includes: a first network card statistics module, a search module, and a first generation module, The first message queue module, where,
  • the first network card statistics module is configured to count the network card related information of all the current physical network cards of the server where it is located, and provide information for recording the connection relationship between the physical network card and the switch port;
  • the search module is configured to search the description information of the bridge and port relationship in the OVS database, search the virtual network card name of the virtual machine, and call the Neutron application program interface (API) to search the information of the virtual network device in the Neutron database;
  • API Neutron application program interface
  • the first generation module is configured to form a virtual network topology within the server based on the information from the search module;
  • the first message queue module is configured to implement inter-process communication.
  • the search module may include: a first search module configured to search the description information of the bridge and port relationship in the OVS database; a second search module configured to search the virtual network card name of the virtual machine
  • the third search module is configured to call the Neutron application program interface (API) to search the information of the virtual network device in the Neutron database.
  • the first generation module includes: according to the information from the first search module and the second search module, obtaining the connection relationship between the virtual machine and the OVS bridge; according to the information from the first search module and the third search module, obtaining the virtual The connection relationship between the network device and the OVS bridge, where the virtual network device includes but is not limited to: such as dhcp namespace, virtual router (vRouter), etc.
  • linux system commands can be used to obtain network card related information, such as name and status, of all physical network cards on all physical hosts.
  • the first acquisition module further includes: a first log module (not shown in FIG. 3 ), configured to record key events of the server where it is located, so as to conveniently locate the problem.
  • a first log module (not shown in FIG. 3 ), configured to record key events of the server where it is located, so as to conveniently locate the problem.
  • the first acquiring module further includes: a first daemon process module (not shown in FIG. 3) configured to convert an ordinary process into a daemon process. In this way, the server runs stably in the background.
  • a first daemon process module (not shown in FIG. 3) configured to convert an ordinary process into a daemon process. In this way, the server runs stably in the background.
  • the first obtaining module further includes: a first format conversion module (not shown in FIG. 3), which is configured to convert the information that needs to be transmitted on the server side into a specified data format and output, such as JSON format Wait.
  • a first format conversion module (not shown in FIG. 3), which is configured to convert the information that needs to be transmitted on the server side into a specified data format and output, such as JSON format Wait.
  • the second acquisition module at least includes: a second network card statistics module, a multi-thread control module, and at least one monitoring Modules (such as the first monitoring module, the second monitoring module...the Nth monitoring module in FIG. 4), and the second message queue module, wherein,
  • the second network card statistics module is configured to count network card related information of all physical network cards currently on the server where it is located;
  • the multi-threaded control module is configured to generate multiple threads and synchronize multiple threads
  • the monitoring module is configured to process the packets received by each network card separately.
  • the multi-thread control module is specifically configured to: start a thread for each network card, the thread is used to monitor all messages sent to the network card, and filter out LLDP messages and CDP messages; set for multi-thread Synchronization strategy, used to protect critical data structures to be read or written by only one thread at a time.
  • a mutual exclusion lock can be used Multi-threaded synchronization.
  • each monitoring module includes: a media access control (MAC) layer processing module, an LLDP layer processing module, and a CDP layer processing module.
  • the MAC layer processing module is configured to analyze and process the MAC header; in an exemplary example, the analysis of the Ethernet frame header may process two types of Ethernet protocols: Ethernet_II and 802.3_Ethernet, automatically identifying the protocol type And deal with separately.
  • the LLDP layer processing module is configured to analyze and process the LLDP packet header and type/length/value (TLV, Token/Length/Value) fields.
  • the LLDP_Interface_Port data structure represents the network card and port mapping information parsed by LLDP.
  • the LLDP_Interface_Port data structure is defined as follows:
  • interface_name represents the name of the network card
  • chassis_subtype generally represents the MAC address of the network device
  • port_subtype represents the type of port
  • time_to_live represents the time-to-live value
  • port_description represents the port description
  • system_name represents the system name of the network device connected to the network card
  • system_description represents the /network card connected System description of network equipment.
  • SIZE_LARGE is 100 bytes
  • SIZE_MIDDLE is 50 bytes
  • SIZE_SMALL and SIZE_NIC_NAME are 20 bytes.
  • a lower-level system call socket (socket) is used for development, which improves the versatility of the system for publicly obtaining the network topology.
  • the CDP layer processing module is configured to analyze and process the CDP packet header and TLV field.
  • processing various types of TLV data and recording the results in the CDP_Interface_Port data structure represents the network card and port mapping information parsed out by CDP.
  • the CDP_Interface_Port data structure is defined as follows:
  • interface_name represents the name of the network card
  • device_id represents the network device ID
  • ip_address represents the management IP of the network device
  • time_to_live represents the time-to-live value
  • port_id represents the port ID
  • capabilities represents the functions supported by the network equipment
  • software_version represents the software version of the network equipment
  • platform represents The platform used by the network equipment
  • native_vlan represents the native VLAN.
  • the CDP layer processing module is mainly for dealing with switches in some data centers. It does not support sending LLDP messages, only CDP messages.
  • the second message queue module is configured to implement inter-process communication. Monitor all data packets arriving at the network card in the background in the form of a daemon, analyze the contents of LLDP and CDP messages, and record them in the corresponding data structures for client requests.
  • linux system commands can be used to obtain network card related information, such as name and status, of all physical network cards on all physical hosts.
  • the second acquisition module further includes: a second log module (not shown in FIG. 4), which is configured to record key events of the server where it is located, so as to conveniently locate the problem.
  • a second log module (not shown in FIG. 4), which is configured to record key events of the server where it is located, so as to conveniently locate the problem.
  • the second acquisition module further includes: a second daemon process module (not shown in FIG. 4) configured to convert an ordinary process into a daemon process. In this way, the server runs stably in the background.
  • a second daemon process module (not shown in FIG. 4) configured to convert an ordinary process into a daemon process. In this way, the server runs stably in the background.
  • the second acquisition module further includes: a second format conversion module (not shown in FIG. 4), configured to convert the information that needs to be transmitted on the server side into a specified data format and output, such as JSON format Wait.
  • a second format conversion module (not shown in FIG. 4), configured to convert the information that needs to be transmitted on the server side into a specified data format and output, such as JSON format Wait.
  • the third acquisition module at least includes: a network element control module, a processing module, and a third message queue module ,among them,
  • the network element control module is configured to manage and implement communication with network devices
  • the processing module is configured to process data related to the SNMP protocol, including data directly sent by network devices; and process network topology data from a software-defined network (SDN) controller.
  • SDN software-defined network
  • the second processing module may be an SDN controller agent module, which communicates with the SDN controller to obtain network topology information known by the SDN controller.
  • the third message queue module is configured to implement inter-process communication.
  • the third message queue module can realize cross-host communication.
  • the processing module may include: a first processing module and a second processing module, wherein,
  • the first processing module is configured to process data related to the SNMP protocol, including data directly sent by the network device;
  • the second processing module is configured to process network topology data from a software-defined network (SDN) controller.
  • the second processing module may be an SDN controller agent module, which communicates with the SDN controller to obtain network topology information known by the SDN controller.
  • the processing module is further configured to: process network topology data from the network management system; accordingly, the network element control module is also configured to: manage and implement network management System communication.
  • the third acquisition module further includes: a third log module (not shown in FIG. 5), configured to record key events of the server where it is located, so as to facilitate the location of the problem.
  • a third log module (not shown in FIG. 5), configured to record key events of the server where it is located, so as to facilitate the location of the problem.
  • the third acquiring module further includes: a third daemon process module (not shown in FIG. 5) configured to convert an ordinary process into a daemon process. In this way, the server runs stably in the background.
  • a third daemon process module (not shown in FIG. 5) configured to convert an ordinary process into a daemon process. In this way, the server runs stably in the background.
  • the third obtaining module further includes: a third format conversion module (not shown in FIG. 5), which is configured to convert the information that needs to be transmitted on the server side into a specified data format and output, such as JSON format Wait.
  • a third format conversion module (not shown in FIG. 5), which is configured to convert the information that needs to be transmitted on the server side into a specified data format and output, such as JSON format Wait.
  • FIG. 6 is a schematic diagram of a management module in a system for acquiring a network topology according to an embodiment of the present disclosure.
  • the management module includes at least a fourth message queue module and a topology information processing module.
  • the fourth message queue module is configured to implement inter-process communication, and call the northbound interface of the client module in the server to obtain topology information from the first acquisition module, the second acquisition module, and the third acquisition module. That is, the fourth message queue module can obtain virtual network topology information inside the server, topology information between the server and the network device, and topology information between the network device and the network device.
  • the topology information processing module is configured to integrate the collected topology information to make a network topology.
  • the management module further includes: a first northbound interface module, configured to be provided to a user such as a cloud platform user to call, and obtain the network topology according to the user's call.
  • a first northbound interface module configured to be provided to a user such as a cloud platform user to call, and obtain the network topology according to the user's call.
  • the management module further includes: a fourth log module (not shown in FIG. 6), which is configured to record key events of the server where it is located, so as to conveniently locate the problem.
  • a fourth log module (not shown in FIG. 6), which is configured to record key events of the server where it is located, so as to conveniently locate the problem.
  • the management module further includes: a fourth daemon process module (not shown in FIG. 6) configured to convert an ordinary process into a daemon process. In this way, the server runs stably in the background.
  • the management module further includes: a fourth format conversion module (not shown in FIG. 6), which is configured to convert the information that needs to be transmitted on the server side into a specified data format and output it, such as a JSON format.
  • a fourth format conversion module (not shown in FIG. 6), which is configured to convert the information that needs to be transmitted on the server side into a specified data format and output it, such as a JSON format.
  • the client module at least includes: a fifth message queue module, a second northbound interface module, and an output module, wherein ,
  • the fifth message queue module is configured to implement inter-process communication and monitor the data of its own server in the background in the form of a daemon process;
  • the second northbound interface module is configured to obtain the corresponding topology from the first acquisition module, and/or the second acquisition module, and/or the third acquisition module in the control node where it is located according to the call from the management module in the control node Information; or, obtain the corresponding topology information from the first acquisition module and/or the second acquisition module of the computing node where it is located, and output it to the control node;
  • the output module is configured to output the obtained topology information to the control node or the client that initiated the request.
  • the northbound interface module is further configured to: according to the call from the user, obtain corresponding topology information from each module that obtains topology information on the server where it is located, and output it through the output module.
  • the present disclosure also provides a server, including: an acquisition module and a client module, wherein,
  • the obtaining module is configured to obtain virtual network topology information inside the server where it is located, and/or obtain topology information between the server where it is located and the network device;
  • the client module is configured to acquire corresponding topology information from the acquisition module according to the call from the management module.
  • the acquisition module includes a first acquisition module and a second acquisition module, where,
  • the first obtaining module is configured to obtain virtual network topology information inside the server where it is located;
  • the second acquisition module is configured to acquire topology information between the server where it is located and the network device.
  • the server further includes: a management module
  • the acquisition module further includes: a third acquisition module, wherein,
  • the third acquisition module is configured to acquire topology information between the network device and the network device;
  • the management module is configured to make a network topology based on the obtained topology information.
  • the client module is further configured to:
  • corresponding topology information is obtained from the acquisition module, so that the user who initiated the request obtains the network topology of the server.
  • FIG. 8 is a schematic flowchart of a method for acquiring a network topology according to an embodiment of the present disclosure. As shown in FIG. 8, the method includes:
  • Step 800 Obtain virtual network topology information inside the server, topology information between the server and network device, and topology information between the network device and network device.
  • the virtual network topology information inside the server includes: topology information between the virtual machine inside the server and the virtual network device, and topology information between the virtual network device inside the server and the virtual network device.
  • the topology information between the server and the network device includes: topology information between each network card of the physical server and the network device.
  • the topology information between the network device and the network device includes: topology information between the physical network device and the physical network device.
  • the virtual network topology information inside the server is obtained in this step, including: counting the network card related information of all the physical network cards currently on the server; searching the description information of the bridge and port relationship in the OVS database, and searching the virtual machine virtual The name of the network card, call Neutron API to search the information of the virtual network equipment in the Neutron database; according to the obtained information, form the internal virtual network topology of the server.
  • the steps of forming a virtual network topology inside the server according to the obtained information include:
  • the virtual network devices include but are not limited to: such as dhcp namespace, vRouter and so on.
  • the step of obtaining the topology information between the server and the network device in this step includes: counting the network card related information such as name and status of all physical network cards currently on the server where the server is located; starting a thread for each network card , This thread is used to monitor all messages sent to the network card, and filter out LLDP messages and CDP messages; and process the messages received by each network card separately.
  • linux system commands can be used to obtain network card related information, such as name and status, of all physical network cards on all physical hosts.
  • the steps for processing the packets received by each network card include: analyzing and processing the MAC header, where, in an exemplary example, the analysis of the Ethernet frame header may cause processing To two types of Ethernet protocols: Ethernet_II and 802.3_Ethernet, automatically identify the protocol type and process them separately; analyze and process the LLDP packet header and TLV field.
  • various types of TLV data are processed, and the results are recorded in the LLDP_Interface_Port data structure; and the CDP message header and TLV field are analyzed and processed.
  • various types of TLV data are processed and the results are recorded in the CDP_Interface_Port data structure.
  • a lower-level system call socket (socket) is used for development, which improves the system versatility of publicly obtaining network topology.
  • the step of obtaining topology information between the network device and the network device in this method includes: processing data related to the SNMP protocol, including data directly sent by the network device; and processing network topology data from the SDN controller .
  • Step 801 Create a network topology based on the obtained topology information of any one or any combination of the following: virtual network topology information inside the server, topology information between the server and network device, and topology information between the network device and network device.
  • the method for obtaining a network topology of the present disclosure further includes: outputting the obtained topology information to the client where the requesting user is located according to the request from the user.
  • An embodiment of the present invention further provides a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are used to perform any one of the foregoing methods for acquiring a network topology.
  • An embodiment of the present invention also provides an electronic device for acquiring a network topology, including a processor and a memory; wherein, the memory stores a computer program that can run on the processor: for performing any of the above methods for acquiring a network topology step.
  • FIG. 9 is a schematic diagram of a first example of a method for acquiring a network topology according to an embodiment of the present disclosure. As shown in FIG. 9, in the first example, the topology of the connection relationship between the server network card and the port of the network device will be taken as an example Describe in detail.
  • the server-side program starts the server-side program and run it as a daemon. It should be noted that if the process already exists, delete the existing process first, and then start the process. Start logging.
  • the recorded logs include key events in the server, such as: whether there is a problem in the subsequent multi-thread creation process, whether LLDP messages or CDP messages have been received, the MAC address of the device that sent the LLDP messages, and the recording program operation Abnormal conditions in etc. Start to count the information of all physical network cards on the current host, and record the name of the network card in the pre-set LLDP_Interface_Port data structure and CDP_Interface_Port data structure.
  • a thread is started for each physical network card, and the thread is used to monitor LLDP messages and CDP messages sent to the thread.
  • the monitoring method can be to use the original socket, grab all the packets that reach the specified network card, and filter out the LLDP packets and CDP packets according to the characteristics of the Layer 2 frame.
  • the message After the message reaches the designated network card, it first calls the MAC layer processing module to parse the received message.
  • the LLDP layer processing module is called for corresponding processing; if it is parsed If the received message is a CDP message, the CDP layer processing module is called for corresponding processing; if it is determined that it is neither an LLDP message nor a CDP message, the processing here is skipped and the received message is not processed .
  • Figure 10 shows a schematic diagram of the topology output from the first example.
  • similar fields such as enp4s0f0, enp5s0f0, and enp6s0f0 represent the name of the physical network card, and similar fields such as gei-1/12 and gei-1/13 represent network devices.
  • the port name, MAC:00:22:93:5B:75:C4 and other similar fields indicate the bridge MAC address of the switch, SYSTEM:ZXR10 ROS Version V4.08.23 ZXR10_5928 Software and other similar fields indicate the name and version number of the switch system. According to the obtained topology, server network card configuration problems and switch port configuration problems can be located.
  • FIG. 11 is a schematic flowchart of a second example of a method for acquiring a network topology according to an embodiment of the present disclosure.
  • a client module on an ordinary server will be triggered to acquire the internal virtual of the local server Network topology as an example for detailed description
  • Step 1100 Trigger the client module to start by calling the client northbound interface.
  • Step 1101 The client module learns that the target is to obtain the internal virtual topology of the server according to the parameter of calling the northbound interface of the client, and requests the server to collect the internal virtual network topology of the server through the message queue.
  • Step 1102 The server searches the description information of the relationship between the bridge and the port in the OVS database.
  • Step 1103 The server searches for the virtual network card name of the virtual machine.
  • Step 1104 The server searches the information of the virtual network device in the Neutron database.
  • step 1102 there is no strict execution order between step 1102, step 1103 and step 1104, that is to say, the execution order of step 1102, step 1103 and step 1104 can be adjusted arbitrarily, and is not used to limit the protection of the present disclosure range.
  • Step 1105 Generate a topology based on the information collected in steps 1102 to 1104, and return the topology information to the client.
  • Step 1106 The client module obtains and outputs the virtual topology information inside the server.
  • Fig. 12 shows a schematic diagram of the topology output according to the second example.
  • similar fields such as enp4s0f1, enp7s0f0, enp7s0f1 represent the name of the physical network card
  • similar fields such as br-int and DVS_dp represent the name of the virtual switch
  • VM -1 and other similar fields indicate the name of the virtual machine.
  • the topology type obtained by the second instance is different from the topology type obtained by the first instance.
  • FIG. 13 is a schematic flowchart of a third example of a method for acquiring a network topology according to an embodiment of the present disclosure.
  • the client module on the control node is triggered to acquire the topology between the network device and the network device.
  • the method includes:
  • Step 1300 Trigger the client module to start by calling the client northbound interface.
  • Step 1301 The client module requests the server to collect the topology between the network device and the network device through the message queue.
  • Step 1302 The server performs corresponding processing according to the current network environment, that is, determines to call the response module according to the current network environment to obtain the topology between the network device and the network device.
  • Step 1303 In this example, if the current network environment is a traditional network architecture and a network management system exists, the processing module corresponding to the network management system (such as the second processing module in FIG. 5) is invoked to request the network topology from the network management system.
  • the processing module corresponding to the network management system such as the second processing module in FIG. 5
  • Step 1304 Obtain the topology feedback between the network device and the network device and feed it back to the client module.
  • the client module obtains and outputs the network topology information between the network device and the network device.
  • FIG. 14 is a schematic diagram of the topology output according to the third and fourth examples of the present disclosure.
  • gei-1/12, gei-1/13, gei-1/14, gei-1/15, gei -1/16, gei-1/21 and other similar fields are the port names of the physical switch.
  • the topology type obtained by the third instance is different from the topology type obtained by the first instance and the second instance.
  • FIG. 15 is a schematic flowchart of a fourth example of a method for acquiring a network topology according to an embodiment of the present disclosure.
  • the client module on the control node will be triggered to acquire the topology between the network device and the network device as an example Be explained.
  • the method includes:
  • Step 1500 Trigger the client module to start by calling the client's northbound interface.
  • Step 1501 The client module requests the server to collect the topology between the network device and the network device through the message queue.
  • Step 1502 The server performs corresponding processing according to the current network environment, that is, decides to call the corresponding module according to the current network environment to obtain the topology between the network device and the network device.
  • Step 1503 In this example, the current network environment is a traditional network architecture and there is no network management system.
  • the network element control module shown in FIG. 5 is called to send an SNMP request to the SNMP agent of each network device to obtain management from each network device information.
  • Step 1504 After receiving the reply from each network device, the network element control module sends the obtained result to the processing module corresponding to SNMP (such as the first processing module in FIG. 5).
  • SNMP such as the first processing module in FIG. 5
  • Step 1505 The processing module corresponding to SNMP summarizes the results of all network devices.
  • the topology between the complete network device and the network device can be drawn using the BFS algorithm.
  • Step 1506 Feedback the drawn topology to the client module.
  • Step 1507 The client module obtains and outputs the network topology between the network device and the network device.
  • Figure 14 shows the topology of the output obtained according to this example. In this way, the connection and configuration problems between network devices can be conveniently located according to the obtained topology.
  • the fourth example has a different network scenario.
  • FIG. 16 is a schematic flowchart of a fifth example of a method for acquiring a network topology according to an embodiment of the present disclosure.
  • the client module on the control node is triggered to acquire the topology between the network device and the network device.
  • the method includes:
  • Step 1600 Trigger the client module to start by calling the client's northbound interface.
  • Step 1601 The client module requests the server to collect the topology between the network device and the network device through the message queue.
  • Step 1602 The server performs corresponding processing according to the current network environment, that is, decides to call the corresponding module according to the current network environment to obtain the topology between the network device and the network device.
  • Step 1603 In this embodiment, the current network environment is a traditional network architecture and there is a network management system. At this time, there is a topology between network devices in the database of the SDN controller, then the SDN controller proxy module is called (see Three processing modules) request the overlay network topology from the SDN controller; and call the processing module of the network management system to request the underlay network topology from the network management system.
  • Step 1604 Present the overlay network topology and the underlay network topology on a topology map.
  • Step 1605 Feedback the topology of the overlay network and the underlay network to the client module.
  • Step 1606 The client module obtains and outputs network topology information between the network device and the network device.
  • FIG. 17 is a schematic diagram of the topology output according to the fifth example and the sixth example of the present disclosure.
  • the solid line connection line represents an Underlay network
  • the dashed line connection line represents an Overlay connection line.
  • gei-1/12, gei-1/13, gei-1/14, gei-1/15, gei-1/16, gei-1/21 and other similar fields are the port name of the physical switch; the endpoint of the VXLAN tunnel ( VTEP, Vxlan Tunnel End) are used to encapsulate and decapsulate VXLAN packets.
  • VTEP Vxlan Tunnel End
  • Overlay as the name implies, upper layer, or business level, user level; and corresponding to the overlay is underlay, as the name implies, lower layer, or, infrastructure layer, specifically used to carry traditional user traffic IP network, as long as it can provide the forwarding of IP packets.
  • FIG. 18 is a schematic flowchart of a sixth example of a method for acquiring a network topology according to the present disclosure.
  • the client module on the control node is triggered to acquire the topology between the network device and the network device.
  • the method includes:
  • Step 1800 Trigger the client module to start by calling the client northbound interface.
  • Step 1801 The client module requests the server to collect the topology between the network device and the network device through the message queue.
  • Step 1802 The server performs corresponding processing according to the current network environment, that is, determines to call the corresponding module according to the current network environment to obtain the topology between the network device and the network device.
  • Step 1803 In this embodiment, the current network environment is a traditional network architecture and there is no network management system. At this time, there is a topology between network devices in the database of the SDN controller, then the SDN controller agent module is called (as shown in FIG. 5) The third processing module) requests the overlay network topology from the SDN controller; since there is no network management system, in this embodiment, the network element control module shown in FIG. 5 is called to send SNMP request information to the SNMP agent of each network device to Obtain management information from network devices.
  • Step 1804 After receiving the reply message from each network device, the network element control module sends the obtained result to the processing module corresponding to SNMP (such as the first processing module in FIG. 5).
  • Step 1805 After the SNMP processing module summarizes the responses of all network devices, in this embodiment, the topology map between the complete network device and the network device can be drawn using the BFS algorithm.
  • the topology here is the underlay network topology; the overlay network topology and The underlay network topology is presented on a topology map, and the topology of the overlay network and the underlay network is fed back to the client module.
  • Step 1806 The client module obtains and outputs network topology information between the network device and the network device.
  • Figure 17 shows the topology of the output obtained according to this example. In this way, the connection and configuration problems between network devices can be conveniently located according to the obtained topology. Compared with the fifth example, the sixth example has a different network scenario.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开提供了一种获取网络拓扑的系统、方法和服务器。该方法包括：获取服务器内部的虚拟网络拓扑信息、服务器和网络设备之间的拓扑信息、网络设备和网络设备之间的拓扑信息；根据获得的以下任一项或任意组合的拓扑信息制作网络拓扑：服务器内部的虚拟网络拓扑信息、服务器和网络设备之间的拓扑信息以及网络设备和网络设备之间完整的拓扑信息。摘图1

Description

一种获取网络拓扑的系统、方法和服务器 技术领域
本公开涉及但不限于计算机网络技术，尤指涉及一种获取网络拓扑的系统、方法和服务器。
背景技术
随着网络技术和云计算技术的不断发展，越来越多的物理网络设备、物理服务器、虚拟网络设备和虚拟机出现在数据中心。为了更好地定位网络问题，相关技术中会采用链路层发现协议(LLDP，Link Layer Discovery Protocol)、思科发现协议(CDP，Cisco Discovery Protocol)和简单网络管理协议(SNMP，Simple Network Management Protocol)来获取网络拓扑信息。
其中，LLDP协议是IEEE802.1AB标准，规定设备定期向周围的设备发送LLDP报文，在LLDP报文中携带有配置信息、设备能力、系统名称及描述、端口名称及描述等信息，同时接收和处理来自邻居设备的LLDP报文。CDP协议和LLDP协议的功能是类似的，不过CDP是私有协议，相对LLDP更轻量并且可以携带私有信息。SNMP协议采用传输控制协议/因特网互联协议(TCP/IP)族对互联网上的网络设备进行管理，提供了一组基本的操作，用来监控和维护网络设备。
在一种方案中，在获取网络拓扑时，只获取物理设备之间的网络拓扑，或者是只获取服务器内部的虚拟网络的网络拓扑；在获取服务器内部虚拟网络拓扑时，只获取虚拟机和虚拟交换机(OVS，Open vSwitch)的连接关系；在处理LLDP报文时，采用第三方库libpcap来开发。这种方案降低了通用性。
发明内容
本公开提供一种获取网络拓扑的系统、方法和服务器，能够获取 完整的网络拓扑信息。
本公开的一个实施例提供了一种获取网络拓扑的系统，包括：作为控制节点的服务器和至少一个作为计算节点的服务器。控制节点包括：第一获取单元、客户端模块以及管理模块，其中，第一获取单元，被配置成获取以下任一或任意组合的拓扑信息：自身所在服务器内部的虚拟网络拓扑信息，自身所在服务器和网络设备之间的拓扑信息以及网络设备和网络设备之间的拓扑信息；客户端模块，被配置成根据来自管理模块的调用，从自身所在服务器中的第一获取单元获取相应的拓扑信息；管理模块，被配置成根据获得的拓扑信息制作网络拓扑。计算节点包括：第二获取单元以及客户端模块，其中，第二获取单元，被配置成获取以下任一或任意组合的拓扑信息：自身所在服务器内部的虚拟网络拓扑信息；自身所在服务器和网络设备之间的拓扑信息；客户端模块，被配置成根据来自控制节点的调用，从自身所在服务器中的第二获取单元获取相应的拓扑信息并输出给控制节点。
本公开的一个实施例还提供了一种服务器，包括：获取模块和客户端模块，其中，获取模块，被配置成获取自身所在服务器内部的虚拟网络拓扑信息，和/或获取自身所在服务器和网络设备之间的拓扑信息；客户端模块，被配置成根据来自管理模块的调用，从获取模块获取相应的拓扑信息。
在一种示例性实例中，所述获取模块包括第一获取模块和第二获取模块，其中，第一获取模块，被配置成获取自身所在服务器内部的虚拟网络拓扑信息；第二获取模块，被配置成获取自身所在服务器和网络设备之间的拓扑信息。
在一种示例性实例中，所述服务器还包括：管理模块，并且所述获取模块还包括：第三获取模块，其中，第三获取模块，被配置成获取网络设备和网络设备之间的拓扑信息；管理模块，被配置成根据获得的拓扑信息制作网络拓扑。
本公开的一个实施例还提供了一种获取网络拓扑的方法，包括： 获取服务器内部的虚拟网络拓扑信息、服务器和网络设备之间的拓扑信息、以及网络设备和网络设备之间的拓扑信息；以及根据获得的以下任一项或任意组合的拓扑信息制作网络拓扑：服务器内部的虚拟网络拓扑信息、服务器和网络设备之间的拓扑信息、网络设备和网络设备之间的拓扑信息。
本公开的一个实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令在被处理器运行时用于执行上述任一项所述的获取网络拓扑的方法。
本公开的一个实施例还提供了一种获取网络拓扑的电子设备，包括处理器和存储器，其中，存储器上存储有可在处理器上运行的计算机程序，并且所述计算机程序在被处理器运行时用于执行上述任一项获取网络拓扑的方法的步骤。
本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本公开技术方案的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开的技术方案，并不构成对本公开技术方案的限制。
图1为根据本公开实施例的获取网络拓扑的系统的示意图；
图2为虚拟数据中心通过本公开实施例的获取网络拓扑的系统获得的完整网络拓扑图的示意图；
图3为根据本公开实施例的获取网络拓扑的系统中第一获取模块的示意图；
图4为根据本公开实施例的获取网络拓扑的系统中第二获取模块的示意图；
图5为根据本公开实施例的获取网络拓扑的系统中第三获取模块的示意图；
图6为根据本公开实施例的获取网络拓扑的系统中管理模块的示意图；
图7为根据本公开实施例的获取网络拓扑的系统中客户端模块的示意图；
图8为根据本公开实施例的获取网络拓扑的方法的流程示意图；
图9为根据本公开实施例的获取网络拓扑的方法的示意图；
图10为根据本公开实施例输出的拓扑示意图；
图11为根据本公开实施例的获取网络拓扑的方法的流程示意图；
图12为根据本公开实施例输出的拓扑示意图；
图13为根据本公开实施例的获取网络拓扑的方法的流程示意图；
图14为根据本公开实施例输出的拓扑的示意图；
图15为根据本公开实施例的获取网络拓扑的方法的流程示意图；
图16为根据本公开实施例的获取网络拓扑的方法的流程示意图；
图17为根据本公开实施例输出的拓扑的示意图；
图18为根据本公开实施例的获取网络拓扑的方法的流程示意图。
具体实施方式
为使本公开的目的、技术方案和优点更加清楚明白，下文中将结合附图对本公开的实施例进行详细说明。需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互任意组合。
LLDP报文和CDP报文的发送和接收是在网络设备上完成的，但是，出于安全考虑，是不允许登录这些网络设备的，这种情况下，为了获得完整的网络拓扑，本公开发明人发现，在数据中心环境下，服务器上能看到和网络设备的连接情况，因此，可以通过在服务器上得到网卡所连接的网络设备的情况，来提高网络问题定位的效率。另外，本公开还利用SNMP获取网络设备之间的连接关系，为绘制完整的数 据中心网络拓扑提供了保障。
图1为本公开获取网络拓扑的系统的组成示意图，如图1所示，该系统至少包括：作为控制节点的服务器、至少一个作为计算节点的服务器。
控制节点包括：第一获取单元、客户端模块以及管理模块，其中，
第一获取单元，被配置成获取以下任一或任意组合的拓扑信息：自身所在服务器内部的虚拟网络拓扑信息，自身所在服务器和网络设备之间的拓扑信息和网络设备和网络设备之间的拓扑信息；
客户端模块，被配置成根据来自管理模块的调用，从自身所在服务器中的第一获取单元获取相应的拓扑信息；以及
管理模块，被配置成根据获得的拓扑信息制作网络拓扑。
在一种示例性实例中，第一获取单元可以包括：第一获取模块、第二获取模块、第三获取模块，其中，
第一获取模块，被配置成获取自身所在服务器内部的虚拟网络拓扑信息；
第二获取模块，被配置成获取自身所在服务器和网络设备之间的拓扑信息；以及
第三获取模块，被配置成获取网络设备和网络设备之间的拓扑信息。
计算节点包括：第二获取单元以及客户端模块，其中，
第二获取单元，被配置成获取以下任一或任意组合的拓扑信息：自身所在服务器内部的虚拟网络拓扑信息和身所在服务器和网络设备之间的拓扑信息；
客户端模块，被配置成根据来自控制节点的调用，从自身所在计算节点的第二获取单元获取相应的拓扑信息并输出给控制节点。
在一种示例性实例中，第二获取单元可以包括：第一获取模块、第二获取模块，其中，
第一获取模块，被配置成获取自身所在服务器内部的虚拟网络拓 扑信息；以及
第二获取模块，被配置成获取自身所在服务器和网络设备之间的拓扑信息。
在一种示例性实例中，客户端模块还被配置成：根据来自用户的调用，从自身所在服务器的各获取拓扑信息的单元获取相应的拓扑信息。更具体地，对于位于作为控制节点的服务器上的客户端模块，具体被配置成：根据来自用户的请求，从自身所在控制节点的第一获取单元中获取相应的拓扑信息，以便发起请求的用户获得该服务器的网络拓扑。对于位于作为计算节点的服务器上的客户端模块，具体被配置成：根据来自用户的请求，从自身所在计算节点的第二获取单元获取相应的拓扑信息，以便发起请求的用户获得该服务器的网络拓扑。
在一种示例性实例中，服务器内部的虚拟网络拓扑信息包括：服务器内部虚拟机和虚拟网络设备之间的拓扑信息，以及服务器内部虚拟网络设备和虚拟网络设备之间的拓扑信息。
在一种示例性实例中，服务器和网络设备之间的拓扑信息包括：物理服务器的每一个网卡和网络设备之间的拓扑信息。
在一种示例性实例中，网络设备和网络设备之间的拓扑信息包括：物理网络设备与物理网络设备之间的拓扑信息。
在一种示例性实例中，如图1所示，控制节点可以包括两个或两个以上，分别设置为主控制节点、一个或一个以上备控制节点。
主控制节点和备控制节点的工作方式可以是主备方式，如果主设备出现严重工作异常，比如：某些重要的模块或者大量的模块出现非激活(INACTIVE)状态，就会触发从主控制节点向备控制节点的主备切换。
图2为本公开虚拟数据中心通过本公开的获取网络拓扑的系统获得的完整网络拓扑图的示意图，如图2所示，从右到左依次是：网络设备之间的网络拓扑，包括如各级交换机之间的连接情况等；服务器网卡和网络设备之间的连接关系，包括如服务器上各个物理网卡和网 络设备的连接情况等，如图2中的enp4s0f1、enp7s0f0等类似字段表示物理网卡的名称；以及，服务器内部虚拟网络拓扑，包括如虚拟交换机和虚拟路由器的连接关系、虚拟交换机和动态主机配置协议(DHCP)服务器的连接关系、虚拟交换机和虚拟机之间的连接关系等。
通过本公开获取网络拓扑的系统，在获取网络拓扑时，不仅获取了物理设备之间的网络拓扑，也获取了服务器内部的虚拟网络的网络拓扑；而且，在获取服务器内部虚拟网络拓扑时，不仅获取虚拟机和虚拟交换机的连接关系，也获取了虚拟网络设备和虚拟交换机的连接关系。也就是说，通过本公开提供的获取网络拓扑的系统，获取了完整的网络拓扑信息。
图3为根据本公开实施例的获取网络拓扑的系统中第一获取模块的示意图，如图3所示，该第一获取模块至少包括：第一网卡统计模块、搜索模块、第一生成模块、第一消息队列模块，其中，
第一网卡统计模块，被配置成统计自身所在服务器当前所有的物理网卡的网卡相关信息，为记录物理网卡和交换机端口的连接关系提供信息；
搜索模块，被配置成搜索OVS数据库中对网桥和端口关系的描述信息，搜索虚拟机的虚拟网卡名称，调用Neutron应用程序接口(API)以搜索Neutron数据库中虚拟网络设备的信息；
第一生成模块，被配置成根据来自搜索模块的信息，形成服务器内部虚拟网络拓扑；以及
第一消息队列模块，被配置成实现进程间通信。
在一种示例性实例中，搜索模块可以包括：第一搜索模块，被配置成搜索OVS数据库中对网桥和端口关系的描述信息；第二搜索模块，被配置成搜索虚拟机的虚拟网卡名称；第三搜索模块，被配置成调用Neutron应用程序接口(API)以搜索Neutron数据库中虚拟网络设备的信息。这样，第一生成模块包括：根据来自第一搜索模块和第二搜索模块的信息，获取虚拟机和OVS桥之间的连接关系；根据来自第一 搜索模块和第三搜索模块的信息，获取虚拟网络设备和OVS桥之间的连接关系，其中虚拟网络设备包括但不限于：如dhcp命名空间、虚拟路由器(vRouter)等。
在一种示例性实例中，可以通过linux的系统命令来自获取所有物理主机上所有物理网卡的网卡相关信息如名字、状态等信息。
在一种示例性实例中，第一获取模块还包括：第一日志模块(图3中未示出)，被配置成记录自身所在服务器的关键事件，以方便定位问题。
在一种示例性实例中，第一获取模块还包括：第一守护进程模块(图3中未示出)，被配置成将普通的进程转换为守护进程。这样，实现了服务端稳定运行在后台。
在一种示例性实例中，第一获取模块还包括：第一格式转换模块(图3中未示出)，被配置成将服务器端需要传送的信息转化为指定数据格式后输出，比如JSON格式等。
图4为根据本公开实施例的获取网络拓扑的系统中第二获取模块的示意图，如图4所示，该第二获取模块至少包括：第二网卡统计模块、多线程控制模块、至少一个监听模块(如图4中的第一监听模块、第二监听模块…第N监听模块)、第二消息队列模块，其中，
第二网卡统计模块，被配置成统计自身所在服务器当前所有的物理网卡的网卡相关信息；
多线程控制模块，被配置成产生多线程，并同步多线程；以及
监听模块，被配置成分别对每个网卡收到的报文进行处理。
可选地，多线程控制模块具体被配置成：为每一个网卡开启一个线程，该线程用于监控发送到该网卡的所有报文，并过滤出LLDP报文和CDP报文；为多线程设置同步策略，用于保护关键数据结构同一时间只被一个线程读或者写。
在一种示例性实例中，本公开实施例中，由于最多出现两个线程竞争同一个数据结构，比如网卡监听模块的线程和服务端主线程之间 的竞争，因此，可以采用互斥锁实现多线程的同步。
可选地，每个监听模块均包括：介质访问控制(MAC)层处理模块、LLDP层处理模块、CDP层处理模块。MAC层处理模块，被配置成分析处理MAC头部；在一种示例性实例中，对以太帧头的分析，处理可能遇到两种类型的以太协议：Ethernet_II和802.3_Ethernet，自动识别出协议类型并分别处理。LLDP层处理模块，被配置成分析处理LLDP报文头部和类型/长度/值(TLV，Token/Length/Value)字段。
在一种示例性实例中，处理各种类型的TLV数据，将结果记录到LLDP_Interface_Port数据结构中，该LLDP_Interface_Port数据结构中表示了通过LLDP解析出的网卡和端口映射信息，LLDP_Interface_Port数据结构定义如下：
typedef struct LLDP_Interface_Port{
char interface_name[SIZE_NIC_NAME]；
char chassis_subtype[SIZE_MIDDLE]；
char port_subtype[SIZE_SMALL]；
char time_to_live[SIZE_SMALL]；
char port_description[SIZE_LARGE]；
char system_name[SIZE_MIDDLE]；
char system_description[SIZE_LARGE]；
}lldp_interface_port；
其中，interface_name表示网卡名称；chassis_subtype一般表示网络设备的MAC地址；port_subtype表示端口的类型；time_to_live表示生存时间值；port_description表示端口描述；system_name表示网卡所连网络设备的系统名称；system_description表示/网卡所连网络设备的系统描述。
这里，为了减少不必要的空间开销，不同的信息使用的数组长度不同。比如：SIZE_LARGE为100字节，SIZE_MIDDLE为50字节，SIZE_SMALL和SIZE_NIC_NAME为20字节。
在一种示例性实例中，在处理LLDP报文时，采用更底层的系统 调用套接字(socket)来开发，提升了公开获取网络拓扑的系统通用性。
CDP层处理模块，被配置成分析处理CDP报文头部和TLV字段。在一种示例性实例中，处理各种类型的TLV数据，将结果记录到CDP_Interface_Port数据结构中表示了通过CDP解析出的网卡和端口映射信息，该CDP_Interface_Port数据结构定义如下：
typedef struct CDP_Interface_Port{
char interface_name[SIZE_NIC_NAME]；
char device_id[SIZE_MIDDLE]；
char ip_address[SIZE_MIDDLE]；
char time_to_live[SIZE_SMALL]；
char port_id[SIZE_MIDDLE]；
char capabilities[SIZE_MIDDLE]；
char software_version[SIZE_LARGE]；
char platform[SIZE_LARGE]；
char native_vlan[SIZE_SMALL]；
}cdp_interface_port；
其中，interface_name表示网卡名称；device_id表示网络设备ID；ip_address表示网络设备的管理IP；time_to_live表示生存时间值；port_id表示端口ID；capabilities表示网络设备支持的功能；software_version表示网络设备的软件版本；platform表示网络设备所用的平台；native_vlan表示本地VLAN。
CDP层处理模块主要是为了应对一些数据中心的交换机，不支持发送LLDP报文，只支持CDP报文。
第二消息队列模块，被配置成实现进程间通信。以守护进程的方式在后台监控所有到达网卡的数据包，分析出LLDP和CDP报文的内容，并记录在相应的数据结构中供客户端请求。
在一种示例性实例中，可以通过linux的系统命令来自获取所有物理主机上所有物理网卡的网卡相关信息如名字、状态等信息。
在一种示例性实例中，第二获取模块还包括：第二日志模块(图 4中未示出)，被配置成记录自身所在服务器的关键事件，以方便定位问题。
在一种示例性实例中，第二获取模块还包括：第二守护进程模块(图4中未示出)，被配置成将普通的进程转换为守护进程。这样，实现了服务端稳定运行在后台。
在一种示例性实例中，第二获取模块还包括：第二格式转换模块(图4中未示出)，被配置成将服务器端需要传送的信息转化为指定数据格式后输出，比如JSON格式等。
图5为根据本公开的实施例的获取网络拓扑的系统中第三获取模块的示意图，如图5所示，该第三获取模块至少包括：网元控制模块、处理模块、第三消息队列模块，其中，
网元控制模块，被配置成管理和实现与网络设备的通信；
处理模块，被配置成处理SNMP协议相关的数据，包括网络设备直接发来的数据；处理来自软件自定义网络(SDN)控制器的网络拓扑数据。
在一种示例性实例中，第二处理模块可以是一个SDN控制器代理模块，通过自身与SDN控制器通信来获取SDN控制器已知的网络拓扑信息。
第三消息队列模块，被配置成实现进程间通信。第三消息队列模块可以实现跨越主机通信。
在一种示例性实例中，处理模块可以包括：第一处理模块、第二处理模块，其中，
第一处理模块，被配置成处理SNMP协议相关的数据，包括网络设备直接发来的数据；
第二处理模块，被配置成处理来自软件自定义网络(SDN)控制器的网络拓扑数据。在一种示例性实例中，第二处理模块可以是一个SDN控制器代理模块，通过自身与SDN控制器通信来获取SDN控制器已知的网络拓扑信息。
可选地，如果系统中还包括有网管系统，那么，所述处理模块还被配置成：处理来自网管系统的网络拓扑数据；相应地，网元控制模块还被配置成：管理和实现与网管系统的通信。
在一种示例性实例中，第三获取模块还包括：第三日志模块(图5中未示出)，被配置成记录自身所在服务器的关键事件，以方便定位问题。
在一种示例性实例中，第三获取模块还包括：第三守护进程模块(图5中未示出)，被配置成将普通的进程转换为守护进程。这样，实现了服务端稳定运行在后台。
在一种示例性实例中，第三获取模块还包括：第三格式转换模块(图5中未示出)，被配置成将服务器端需要传送的信息转化为指定数据格式后输出，比如JSON格式等。
图6为根据本公开实施例的获取网络拓扑的系统中管理模块的示意图，如图6所示，该管理模块至少包括：第四消息队列模块、拓扑信息处理模块。
第四消息队列模块，被配置成实现进程间通信，调用服务器中客户端模块的北向接口来获取来自第一获取模块、第二获取模块及第三获取模块的拓扑信息。即，第四消息队列模块可以获取服务器内部的虚拟网络拓扑信息，服务器和网络设备之间的拓扑信息，以及网络设备和网络设备之间的拓扑信息。
拓扑信息处理模块，被配置成对收集到的拓扑信息进行整合以制作网络拓扑。
可选地，管理模块还包括：第一北向接口模块，被配置成提供给用户如云平台用户调用，并根据用户的调用获取网络拓扑。
在一种示例性实例中，管理模块还包括：第四日志模块(图6中未示出)，被配置成记录自身所在服务器的关键事件，以方便定位问题。
在一种示例性实例中，管理模块还包括：第四守护进程模块(图 6中未示出)，被配置成将普通的进程转换为守护进程。这样，实现了服务端稳定运行在后台。
在一种示例性实例中，管理模块还包括：第四格式转换模块(图6中未示出)，被配置成将服务器端需要传送的信息转化为指定数据格式后输出，比如JSON格式等。
图7为根据本公开实施例的获取网络拓扑的系统中客户端模块的示意图，如图7所示，该客户端模块至少包括：第五消息队列模块、第二北向接口模块和输出模块，其中，
第五消息队列模块，被配置成实现进程间通信，以守护进程的方式在后台监控自身所在服务器的数据；
第二北向接口模块，被配置成根据来自控制节点中管理模块的调用，从自身所在控制节点中的第一获取模块，和/或第二获取模块，和/或第三获取模块获取相应的拓扑信息；或者，从自身所在计算节点的第一获取模块和/或第二获取模块获取相应的拓扑信息，并输出给控制节点；
输出模块，被配置成将获取的拓扑信息输出给控制节点或发起请求的用户端。
在一种示例性实例中，北向接口模块还被配置成：根据来自用户的调用，从自身所在服务器的各获取拓扑信息的模块获取相应的拓扑信息，并经过输出模块输出。
本公开还提供一种服务器，包括：获取模块和客户端模块，其中，
获取模块，被配置成获取自身所在服务器内部的虚拟网络拓扑信息，和/或获取自身所在服务器和网络设备之间的拓扑信息；
客户端模块，被配置成根据来自管理模块的调用，从获取模块获取相应的拓扑信息。
在一种示例性实例中，获取模块包括第一获取模块和第二获取模块，其中，
第一获取模块，被配置成获取自身所在服务器内部的虚拟网络拓 扑信息；
第二获取模块，被配置成获取自身所在服务器和网络设备之间的拓扑信息。
在一种示例性实例中，所述服务器还包括：管理模块，并且所述获取模块还包括：第三获取模块，其中，
第三获取模块，被配置成获取网络设备和网络设备之间的拓扑信息；
管理模块，被配置成根据获得的拓扑信息制作网络拓扑。
在一种示例性实例中，所述客户端模块还被配置成：
根据来自用户的请求，从所述获取模块获取相应的拓扑信息，以便发起请求的用户获得所述服务器的网络拓扑。
服务器中各模块的具体实现请参见上文的描述，这里不再赘述。
图8为根据本公开实施例的获取网络拓扑的方法的流程示意图，如图8所示，该方法包括：
步骤800：获取服务器内部的虚拟网络拓扑信息、服务器和网络设备之间的拓扑信息、以及网络设备和网络设备之间的拓扑信息。
在一种示例性实例中，服务器内部的虚拟网络拓扑信息包括：服务器内部虚拟机和虚拟网络设备之间的拓扑信息，以及服务器内部虚拟网络设备和虚拟网络设备之间的拓扑信息。
在一种示例性实例中，服务器和网络设备之间的拓扑信息包括：物理服务器的每一个网卡和网络设备之间的拓扑信息。
在一种示例性实例中，网络设备和网络设备之间的拓扑信息包括：物理网络设备与物理网络设备之间的拓扑信息。
可选地，本步骤中的获取服务器内部的虚拟网络拓扑信息，包括：统计服务器当前所有的物理网卡的网卡相关信息；搜索OVS数据库中对网桥和端口关系的描述信息，搜索虚拟机的虚拟网卡名称，调用Neutron API以搜索Neutron数据库中虚拟网络设备的信息；根据获得的信息，形成服务器内部虚拟网络拓扑。
在一种示例性实例中，根据获得的信息形成服务器内部虚拟网络拓扑的步骤，包括：
根据获得的对网桥和端口关系的描述信息和虚拟机的虚拟网卡名称，获取虚拟机和OVS桥之间的连接关系；根据获得的对网桥和端口关系的描述信息和虚拟网络设备的信息，获取虚拟网络设备和OVS桥之间的连接关系。其中虚拟网络设备包括但不限于：如dhcp命名空间、vRouter等。
可选地，本步骤中的获取服务器和网络设备之间的拓扑信息的步骤，包括：统计自身所在服务器当前所有的物理网卡的网卡相关信息如名字、状态等信息；为每一个网卡开启一个线程，该线程用于监控发送到该网卡的所有报文，并过滤出LLDP报文和CDP报文；以及分别对每个网卡收到的报文进行处理。
在一种示例性实例中，可以通过linux的系统命令来自获取所有物理主机上所有物理网卡的网卡相关信息如名字、状态等信息。
在一种示例性实例中，对每个网卡收到的报文进行处理的步骤，包括：分析处理MAC头部，其中，在一种示例性实例中，对以太帧头的分析，处理可能遇到两种类型的以太协议：Ethernet_II和802.3_Ethernet，自动识别出协议类型并分别处理；分析处理LLDP报文头部和TLV字段。在一种示例性实例中，处理各种类型的TLV数据，将结果记录到LLDP_Interface_Port数据结构中；以及分析处理CDP报文头部和TLV字段。
在一种示例性实例中，处理各种类型的TLV数据，将结果记录到CDP_Interface_Port数据结构中。
可选地，在处理LLDP报文时，采用更底层的系统调用套接字(socket)来开发，提升了公开获取网络拓扑的系统通用性。
可选地，本方法中的获取网络设备和网络设备之间的拓扑信息的步骤，包括：处理SNMP协议相关的数据，包括网络设备直接发来的数据；以及处理来自SDN控制器的网络拓扑数据。
步骤801：根据获得的以下任一项或任意组合的拓扑信息制作网络拓扑：服务器内部的虚拟网络拓扑信息、服务器和网络设备之间的拓扑信息、网络设备和网络设备之间的拓扑信息。
可选地，本步骤中的制作的完整的网络拓扑。
在一种示例性实例中，本公开获取网络拓扑的方法，还包括：根据来自用户的请求，将获得的拓扑信息输出给发起请求的用户所在的客户端。
本发明实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述任一项所述的获取网络拓扑的方法。
本发明实施例还提供一种获取网络拓扑的电子设备，包括处理器、存储器；其中，存储器上存储有可在处理器上运行的计算机程序：用于执行上述任一项获取网络拓扑的方法的步骤。
下面结合具体实施例对本公开获取网络拓扑的方法进行详细描述。
图9为根据本公开实施例的获取网络拓扑的方法的第一实例的示意图，如图9所示，在第一实例中，将以获取服务器网卡和网络设备端口之间的连接关系拓扑为例进行详细描述。
首先，启动服务器端程序，以守护进程的方式运行。需要说明的是，如果已有该进程，则先删除已有的该进程，然后再启动进程。启动对日志的记录。记录的日志包括服务器中的关键事件，比如：紧接着的多线程创建过程中是否有问题、有没有收到LLDP报文或者CDP报文、发送LLDP报文的设备的MAC地址，以及记录程序运行中的异常情况等。开始统计当前主机上所有的物理网卡的信息，将网卡名对应记录在预先设置的LLDP_Interface_Port数据结构和CDP_Interface_Port数据结构中。
然后，为每个物理网卡启动一个线程，该线程用于监控发送到该线程的LLDP报文和CDP报文。监控的方法可以是使用原始套接字，抓取所有到达指定网卡的报文，并根据二层帧的特点过滤出LLDP报 文和CDP报文。结合图4，报文到达指定网卡后，先调用MAC层处理模块，解析收到的报文，如果解析出收到的报文是LLDP报文，则调用LLDP层处理模块进行相应处理；如果解析出收到的报文是CDP报文，则调用CDP层处理模块进行相应处理；如果判断出既不是LLDP报文也不是CDP报文，则跳过这里的处理即不对收到的报文进行处理。
之后，根据报文相应的协议解析所有的TLV字段，将相关的结果对应记录在LLDP_Interface_Port数据结构和CDP_Interface_Port数据结构中。本实施例中，为了确保服务端只有一个线程在修改，或者在一个线程修改时不会同时被另一个线程读，采用互斥锁来处理多线程的同步问题。
最后，启动消息队列以准备处理来自客户端的请求。本实施例中，在向发起请求的客户端返回结果时，是将LLDP_Interface_Port数据结构和CDP_Interface_Port数据结构中的数据以指定的格式如JSON格式等进行返回，以方便客户端处理。
图10显示了第一实例输出的拓扑的示意图，如图10所示，enp4s0f0、enp5s0f0、enp6s0f0等类似字段表示物理网卡的名称，gei-1/12、gei-1/13等类似字段表示网络设备端口名称，MAC:00:22:93:5B:75:C4等类似字段表示交换机的桥MAC地址，SYSTEM:ZXR10 ROS Version V4.08.23 ZXR10_5928 Software等类似字段表示交换机系统的名称和版本号。根据获得的拓扑可以定位服务器网卡配置问题和交换机端口配置问题。
图11为根据本公开实施例的获取网络拓扑的方法的第二实例的流程示意图，在第二实例中，如图11所示，将以触发普通服务器上的客户端模块获取本地服务器的内部虚拟网络拓扑为例进行详细描述
步骤1100：通过调用客户端北向接口触发客户端模块启动。
步骤1101：客户端模块根据调用客户端北向接口的参数获知目标是获取服务器内部虚拟拓扑，通过消息队列向服务器请求收集服务器内部虚拟网络拓扑。
步骤1102：服务器搜索OVS数据库中对网桥和端口关系的描述信息。
步骤1103：服务器搜索虚拟机的虚拟网卡名称。
步骤1104：服务器搜索Neutron数据库中虚拟网络设备的信息。
需要说明的是，步骤1102、步骤1103和步骤1104之间并没有严格的先后执行顺序，也就是说，步骤1102、步骤1103和步骤1104的执行顺序可以任意调整，并不用于限定本公开的保护范围。
步骤1105：根据步骤1102～步骤1104收集到的信息产生拓扑，并将拓扑信息返回给客户端。
步骤1106：客户端模块获得服务器内部虚拟拓扑信息并输出。
图12示出了根据第二实例输出的拓扑的示意图，如图12所示，enp4s0f1、enp7s0f0、enp7s0f1等类似字段表示物理网卡的名称，br-int和DVS_dp等类似字段表示虚拟交换机的名称，VM-1等类似字段表示虚机的名称。根据获得的拓扑可以方便定位虚拟网络中的配置问题。第二实例获得的拓扑类型不同于第一实例获得的拓扑类型。
图13为根据本公开实施例的获取网络拓扑的方法的第三实例的流程示意图。在第三实施例中，将以触发控制节点上的客户端模块获取网络设备和网络设备之间的拓扑为例进行说明。假设当前虚拟数据中心采用的是传统网络架构，并且有网管系统，如图13所示，该方法包括：
步骤1300：通过调用客户端北向接口触发客户端模块启动。
步骤1301：客户端模块通过消息队列向服务器请求收集网络设备和网络设备之间的拓扑。
步骤1302：服务器根据当前网络环境进行相应处理，即根据当前网络环境决定调用响应模块来获取网络设备和网络设备之间的拓扑。
步骤1303：本实例中，当前网络环境为传统网络架构且存在网管系统，则调用网管系统对应的处理模块(如图5中的第二处理模块)向网管系统请求网络拓扑。
步骤1304：获取网络设备和网络设备之间的拓扑后向反馈给客户端模块，客户端模块获得网络设备和网络设备之间的网络拓扑信息并输出。
图14为根据本公开第三实例和第四实例输出的拓扑的示意图，如图14所示，gei-1/12、gei-1/13、gei-1/14、gei-1/15、gei-1/16、gei-1/21等类似字段是物理交换机的端口名称。根据获得的拓扑可以方便定位网络设备之间的连接和配置。第三实例获得的拓扑类型不同于第一实例和第二实例获取的拓扑类型。
图15为根据本公开实施例的获取网络拓扑的方法的第四实例的流程示意图，在第四实例中，将以触发控制节点上的客户端模块获取网络设备和网络设备之间的拓扑为例进行说明。假设当前虚拟数据中心采用的是传统网络架构，并且没有网管系统，如图15所示，该方法包括：
步骤1500：通过调用客户端北向接口触发客户端模块启动。
步骤1501：客户端模块通过消息队列向服务器请求收集网络设备和网络设备之间的拓扑。
步骤1502：服务器根据当前网络环境进行相应处理，即根据当前网络环境决定调用相应模块来获取网络设备和网络设备之间的拓扑。
步骤1503：本实例中，当前网络环境为传统网络架构且不存在网管系统，调用如图5所示的网元控制模块向各个网络设备的SNMP代理发出SNMP请求，以从各网络设备中获取管理信息。
步骤1504：网元控制模块收到各个网络设备的回复后，将获得的结果发给SNMP对应的处理模块(如图5中的第一处理模块)。
步骤1505：SNMP对应的处理模块汇总所有网络设备的结果，本实施例中可以利用BFS算法绘制出完整的网络设备与网络设备之间的拓扑。
步骤1506：将绘制的拓扑反馈给向客户端模块。
步骤1507：客户端模块获得网络设备与网络设备之间的网络拓扑 并输出。
图14示出根据本实例获得的输出的拓扑。这样，根据获得的拓扑可以方便定位网络设备之间的连接和配置问题。第四实例与第三实例相比，二者的网络场景不一样。
图16为根据本公开实施例的获取网络拓扑的方法的第五实例的流程示意图。在第五实例中，将以触发控制节点上的客户端模块获取网络设备和网络设备之间的拓扑为例进行说明。假设当前虚拟数据中心采用的是SDN网络架构，并且有网管系统，如图16所示，该方法包括：
步骤1600：通过调用客户端北向接口触发客户端模块启动。
步骤1601：客户端模块通过消息队列向服务器请求收集网络设备和网络设备之间的拓扑。
步骤1602：服务器根据当前网络环境进行相应处理，即根据当前网络环境决定调用相应模块来获取网络设备和网络设备之间的拓扑。
步骤1603：本实施例中，当前网络环境为传统网络架构且存在网管系统，此时SDN控制器的数据库中有网络设备之间的拓扑，则调用SDN控制器代理模块(如图5中的第三处理模块)向SDN控制器请求overlay网络拓扑；并调用网管系统的处理模块向网管系统请求underlay网络拓扑。
步骤1604：将overlay网络拓扑和underlay网络拓扑呈现在一张拓扑图上。
步骤1605：将融合了overlay网络和underlay网络的拓扑反馈给客户端模块。
步骤1606：客户端模块获得网络设备和网络设备之间的网络拓扑信息并输出。
图17为根据本公开第五实例和第六实例输出的拓扑的示意图，如图17所示，实线连接线表示Underlay网络，虚线连接线表示Overlay连接线。gei-1/12、gei-1/13、gei-1/14、gei-1/15、gei-1/16、gei-1/21等 类似字段是物理交换机的端口名称；VXLAN隧道的端点(VTEP，Vxlan Tunnel End Point)用于VXLAN报文的封装和解封装。根据获得的拓扑可以方便定位网络设备之间的连接和配置问题，本实施例与第三实施例和第四实施例相比，网络架构不同。其中，Overlay，顾名思义，上层的，或者说，业务层面的、用户层面的；而与overlay所对应的是underlay，顾名思义，下层的，或者说，基础架构层，专门用于承载用户流量的传统的IP网络，只要可以提供IP包的转发即可。
图18为根据本公开获取网络拓扑的方法的第六实例的流程示意图。在第六实例中，将以触发控制节点上的客户端模块获取网络设备和网络设备之间的拓扑为例进行说明。假设当前虚拟数据中心采用的是SDN网络架构，并且没有网管系统，如图18所示，该方法包括：
步骤1800：通过调用客户端北向接口触发客户端模块启动。
步骤1801：客户端模块通过消息队列向服务器请求收集网络设备和网络设备之间的拓扑。
步骤1802：服务器根据当前网络环境进行相应处理，即根据当前网络环境决定调用相应模块来获取网络设备和网络设备之间的拓扑。
步骤1803：本实施例中，当前网络环境为传统网络架构且不存在网管系统，此时SDN控制器的数据库中有网络设备之间的拓扑，则调用SDN控制器代理模块(如图5中的第三处理模块)向SDN控制器请求overlay网络拓扑；由于没有网管系统，则本实施例中，调用如图5所示的网元控制模块向各个网络设备的SNMP代理发出SNMP请求信息，以从网络设备中获取管理信息。
步骤1804：网元控制模块收到各个网络设备的回复消息后，将获得的结果发给SNMP对应的处理模块(如图5中的第一处理模块)。
步骤1805：SNMP处理模块汇总所有网络设备的回复后，本实施例中可以利用BFS算法绘制出完整的网络设备与网络设备之间的拓扑图，这里的拓扑就是underlay网络拓扑；将overlay网络拓扑和underlay网络拓扑呈现在一张拓扑图上，将融合了overlay网络和underlay网络 的拓扑反馈给客户端模块。
步骤1806：客户端模块获得网络设备和网络设备之间的网络拓扑信息并输出。
图17示出根据本实例获得的输出的拓扑。这样，根据获得的拓扑可以方便定位网络设备之间的连接和配置问题。第六实例与第五实例相比，二者的网络场景不一样。
以上所述，仅为本发明的较佳实例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (36)

  1. 一种获取网络拓扑的系统，包括：作为控制节点的服务器和至少一个作为计算节点的服务器，其中，
    控制节点包括：第一获取单元、客户端模块以及管理模块，其中，
    第一获取单元，被配置成获取以下任一或任意组合的拓扑信息：自身所在服务器内部的虚拟网络拓扑信息，自身所在服务器和网络设备之间的拓扑信息以及网络设备和网络设备之间的拓扑信息；
    客户端模块，被配置成根据来自管理模块的调用，从自身所在服务器中的第一获取单元获取相应的拓扑信息；
    管理模块，被配置成根据获得的拓扑信息制作网络拓扑，
    计算节点包括：第二获取单元以及客户端模块，其中，
    第二获取单元，被配置成获取以下任一或任意组合的拓扑信息：自身所在服务器内部的虚拟网络拓扑信息以及自身所在服务器和网络设备之间的拓扑信息；
    客户端模块，被配置成根据来自控制节点的调用，从自身所在服务器中的第二获取单元获取相应的拓扑信息并输出给控制节点。
  2. 根据权利要求1所述的系统，其中，所述客户端模块还被配置成：根据来自用户的调用，从自身所在服务器的各获取拓扑信息的模块获取相应的拓扑信息。
  3. 根据权利要求1所述的系统，其中，所述控制节点的客户端模块还被配置成：根据来自用户的请求，从所述第一获取单元中获取拓扑信息，以便发起请求的用户获得所述控制节点的网络拓扑。
  4. 根据权利要求1所述的系统，其中，所述计算节点的客户端模块还被配置成：根据来自用户的请求，从所述计算节点的第二获取单 元获取拓扑信息，以便发起请求的用户获得所述计算节点的网络拓扑。
  5. 根据权利要求1所述的系统，其中，所述控制节点包括主控制节点和备控制节点。
  6. 根据权利要求1～5任一项所述的系统，其中，
    所述服务器内部的虚拟网络拓扑信息包括：服务器内部虚拟机和虚拟网络设备之间的拓扑信息，以及服务器内部虚拟网络设备和虚拟网络设备之间的拓扑信息；
    所述服务器和网络设备之间的拓扑信息包括：物理服务器的每一个网卡和网络设备之间的拓扑信息；
    所述网络设备和网络设备之间的拓扑信息包括：物理网络设备与物理网络设备之间的拓扑信息。
  7. 一种服务器，包括：获取模块和客户端模块，其中，
    获取模块，被配置成获取自身所在服务器内部的虚拟网络拓扑信息，和/或获取自身所在服务器和网络设备之间的拓扑信息；
    客户端模块，被配置成根据来自管理模块的调用，从获取模块获取相应的拓扑信息。
  8. 根据权利要求7所述的服务器，所述获取模块包括第一获取模块和第二获取模块，其中，
    第一获取模块，被配置成获取自身所在服务器内部的虚拟网络拓扑信息；
    第二获取模块，被配置成获取自身所在服务器和网络设备之间的拓扑信息。
  9. 根据权利要求8所述的服务器，所述服务器还包括：管理模块， 并且所述获取模块还包括：第三获取模块，其中，
    第三获取模块，被配置成获取网络设备和网络设备之间的拓扑信息；
    管理模块，被配置成根据获得的拓扑信息制作网络拓扑。
  10. 根据权利要求9所述的服务器，其中，所述客户端模块还被配置成：
    根据来自用户的请求，从所述获取模块获取相应的拓扑信息，以便发起请求的用户获得所述服务器的网络拓扑。
  11. 根据权利要求8所述的服务器，所述第一获取模块包括：第一网卡统计模块、搜索模块、第一生成模块和第一消息队列模块，其中，
    第一网卡统计模块，被配置成统计自身所在服务器当前所有的物理网卡的网卡相关信息，为记录网卡和交换机端口的连接关系提供信息；
    搜索模块，被配置成搜索虚拟交换机OVS数据库中对网桥和端口关系的描述信息；搜索虚拟机的虚拟网卡名称；调用Neutron应用程序接口API以搜索Neutron数据库中虚拟网络设备的信息；
    第一生成模块，被配置成根据来自搜索模块的信息，形成服务器内部虚拟网络拓扑；以及
    第一消息队列模块，被配置成实现进程间通信。
  12. 根据权利要求11所述的服务器，其中，所述第一生成模块被配置成：根据来自所述搜索模块的所述描述信息和所述虚拟网卡名称，获取虚拟机和OVS桥之间的连接关系，并且根据来自所述搜索模块的所述描述信息和所述虚拟网络设备的信息，获取虚拟网络设备和OVS桥之间的连接关系。
  13. 根据权利要求11所述的服务器，其中，所述第一获取模块还包括：
    被配置成记录自身所在服务器的事件的第一日志模块；
    被配置成将普通的进程转换为守护进程的第一守护进程模块；以及，
    被配置成将服务器端需要传送的信息转化为指定数据格式后输出的第一格式转换模块。
  14. 根据权利要求8所述的服务器，其中，所述第二获取模块包括：第二网卡统计模块、多线程控制模块、至少一个监听模块和第二消息队列模块，其中，
    第二网卡统计模块，被配置成统计自身所在服务器当前所有的物理网卡的网卡相关信息；
    多线程控制模块，被配置成产生多线程，并同步多线程；
    监听模块，被配置成分别对每个网卡收到的报文进行处理；
    第二消息队列模块，被配置成实现进程间通信。
  15. 根据权利要求14所述的服务器，其中，所述多线程控制模块被配置成：
    为每一个网卡开启一个线程，该线程用于监控发送到该网卡的所有报文，并过滤出链路层发现协议LLDP报文和思科发现协议CDP报文；并且为多线程设置用于保护关键数据结构同一时间只被一个线程读或者写的同步策略。
  16. 根据权利要求14所述的服务器，其中，所述监听模块均包括：介质访问控制MAC层处理模块、LLDP层处理模块和CDP层处理模块，其中，
    MAC层处理模块，被配置成分析处理MAC头部；
    LLDP层处理模块，被配置成分析处理LLDP报文头部和类型/长度/值TLV字段；
    CDP层处理模块，被配置成分析处理CDP报文头部和TLV字段。
  17. 根据权利要求16所述的服务器，其中，所述LLDP层处理模块调用套接字处理所述LLDP报文。
  18. 根据权利要求9所述的服务器，其中，所述第三获取模块包括：网元控制模块、处理模块和第三消息队列模块，其中，
    网元控制模块，被配置成管理和实现与网络设备的通信；
    处理模块，被配置成处理简单网络管理协议SNMP协议相关的数据；处理来自软件自定义网络SDN控制器的网络拓扑数据；
    第三消息队列模块，被配置成实现进程间通信。
  19. 根据权利要求18所述的服务器，其中，在所述系统中还包括网管系统的情况下，所述处理模块还被配置成：处理来自网管系统的网络拓扑数据，并且
    所述网元控制模块还被配置成：管理和实现与网管系统的通信。
  20. 根据权利要求16所述的服务器，其中，所述第三获取模块还包括：
    被配置成记录自身所在服务器的事件的第三日志模块；
    被配置成将普通的进程转换为守护进程的第三守护进程模块；
    被配置成将服务器端需要传送的信息转化为指定数据格式后输出的第三格式转换模块。
  21. 根据权利要求9所述的服务器，其中，所述管理模块包括： 第四消息队列模块和拓扑信息处理模块，其中，
    第四消息队列模块，被配置成实现进程间通信，调用服务器中客户端模块的北向接口来获取来自所述第一获取模块、所述第二获取模块及所述第三获取模块的拓扑信息；
    拓扑信息处理模块，被配置成对收集到的拓扑信息进行整合以制作网络拓扑。
  22. 根据权利要求21所述的服务器，其中，所述管理模块还包括：第一北向接口模块，被配置成提供给用户调用，并根据用户的调用获取所述网络拓扑。
  23. 根据权利要求19所述的服务器，其中，所述管理模块还包括：
    被配置成记录自身所在服务器的事件的第四日志模块；
    被配置成将普通的进程转换为守护进程的第四守护进程模块；
    被配置成将服务器端需要传送的信息转化为指定数据格式后输出的第四格式转换模块。
  24. 根据权利要求8所述的服务器，其中，所述客户端模块包括：第五消息队列模块、第二北向接口模块和输出模块，其中，
    第五消息队列模块，被配置成实现进程间通信，以守护进程的方式在后台监控自身所在服务器的数据；
    第二北向接口模块，被配置成根据来自所述管理模块的调用，从所述第一获取模块，和/或所述第二获取模块，和/或所述第三获取模块获取相应的拓扑信息；
    输出模块，被配置成将获取的拓扑信息输出给控制节点或发起请求的客户端。
  25. 根据权利要求24所述的服务器，其中，所述北向接口模块还 被配置成：根据来自用户的调用，从自身所在服务器的各获取拓扑信息的模块获取相应的拓扑信息并输出；或者，从自身所在计算节点的第一获取模块和/或第二获取模块获取相应的拓扑信息，并输出给控制节点。
  26. 一种获取网络拓扑的方法，包括：
    获取服务器内部的虚拟网络拓扑信息、服务器和网络设备之间的拓扑信息、以及网络设备和网络设备之间的拓扑信息；以及
    根据获得的以下任一项或任意组合的拓扑信息制作网络拓扑：服务器内部的虚拟网络拓扑信息、服务器和网络设备之间的拓扑信息以及网络设备和网络设备之间的拓扑信息。
  27. 根据权利要求26所述的方法，还包括：根据来自用户的请求，将获得的拓扑信息输出给发起请求的用户所在的客户端。
  28. 根据权利要求26或27所述的方法，其中，
    所述服务器内部的虚拟网络拓扑信息包括：服务器内部虚拟机和虚拟网络设备之间的拓扑信息，以及服务器内部虚拟网络设备和虚拟网络设备之间的拓扑信息；
    所述服务器和网络设备之间的拓扑信息包括：物理服务器的每一个网卡和网络设备之间的拓扑信息；
    所述网络设备和网络设备之间的拓扑信息包括：物理网络设备与物理网络设备之间的拓扑信息。
  29. 根据权利要求26或27所述的方法，其中，所述获取服务器内部的虚拟网络拓扑信息的步骤，包括：
    统计所述服务器当前所有的物理网卡的信息；
    搜索OVS数据库中对网桥和端口关系的描述信息，搜索虚拟机的 虚拟网卡名称，调用Neutron API以搜索Neutron数据库中虚拟网络设备的信息；以及
    根据获得的信息，形成所述服务器内部虚拟网络拓扑。
  30. 根据权利要求29所述的方法，其中，所述根据获得的信息形成服务器内部虚拟网络拓扑的步骤，包括：
    根据获得的所述对网桥和端口关系的描述信息和所述虚拟机的虚拟网卡名称，获取虚拟机和OVS桥之间的连接关系；根据获得的所述对网桥和端口关系的描述信息和所述虚拟网络设备的信息，获取虚拟网络设备和OVS桥之间的连接关系。
  31. 根据权利要求26或27所述的方法，其中，所述获取服务器和网络设备之间的拓扑信息的步骤，包括：
    统计所述服务器当前所有的物理网卡的网卡相关信息；
    为每一个网卡开启一个线程，该线程用于监控发送到该网卡的所有报文，并过滤出LLDP报文和CDP报文；以及
    分别对每个网卡收到的报文进行处理。
  32. 根据权利要求31所述的方法，其中，所述对每个网卡收到的报文进行处理的步骤，包括：
    分析处理MAC头部；分析处理LLDP报文头部和TLV字段；分析处理CDP报文头部和TLV字段。
  33. 根据权利要求32所述的方法，其中，通过调用套接字来处理所述LLDP报文。
  34. 根据权利要求26或27所述的方法，其中，所述获取网络设备和网络设备之间的拓扑信息的步骤，包括：
    处理SNMP协议相关的数据，所述SNMP协议相关的数据包括网络设备直接发来的数据；以及
    处理来自SDN控制器的网络拓扑数据。
  35. 一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令在被处理器运行时，用于执行上述权利要求26-34中任一项所述的获取网络拓扑的方法。
  36. 一种获取网络拓扑的电子设备，包括处理器和存储器，其中，存储器上存储有可在处理器上运行的计算机程序，并且所述计算机程序在被处理器运行时，用于执行上述权利要求26-34中任一项获取网络拓扑的方法的步骤。
PCT/CN2019/128659 2018-12-26 2019-12-26 一种获取网络拓扑的系统、方法和服务器 WO2020135575A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19905178.0A EP3905590A4 (en) 2018-12-26 2019-12-26 SYSTEM AND METHOD FOR ESTABLISHING A NETWORK TOPOLOGY AND SERVER

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811598855.3A CN109831318A (zh) 2018-12-26 2018-12-26 一种获取网络拓扑的系统、方法和服务器
CN201811598855.3 2018-12-26

Publications (1)

Publication Number Publication Date
WO2020135575A1 true WO2020135575A1 (zh) 2020-07-02

Family

ID=66861126

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/128659 WO2020135575A1 (zh) 2018-12-26 2019-12-26 一种获取网络拓扑的系统、方法和服务器

Country Status (3)

Country Link
EP (1) EP3905590A4 (zh)
CN (1) CN109831318A (zh)
WO (1) WO2020135575A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113364628A (zh) * 2021-06-11 2021-09-07 上海中通吉网络技术有限公司 服务器与交换机拓扑关系建立方法及设备
CN113794732A (zh) * 2021-09-22 2021-12-14 上海观安信息技术股份有限公司 一种部署仿真网络环境的方法、装置、设备及存储介质
CN114422374A (zh) * 2022-03-22 2022-04-29 南京赛宁信息技术有限公司 一种靶场场景拓扑解析、初始化、回收方法及系统
CN114553707A (zh) * 2020-11-26 2022-05-27 腾讯科技（深圳）有限公司 网络的拓扑信息的生成和网络故障的定界方法、装置
CN116094938A (zh) * 2023-01-16 2023-05-09 紫光云技术有限公司 基于kafka的网络拓扑同步方法、设备、服务器及存储介质

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109831318A (zh) * 2018-12-26 2019-05-31 中兴通讯股份有限公司 一种获取网络拓扑的系统、方法和服务器
CN110636044B (zh) * 2019-08-19 2021-01-01 视联动力信息技术股份有限公司 一种虚拟终端的入网方法、系统及装置和存储介质
CN113037520A (zh) * 2019-12-09 2021-06-25 深信服科技股份有限公司 一种环路检测方法、装置、设备及可读存储介质
CN113760440A (zh) 2020-06-03 2021-12-07 华为技术有限公司 一种虚拟化的网络服务的部署方法及装置
CN113301073A (zh) * 2020-04-16 2021-08-24 阿里巴巴集团控股有限公司 分布式机器学习系统中服务器节点之间的通信方法和装置
CN112398738B (zh) * 2020-11-05 2022-06-28 竞技世界（北京）网络技术有限公司 连接关系的获取方法及装置、设备、计算机可读存储介质
CN113965515B (zh) * 2021-09-26 2023-04-18 杭州安恒信息技术股份有限公司 虚拟化网络链路可视化方法、系统、计算机及存储介质
CN114268940A (zh) * 2021-12-22 2022-04-01 深圳市共进电子股份有限公司 Mesh网络拓扑图显示方法、系统、设备及存储介质
CN114422518A (zh) * 2022-03-31 2022-04-29 北京奥星贝斯科技有限公司 请求服务的方法及装置
CN114745281B (zh) * 2022-04-11 2023-12-05 京东科技信息技术有限公司 一种数据处理的方法和装置
CN114866432B (zh) * 2022-04-11 2023-10-17 张槐权 一种网络交换机远程管理和监控系统及方法
CN116016196A (zh) * 2022-12-14 2023-04-25 四川新网银行股份有限公司 一种实时构建系统架构拓扑的方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103036703A (zh) * 2011-10-04 2013-04-10 株式会社日立制作所 虚拟网络的逻辑拓扑的结构管理方法以及管理服务器
CN103281248A (zh) * 2013-06-09 2013-09-04 北京星网锐捷网络技术有限公司 网络拓扑的发现方法、装置和系统
CN103516754A (zh) * 2012-06-27 2014-01-15 中兴通讯股份有限公司 一种将物理网络向虚拟网络迁移的方法及装置
US20160344591A1 (en) * 2015-05-23 2016-11-24 Cisco Technology, Inc. Determining Connections of Non-External Network Facing Ports
CN109831318A (zh) * 2018-12-26 2019-05-31 中兴通讯股份有限公司 一种获取网络拓扑的系统、方法和服务器

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1756189B (zh) * 2004-09-30 2010-04-14 北京航空航天大学 基于snmp的ip网络拓扑发现方法
US8621057B2 (en) * 2011-03-07 2013-12-31 International Business Machines Corporation Establishing relationships among elements in a computing system
CN104468219B (zh) * 2014-12-11 2019-01-08 新华三技术有限公司 虚拟组网网络拓扑发现方法和设备
CN104618246A (zh) * 2015-02-12 2015-05-13 浪潮电子信息产业股份有限公司 一种面向xen虚拟化环境的网络拓扑发现方法
US10630557B2 (en) * 2015-10-19 2020-04-21 Nicira, Inc. Virtual network management
CN107659423A (zh) * 2016-07-25 2018-02-02 南京中兴新软件有限责任公司 业务处理方法及装置
CN106713042B (zh) * 2016-12-29 2020-05-26 中国银联股份有限公司 一种确定网络拓扑方法及装置
US10462013B2 (en) * 2017-02-13 2019-10-29 Oracle International Corporation Implementing a single-addressable virtual topology element in a virtual topology
US10484265B2 (en) * 2017-04-27 2019-11-19 At&T Intellectual Property I, L.P. Dynamic update of virtual network topology

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103036703A (zh) * 2011-10-04 2013-04-10 株式会社日立制作所 虚拟网络的逻辑拓扑的结构管理方法以及管理服务器
CN103516754A (zh) * 2012-06-27 2014-01-15 中兴通讯股份有限公司 一种将物理网络向虚拟网络迁移的方法及装置
CN103281248A (zh) * 2013-06-09 2013-09-04 北京星网锐捷网络技术有限公司 网络拓扑的发现方法、装置和系统
US20160344591A1 (en) * 2015-05-23 2016-11-24 Cisco Technology, Inc. Determining Connections of Non-External Network Facing Ports
CN109831318A (zh) * 2018-12-26 2019-05-31 中兴通讯股份有限公司 一种获取网络拓扑的系统、方法和服务器

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3905590A4 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114553707A (zh) * 2020-11-26 2022-05-27 腾讯科技（深圳）有限公司 网络的拓扑信息的生成和网络故障的定界方法、装置
CN114553707B (zh) * 2020-11-26 2023-09-15 腾讯科技（深圳）有限公司 网络的拓扑信息的生成和网络故障的定界方法、装置
CN113364628A (zh) * 2021-06-11 2021-09-07 上海中通吉网络技术有限公司 服务器与交换机拓扑关系建立方法及设备
CN113794732A (zh) * 2021-09-22 2021-12-14 上海观安信息技术股份有限公司 一种部署仿真网络环境的方法、装置、设备及存储介质
CN114422374A (zh) * 2022-03-22 2022-04-29 南京赛宁信息技术有限公司 一种靶场场景拓扑解析、初始化、回收方法及系统
CN116094938A (zh) * 2023-01-16 2023-05-09 紫光云技术有限公司 基于kafka的网络拓扑同步方法、设备、服务器及存储介质
CN116094938B (zh) * 2023-01-16 2024-04-19 紫光云技术有限公司 基于kafka的网络拓扑同步方法、设备、服务器及存储介质

Also Published As

Publication number Publication date
EP3905590A1 (en) 2021-11-03
CN109831318A (zh) 2019-05-31
EP3905590A4 (en) 2022-09-14

Similar Documents

Publication Publication Date Title
WO2020135575A1 (zh) 一种获取网络拓扑的系统、方法和服务器
CN110247784B (zh) 确定网络拓扑结构的方法和装置
WO2021203623A1 (zh) 一种物联网资源接入系统及资源接入方法
US20180173557A1 (en) Physical path determination for virtual network packet flows
US8549119B1 (en) Error handling for device management configuration and operational data retrieval commands
US8898265B2 (en) Determining data flows in a network
CN110659109B (zh) 一种openstack集群虚拟机监控系统及方法
CN111543038A (zh) 使用中间设备流拼接的网络流拼接
WO2018049966A1 (zh) 视频监控系统的控制方法、装置及系统
EP3844911B1 (en) Systems and methods for generating network flow information
US20150331777A1 (en) System and method of generating data center alarms for missing events
CN114024880B (zh) 基于代理ip与流表的网络靶场探针采集方法与系统
WO2023056722A1 (zh) 一种分布式防火墙定义方法及系统
CN114389792B (zh) 一种web日志nat前后关联方法及系统
US20210409294A1 (en) Application flow monitoring
CN113067810B (zh) 网络抓包方法、装置、设备和介质
WO2016187967A1 (zh) 一种实现日志传输的方法及装置
US8489727B2 (en) Active storage area network discovery system and method
EP3952212B1 (en) Using a programmable resource dependency mathematical model to perform root cause analysis
JP7228712B2 (ja) 異常ホストのモニタニング
US11146468B1 (en) Intelligent export of network information
US10904123B2 (en) Trace routing in virtual networks
US10887204B2 (en) Network infrastructure management
WO2016184025A1 (zh) 一种设备管理方法和装置
Zhou et al. Discovery algorithm for network topology based on SNMP

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19905178

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019905178

Country of ref document: EP

Effective date: 20210726