Client auto-configuration in a multi-switch link aggregation

Abstract

One embodiment of the present invention provides a switch capable of auto-configuration of client devices for a link aggregation. The switch includes a packet processor, an auto-configuration module, and a link-aggregation management module. During operation, the packet processor extracts an identifier of a client device from a notification message received via a local port. The auto-configuration module, which is coupled to the packet processor, associates the local port with the identifier of the client device. If the packet processor recognizes the identifier of the client device in a message received from a remote switch, the link-aggregation management module forms a multi-switch link aggregation for the client device in conjunction with the remote switch.

Description

BACKGROUND

Field

The present disclosure relates to network management. More specifically, the present disclosure relates to a method and system for facilitating automatic configuration of a multi-switch link aggregation for a respective client device.

Related Art

The exponential growth of the Internet has made it a popular delivery medium for heterogeneous data flows. Such heterogeneity has caused an increasing demand for bandwidth. As a result, equipment vendors race to build larger and faster switches with versatile capabilities, such as link aggregation (LAG), to move more traffic efficiently. However, the complexity of a switch cannot grow infinitely. It is limited by physical space, power consumption, and design complexity, to name a few factors. Furthermore, switches with higher and more versatile capability are usually more complex and expensive.

As more time-critical applications are being implemented in data communication networks, high-availability operation is becoming progressively more important as a value proposition for network architects. It is often desirable to aggregate links to multiple switches to operate as a single logical link (referred to as a multi-switch link aggregation) to facilitate load balancing among the multiple switches while providing redundancy to ensure that a device failure or link failure would not affect the data flow. The switches participating in a multi-switch link aggregation are referred to as partner switches.

A multi-switch link aggregation allows multiple links between a client device, which can be an end host or a switching device, and a plurality of partner switches. Currently, such a multi-switch link aggregation in a network has not been able to take advantage of the automatic configuration of the client device coupled to the partner switches. While coupling the client device, a network administrator typically configures the multi-switch link aggregation manually on a respective client device. In the current era of reduced operational expenditure, such manual configuration can lead to a substantial bottleneck.

While multi-switch link aggregation brings many desirable features to networks, some issues remain unsolved for client device configurations.

SUMMARY

One embodiment of the present invention provides a switch capable of auto-configuration of client devices for a link aggregation. The switch includes a packet processor, an auto-configuration module, and a link-aggregation management module. During operation, the packet processor extracts an identifier of a client device from a notification message received via a local port. The auto-configuration module, which is coupled to the packet processor, associates the local port with the identifier of the client device. If the packet processor recognizes the identifier of the client device in a message received from a remote switch, the link-aggregation management module forms a multi-switch link aggregation for the client device in conjunction with the remote switch.

In a variation on this embodiment, the identifier of the client device is either a media access control (MAC) address of the client device or a hash value of the MAC address.

In a variation on this embodiment, the notification message is based on a discovery protocol. This discovery protocol is one of: Link Layer Discovery Protocol (LLDP), Cisco Discovery Protocol (CDP), and Advanced Device Discovery Protocol (ADDP).

In a variation on this embodiment, the notification message also includes one or more of: name and description of the client device, a port identifier associated with an outgoing port of the client device, a virtual local area network (VLAN) identifier associated with the port or the client device, an Internet Protocol (IP) management address, capabilities associated with the client device, power management information, and link aggregation information.

In a variation on this embodiment, the packet processor extracts the identifier of the client device from a plurality of notification messages received via a plurality of local ports. The link-aggregation management module forms a local link aggregation using the plurality of local ports. The auto-configuration module associates the local link aggregation with the identifier of the client device.

In a variation on this embodiment, the link-aggregation management module represents the multi-switch link aggregation using a virtual switch identifier. This virtual switch identifier is associated with the switch and the remote switch.

In a variation on this embodiment, the packet processor encapsulates a data frame received from the client device in a Transparent Interconnection of Lots of Links (TRILL) packet.

In a variation on this embodiment, the switch also includes a fabric switch management module which maintains a membership in a fabric switch. The fabric switch is configured to accommodate a plurality of switches and operates as a single logical switch.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1A illustrates an exemplary multi-switch link aggregation with client auto-configuration support, in accordance with an embodiment of the present invention.

FIG. 1B illustrates how a respective client device uses a discovery protocol for auto-configuration in conjunction with the example in FIG. 1A, in accordance with an embodiment of the present invention.

FIG. 2A presents a flowchart illustrating the auto-configuration process of a client device associated with a multi-multi-switch link aggregation, in accordance with an embodiment of the present invention.

FIG. 2B presents a flowchart illustrating the auto-configuration process of a partner switch associated with a multi-multi-switch link aggregation, in accordance with an embodiment of the present invention.

FIG. 3 presents a flowchart illustrating the process of a switch configuring a multi-multi-switch link aggregation based on client auto-configuration, in accordance with an embodiment of the present invention.

FIG. 4 illustrates an exemplary switch in a software-defined network, in accordance with an embodiment of the present invention.

In the figures, like reference numerals refer to the same figure elements.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.

Overview

In embodiments of the present invention, the problem of facilitating automatic configuration of a multi-switch link aggregation for a client device is solved by sharing client device information via a proactive communication between a client device and a respective partner switch. This allows the partner switch to automatically configure a link aggregation for the client device. It is often desirable to aggregate multiple links between multiple switches and a client device in a network into a logical link aggregation (can also be referred to as a trunk) in a network. Such a link aggregation includes several links among a plurality of switches, and a client device to create a single logical link and support increased bandwidth. This multi-switch link aggregation can also provide high availability. If one of the links or switches in the multi-switch link aggregation fails, the active switch(es) associated with the link aggregation can automatically redistribute traffic across the active links in the link aggregation.

However, with the existing technologies, a multi-switch link aggregation implementation requires manual configuration for a respective client device in a respective partner switch. Such manual configuration typically requires multiple command line interface (CLI) commands for a respective client device. Consequently, a network administrator configuring the multi-switch link aggregation requires the knowledge of the exact number of client devices and the corresponding client device information, such as identification and configuration information. For example, if a multi-switch link aggregation supports 256 client devices, the network administrator needs to know the identification and configuration of 256 client devices. If configuring a client requires “x” number of command line interface commands, the network administrator issues (256*x) commands to a respective partner switch in the multi-switch link aggregation. Such a large volume of manual commands can be repetitious, tedious, and error-prone, and can lead to high operational expenses.

This problem is solved by using proactive communication between a respective client device and the partner switches, typically based on a discovery protocol available in the client devices and partner switches. A respective client device automatically sends the associated information in a notification message via a respective active link of the client device. A respective partner switch receives the notification message via an active link coupling the client device and configures the corresponding multi-switch link aggregation using the received information. Note that the discovery protocol in a respective client device can automatically send out the notification message without any external instruction.

Client device information can include one or more of: a unique identifier (e.g., a media access control (MAC) address) of the client device, name and description of the client device, a port identifier associated with the link, a virtual local area network (VLAN) identifier associated with the port or the client device, an Internet Protocol (IP) management address, capabilities associated with the client device, power management information, and link aggregation information. Examples of a discovery protocol include, but are not limited to, Link Layer Discovery Protocol (LLDP), Cisco Discovery Protocol (CDP), and Advanced Device Discovery Protocol (ADDP).

Upon receiving the client device information, a respective partner switch retrieves the unique identifier of the client device (e.g., the MAC address). The switch identifies the one or more ports from which the notification messages comprising the identifier have been received. In this way, the partner switch recognizes the ports coupling the client device. During the synchronization process with the partner switches, the switch receives the client device information from the remote partner switches. Consequently, the switch recognizes the client device to be multi-homed (i.e., coupled to multiple partner switches). Similarly, a respective remote partner switch receives the client device information from other partner switches and recognizes the client device to be multi-homed. As a result, a respective partner switch then configures a multi-switch link aggregation for the client device across the partner switches.

In some embodiments, the partner switches of a multi-switch link aggregation are member switches of a fabric switch. A client device can be coupled to the fabric switch via the multi-switch link aggregation. A fabric switch in the network can be an Ethernet fabric switch or a virtual cluster switch (VCS). In an Ethernet fabric switch, any number of switches coupled in an arbitrary topology may logically operate as a single switch. Any new switch may join or leave the fabric switch in “plug-and-play” mode without any manual configuration. In some embodiments, a respective switch in the Ethernet fabric switch is a Transparent Interconnection of Lots of Links (TRILL) routing bridge (RBridge). A fabric switch appears as a single logical switch to the end device.

Although the present disclosure is presented using examples based on the use of a discovery protocol, embodiments of the present invention are not limited to the use of a discovery protocol. Embodiments of the present invention are relevant to any method that facilitates automatic information dispersion from a client device for facilitating auto-configuration. In this disclosure, the term “discovery protocol” is used in a generic sense, and can refer to any set of actions that enable a switch to automatically learn information about a client device. Such a set of actions can be implemented in any networking layer, sub-layer, or a combination of networking layers.

The term “client device” refers to any device coupled to a switch via a link aggregation. “Client device” can refer to a host device, which is referred to as a “client host device,” or any type of network switching device, which is referred to as a “client switching device.” “Client switching device” can refer to any client device that can forward traffic to another device. Additionally, a client device can be coupled to other switches or hosts further away from a network. A client device can also be an aggregation point for a number of network devices to enter the network.

The term “message” refers to a group of bits that can be transported together across a network. “Message” should not be interpreted as limiting embodiments of the present invention to any specific networking layer. “Message” can be replaced by other terminologies referring to a group of bits, such as “frame,” “packet,” “cell,” or “datagram.” The term “frame” is used in a generic sense and should not be interpreted as limiting embodiments of the present invention to layer-2 networks. “Frame” can be replaced by other terminologies referring to a group of bits, such as “packet,” “cell,” or “datagram.”

The term “switch” is used in a generic sense, and it can refer to any standalone or fabric switch operating in any network layer. “Switch” should not be interpreted as limiting embodiments of the present invention to layer-2 networks. Any device that can forward traffic to a client device can be referred to as a “switch.” Examples of a “switch” include, but are not limited to, a layer-2 switch, a layer-3 router, a Transparent Interconnection of Lots of Links (TRILL) Routing Bridge (RBridge), an FC router, or an FC switch.

The term “Ethernet fabric switch” refers to a number of interconnected physical switches which form a single, scalable logical switch. In a fabric switch, any number of switches can be connected in an arbitrary topology, and the entire group of switches functions together as one single, logical switch. This feature makes it possible to use many smaller, inexpensive switches to construct a large fabric switch, which can be viewed as a single logical switch externally.

Network Architecture

FIG. 1A illustrates an exemplary multi-switch link aggregation with client auto-configuration support, in accordance with an embodiment of the present invention. A network 100 includes switches 102 and 104 coupled to each other via inter-switch link 110. Also included is a layer-2 and/or layer-3 sub-network 150 coupled to switches 102 and 104. In some embodiments, network 100 is a fabric switch. A large number of multi-homed client host devices, from 121 to 129, are coupled to switches 102 and 104. Similarly, a large number of multi-homed client switching devices, from 131 to 139 are coupled to switches 102 and 104. The total number of multi-homed client devices supported by switches 102 and 104 is equal to or greater than the number of client devices coupled to both switches 102 and 104. A switch can also have single-homed client devices coupled to the switch. For example, switch 104 is coupled to single-homed client host device 140.

With the existing technologies, configuring a multi-switch link aggregation for a client device (e.g., client device 121 or 131) requires manual configuration involving multiple command line interface commands on both switches 102 and 104. Furthermore, for issuing the commands, the network administrator of network 100 requires explicit knowledge of client device information, such as identification and configuration of client devices 121-129 and 131-139. A large volume of manual commands can be repetitious, tedious, and error-prone, and can lead to high operational expenses. To solve this problem, client devices 121-129 and 131-139 can proactively convey their respective client device information to switches 102 and 104.

In some embodiments, client devices 121-129 and 131-139 support one or more discovery protocols for automatic information dispersion. A respective client device can use a different discovery protocol, as long as switches 102 and 104 support that discovery protocol. Client device information of client devices 121-129 and 131-139 can include one or more of: a MAC address of the client device, name and description of the client device, a port identifier associated with the active link, a VLAN identifier associated with the port or the client device, an IP management address, capabilities associated with the client device, power management information, and link aggregation information. Examples of a discovery protocol include, but are not limited to, LLDP, CDP, and ADDP.

During operation, switches 102 and 104 are configured as partner switches for multi-switch link aggregations. As a result, all client devices multi-homed to switches 102 and 104 synchronize information with each other. Upon coupling to switch 102, client device 121 sends to switch 102 a notification message, which includes the MAC address of client device 121 and an identifier of the local port coupling switch 102. Switch 102 receives the notification message from client device 121 and retrieves the MAC address of client device 121 from the message. Switch 102 identifies the port from which the notification message has been received and associates the identifier with the port. If switch 102 receives notification messages from client device 121 via a plurality of ports, switch 102 associates these ports with client device 121. In this way, switch 102 recognizes all local ports coupling client device 121. Similarly, client device 121 sends a notification message to switch 104 as well for a respective link coupling client device 121 to switch 104. This allows switch 104 to recognize the local ports coupling client device 121.

Partner switches 102 and 104 synchronize the received information from client device 121 with each other via inter-switch link 110. When switch 102 receives information of client device 121 from partner switch 104, switch 102 checks whether the same client device (e.g., a device with the same MAC address) is locally coupled and discovers that client device 121 is coupled to switch 102 as well. In this way, switch 102 recognizes client device 121 to be multi-homed. Similarly, when switch 104 receives information about client device 121 from switch 102, switch 104 recognizes client device 121 to be multi-homed. Partner switches 102 and 104, in conjunction with each other, configure a multi-switch link aggregation for client device 121 across switches 102 and 104. Similarly, client devices 122-129 and 131-139 send respective client device information to switches 102 and 104. Partner switches 102 and 104 configure a respective multi-switch link aggregation for client devices 122-129 and 131-139 across switches 102 and 104.

FIG. 1B illustrates how a respective client device uses a discovery protocol for auto-configuration in conjunction with the example in FIG. 1A, in accordance with an embodiment of the present invention. A respective client device can be coupled to a respective partner switch via any number of links within the maximum number of links supported by the switch and the client device. As a result, a client device can couple with different partner switches via different numbers of links. In the example in FIG. 1B, client device 121 is coupled to switches 102 and 104 via one and two links, respectively. Similarly, client device 131 is coupled to switches 102 and 104 via two and three links, respectively.

When client device 121 sends a notification message to switch 102 via port 161, client device 121 includes the MAC address of client device 121 and an identifier of port 161. Client device 121 can also include the corresponding link capability and a VLAN identifier associated with port 161. Upon receiving the notification message from client device 121, switch 102 identifies the MAC address of client device 121 and the port identifier of port 161. Switch 102 also identifies port 171 from which switch 102 has received the notification message comprising the MAC address of client device 121. Similarly, when client device 121 sends notification messages to switch 104 via ports 162 and 163, client device 121 includes the MAC address of client device 121 in both notification messages. However, client device 121 includes in the message an identifier of port 162 while sending via port 162 and an identifier of port 163 when sending via port 163. Switch 104 receives the notification messages from client device 121, and identifies the MAC address of client device 121 and the port identifiers of ports 162 and 163. Switch 102 also identifies ports 172 and 173 from which switch 104 has received the notification messages comprising the MAC address of client device 121.

Because switch 104 has received notification messages with the same MAC address (i.e., the MAC address of client device 121) via multiple ports (i.e., ports 172 and 173), switch 104 detects that client device 121 is coupled to switch 104 via multiple links. Switch 104 then forms a local link aggregation 170 comprising ports 172 and 173. In some embodiments, switch 104 sends a notification message to client device 121 regarding the link aggregation. Client device 121 receives the notification message and becomes aware of the link aggregation via ports 162 and 163. In some embodiments, client device 121 and switches 102 and 104 support a dynamic link aggregation protocol. An example of a dynamic link aggregation protocol includes, but is not limited to, Link Aggregation Control Protocol (LACP). A dynamic link aggregation protocol allows client device 121 and switches 102 and 104 to verify local link aggregation 170 and detect any misconfiguration, such as inconsistent link aggregation configuration between ports 172 and 173.

Partner switches 102 and 104 synchronize the received information from client device 121 with each other. When switch 102 receives the MAC address of client device 121 from partner switch 104, switch 102 detects that the MAC address is associated with a locally coupled client device 121 and recognizes client device 121 to be multi-homed. Similarly, switch 104 receives the MAC address of client device 121 from switch 102 and recognizes client device 121 to be multi-homed. Partner switches 102 and 104 then automatically configure multi-switch link aggregation 180 for client device 121 across switches 102 and 104. Switch 102 associates port 171 with multi-switch link aggregation 180 while switch 104 associates local link aggregation 170 with multi-switch link aggregation 180.

Auto-Configuration

In the example in FIG. 1B, switches 102 and 104, and client device 121 facilitate auto-configuration using proactive communication between them. FIG. 2A presents a flowchart illustrating the auto-configuration process of a client device associated with a multi-multi-switch link aggregation, in accordance with an embodiment of the present invention. During the initial powering up (i.e., the booting up), the client device identifies the locally configured discovery protocol (operation 202). The client device constructs a notification message, which is based on the discovery protocol, comprising a device identifier (e.g., a MAC address of the client device) (operation 204). The client device identifies an active local port (i.e., an active link) (operation 206) and includes an identifier to the identified port, and other associated information, such as a VLAN identifier, a link capability, and link aggregation information, in the notification message (operation 208). Note that the construction of the notification message and inclusion of the client device information can be specified in the discovery protocol. The client device simply implements the discovery protocol to facilitate the auto-configuration.

The client device can check whether the client device supports a dynamic link aggregation protocol (operation 210). In some embodiments, the dynamic link aggregation protocol is LACP. If the client device supports a dynamic link aggregation protocol, the client device indicates the support for the dynamic link aggregation protocol in the notification message (operation 212). In some embodiments, the client device uses a modified notification message of the discovery protocol to indicate the support for the dynamic link aggregation protocol. For example, the client device can use a modified version of an LLDP notification message to indicate the support for LACP. The client device then transmits the notification message via the identified port (operation 214). Next, the client device checks whether the client device has any more active ports (operation 216). If so, the client device continues to identify active ports (operation 206).

FIG. 2B presents a flowchart illustrating the auto-configuration process of a partner switch associated with a multi-multi-switch link aggregation, in accordance with an embodiment of the present invention. Upon receiving a notification message via a local port (operation 252), the switch obtains a device identifier of a client device from the received notification message (operation 254). This identifier can be a MAC address of the client device. The switch generates a local identifier, which can be shorter than the received client device identifier, for the client device (operation 256). Such generation of shorter local identifier can reduce memory requirements and have ease of deployment. In some embodiments, the local identifier is a hashed value of the MAC address of the client device. A respective partner switch uses the same hash function. Consequently, the same MAC address generates the same local identifier in a respective partner switch. In the example in FIG. 1B, switches 102 and 104 generate the same local identifier for the MAC address of device 121. The switch can optionally generate a local name for the client device (operation 258). In some embodiments, the local name is created as a combined string of the phrase “Auto,” a system name of the client device with a maximum length of 20 characters, and the 12 digits of the base MAC address of the client device.

The switch then associates the local port with the local identifier (operation 260). This allows the switch to identify a respective port from which a notification message from the same client device (i.e., comprising the same identifier) has been received. The switch then identifies other local ports, if any, associated with the local identifier (operation 262) and checks whether a local link aggregation is required (operation 264), as described in conjunction with FIG. 1B. The switch can check the requirement of a local link aggregation by checking whether a plurality of ports are associated with the same local identifier. If a local link aggregation is needed, the switch forms a local link aggregation using the plurality of ports associated with the local identifier (operation 266). In some embodiments, the switch checks whether the switch supports a dynamic link aggregation protocol (operation 268). An example of the dynamic link aggregation protocol is LACP. If the switch supports dynamic link aggregation protocol, the switch verifies the local link aggregation based on the dynamic link aggregation protocol (operation 270) and detects any misconfiguration, such as inconsistent link aggregation configuration.

Multi-Switch Link Aggregation

In the example in FIG. 1B, after the auto-configuration of device 121, switches 102 and 104, in conjunction with each other, automatically configure a multi-switch link aggregation for client device 121. FIG. 3 presents a flowchart illustrating the process of a switch configuring a multi-multi-switch link aggregation based on client auto-configuration, in accordance with an embodiment of the present invention. The switch can repeat the process described in conjunction with FIG. 3 for a respective partner switch. During operation, the switch receives an information message comprising client device information from a partner switch (operation 302). The switch retrieves the device identifier from the information message (operation 304). This device identifier can be the MAC address of the client device or a locally generated hashed value of the MAC address. Next, the switch checks whether the same identifier is locally known (i.e., associated with a local port) (operation 306). If not, the corresponding client device is not multi-homed and not a candidate for a multi-switch link aggregation. The switch then continues to receive information message from the partner switch (operation 302).

If the same identifier exists locally, the corresponding client device is multi-homed. The switch then checks whether the switch has a local link aggregation for the identifier (i.e., a local link aggregation is associated with the identifier) (operation 308). If the switch does not have a local link aggregation for the identifier, the switch identifies the local port associated with the identifier (operation 310). Otherwise, the switch identifies the link aggregation associated with the identifier (operation 312). After identifying the local port or link aggregation, the switch forms a multi-switch link aggregation using the local port or link aggregation associated with the identifier (operation 314). In some embodiments, the switch can check whether the client device supports a dynamic link aggregation protocol (operation 316), such as LACP.

If the end device supports a dynamic link aggregation protocol, the switch verifies the multi-switch link aggregation based on the dynamic link aggregation protocol (operation 318) and detects any misconfiguration, such as inconsistent link aggregation configuration. If the end device does not support a dynamic link aggregation protocol (operation 316) or has verified the multi-switch link aggregation (operation 318), the switch notifies the partner switch regarding the multi-switch link aggregation (operation 320). Consequently, the partner switches become aware of each others' multi-switch link aggregation configuration. In some embodiments, the switch, in conjunction with the partner switch, can create a virtual switch representing the multi-switch link aggregation. Switch virtualization and its associated operations, such as data synchronization, are specified in U.S. Patent Publication No. 2010/0246388, titled “Redundant Host Connection in a Routed Network,” the disclosure of which is incorporated herein in its entirety.

Exemplary Switch

FIG. 4 illustrates an exemplary switch in a software-defined network, in accordance with an embodiment of the present invention. In this example, a switch 400 includes a number of communication ports 402, a link aggregation management module 420, an auto-configuration module 430, a packet processor 410 coupled to auto-configuration module 430, and a storage 450. In some embodiments, switch 400 may maintain a membership in a fabric switch, wherein switch 400 also includes a fabric switch management module 440. Fabric switch management module 440 maintains a configuration database in storage 450 that maintains the configuration state of a respective switch within the fabric switch. Fabric switch management module 440 maintains the state of the fabric switch, which is used to join other switches. Under such a scenario, communication ports 402 can include inter-switch communication channels for communication within a fabric switch. This inter-switch communication channel can be implemented via a regular communication port and based on any open or proprietary format.

During operation, packet processor 410 extracts an identifier of a client device from a notification message received via a local port, which is one of the communication ports 402. This identifier of the client device can be the MAC address of the client device or a hash value of the MAC address, as described in conjunction with FIG. 2B. In some embodiments, the notification message is based on a discovery protocol 432. Discovery protocol 432 enables switch 400 to recognize the notification message sent by the client device. The notification message can also include one or more of: name and description of the client device, a port identifier, a VLAN identifier associated with the port or the client device, an IP management address, capabilities associated with the client device, power management information, and link aggregation information. Examples of discovery protocol 432 include, but are not limited to, LLDP, CDP, and ADDP.

Auto-configuration module 430 then associates the local port with the identifier of the client device. If packet processor 410 recognizes the identifier of the client device in a message received from a remote switch, link-aggregation management module 420 forms a multi-switch link aggregation for the client device in conjunction with the remote switch. If the client device is coupled to switch 400 via multiple links, packet processor 410 can extract the identifier of the client device from a plurality of notification messages received via the corresponding local ports. Under such a scenario, link-aggregation management module 420 forms a local link-aggregation using the plurality of local ports. Auto-configuration module 430 associates the local link aggregation with the identifier of the client device.

In some embodiments, link-aggregation management module 420 represents the multi-switch link aggregation using a virtual switch identifier. This virtual switch identifier is associated with the switch and the remote switch. In some embodiments, switch 400 is a TRILL RBridge. Under such a scenario, the virtual switch identifier can be a virtual RBridge identifier. Furthermore, packet processor 410 encapsulates a respective data frame received from the client device in a TRILL packet to send the data packet to another RBridge.

Note that the above-mentioned modules can be implemented in hardware as well as in software. In one embodiment, these modules can be embodied in computer-executable instructions stored in a memory which is coupled to one or more processors in switch 400. When executed, these instructions cause the processor(s) to perform the aforementioned functions.

In summary, embodiments of the present invention provide a switch and a method for facilitating automatic configuration of a client device for a multi-switch link aggregation. In one embodiment, the switch includes a packet processor, an auto-configuration module, and a link aggregation management module. During operation, the packet processor extracts an identifier of a client device from a notification message received via a local port. The auto-configuration module, which is coupled to the packet processor, associates the local port with the identifier of the client device. If the packet processor recognizes the identifier of the client device in a message received from a remote switch, the link-aggregation management module forms a multi-switch link aggregation for the client device in conjunction with the remote switch.

The methods and processes described herein can be embodied as code and/or data, which can be stored in a computer-readable non-transitory storage medium. When a computer system reads and executes the code and/or data stored on the computer-readable non-transitory storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the medium.

The methods and processes described herein can be executed by and/or included in hardware modules or apparatus. These modules or apparatus may include, but are not limited to, an application-specific integrated circuit (ASIC) chip, a field-programmable gate array (FPGA), a dedicated or shared processor that executes a particular software module or a piece of code at a particular time, and/or other programmable-logic devices now known or later developed. When the hardware modules or apparatus are activated, they perform the methods and processes included within them.

The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit this disclosure. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. The scope of the present invention is defined by the appended claims.

Claims

1. A switch, comprising: one or more ports;processing circuitry configured to obtain, from a first message from a client device, a device identifier of the client device, a port identifier of a port of the client device, and an indicator, which is distinct from the device identifier and indicates indicating whether the client device supports dynamic link aggregation; andmanagement circuitry configured to: obtain, from a second message from a remote switch, the device identifier, wherein the switch and the remote switch are in a plug-and-play mode for forming a logical switch;determine that the client device is multi-homed with the switch and the remote switch; anddetermine whether the client device supports dynamic link aggregation based on the indicator;in response to the indicator indicating that the client device supports dynamic link aggregation: dynamically form a multi-switch link aggregation for the client device;verify the multi-switch link aggregation based on a dynamic link aggregation protocol for detecting any misconfiguration; andin response to detecting a misconfiguration, generate a notification message for the remote switch regarding the misconfiguration;in response to the indicator indicating that the client device does not support dynamic link aggregation, generate a notification message for the remote switch regarding the multi-switch link aggregation.

2. The switch of claim 1, wherein the device identifier of the client device is one of: a media access control (MAC) address of the client device and a hash value of the MAC address.

3. The switch of claim 1, wherein the first message is based on a discovery protocol; and wherein the discovery protocol is one of: Link Layer Discovery Protocol (LLDP);Cisco Discovery Protocol (CDP); andAdvanced Device Discovery Protocol (ADDP).

4. The switch of claim 1, wherein the first message further comprises one or more of: name and description of the client device;a virtual local area network (VLAN) identifier associated with the port of the client device;an Internet Protocol (IP) management address;capabilities associated with the client device;power management information; andlink aggregation information.

5. The switch of claim 1, wherein the first message received is via a first port of the one or more ports of the switch; wherein the processing circuitry is further configured to obtain the device identifier of the client device from a third message received via a second port of the one or more ports of the switch; andwherein the management circuitry is further configured to form a local link aggregation for the client device using the first and second ports, wherein the local link aggregation is incorporated in the multi-switch link aggregation.

6. The switch of claim 1, wherein the multi-switch link aggregation is represented by a virtual switch reachable from the switch and the remote switch, and wherein the virtual switch is identified by a virtual switch identifier associated with the switch and the remote switch.

7. The switch of claim 6, wherein the packet processing circuitry is further configured to encapsulate, with an encapsulation header, a data frame received via the multi-switch link aggregation from the client device, wherein the virtual switch identifier is an ingress identifier of the encapsulation header.

8. The switch of claim 1, wherein the switch and the remote switch are members of a network of interconnected switches, wherein the network of interconnected switches is identified by a fabric identifier associated with the switch and the remote switch.

9. A method, comprising: obtaining, from a first message from a client device, a device identifier of the client device, a port identifier of a port of the client device, and an indicator, which is distinct from the device identifier and indicates whether the client device supports dynamic link aggregation;obtain, from a second message from a remote switch, the device identifier;determining that the client device is multi-homed with a local switch and the remote switch, wherein the switch and the remote switch are in a plug-and-play mode for forming a logical switch;determining whether the client device supports dynamic link aggregation based on the indicator;in response to the indicator indicating that the client device supports dynamic link aggregation; forming a multi-switch link aggregation for the client device;verify the multi-switch link aggregation based on a dynamic link aggregation protocol for detecting any misconfiguration; andin response to detecting a misconfiguration, generate a notification message for the remote switch regarding the misconfiguration;in response to the indicator indicating that the client device does not support dynamic link aggregation, generate a notification message for the remote switch regarding the multi-switch link aggregation.

10. The method of claim 9, wherein the device identifier of the client device is one of: a media access control (MAC) address of the client device and a hash value of the MAC address.

11. The method of claim 9, wherein the first message is based on a discovery protocol; and wherein the discovery protocol is one of: Link Layer Discovery Protocol (LLDP);Cisco Discovery Protocol (CDP); andAdvanced Device Discovery Protocol (ADDP).

12. The method of claim 9, wherein the first message further comprises one or more of: name and description of the client device;a virtual local area network (VLAN) identifier associated with the port of the client device;an Internet Protocol (IP) management address;capabilities associated with the client device;power management information; andlink aggregation information.

13. The method of claim 9, wherein the first message received is via a first port of the local switch; and wherein the method further comprises: obtaining the device identifier of the client device from a third message received via a second port of the local switch; andforming a local link aggregation for the client device using the first and second ports, wherein the local link aggregation is incorporated in the multi-switch link aggregation.

14. The method of claim 9, wherein the multi-switch link aggregation is represented by a virtual switch reachable from the local switch and the remote switch, and wherein the virtual switch is identified by a virtual switch identifier associated with the local switch and the remote switch.

15. The method of claim 14, further comprising encapsulating, with an encapsulation header, a data frame received via the multi-switch link aggregation from the client device, wherein the virtual switch identifier is an ingress identifier of the encapsulation header.

16. The method of claim 9, wherein the local switch and the remote switch are members of a network of interconnected switches, wherein the network of interconnected switches is identified by a fabric identifier associated with the local switch and the remote switch.

17. A computing system, comprising: one or more ports;a processor; anda non-transitory memory storing instructions that when executed by the processor cause the computing system to perform a method, the method comprising: obtaining, from a first message from a client device, a device identifier of the client device from a first message from the client device, a port identifier of a port of the client device, and an indicator, which is distinct from the device identifier and indicates whether the client device supports dynamic link aggregation;obtaining, from a second message from a remote computing system, the device identifier, wherein the computing system and the remote computing system are in a plug-and-play mode for forming a logical switch;determining that the client device is multi-homed with the computing system and the remote computing system; anddetermine whether the client device supports dynamic link aggregation based on the indicator;in response to the indicator indicating that the client device supports dynamic link aggregation; forming a multi-switch link aggregation for the client device;verify the multi-switch link aggregation based on a dynamic link aggregation protocol for detecting any misconfiguration; andin response to detecting a misconfiguration, generate a notification message for the remote switch regarding the misconfiguration;in response to the indicator indicating that the client device does not support dynamic link aggregation, generate a notification message for the remote switch regarding the multi-switch link aggregation.

18. The computing system of claim 17, wherein the device identifier of the client device is one of: a media access control (MAC) address of the client device and a hash value of the MAC address.

19. The computing system of claim 17, wherein the first message is based on a discovery protocol; and wherein the discovery protocol is one of: Link Layer Discovery Protocol (LLDP);Cisco Discovery Protocol (CDP); andAdvanced Device Discovery Protocol (ADDP).

20. The computing system of claim 17, wherein the first message further comprises one or more of: name and description of the client device;a virtual local area network (VLAN) identifier associated with the port of the client device;an Internet Protocol (IP) management address;capabilities associated with the client device;power management information; and link aggregation information.

21. The computing system of claim 17, wherein the first message received is via a first port of the one or more ports of the computing system; and wherein the method further comprises: obtaining the device identifier of the client device from a third message received via a second port of the one or more ports of the computing system;forming a local link aggregation for the client device using the first and second ports, wherein the local link aggregation is incorporated in the multi-switch link aggregation.

22. The computing system of claim 17, wherein the multi-switch link aggregation is represented by a virtual switch reachable via the computing system and the remote computing system, and wherein the virtual switch is identified by a virtual switch identifier associated with the computing system and the remote computing system.

23. The computing system of claim 22, wherein the method further comprises encapsulating, with an encapsulation header, a data frame received via the multi-switch link aggregation from the client device, wherein the virtual switch identifier is an ingress identifier of the encapsulation header.

24. The computing system of claim 17, wherein the method further comprises maintaining a membership in a network of interconnected switches, wherein the network of interconnected switches is identified by a fabric identifier associated with the computing system and the remote computing system.