Systems and methods for extending link layer discovery over virtual Ethernet bridges

In accordance with embodiments of the present disclosure, an information handling system may include a host system comprising a host system processor and a network interface coupled to the host system processor and may include a management controller communicatively coupled to the host system processor and configured to provide management of the information handling system. The network interface may be configured to capture discovery protocol packets and encode the discovery protocol packets with extended discovery protocol information comprising information regarding physical functions, virtual functions, and ports associated with the discovery protocol packets.

TECHNICAL FIELD

The present disclosure relates in general to information handling systems, and more particularly to methods and systems for extending link layer discovery over virtual Ethernet bridges.

BACKGROUND

Virtualization, wherein actual physical components are emulated to a computing device, is often used in information handling systems. For example, single root input/output virtualization (SR-IOV) is a technique that allows the isolation of PCI Express (PCIe) resources for manageability and performance reasons. Using SR-IOV, a single physical PCIe device may be shared on a virtualized computing environment. SR-IOV offers different virtual functions to different virtual components (e.g., a network adapter) on a physical server machine. Thus, SR-IOV allows different virtual machines in a virtualized computing environment to share a single PCIe hardware interface.

Virtual Ethernet Bridge (VEB) is defined in Institute of Electrical and Electronics Engineers (IEEE) standard 802.1Qbg-2012 and incorporated into IEEE standard 802.1Q-2014. A VEB must filter reserved Media Access Control (MAC) addresses used for Link Layer Discover Protocol (LLDP). An SR-IOV network interface card may include an embedded switch (eSwitch) that acts as an Edge Relay (ER) that may act as VEB. Accordingly, when SR-IOV is used for virtualization, the network edge exists at a Virtual Ethernet Bridge (VEB) inside a network interface (e.g., a network interface card) of an information handling system. A VEB is intended to act like a dumb switch. For example, a VEB does not implement Link Layer Discover Protocol (LLDP) and Simple Network Management Protocol (SNMP) like a typical managed switch, and thus a management console that attempts to discover a network topology may not be able to see beyond the VEB. In addition, a host operating system/hypervisor attached to physical functions (PFs) and guest operating system/virtual machines attached to virtual functions (VFs) normally cannot transmit LLDP messages through a VEB and a VEB does not collect this information. However, knowledge by a management console regarding where a virtual machine exists within a network topology may be useful to limit outages and balance port usage.

SUMMARY

In accordance with the teachings of the present disclosure, the disadvantages and problems associated with existing approaches for link layer discovery may be reduced or eliminated.

In accordance with embodiments of the present disclosure, an information handling system may include a host system comprising a host system processor and a network interface coupled to the host system processor and may include a management controller communicatively coupled to the host system processor and configured to provide management of the information handling system. The network interface may be configured to capture discovery protocol packets and encode the discovery protocol packets with extended discovery protocol information comprising information regarding physical functions, virtual functions, and ports associated with the discovery protocol packets.

In accordance with these and other embodiments of the present disclosure, a method may include, in an information handling system comprising a host system including a host system processor and a network interface coupled to the host system processor and comprising a management controller communicatively coupled to the host system processor and configured to provide management of the information handling system: capturing, by the network interface, discovery protocol packets, and encoding, by the network interface, the discovery protocol packets with extended discovery protocol information comprising information regarding physical functions, virtual functions, and ports associated with the discovery protocol packets.

In accordance with these and other embodiments of the present disclosure, an article of manufacture may include a non-transitory computer-readable medium and computer-executable instructions carried on the computer-readable medium, the instructions readable by a processor, the instructions, when read and executed, for causing the processor to, in an information handling system comprising a host system including a host system processor and a network interface coupled to the host system processor and comprising a management controller communicatively coupled to the host system processor and configured to provide management of the information handling system: capture, by the network interface, discovery protocol packets, and encode, by the network interface, the discovery protocol packets with extended discovery protocol information comprising information regarding physical functions, virtual functions, and ports associated with the discovery protocol packets.

DETAILED DESCRIPTION

Preferred embodiments and their advantages are best understood by reference toFIGS. 1 through 5, wherein like numbers are used to indicate like and corresponding parts.

FIG. 1illustrates a block diagram of an example information handling system102, in accordance with embodiments of the present disclosure. In some embodiments, information handling system102may comprise a personal computer. In some embodiments, information handling system102may comprise or be an integral part of a server. In other embodiments, information handling system102may comprise a portable information handling system (e.g., a laptop, notebook, tablet, handheld, smart phone, personal digital assistant, etc.). As depicted inFIG. 1, information handling system102may include a processor103, a memory104communicatively coupled to processor103, a BIOS105communicatively coupled to processor103, a network interface108communicatively coupled to processor103, and a management controller112communicatively coupled to processor103. As also shown inFIG. 1, a switch109may ommunicatively coupled to network interface108via a network link120. In operation, processor103, memory104, BIOS105, and network interface108may comprise at least a portion of a host system98of information handling system102. For purposes of clarity and exposition, information handling system102has been depicted to comprise only a single host system98. In some embodiments, information handling system102may comprise a plurality of host systems98.

As shown inFIG. 1, a memory104may have stored thereon a hypervisor106and one or more guest operating systems (OS)107. In some embodiments, hypervisor106and one or more of guest OSes107may be stored in a computer-readable medium (e.g., a local or remote hard disk drive) other than a memory104which is accessible to processor102.

A hypervisor106may comprise software and/or firmware generally operable to allow multiple virtual machines and/or operating systems to run on a single computing system (e.g., an information handling system102) at the same time. This operability is generally allowed via virtualization, a technique for hiding the physical characteristics of computing system resources (e.g., physical hardware of the computing system) from the way in which other systems, applications, or end users interact with those resources. A hypervisor106may be one of a variety of proprietary and/or commercially available virtualization platforms, including without limitation, VIRTUALLOGIX VLX FOR EMBEDDED SYSTEMS, IBM's Z/VM, XEN, ORACLE VM, VMWARE's ESX SERVER, L4 MICROKERNEL, TRANGO, MICROSOFT's HYPER-V, SUN's LOGICAL DOMAINS, HITACHI's VIRTAGE, KVM, VMWARE SERVER, VMWARE WORKSTATION, VMWARE FUSION, QEMU, MICROSOFT's VIRTUAL PC and VIRTUAL SERVER, INNOTEK's VIRTUALBOX, and SWSOFT's PARALLELS WORKSTATION and PARALLELS DESKTOP.

In some embodiments, a hypervisor106may comprise a specially-designed OS with native virtualization capabilities. In another embodiment, a hypervisor106may comprise a standard OS with an incorporated virtualization component for performing virtualization.

In other embodiments, a hypervisor106may comprise a standard OS running alongside a separate virtualization application. In such embodiments, the virtualization application of the hypervisor106may be an application running above the OS and interacting with computing system resources only through the OS. Alternatively, the virtualization application of a hypervisor106may, on some levels, interact indirectly with computing system resources via the OS, and, on other levels, interact directly with computing system resources (e.g., similar to the way the OS interacts directly with computing system resources, or as firmware running on computing system resources). As a further alternative, the virtualization application of a hypervisor106may, on all levels, interact directly with computing system resources (e.g., similar to the way the OS interacts directly with computing system resources, or as firmware running on computing system resources) without utilizing the OS, although still interacting with the OS to coordinate use of computing system resources.

As stated above, a hypervisor106may instantiate one or more virtual machines. A virtual machine may comprise any program of executable instructions, or aggregation of programs of executable instructions, configured to execute a guest OS107in order to act through or in connection with a hypervisor106to manage and/or control the allocation and usage of hardware resources such as memory, CPU time, disk space, and input and output devices, and provide an interface between such hardware resources and application programs hosted by the guest OS107. In some embodiments, a guest OS107may be a general-purpose OS such as WINDOWS or LINUX, for example. In other embodiments, a guest OS107may comprise a specific- and/or limited-purpose OS, configured so as to perform application-specific functionality (e.g., persistent storage).

A BIOS105may include any system, device, or apparatus configured to identify, test, and/or initialize information handling resources of information handling system102, and/or initialize interoperation of information handling system102with other information handling systems. “BIOS” may broadly refer to any system, device, or apparatus configured to perform such functionality, including without limitation, a Unified Extensible Firmware Interface (UEFI). In some embodiments, BIOS105may be implemented as a program of instructions that may be read by and executed on processor103to carry out the functionality of BIOS105. In these and other embodiments, BIOS105may comprise boot firmware configured to be the first code executed by processor103when information handling system102is booted and/or powered on. As part of its initialization functionality, code for BIOS105may be configured to set components of information handling system102into a known state, so that one or more applications (e.g., an operating system or other application programs) stored on compatible media (e.g., disk drives) may be executed by processor103and given control of information handling system102.

Network interface108may comprise any suitable system, apparatus, or device operable to serve as an interface between information handling system102and one or more other information handling systems via a network. Network interface108may enable information handling system102to communicate using any suitable transmission protocol and/or standard. In these and other embodiments, network interface108may comprise a network interface card, or “NIC.” In these and other embodiments, network interface108may be enabled as a local area network (LAN)-on-motherboard (LOM) card. In these and other embodiments, processor103and network interface108may be coupled via any suitable interface, including without limitation a Peripheral Component Interconnect Express (PCIe) bus/interface.

As shown inFIG. 1, network interface108may have stored thereon firmware111. Firmware111may comprise any program of executable instructions, or collection of such programs, configured to, when executed, carry out the functionality of network interface108as described in more detail herein.

Switch109may be communicatively coupled between network interface108and a network external to information handling system102, and may comprise any system, device, or apparatus configured to route communications between network interface108and the external network. In some embodiments, switch109may comprise a “top of rack” switch or similar device. Such management network may couple to a management console and/or other device whereby an administrator may manage information handling system102via network interface108and/or management controller112.

Management controller112may be configured to provide management facilities for management of information handling system102. Such management may be made by management controller112even if information handling system102is powered off or powered to a standby state. Management controller112may include a processor113, memory114, and a network interface118separate from and physically isolated from network interface108. In certain embodiments, management controller112may include or may be an integral part of a baseboard management controller (BMC) or a remote access controller (e.g., a Dell Remote Access Controller or Integrated Dell Remote Access Controller).

Processor113may include any system, device, or apparatus configured to interpret and/or execute program instructions and/or process data, and may include, without limitation, a microprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), or any other digital or analog circuitry configured to interpret and/or execute program instructions and/or process data. In some embodiments, processor113may interpret and/or execute program instructions and/or process data stored in memory114and/or another component of information handling system102or management controller112. As shown inFIG. 1, processor113may be communicatively coupled to processor103. Such coupling may be via a Universal Serial Bus (USB), System Management Bus (SMBus), Peripheral Component Interconnect Express (PCIe) bus, and/or one or more other communications channels.

Memory114may be communicatively coupled to processor113and may include any system, device, or apparatus configured to retain program instructions and/or data for a period of time (e.g., computer-readable media). Memory114may include RAM, EEPROM, a PCMCIA card, flash memory, magnetic storage, opto-magnetic storage, or any suitable selection and/or array of volatile or non-volatile memory that retains data after power to management controller112is turned off.

As shown inFIG. 1, network interface108may have stored thereon firmware117. Firmware117may comprise any program of executable instructions, or collection of such programs, configured to, when executed, carry out the functionality of management controller112as described in more detail herein.

Network interface118may comprise any suitable system, apparatus, or device operable to serve as an interface between management controller112and one or more other information handling systems via a network. Network interface118may enable management controller112to communicate using any suitable transmission protocol and/or standard. In these and other embodiments, network interface118may comprise a network interface card, or “NIC.”

In addition to processor103, memory104, network interface108, and management controller112, information handling system102may include one or more other information handling resources.

FIG. 2illustrates an architectural functional block diagram of selected components of information handling system102, in accordance with embodiments of the present disclosure. As shown inFIG. 2, each of hypervisor106and a guest OS107may execute a Link Layer Discovery Protocol (LLDP) daemon202. An LLDP daemon202may comprise any background process that may execute in connection with hypervisor106or guest OS107to perform tasks related to carrying out LLDP operations on hypervisor106or guest OS107.

Also as shown inFIG. 2, hypervisor106may be attached to a physical function204and guest OS107may be attached to a virtual function206. A device (e.g., network interface108) which has been virtualized may be accessed by two or more virtual functions206, which allows the sharing of the resource. A physical function204representing an information handling resource may be provided to a single operating system (e.g., hypervisor106). Multiple instances of a virtual function206may be provided to multiple operating systems (e.g., guest OSes107). If, for example, multiple operating systems are sharing a device, then access to such device may be divided into multiple virtual functions (e.g., divided into multiple network interfaces using virtual functions), each of which may be mapped to their respective guest OS107.

Physical function204and virtual function206may interact with firmware111of network interface108as shown inFIG. 2and as also described in greater detail below.

Network interface108may couple to switch109via a port208of network interface108, and switch109may in turn couple to network222.

As shown inFIG. 2, firmware117of management controller112may execute a kernel210, a virtual Ethernet bridge daemon214, an LLDP daemon216, and a Simple Network Management Protocol (SNMP) daemon218. Kernel210may include a Network Controller Sideband Interface (NC-SI) driver212and a plurality of tap interfaces including at least a tap interface224(TapPF0) for physical function204, a tap interface226(TapVF0) for a virtual function206, and a tap interface228(TapP0) for port208. As known in the art, a tap interface is a feature present in by an operating system (e.g., Linux and/or other UNIX-like operating systems) that may perform user space networking, which may allow user space programs to see raw network traffic (at the Ethernet or Internet Protocol level) and act on such traffic. A virtual private network (VPN) is an example of a tap interface.

VEB daemon214may comprise any background process that may execute to perform tasks related to carrying out VEB operations on management controller112, as described in greater detail herein. LLDP daemon216may comprise any background process that may execute to perform tasks related to carrying out LLDP operations on management controller112. SNMP daemon218may comprise any background process that may execute to perform tasks related to carrying out SNMP operations on management controller112.

In operation, firmware111of network interface108may be configured to encapsulate all LLDP packets sent from guest OS virtual functions206, hypervisor physical functions204, and switch109, and directs all LLDP packets to VEB daemon214via NC-SI. Such encapsulation may include extended LLDP information on how the packet came into network interface108(e.g., physical function, virtual function, or port via which the packet entered network interface108). Firmware111and VEB daemon214may use any appropriate encoding or encapsulation to communicate, including without limitation Distributed Switch Architecture (DSA) as shown inFIG. 2, or other encoding such as virtual local area network (VLAN) encoding or Ethernet encoding. VEB daemon214may unpack the encapsulated packets and route the packets to tap interfaces224,226, and228, as appropriate, based on the extended LLDP information present in the packet encapsulation.

Using the tap interfaces224,226,228, LLDP daemon216and SNMP daemon218may be used to provide neighbor information to network222. For example, LLDP daemon216may process the LLDP packets it receives on the tap interfaces224,226, and228and LLDP daemon may also send LLDP information including the management controller unique address (e.g., Internet Protocol address) and tap interface identifier on each tap interface224,226, and228.

VEB daemon214may also read packets received on all the tap interfaces224,226, and228and may encapsulate the packets with extended LLDP information to direct them to the correct physical function, virtual functions, or external port based on the tap. Firwmare111(which may comprise specially modified or adapted firmware) may decode the encapsulated packets received from VEB daemon214and forward such LLDP packets based on the extended LLDP information of the encapsulation. In this way, LLDP daemon216of management controller112may communicate unique LLDP information to each physical function, virtual function, and external port (e.g., port208). One use of such unique LLDP information is to inform a virtual machine of a guest OS107which virtual function it is associated with so that it can obtain device physical port information.

To further illustrate the advantages of the systems and methods described herein, LLDP may comprise one-directional communication and the packets sent to each virtual function, physical function, and port may need to be different. However, even though the contents of the LLDP packets are different the destination MAC address may always be the same. Firmware111may be advantageously useful as it may allow management controller112to send packets that all have the same destination MAC address over a common link between management controller112and network interface108and have network interface108forward the packet to a specific port based not on destination MAC but based on the port assignment in the encapsulation. In other words, if firmware111did not encode LLDP packets it receives with port information before sending it to management controller112, management controller112would not be able to distinguish which virtual function, physical function, or port the LLDP packet arrived on.

FIG. 3illustrates a flow diagram of processing for incoming LLDP traffic, in accordance with embodiments of the present disclosure. In particular,FIG. 3illustrates LLDP traffic entering network interface108via hypervisor106(e.g., at operation301), guest OS107(e.g., at operation304) and switch109(e.g., at operation307), respectively. All incoming LLDP may be captured but not forwarded by network interface108. Instead, firmware111may encapsulate/encode the captured LLDP packets with extended LLDP information (e.g., with DSA tags) and send such encapsulated LLDP packets to VEB daemon214(e.g., operations302,305, and308). VEB daemon214may decode the encapsulated LLDP packets and send the decoded packets to an appropriate tap interface224,226, and228based on the extended LLDP information (e.g., present in the DSA tags) (e.g., operations303,306, and309). LLDP daemon216may receive each LLDP packet from tap interfaces224,226, and228and populates a neighbor information table based on the respective tap interface224,226, or228associated with the LLDP packet.

FIG. 4illustrates a flow diagram of processing for outgoing LLDP traffic, in accordance with embodiments of the present disclosure. In other words,FIG. 4illustrates processing of LLDP packets generated at management controller112for physical functions, virtual functions, and switch109. In operation, LLDP daemon216may send different LLDP packets on each tap interface224,226, and228(e.g., operations401,404, and407). The packets may be sent to different tap interfaces224,226, and228because an identifier of the tap interface to which the LLDP packets are being sent may be included within the LDDP packets themselves. VEB daemon214may receive the LLDP packets from the various tap interfaces224,226, and228and encode the LLDP packets based on the tap interface on which each LLDP packet was received by VEB daemon214(e.g., operations402,405, and408). Accordingly, there may be a one-to-one mapping of tap interfaces224,226, and228to physical functions, virtual functions, and ports. Firmware111of network interface108may decode the encapsulated LLDP packets and communicate each packet to the appropriate physical function, virtual function, or port based on the extended LLDP information (e.g., operations403,406, and409).

FIG. 5illustrates a flow diagram of a process for gathering information regarding virtual machines coupled to single root input/output virtualization connections, in accordance with embodiments of the present disclosure. One of the type-length-value encodings sent by management controller112in an outgoing LLDP packet received by switch109may be the unique address (e.g., Internet Protocol address) of management controller112. When a user performs network discovery, the standard procedure is to start at a known location in a network and retrieve management unique identifiers for addresses of all the neighbors and recursively query neighbors, neighbor's neighbors, and so on to complete network discovery. Accordingly, operations such as operations501-507shown inFIG. 5may be performed to gather information regarding virtual machines coupled to single root input/output virtualization connections using existing approaches to network discovery.