Abstract:
A technique includes determining a network interface aggregation information for a given network device. Determining the aggregation includes determining whether the network device is capable of providing first data identifying an aggregation and selectively inferring the aggregation based at least in part on other data if a determination is made that the network device is incapable of providing the first data.

Description:
BACKGROUND 
       [0001]    Link aggregation typically has been used to increase the communication bandwidths and fault tolerance capabilities of network devices. With link aggregation, multiple physical links (network cables, for example) between two network devices form a single logical link, or link aggregation group (LAG), which has a larger available bandwidth than any of the individual physical links. Moreover, link aggregation provides for failover, in that should one of the physical links of the LAG fail, communication between the network devices continues using the remaining physical links. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0002]      FIG. 1  is a schematic diagram of a network according to an example implementation. 
           [0003]      FIG. 2  is an illustration of a link aggregation group (LAG) used for communications between a server and a network switch according to an example implementation. 
           [0004]      FIG. 3  is a flow diagram depicting a technique to discover server interface aggregation information according to an example implementation. 
           [0005]      FIG. 4  is a flow diagram representing a technique to determine server interface aggregation information in a manner that accommodates different degrees of system network management protocol (SNMP) capabilities of the server according to an example implementation. 
           [0006]      FIG. 5  is a flow diagram depicting server-side discovery of server-to-switch physical aggregation connections according to an example implementation. 
           [0007]      FIG. 6  is a flow diagram depicting switch-side discovery of server-to-switch physical aggregation connections according to an example implementation. 
           [0008]      FIG. 7  is a flow diagram depicting a technique to discover aggregation information for a network device according to an example implementation. 
       
    
    
     DETAILED DESCRIPTION 
       [0009]    Referring to  FIG. 1 , an example network  100  may include servers  110  (N servers  110 - 1  . . .  110 -N, being depicted in  FIG. 1  as examples), which may provide a variety of services for a datacenter, such as services relating to serving Internet, or “web,” pages to public consumers; database services; email services; and so forth. A given server  110  may provide the platform for multiple virtual machine (VMs). In this regard, for the example implementation that is depicted in  FIG. 1 , the server  110 - 1  has multiple VMs  120 , which are supervised by a hypervisor  122 . 
         [0010]    For purposes of ensuring that a given server  110  (and its VMs) remain visible and functional for such events as a local network port outage or an access switch outage, the network ports, or interfaces, of a given server  110  (such as network interfaces  150  of the server  110 - 1 , for example) may be connected in one or multiple link aggregation groups(s) (LAG(s)) with network interfaces  163  of one or multiple network switches  162  (of network fabric  160 ). Thus, the edge of network encroaches beyond the network fabric  160  and onto the server  110  itself. Two or more network interfaces  150  of a given server  110  may be physically connected to network multiple network interfaces  163  of a given network switch  162  (to form a LAG) or may be physically connected to network interfaces  163  of multiple network switches  162  (to form a split LAG (SLAG)). 
         [0011]    As a more specific example,  FIG. 2  depicts an example LAG  200  that is used by a server  110  and network switch  162 . Referring to  FIG. 2  in conjunction with  FIG. 1 , to form the LAG  200 , an aggregation of network interfaces  150  of the server  110  are physically connected by network cables  210  to an aggregation of network interfaces  163  of the network switch  162 . 
         [0012]    An aggregation is a logical representation of the network interfaces on a given network device (such as a network switch or a server), which are grouped together to form a LAG or SLAG. For a given aggregation, one of the network interfaces is the master, or “aggregator;” and the remaining network interface(s) are the member(s) of the aggregation. Thus, for the example of  FIG. 3 , the network interfaces  150  of the server  110  form a server aggregation, with one of the network interfaces  150  being the aggregator. Likewise, from the side of the network switch  162 , one of the network interfaces  163  is the aggregator of the switch aggregation. with other network interface(s)  163  being the member(s) of the aggregation. The interfaces  150  and  163  of the LAG are connected by physical ports (which are connected by physical cables  210 ). As described herein, the layer 2 (L2), or physical characteristics of the physical ports, such as the Media Access Control (MAC) addresses, may be used to infer aggregations. 
         [0013]    Referring back to  FIG. 1 , in accordance with example implementations, a network manager  174  of the network  100  discovers aggregation information for network devices of the network  100  and uses the discovered information for such purposes as monitoring the statuses of network connections (e.g., determining whether a given connection is “up” or “down”) and monitoring the performances of the network connections (monitoring the number of dropped packets and errors of a given network connection, and so forth). 
         [0014]    For purposes of discovering aggregation information for a given server  110  of the network  100 , the network manager  174  generally performs a technique  300  that is depicted in  FIG. 3 . Referring to  FIG. 3  in conjunction with  FIG. 1 , pursuant to the technique  300 , the network manager  174  determines (block  302 ) one or multiple server interface aggregations of the server and determines (block  304 ) the server-to-switch physical aggregation connections (otherwise called the “L2 connections” or “L2 links”) for the server interface aggregation(s). 
         [0015]    Referring back to  FIG. 1 , a given server  110 , such as example server  110 - 1 , is a physical machine that is formed from actual hardware and actual machine executable instructions, or “software.” For example, the server  110 - 1  has one or multiple central processing units (CPUs)  130 , as well as other hardware, such as the network interfaces  150 , non-transitory memory storage devices that collectively form a memory  119 , and so forth. The machine executable instructions, or software, of the server  110 - 1  may include, for example, instructions that when executed by the CPU(s)  130 , form the VMs  120 , the hypervisor  122 , an operating system, and so forth. These instructions, as well as data associated with the execution of the instructions may be stored in a non-transitory computer readable storage media, such as the memory  119 . 
         [0016]    In accordance with example implementations, the other servers  110  are standalone servers that include such hardware as CPU(s), random access memory (RAM), static storage, NIC interfaces, and so forth. 
         [0017]    As depicted in  FIG. 1 , for this example, the network manager  174  resides on a server  170  that is coupled to the network fabric  160 . In general, the server  170  is also a physical machine that is formed from actual hardware and actual software. Moreover, the network manager  174  may, for example, be formed from a set of machine executable instructions that may be stored in a non-transitory computer readable storage medium, such as a memory  177  of the server  170 , and executed by one or more CPUs  176  of the server  170 . In accordance with example implementations, the network manager  174  may execute on a Windows or Linux platform. Also, in accordance with example implementations, the server  170  may be a standalone server and may include hardware similar to that described above for the standalone servers  110 . 
         [0018]    For the example that is depicted in  FIG. 1 , the server  110 - 1  is simple network management protocol (SNMP) capable, in that the server  110 - 1  has a management information base (MIB)  122  that can provide information to the network manager  174  regarding the network objects of the server  110 - 1 . which are coupled to the network fabric  160 . In this regard, for this example, the server  110 - 1  is a network managed device, and has a corresponding SNMP agent  140  to provide the MIB information to the network manager  174 . As discussed below, the SNMP agent  140  may provide information in the form of an interfaces table and an ifStack table. 
         [0019]    Not all of the servers  110  may, however, be SNMP capable or may be partially SNMP capable. In other words, a given server  110  may not be capable of providing certain MIB information, such as the MIB interfaces or ifStack tables. For example, certain MIB information may not be available or may not be loaded onto the server  110 . Thus, a given server  110  may provide no or partial MIB information, as further described herein. 
         [0020]    In general, traditionally, MIBs for network devices, such as switches and routers, have been available. However, servers running traditional operating systems, such as Windows or Unix, may not provide access to SNMP MIBs that identify port and connection redundancies. In this manner, datacenter operators may not load such MIBs on the servers, and many cases, no SNMP capabilities may not be provided by a given server  110 . This makes SNMP-based identification of the server interface aggregations and aggregation connections potentially challenging for the network manager  174 . As described herein, the network manager  174  may discover server interface aggregations and switch-to-server interface aggregations for a large number of different operating system-based platforms, such as platforms that run Windows, Linux, Solaris , HPUX and AIX operating systems, as examples. 
         [0021]    Referring to  FIG. 4  in conjunction with  FIG. 1 , in accordance with example implementations, the network manager  174  performs a technique  400  for purposes of identifying server interface aggregations and identifying the switch-to-server physical aggregation connections (i.e., the L2 connections) for a given server (such as one of the servers  110 ). The technique  400  accommodates different degrees of information that may be provided by a given server about its aggregation information. 
         [0022]    Pursuant to the technique  400 , the network manager  174  first determines (decision block  402 ) whether the server supports SNMP, or is “SNMP capable.” If so, the network manager  174  requests (block  404 ) the SNMP-based interfaces table and the ifStack table from the server. In general, the interfaces table identifies the logical network interfaces of the server and the corresponding characteristics of these logical interfaces, such as physical addresses, Internet protocol (IP) addresses, aggregation labels, and so forth. The ifStack table identifies a hierarchical relationship among the logical network interfaces of the server. 
         [0023]    The server may or may not, however, provide an if Stack table, even if the server is SNMP capable. If the server provides the ifStack table (decision block  406 ), then the network manager  174  creates (block  408 ) aggregator-to-member relationships by matching physical member interface indexes to logical aggregator interface indexes, using both the interfaces table and the ifStack table. If, however, the server does not support the ifStack table (decision block  406 ), then the network manager  174  processes the interfaces table and makes various assumptions based on the information found in this table. 
         [0024]    More specifically, in accordance with example implementations, the network manager  174  performs the following technique. First, by examining the interfaces table, the network manager  174  determines (block  410 ) one or multiple groups of server network interfaces that share a common physical address. In this regard, the network manager  174  considers network interfaces that share a common physical address, such as a MAC address, as belonging to a server aggregation group. Next, the network manager  174  begins a process (by deciding whether there is another group to process in decision block  411 ) to identify the aggregator for each of the identified aggregation group(s). 
         [0025]    More specifically, one way to identify the aggregator for a given group is for the network manager  174  to determine (decision block  412 ) whether a specific label, or aggregator “iftype” (or “IANAiftype”), is present in the interfaces table. For example, a given logical network interface acting as an aggregator may be of an ifType ieee8023adLag, propMultiplexor or another type. If a given logical network interface is associated with one of these labels, then, in accordance with example implementations, the network manager  174  labels (block  414 ) the interface as being the aggregator and labels the other logical interface(s) of the aggregation as being member(s) of the aggregation. Control then returns to decision block  412  to process the next group of interfaces. 
         [0026]    If in decision block  412  the network manager  174  fails to find the aggregator iftype label (pursuant to decision block  412 ), then the network manager  174  proceeds to identify the aggregator based on other criteria. More specifically, the network manager  174  determines (decision block  416 ) whether one of the logical interfaces has an IP address. If so, the network manager  174  labels the interface having the IP address as the aggregator and labels the other interface(s) as member(s), pursuant to block  418 . Control then returns to decision block  411  to process the next aggregation, if any. 
         [0027]    If, however, pursuant to decision block  416 , the network manager  174  does not find an IP address, the network manager  174  applies a different criteria to identify the aggregation. In this manner, the network manger  174  determines (decision block  420 ) whether one of the logical network interfaces has a different speed. If so, the network manager labels the interface having the different speed as the aggregator and labels the other interface(s) as a member(s) of the aggregation, pursuant to block  422 . Control then returns to decision block  411  to process the next aggregation, if any. 
         [0028]    Lastly, if the network manager  174  does not, pursuant to decision block  420 , determine that one of the logical interfaces has a different speed, then the network manager  174  labels the interface having the highest numbered interface index as the aggregator and labels the other interface(s) as the member(s) of the aggregation, pursuant to block  424 . Control then returns to decision block  412 . 
         [0029]    If the network manager  174  determines (decision block  402 ) that the server is not SNMP capable, then the interfaces and if Stack tables are not available, and the network manager  174  identifies aggregation information based on other criteria. In this manner, the network manager  174  collects (block  430 ) address resolution protocol (ARP) information from the switches and routers of the network fabric  160  to pair (block  432 ) physical addresses of the logical interfaces to IP addresses using the ARP information. By using forward database (FDB) table information, the network manager  174  identifies (block  434 ) a given server network interface as an aggregator if the server interface communicates with the switch&#39;s aggregator interface. It is noted that for this case, the aggregation includes no members other than the aggregator, because the SNMP interface information is not available from the server. 
         [0030]    It is noted that each server operating system presents its network interface model using a different SNMP interfaces table representation. For example, Linux is relatively simplistic in responding with a grouped interface aggregation. Windows® is relatively complex offering a relatively large number of logical interfaces as potential aggregator candidates. A Solaris operating system may provide the aggregator interface with no members, while HPUX provides the SNMP interface information closer to Linux. Thus, the network manager  174  may modify its heuristics for server aggregator identification as new operating systems are added to the supported list. 
         [0031]    After discovering a given server network interface aggregation, the network manager  174  next discovers the physical, or L2, connections, which physically connect the server interfaces to the switch interfaces. The L2 connections may be discovered from either the server or the switch side. In this regard, different switch-side and server-side aggregations and corresponding connections are formed over the course of time. Thus, the network manager  174  uses both server-side connection discovery ( FIG. 5 ) as well as switch-side connection discovery ( FIG. 6 ), in accordance with example implementations. 
         [0032]      FIG. 5  is an illustration of a server-side connection discovery technique  500  in accordance with example implementations. Referring to  FIG. 5  in conjunction with  FIG. 1 , the technique  500  includes the network manager  174  determining (decision block  502 ) whether there is another server aggregation to process for purposes of determining the corresponding L2 connections for this aggregation. If so, the technique  500  includes the network manager  174  identifying a switch that has an aggregation and has recorded communicating with a physical address of the server aggregation over the switch&#39;s aggregator interface, pursuant to block  504 . If such a switch is identified, the network manager  174  creates (block  506 ) the corresponding L2 link (i.e., identifies the L2 physical connection). Control then returns to decision block  502  for purposes of processing any further server aggregations. 
         [0033]      FIG. 6  depicts a switch-side connection discovery technique  600  that may be used by the network manager  174 , in accordance with example implementations. Pursuant to the technique  600 , the network manager  174  determines (decision block  602 ) whether there is another switch aggregation to process. If so, the network manager  174  uses (block  604 ) the FDB table of the switch to identify the physical address paired to a server aggregator interface. If one is found, the network manager  174  identifies (block  606 ) the server aggregator for the aggregation and creates (block  608 ) the corresponding L2 link before control returns to decision block  602 . 
         [0034]    Among the possible advantages of the systems and techniques that are disclosed herein, server interface aggregations as well as L2 connections are discovered, which are both important for maintaining accessibility of servers. Moreover, server aggregations and L2 connections may be identified even when one or multiple servers do not support SNMP. The systems and techniques that are disclosed herein allow incident alerting when member(s) of a given server aggregation are faulting or faulting when an entire aggregation has faulted. The systems and techniques that are disclosed herein permit incident alerting when the server&#39;s aggregate L2 link to its access switch or switches have faulted. Virtual server aggregations may be identified and correctly monitored for operational status, bandwidth utilization, and other monitored conditions. Other and different advantages are contemplated, in accordance with other example implementations. 
         [0035]    Other implementations are contemplated and are within the scope of the appended claims. For example, although server-to-switch link aggregations are described in the examples above, the network manager  174  may find heterogeneous network equipment aggregations using the same techniques. For example, a network switch made by a first company may have a link aggregation to a network switch made by a second company, but neither device&#39;s SNMP agent may provide standard MIB aggregation responses that contain data identifying the aggregations and allow linking of the aggregations. However, using the above-described techniques, the network manager  174  may find and link aggregations between heterogeneous network equipment. Because network switches tend to support the ifStack MIB, the network manager  174  may use this information to create and link the aggregations, but the other techniques described above may also be used. 
         [0036]    Likewise, in accordance with further example implementations, the network manager  174  may use techniques that are disclosed herein to find router-to-switch and router-to-router aggregations. 
         [0037]    Thus, referring to  FIG. 7 , in general, the network manager  174  performs a technique  700  that includes determining (decision block  702 ) whether a given network device is capable of providing data that identifies network interface aggregation(s) of the device. If so, the network manager  174  uses the data to identify the aggregation(s), pursuant to block  704 . Otherwise, the network manager infers (block  706 ) the aggregation(s) based on other data that may or may not be provided by the device, as described herein. 
         [0038]    While the present invention has been described with respect to a limited number of embodiments, those skilled in the art, having the benefit of this disclosure, will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.