Lldp neighbor information processing method, device and equipment and storage medium

Abstract

The application provides a kind of LLDP neighbor information processing method, device, equipment and storage medium, related to communication technical field.The method comprises: when information receiving thread is in starting state, receiving the link layer discovery protocol (LLDP) neighbor message sent by neighbor device;Wherein, the interface link information of neighbor device is included in the LLDP neighbor message;According to the configuration of network card interface, the LLDP neighbor message is uploaded to LLDP kernel protocol stack.The method of the application does not consider the difference of scene, and the LLDP neighbor message sent by neighbor device is uploaded to LLDP kernel protocol stack by unified configuration, so that the LLDP kernel process can continue to process the LLDP neighbor message, and finally the administrator can query all neighbor information, so that the user can faster and better network management and maintenance.

Description

LLDP Neighbor Information Processing Method, Apparatus, Equipment and Storage Medium Technical Field

[0001] This application relates to the field of communication technology, and in particular to an LLDP neighbor information processing method, apparatus, device and storage medium. Background Technology

[0002] In the context of cloud operations, operations and maintenance personnel and network administrators typically need to view the interface link information between various network cards on the server side and the switch side in order to better query and judge the communication status of the links, thereby performing network management.

[0003] In existing technologies, interface link information between network interface cards (NICs) is typically implemented based on the Link Layer Discovery Protocol (LLDP). LLDP, as a slow, one-way information announcement protocol, can broadcast its own link information to neighboring devices. However, in special scenarios such as the Open vSwitch DPDK environment and the Open vSwitch DPDK smart NIC hardware offloading environment from specific vendors, due to their own special configurations, LLDP protocol messages sent from the switch to the compute node cannot be sent back to the kernel protocol stack. This prevents the LLDP kernel process running on the server from obtaining and processing this neighbor information. Ultimately, network administrators and maintenance personnel cannot query neighbor information via command line, and therefore cannot query or determine the communication status of the links, which hinders network management.

[0004] Therefore, a new LLDP neighbor information processing method is urgently needed to solve the above problems. Summary of the Invention

[0005] This application provides an LLDP neighbor information processing method, apparatus, device, and storage medium to solve technical problems such as the inability to send LLDP protocol messages from the switch to the computing node back to the kernel protocol stack and the inconsistency of the carriers used to send LLDP messages from the computing node to the outside world.

[0006] Firstly, this application provides a method for processing Link Layer Discovery Protocol (LLDP) neighbor information, including:

[0007] When the information receiving thread is in the started state, it receives Link Layer Discovery Protocol (LLDP) neighbor messages sent by neighboring devices; wherein, the LLDP neighbor message includes the interface link information of the neighboring devices;

[0008] According to the network interface configuration, the LLDP neighbor message is sent to the LLDP kernel protocol stack.

[0009] Optionally, according to the method described above, the LLDP neighbor packets are sent to the LLDP kernel protocol stack based on the network interface configuration, including:

[0010] Based on the connection status between the network card interface and the bridge device, determine the uplink path of the LLDP neighbor message;

[0011] According to the aforementioned upload path, the LLDP neighbor message is uploaded to the LLDP kernel protocol stack.

[0012] Optionally, the method described above, determining the uplink path of the LLDP neighbor packet based on the connection status between the network card interface and the bridge device, includes:

[0013] Determine the connection status between the network interface card (NIC) and the bridge device. If it is determined that the NIC is connected to the bridge device, then determine the uplink path of the LLDP neighbor packet as the first path; wherein, the first path passes through the NIC, the bridge device, and the virtual switching process in sequence.

[0014] If it is determined that the network interface card is not connected to the bridge device, then the uplink path of the LLDP neighbor message is determined to be the second path; wherein, the second path passes only through the network interface card.

[0015] Optionally, in the method described above, when the network interface is connected to the bridge device, before sending the LLDP neighbor packet to the LLDP kernel protocol stack according to the uplink path, the method further includes:

[0016] Determine the LLDP enabled state and local LLDP state of the network interface card. If it is determined that the network interface card is in the LLDP enabled state and the local LLDP state of the network interface card is enabled, then send the LLDP neighbor packet to the LLDP kernel protocol stack according to the first path.

[0017] Optionally, the method described above further includes:

[0018] If it is determined that the network interface card is in an LLDP disabled state, then the LLDP neighbor packet is discarded;

[0019] If it is determined that the network interface is in an LLDP enabled state, but the local LLDP state of the network interface is not enabled, then the LLDP neighbor packet is read and saved.

[0020] Secondly, this application also provides a method for processing Link Layer Discovery Protocol (LLDP) neighbor information, including:

[0021] When the information sending thread is in the started state, if it is determined that all network card interfaces are connected to the bridge device, the virtual switching process will uniformly send its own LLDP neighbor messages to the neighbor devices.

[0022] If it is determined that there is a network interface card that is not connected to the bridge device, then the LLDP kernel process will send its own LLDP neighbor messages to the neighboring devices.

[0023] Optionally, in the method described above, when it is determined that there is a network interface card interface that is not connected to the bridge device, the attribute value of the transmit control field of the network interface card interface that is connected to the bridge device is configured to be off.

[0024] Thirdly, this application provides a Link Layer Discovery Protocol (LLDP) neighbor information processing apparatus, comprising:

[0025] The receiving unit is used to receive Link Layer Discovery Protocol (LLDP) neighbor messages sent by neighboring devices when the information receiving thread is in the started state; wherein, the LLDP neighbor message includes the interface link information of the neighboring device;

[0026] The uploading unit is used to upload the LLDP neighbor packets to the LLDP kernel protocol stack according to the configuration of the network card interface.

[0027] Fourthly, this application also provides a Link Layer Discovery Protocol (LLDP) neighbor information processing apparatus, comprising:

[0028] The first sending unit is used to send its own LLDP neighbor messages to neighbor devices by the virtual switching process when the information sending thread is in the started state, provided that all network card interfaces are connected to the bridge device.

[0029] The second sending unit is used to send its own LLDP neighbor messages to neighboring devices by the LLDP kernel process if it is determined that there is a network card interface that is not connected to the bridge device.

[0030] Fifthly, this application provides an electronic device, the electronic device comprising: a processor, and a memory communicatively connected to the processor;

[0031] The memory stores computer-executed instructions;

[0032] The processor executes computer execution instructions stored in the memory to implement the method described above.

[0033] Sixthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described above.

[0034] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, is used to implement the method described above.

[0035] This application provides an LLDP neighbor information processing method, apparatus, device, and storage medium, comprising: receiving LLDP neighbor messages sent by neighboring devices when the information receiving thread is in the started state; wherein the LLDP neighbor messages include interface link information of the neighboring devices; and uploading the LLDP neighbor messages to the LLDP kernel protocol stack according to the network interface configuration. The method of this application, regardless of scenario differences, uniformly uploads all LLDP neighbor messages sent by neighboring devices to the LLDP kernel protocol stack through configuration, thereby allowing the LLDP kernel process to continue processing LLDP neighbor messages, and ultimately enabling administrators to query all neighbor information, so that users can perform network management and maintenance more quickly and effectively. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0037] Figure 1 is a schematic diagram of the transmission path of LLDP neighbor packets in a kernel-mode virtual switch environment provided in an embodiment of this application;

[0038] Figure 2 is a schematic diagram of the transmission path of LLDP neighbor packets in a virtual switch DPDK environment provided by an embodiment of this application;

[0039] Figure 3 is a schematic diagram of the transmission path of LLDP neighbor packets in a hardware offloading environment of a specific vendor's virtual switch DPDK smart network card, provided by an embodiment of this application.

[0040] Figure 4 is a flowchart illustrating a Link Layer Discovery Protocol (LLDP) neighbor information processing method provided in an embodiment of this application.

[0041] Figure 5 is a schematic diagram of the receiving path of LLDP neighbor packets in a virtual switch DPDK environment provided by an embodiment of this application;

[0042] Figure 6 is a schematic diagram of the LLDP neighbor message reception path in a hardware offloading environment of a specific vendor's virtual switch DPDK smart network card provided in an embodiment of this application.

[0043] Figure 7 is a flowchart illustrating another link layer discovery protocol (LLDP) neighbor information processing method provided in an embodiment of this application;

[0044] Figure 8 is a schematic diagram of the transmission path of LLDP neighbor packets in a virtual switch DPDK environment provided by an embodiment of this application;

[0045] Figure 9 is a schematic diagram of the LLDP neighbor message transmission path in a hardware offloading environment of a specific vendor's virtual switch DPDK smart network card, provided by an embodiment of this application.

[0046] Figure 10 is a logical diagram of sending and receiving LLDP neighbor information according to an embodiment of this application;

[0047] Figure 11 is a schematic diagram of a Link Layer Discovery Protocol (LLDP) neighbor information processing device provided in an embodiment of this application.

[0048] Figure 12 is a schematic diagram of another Link Layer Discovery Protocol (LLDP) neighbor information processing device provided in an embodiment of this application.

[0049] Figure 13 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0050] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0051] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0052] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0053] In the context of cloud operations, operations and maintenance personnel and network administrators typically need to view the interconnection interfaces, device names, and other interface link information between various network cards on the server side and the switch side in order to better query and judge the communication status of the links and thus perform network management.

[0054] For example, Figure 1 is a schematic diagram of the transmission path of LLDP neighbor packets in a kernel-mode virtual switch environment provided by an embodiment of this application. As shown in Figure 1, in a kernel-mode virtual switch (Openvswitch) environment, interface link information relies on an additional LLDP kernel process. Specifically, the client's LLDP kernel process can broadcast its own link information to the switch side. When the switch side receives an LLDP neighbor packet sent by the server, it records the neighbor information so that the switch side administrator can query it through relevant command lines. The LLDP kernel process also records the received neighbor information when receiving LLDP neighbor packets broadcast from the switch, and allows the user to query it through relevant command lines via the client. Therefore, in the traditional Openvswitch kernel mode, cloud operations personnel can view the LLDP neighbor information of the compute nodes through relevant command-line interfaces, and can also view the neighbor information sent from the compute nodes on the switch side.

[0055] For example, Figure 2 is a schematic diagram of the LLDP neighbor packet transmission path in a virtual switch DPDK environment provided by an embodiment of this application. As shown in Figure 2, in the Openvswitch DPDK environment, because the network card device is taken over by a non-kernel driver, the LLDP kernel process cannot send and receive LLDP neighbor packets. Therefore, in this scenario, the basic LLDP and AUTOATTACH functions of the virtual switch (Openvswitch) need to be enabled, and the lldpd thread in the virtual switch process (ovs-vswitchd) is responsible for sending and receiving LLDP protocol packets, and neighbor information is queried through the standard command line of the virtual switch (Openvswitch). Since the virtual switch (Openvswitch) does not support querying the peer interface information of physical devices, the query command line only outputs the names of those with LLDP sending enabled, and does not display any other neighbor information. Compared with the output of the scenario shown in Figure 1, the output information is very limited. In addition, the virtual switch (Openvswitch) passes the received LLDP protocol messages to the internal lldpd thread. After processing some information, the thread discards the message. Since the LLDP protocol message can no longer be sent back to the kernel protocol stack, any LLDP client running on a Linux system will be unable to obtain the neighbor information of the peer of the interface (usually the switch and its interface).

[0056] For example, Figure 3 is a schematic diagram of the LLDP neighbor packet transmission path in a hardware offloading environment of a specific vendor's Openvswitch DPDK smart NIC, provided by an embodiment of this application. As shown in Figure 3, in the hardware offloading environment of a specific vendor's Openvswitch DPDK smart NIC, there are some special configurations: NICs Nic1 and Nic2 are configured with bonds (kernel configuration or RDMA hardware configuration), and NIC Nic1 is added to the OVS bridge, while NIC Nic2 is not added to the OVS bridge, and NIC Nic2 is visible in the kernel protocol stack. In this scenario, after enabling the native basic LLDP function of the virtual switch (Openvswitch), all the problems shown in Figure 2 still exist. Furthermore, when only the native basic LLDP function of the virtual switch (Openvswitch) is enabled, the switch side can only receive LLDP neighbor information sent by Bond sub-interface Nic1, while Bond sub-interface Nic2 cannot send or receive LLDP neighbor information through any process or thread. If only the LLDP kernel process is started, the switch side can only receive LLDP neighbor information sent by Nic2. When the native basic LLDP function of the virtual switch (Openvswitch) is enabled and the LLDP kernel process is started, although the switch side can receive neighbor information from both Bond sub-interfaces Nic1 and Nic2, the neighbor information sent back by the switch to network card Nic1 still only outputs a small amount of information. The lldpd thread of the virtual switch process does not process the neighbor information sent back to network card Nic2 and will directly discard it without sending it to the kernel protocol stack, causing the LLDP kernel process to be unable to process the neighbor packets received by Nic2.

[0057] In summary, the following common problems exist in the scenarios shown in Figures 2 and 3: (1) There are cases where LLDP protocol messages sent from the switch to the compute node cannot be sent back to the kernel protocol stack. This causes the LLDP kernel process running on the server to be unable to process and obtain this part of the neighbor information, and ultimately cannot query this part of the neighbor information through the command line; (2) The carriers for sending LLDP messages from the compute node to the outside are not uniform. Some are sent by the LLDP kernel process and some are sent by the virtual switch process, which makes management inconvenient.

[0058] To address the aforementioned issues, this application provides a Link Layer Discovery Protocol (LLDP) neighbor information processing method. This method, regardless of scenario differences, uniformly uploads all LLDP neighbor packets sent by the switch to the kernel protocol stack. This allows the LLDP kernel process to continue processing LLDP neighbor packets, ultimately enabling administrators to query all neighbor information. Furthermore, this application includes configuration options to either uniformly send LLDP neighbor packets via the LLDP kernel process or uniformly send LLDP neighbor packets via the virtual switch process. This allows operations and maintenance personnel and network administrators to query interface link information such as interconnection interfaces and device names between network cards on the server and switch sides via relevant command lines, enabling faster and better network management and maintenance.

[0059] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0060] Figure 4 is a flowchart illustrating a Link Layer Discovery Protocol (LLDP) neighbor information processing method provided in an embodiment of this application. The executing entity in this embodiment can be an LLDP neighbor information processing device, which can be located on an electronic device, such as a server or server cluster; this application does not impose any limitations. This embodiment uses an LLDP neighbor information processing device as an example for detailed explanation.

[0061] As shown in Figure 4, the Link Layer Discovery Protocol (LLDP) neighbor information processing method provided in this embodiment includes:

[0062] S401. When the information receiving thread is in the started state, it receives Link Layer Discovery Protocol (LLDP) neighbor messages sent by neighboring devices; wherein, the LLDP neighbor message includes the interface link information of the neighboring devices.

[0063] For example, in this application, the server and the switch are neighboring devices. When the information receiving thread in the compute node is started, the compute node, i.e., the server, can receive Link Layer Discovery Protocol (LLDP) neighbor messages sent by the neighboring device (usually a switch). The LLDP neighbor message includes the neighboring device's own interface link information, such as the interconnection interface between network cards, device name, management address, device identifier, and interface identifier. Based on this information, the devices in the network topology can be clearly identified, enabling better network management.

[0064] S402. Based on the network card interface configuration, send the LLDP neighbor message to the LLDP kernel protocol stack.

[0065] For example, in this application, on the host side (compute node), regardless of scenario differences, all LLDP neighbor messages sent by neighboring devices are uniformly sent to the LLDP kernel protocol stack. In this way, the traditional LLDP kernel process can continue to process LLDP neighbor messages without changing its operation and maintenance query method. Operation and maintenance personnel and network administrators can query the LLDP neighbor information on the server side and switch side through relevant command lines, so as to perform network management and maintenance faster and better.

[0066] For example, when uploading LLDP neighbor packets to the LLDP kernel protocol stack, the specific uploading path varies depending on the network interface configuration. In one example, uploading LLDP neighbor packets to the LLDP kernel protocol stack, based on the network interface configuration, may include:

[0067] S1. Determine the uplink path for LLDP neighbor messages based on the connection status between the network card interface and the bridge device.

[0068] S2. Following the upload path, upload the LLDP neighbor message to the LLDP kernel protocol stack.

[0069] For example, in different scenarios, the network interface card (NIC) configurations differ, and therefore the corresponding upload paths also differ. When uploading LLDP neighbor packets to the LLDP kernel protocol stack, the upload path for the LLDP neighbor packets can be determined first based on the connection status between the NIC and the bridge device. Then, the LLDP neighbor packets are uploaded to the LLDP kernel protocol stack according to the corresponding upload path for subsequent processing and user querying. The NIC configurations are generally pre-configured. In this application, the configurations of each NIC are pre-set to ensure that LLDP neighbor packets are uploaded to the LLDP kernel protocol stack according to the corresponding upload path.

[0070] Specifically, determining the uplink path for LLDP neighbor packets based on the connection status between the network interface card and the bridge device can include:

[0071] S11. Determine the connection status between the network card interface and the bridge device. If it is determined that the network card interface is connected to the bridge device, then determine the uplink path of the LLDP neighbor message as the first path. The first path passes through the network card interface, the bridge device, and the virtual switching process in sequence.

[0072] S12. If it is determined that the network card interface is not connected to the bridge device, then the uplink path of the LLDP neighbor message is determined to be the second path; wherein, the second path only passes through the network card interface.

[0073] For example, different uplink paths are selected depending on the connection status between the network interface card (NIC) and the bridge device. If it is determined that the NIC and the bridge device are connected, the first path is selected to send the LLDP neighbor packets to the LLDP kernel protocol stack in sequence through the NIC, the bridge device, and the virtual switching process. If it is determined that the NIC and the bridge device are not connected, the second path is selected to send the LLDP neighbor packets directly to the LLDP kernel protocol stack through only the NIC.

[0074] When a network interface card (NIC) is connected to a bridge device, LLDP neighbor packets are first sent to the virtual switching process. To further send them to the LLDP kernel protocol stack, the NIC needs to be configured to be LLDP enabled (lldp enable = true) and its local LLDP state must be enabled (lldp to_local = true). Therefore, before sending LLDP neighbor packets to the LLDP kernel protocol stack according to the upload path when the NIC is connected to the bridge device, it is necessary to determine the LLDP enabled state and the local LLDP state of the NIC. Only when it is determined that the NIC is LLDP enabled and its local LLDP state is enabled will the LLDP neighbor packets be sent to the LLDP kernel protocol stack according to the first path. If it is determined that the NIC is LLDP disabled, the LLDP neighbor packets are discarded. If it is determined that the NIC is LLDP enabled but its local LLDP state is disabled, the LLDP neighbor packets are read and saved. Accordingly, LLDP neighbor messages can be sent to the LLDP kernel protocol stack as needed for subsequent processing and querying, solving the problem of not being able to query some neighbor information, improving convenience, and making it easier for users to manage and maintain the network.

[0075] For example, Figure 5 is a schematic diagram of the LLDP neighbor packet reception path in a virtual switch DPDK environment provided by an embodiment of this application. As shown in Figure 5, in the Openvswitch DPDK environment, the network interface card (NIC) is bonded to the bridge device, and NIC interfaces Nic1 and Nic2 are both added to the OVS bridge and connected to the bridge device. In this application, NIC interfaces Nic1 and Nic2 are configured to be in an LLDP enabled state, and the local LLDP state of NIC interfaces Nic1 and Nic2 is enabled, so that the LLDP neighbor packets received by NIC interfaces Nic1 and Nic2 are sent to the LLDP kernel protocol stack through the bridge device and the virtual switch process.

[0076] For example, Figure 6 is a schematic diagram of the LLDP neighbor packet reception path in a hardware offloading environment of a specific vendor's virtual switch DPDK smart NIC, provided by an embodiment of this application. As shown in Figure 6, in a specific vendor's OpenVSwitch DPDK smart NIC hardware offloading environment, NIC interfaces Nic1 and Nic2 are configured with bonds. NIC interface Nic1 is added to the OVS bridge, but NIC interface Nic2 is not added to the OVS bridge. NIC interface Nic2 is visible in the kernel protocol stack, that is, NIC interface Nic1 is connected to the bridge device, while NIC interface Nic2 is not connected to the bridge device. Since the LLDP neighbor packets received by NIC interface Nic2 can be directly sent to the LLDP kernel protocol stack, it is only necessary to configure NIC interface Nic1 to be in the LLDP enabled state and the local LLDP state of NIC interface Nic1 to be enabled, so that the LLDP neighbor packets received by NIC interface Nic1 can also be sent to the LLDP kernel protocol stack through the bridge device and the virtual switch process.

[0077] The Link Layer Discovery Protocol (LLDP) neighbor information processing method provided in this application includes: when the information receiving thread is in the started state, receiving LLDP neighbor packets sent by neighboring devices; wherein the LLDP neighbor packets include the interface link information of the neighboring devices; and uploading the LLDP neighbor packets to the LLDP kernel protocol stack according to the network interface configuration. This method, regardless of scenario differences, uniformly uploads all LLDP neighbor packets sent by neighboring devices to the LLDP kernel protocol stack through configuration. This allows the LLDP kernel process to continue processing LLDP neighbor packets, ultimately enabling administrators to query all neighbor information, thus facilitating faster and better network management and maintenance for users.

[0078] Figure 7 is a flowchart illustrating another Link Layer Discovery Protocol (LLDP) neighbor information processing method provided in this embodiment. As shown in Figure 7, the LLDP neighbor information processing method provided in this embodiment includes:

[0079] S701. When the information sending thread is in the started state, if it is determined that all network card interfaces are connected to the bridge device, the virtual switching process will uniformly send its own LLDP neighbor messages to the neighbor devices.

[0080] S702. If it is determined that there is a network card interface that is not connected to the bridge device, then the LLDP kernel process will uniformly send its own LLDP neighbor messages to the neighboring devices.

[0081] For example, due to the configuration differences of various network interface cards (NICs) in different scenarios, even within the same scenario, the carriers for sending LLDP packets from the compute node are not uniform; some are sent by the LLDP kernel process, and some by the virtual switching process, leading to management inconvenience. Therefore, this application adopts different outward transmission paths for different NIC configurations. Specifically, when the information sending thread is in the started state, if it is determined that all NICs are connected to the bridge device, the virtual switching process uniformly sends its own LLDP neighbor packets to neighboring devices. If it is determined that there are NICs not connected to the bridge device, the LLDP kernel process uniformly sends its own LLDP neighbor packets to neighboring devices. When it is determined that there are NICs not connected to the bridge device, the attribute value of the sending control field of the NIC connected to the bridge device must be configured to be disabled.

[0082] For example, Figure 8 is a schematic diagram of the LLDP neighbor packet transmission path in a virtual switch DPDK environment provided by an embodiment of this application. As shown in Figure 8, in the Openvswitch DPDK environment, the network interface card (NIC) is bonded to the bridge device, and NIC interfaces Nic1 and Nic2 are both added to the OVS bridge and connected to the bridge device. Since the NIC is taken over by OVS-DPDK in this scenario, the kernel protocol stack cannot see the taken-over NIC, so the LLDP kernel process cannot send neighbor packets. This scenario does not require special configuration, and the LLDP neighbor packets sent by the compute node to NIC interfaces Nic1 and Nic2 can be uniformly executed by the virtual switch process.

[0083] For example, Figure 9 is a schematic diagram of the LLDP neighbor packet transmission path in a hardware offloading environment of a specific vendor's OpenVS DPDK smart NIC, provided by an embodiment of this application. As shown in Figure 9, in the hardware offloading environment of a specific vendor's OpenVS DPDK smart NIC, NIC interfaces Nic1 and Nic2 are configured with bonds. NIC interface Nic1 is added to the OVS bridge, but NIC interface Nic2 is not added to the OVS bridge. NIC interface Nic2 is visible in the kernel protocol stack, that is, NIC interface Nic1 is connected to the bridge device, while NIC interface Nic2 is not connected to the bridge device. To make the scheme uniform and facilitate management, the attribute value of the send control field (lldp:send_out) of NIC interface Nic1 can be configured to be off (False), so that the lldpd thread of the virtual switch process OVS no longer sends neighbor information externally, but instead controls the LLDP kernel process to start, and the LLDP kernel process uniformly sends its own neighbor information.

[0084] The Link Layer Discovery Protocol (LLDP) neighbor information processing method provided in this application includes: when the information sending thread is in the started state, if it is determined that all network interface cards (NICs) are connected to the bridge device, the virtual switching process uniformly sends its own LLDP neighbor packets to the neighbor devices; if it is determined that there are NICs that are not connected to the bridge device, the LLDP kernel process uniformly sends its own LLDP neighbor packets to the neighbor devices. This method, under different scenario configurations, can configure the LLDP kernel process or the virtual switching process to uniformly send LLDP neighbor packets based on the connection status of all NICs to the bridge device, thus unifying the packet sending carrier and improving management convenience.

[0085] For example, Figure 10 is a logical schematic diagram of sending and receiving LLDP neighbor information provided in an embodiment of this application. As shown in Figure 10, based on the configuration of this application, when the information receiving thread (handles) is in the started state, the network interface receives LLDP neighbor packets sent by neighboring devices. If the network interface is in the LLDP enabled state (lldp enable = true) and the local LLDP state of the network interface is enabled (lldp to_local = true), then the LLDP neighbor packet is sent to the LLDP kernel protocol stack. If the network interface is in the LLDP disabled state (lldp enable = false), then the LLDP neighbor packet is directly discarded. If it is determined that the network interface is in the LLDP enabled state (lldp enable = true), but the local LLDP state of the network interface is not enabled (lldp to_local = false), then the LLDP neighbor packet is read and basic LLDP information is written.

[0086] Furthermore, as shown in Figure 10, when the information sending thread (Monitor) is in the started state, it makes judgments based on the connection status of the network interface and the bridge device to determine whether LLDP neighbor packets are sent externally by the LLDP kernel process or by the virtual switch process. Specifically, if the local LLDP state of the network interface is enabled (lldp to_local = true), it further checks whether the attribute value of the send control field (lldp:send_out) of the network interface is disabled (False). If so, the LLDP kernel process sends its own neighbor information externally. If the network interface is in the LLDP enabled state (lldp enable = true), it further checks whether the attribute value of the send control field (lldp:send_out) of the network interface is enabled (true). If so, the virtual switch process sends its own neighbor information.

[0087] Therefore, when OVS-DPDK can take over all sub-network interfaces of the kernel bond and when OVS-DPDK hardware is unloaded, by configuring the network card's lldp:enable=True / False, lldp:send_out=False / False, and lldp:to_local=True / False, and starting the LLDP kernel process, it is possible to bypass the relevant OVS processing flow and send LLDP neighbor information packets received by the compute node back to the kernel protocol stack, where they are ultimately processed by the LLDP kernel process. This not only prevents the switching from... When LLDP protocol messages sent from the machine side to the compute node can no longer be sent back to the kernel protocol stack, it is possible to view rich neighbor information of the peer switch. In addition, the neighbor information sent out by the compute node is also uniformly handled by the LLDP kernel process or the lldpd thread of OVS, which enables the switch to receive neighbor information sent by multiple bond sub-interfaces, and the neighbor information is not duplicated, thus unifying the transmission carrier of LLDP messages. Operation and maintenance personnel and network administrators can query the interface link information between the network cards on the server side and the switch side through relevant command lines, which improves the convenience of network management and maintenance.

[0088] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0089] Figure 11 is a schematic diagram of a Link Layer Discovery Protocol (LLDP) neighbor information processing device provided in an embodiment of this application. As shown in Figure 11, the LLDP neighbor information processing device 110 provided in this embodiment of the application includes a receiving unit 1101 and an uploading unit 1102.

[0090] The receiving unit 1101 is used to receive Link Layer Discovery Protocol (LLDP) neighbor messages sent by neighboring devices when the information receiving thread is in the started state; wherein, the LLDP neighbor message includes the interface link information of the neighboring device.

[0091] The uploading unit 1102 is used to upload LLDP neighbor packets to the LLDP kernel protocol stack according to the configuration of the network card interface.

[0092] In one example, the uploading unit 1102 includes a determining module 11021 and an uploading module 11022.

[0093] The determination module 11021 is used to determine the uplink path of LLDP neighbor packets based on the connection status between the network card interface and the bridge device.

[0094] The uploading module 11022 is used to upload LLDP neighbor messages to the LLDP kernel protocol stack according to the uploading path.

[0095] In one example, module 11021 is specifically used to determine the connection status between the network interface card (NIC) and the bridge device. If it is determined that the NIC and the bridge device are connected, the uplink path of the LLDP neighbor message is determined to be the first path, which passes through the NIC, the bridge device, and the virtual switching process in sequence. If it is determined that the NIC and the bridge device are not connected, the uplink path of the LLDP neighbor message is determined to be the second path, which passes through the NIC only.

[0096] In one example, module 11021 is also used to determine the LLDP enabled state and local LLDP state of the network interface. If it is determined that the network interface is in the LLDP enabled state and the local LLDP state of the network interface is enabled, then the LLDP neighbor packet is sent to the LLDP kernel protocol stack according to the first path.

[0097] In one example, module 11021 is also configured to discard LLDP neighbor packets if it is determined that the network interface is in an LLDP disabled state; and to read and save LLDP neighbor packets if it is determined that the network interface is in an LLDP enabled state, but the local LLDP state of the network interface is not enabled.

[0098] The apparatus provided in this embodiment can be used to execute the methods of the above embodiments. Its implementation principle and technical effects are similar, and will not be described again here.

[0099] Figure 12 is a schematic diagram of another Link Layer Discovery Protocol (LLDP) neighbor information processing device provided in an embodiment of this application. As shown in Figure 12, the LLDP neighbor information processing device 120 provided in this embodiment of the application includes a first sending unit 1201 and a second sending unit 1202.

[0100] The first sending unit 1201 is used to send its own LLDP neighbor messages to neighbor devices by the virtual switching process when the information sending thread is in the started state, provided that all network card interfaces are connected to the bridge device.

[0101] The second sending unit 1202 is used to send its own LLDP neighbor messages to neighboring devices by the LLDP kernel process if it is determined that there is a network card interface that is not connected to the bridge device.

[0102] In one example, when it is determined that there is a network interface card (NIC) that is not connected to the bridge device, the send control field attribute value of the NIC that is connected to the bridge device is configured to be off.

[0103] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. These modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented in software via processing element calls, while others are implemented in hardware. Furthermore, they can be stored as program code in the device's memory, and the data processing modules can be called and executed by a specific processing element. The implementation of other modules is similar. These modules can be fully or partially integrated together, or implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0104] Figure 13 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. As shown in Figure 13, the electronic device 130 includes: a processor 1301 and a memory 1302 communicatively connected to the processor.

[0105] The memory 1302 stores computer-executable instructions; the processor 1301 executes the computer-executable instructions stored in the memory 1302 to implement the method as described above.

[0106] In the specific implementation of the aforementioned electronic device, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The methods disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0107] This application also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the methods described in any of the foregoing embodiments.

[0108] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to computer instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0109] This application also provides a computer program product, including a computer program that, when executed by a processor, is used to implement the method as described in any of the foregoing embodiments.

[0110] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

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

[0112] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0113] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0114] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0115] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0116] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0117] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0118] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for processing neighbor information in the Link Layer Discovery Protocol (LLDP), characterized in that, The method includes: when the information receiving thread is in the started state, receiving a Link Layer Discovery Protocol (LLDP) neighbor message sent by a neighboring device; wherein the LLDP neighbor message includes the interface link information of the neighboring device; determining the connection status between the network interface card (NIC) and the bridge device; if it is determined that the NIC and the bridge device are connected, then determining the uplink path of the LLDP neighbor message as a first path; wherein the first path passes through the NIC, the bridge device, and the virtual switching process in sequence; if it is determined that the NIC and the bridge device are not connected, then determining the uplink path of the LLDP neighbor message as a second path; wherein the second path passes only through the NIC; and uplinking the LLDP neighbor message to the LLDP kernel protocol stack according to the uplink path.

2. The method according to claim 1, characterized in that, When the network interface card (NIC) is connected to the bridge device, before uploading the LLDP neighbor packet to the LLDP kernel protocol stack according to the uploading path, the method further includes: determining the LLDP enabled state and the local LLDP state of the NIC; if it is determined that the NIC is in the LLDP enabled state and the local LLDP state of the NIC is enabled, then the LLDP neighbor packet is uploaded to the LLDP kernel protocol stack according to the first path.

3. The method according to claim 2, characterized in that, The method further includes: if it is determined that the network interface is in an LLDP disabled state, then the LLDP neighbor packet is discarded; if it is determined that the network interface is in an LLDP enabled state, but the local LLDP state of the network interface is not enabled, then the LLDP neighbor packet is read and saved.

4. A method for processing neighbor information in the Link Layer Discovery Protocol (LLDP), characterized in that, The method includes: when the information sending thread is in the started state, if it is determined that all network card interfaces are connected to the bridge device, then the virtual switching process uniformly sends its own LLDP neighbor messages to the neighboring devices; if it is determined that there are network card interfaces that are not connected to the bridge device, then the LLDP kernel process uniformly sends its own LLDP neighbor messages to the neighboring devices.

5. The method according to claim 4, characterized in that, When it is determined that there is a network interface card interface that is not connected to the bridge device, the attribute value of the transmit control field of the network interface card interface that is connected to the bridge device is configured to be off.

6. A Link Layer Discovery Protocol (LLDP) neighbor information processing device, characterized in that, The apparatus includes: a receiving unit, configured to receive Link Layer Discovery Protocol (LLDP) neighbor messages sent by neighboring devices when the information receiving thread is in an active state; wherein the LLDP neighbor messages include interface link information of the neighboring devices; and an uploading unit, configured to determine the connection status between the network interface card (NIC) and the bridge device; if it is determined that the NIC and the bridge device are connected, the uploading path of the LLDP neighbor messages is determined to be a first path; wherein the first path passes through the NIC, the bridge device, and the virtual switching process in sequence; if it is determined that the NIC and the bridge device are not connected, the uploading path of the LLDP neighbor messages is determined to be a second path; wherein the second path passes only through the NIC; and the LLDP neighbor messages are uploaded to the LLDP kernel protocol stack according to the uploading path.

7. A Link Layer Discovery Protocol (LLDP) neighbor information processing apparatus, characterized in that, The device includes: a first sending unit, configured to, when the information sending thread is in the started state, uniformly send its own LLDP neighbor messages to neighboring devices by the virtual switching process if it is determined that all network interface cards are connected to the bridge device; and a second sending unit, configured to, if it is determined that there are network interface cards that are not connected to the bridge device, uniformly send its own LLDP neighbor messages to neighboring devices by the LLDP kernel process.

8. An electronic device, characterized in that, The electronic device includes: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method as described in any one of claims 1-5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-5.

Images