Patent Publication Number: US-8526427-B1

Title: Port-based loadsharing for a satellite switch

Description:
FIELD OF THE INVENTION 
     The present invention relates to networking and, more specifically, to load-sharing of redundant links between access-layer satellite switches and distribution-layer switches. 
     BACKGROUND 
     In order to provide increased network reliability, redundant switches and links are often included in a network. If a switch or link fails, a redundant switch or link, already in place within the network, can quickly be enabled to replace the failed switch or link. Since the redundant switch or link can typically be enabled as a replacement more quickly than the failed component can be replaced or repaired, having redundant links and/or switching can provide a more reliable network. 
     When redundant components are included within a network, it is often desirable to be able to use the redundant components during normal network operation, before the failure of corresponding components. For example, if two links are implemented between an access-layer switch in a wiring closet (referred to herein as a satellite switch) and a group of distribution-layer switches, it is desirable to use both links (as opposed to leaving one link idle) to provide increased bandwidth. However, the use of both links can lead to undesirable bridging loops. 
     Bridging loops arise when there are multiple paths between two LANs (Local Area Networks) and those paths are each used to send a copy of the same packet. This can result in the device to which the packet is being sent receiving multiple copies of the packet. If the packet is being broadcast, the use of multiple paths can lead to situations in which the packet is forwarded endlessly, consuming a significant portion of the available network bandwidth and blocking the transmission of other packets. Bridging loops can also lead to network problems by interfering with the ability of network devices to correctly learn the network configuration. Typically, network devices operate by “learning” which LAN includes a particular client device by tracking which of the network device&#39;s ports receives packets sent by that client device. For example, if a copy of the same packet is transmitted via multiple paths to multiple different network devices, one of those network devices may in turn forward its copy back to another one of the network devices that has already received a copy of the packet directly from the client device. As a result, the other network device receives two copies of the packet and incorrectly updates its forwarding information to indicate that the network device should communicate with the client device via the port that received the second copy of the packet. However, the network device&#39;s forwarding information should instead indicate that the network device should communicate with the client device via the port that received the first copy of the packet directly from the client device. The incorrect forwarding information causes the network device to use the wrong port when subsequently attempting to communicate with the client device, which can lead to inefficiencies or even failures in communication. 
     In order to avoid bridging loops that result from using redundant links, a STP (Spanning Tree Protocol) may be used. Typically, a STP identifies multiple paths between a given pair of network nodes and blocks all but one of those paths. Thus, while STP prevents bridging loops, it may also prevent utilization of redundant links between network nodes. A more recent version of STP, which operates on a per-VLAN (Virtual Local Area Network) basis, provides a better solution (VLANs logically separate a single physical LAN into multiple logical LANs). With per-VLAN STP, one redundant link can be blocked for one set of one or more VLANs while the other redundant link is blocked for another set of VLANs. Thus, if there are multiple VLANs implemented, both of the redundant links can be used and bridging loops for each VLAN can be avoided. However, this solution is only available when there are multiple VLANs. If multiple VLANs are not implemented, effective utilization of both redundant links that avoids bridging loops may be difficult. Additionally, the granularity of the load balancing provided by per-VLAN STP is limited to the number of VLANs. The loadsharing provided by per-VLAN STP may also be heavily lopsided if one VLAN carries significantly more traffic than the other VLANs. As the above description shows, existing technologies may not provide desired usage of redundant resources in certain situations. 
     SUMMARY 
     Various embodiments of systems and methods for performing port-based loadsharing in a satellite switch are disclosed. Such systems and methods may be used to achieve better usage of redundant resources than might otherwise be available. 
     A method may involve: receiving a packet (e.g., via a port or uplink interface in a satellite switch) and conveying the packet between one or more ports and one of several uplink interfaces. The one or more ports and the uplink interface are associated with each other. The association can be independent of VLAN (Virtual Local Area Network). As an example, in one embodiment, such a method can involve: receiving a first packet via a first port; conveying the first packet to the distribution-layer via a first uplink interface; receiving a second packet via a second port; and conveying the second packet to the distribution-layer via a second uplink interface, where the first uplink interface is associated with the first port and the second uplink interface is associated with the second port. The first port can be associated with the same VLAN as the second port. By communicating packets between only associated ports and uplink interfaces, undesirable bridging loops can be avoided. Several of the ports can be associated with the same uplink interface, and several uplink interfaces can be associated with the same port. 
     In some embodiments, a system includes several ports, several uplink interfaces, and a local target agent configured to convey packets between the ports and uplink interfaces. The local target agent is configured to convey a packet between one of the ports and one of the uplink interfaces. The one of the ports and the one of the uplink interfaces are associated with each other (e.g., by being assigned to the same virtual linecard). Ports associated with different VLANs can be assigned to the same virtual linecard. 
     The local target agent can use a forwarding index, appended to each packet received via one of the uplink interfaces, to select one or more of the ports from which to output each packet. The local target agent selects one set of ports if a first packet, to which a first forwarding index is appended, is received via one of the uplink interfaces. However, if a second packet to which the first forwarding index is appended is received via a different one of the plurality of uplink interfaces, the local target agent is configured to select a different set of ports. In other words, the same forwarding index may be used differently depending on which uplink interface received that forwarding information. 
     Software implementing a local target agent can be stored upon a computer readable medium. Such software can be configured to detect reception of a packet by a network device, which includes several ports and several uplink interfaces. The software can convey the packet between one or more of the ports and an associated one of the uplink interfaces. 
     The foregoing is a summary and thus contains, by necessity, simplifications, generalizations and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. The operations disclosed herein may be implemented in a number of ways, and such changes and modifications may be made without departing from this invention and its broader aspects. Other aspects of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A more complete understanding of the present invention may be acquired by referring to the following description and the accompanying drawings, in which like reference numbers indicate like features. 
         FIG. 1  is a block diagram of network that includes several distribution-layer switches and several access-layer satellite switches, according to one embodiment. 
         FIG. 2  illustrates a satellite switch coupled to the distribution layer by several links, according to one embodiment. 
         FIG. 3A  is a block diagram of a satellite switch showing how a satellite switch is partitioned into several virtual linecards, each of which acts as a virtual linecard of a different distribution-layer switch, according to one embodiment. 
         FIG. 3B  shows how each virtual linecard implemented in the satellite switch behave as if it were physically included in the distribution-layer switch to which that virtual linecard is assigned, according to one embodiment. 
         FIG. 3C  shows an example of the content of a port-specific register that assigns a satellite switch port to a particular virtual linecard, according to one embodiment. 
         FIG. 4  is a flowchart of one embodiment of a method of performing port-based loadsharing in a satellite switch. 
         FIG. 5  is a flowchart of a method of associating each of several satellite switch ports with a satellite switch uplink interface, according to one embodiment. 
         FIG. 6A  is a flowchart of a method of forwarding a packet from a satellite switch to the distribution layer, according to one embodiment. 
         FIG. 6B  is a flowchart of a method of forwarding a packet from a satellite switch to a client device, according to one embodiment. 
         FIG. 7  is a block diagram of a local target unit included in a satellite switch according to one embodiment. 
         FIG. 8  is a flowchart of a method of operating a satellite switch that implements port-based loadsharing by using virtual-linecard-specific masks to ensure that ports and uplinks included in different virtual linecards do not directly communicate packets, according to one embodiment. 
         FIG. 9A  is a block diagram of a local target unit included in a satellite switch, according to another embodiment. 
         FIG. 9B  illustrates how forwarding indices generated by a distribution-layer switch are modified by the satellite switch in order to ensure that ports and uplinks included in different virtual linecards do not directly communicate packets, according to one embodiment. 
         FIG. 10  is another flowchart of a method of operating a satellite switch that implements port-based loadsharing to ensure that ports and uplinks included in different virtual linecards do not directly communicate packets, according to another embodiment. 
         FIG. 11A  is a block diagram of a satellite switch in which multiple uplinks are assigned to the same virtual linecard, according to one embodiment. 
         FIG. 11B  illustrates local target masks useable in a satellite switch in which multiple uplinks are assigned to the same virtual linecard, according to one embodiment. 
         FIG. 12  is a block diagram of a satellite switch illustrating how a local target agent can be implemented in software executing on the switch, according to one embodiment. 
     
    
    
     While the invention is susceptible to various modifications and alternative forms, specific embodiments of the invention are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the invention to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the invention as defined by the appended claims. 
     DETAILED DESCRIPTION 
       FIG. 1  shows a block diagram of network  100 , which includes several distribution-layer switches  110 A- 110   n  (collectively, distribution-layer switches  110 ) and several satellite switches  150 A- 150   n  (collectively, satellite switches  150 ). Network  100  is configured as a multilayer campus area network that includes a core layer (not shown), a distribution layer that includes distribution-layer switches  110 , and an access layer that includes satellite switches  150 . 
     A distribution-layer switch is a switch that resides at the distribution-layer in the network. In other words, it is a switch with subtended access-layer switches. Distribution-layer switches  110  perform both OSI (Open Systems Interconnection) layer 2 and/or layer 3 switching. 
     A satellite switch is a switch that resides at the access-layer of the network. In many embodiments, satellite switches do not support local switching. For example, in some embodiments, satellite switches  150  rely on distribution-layer switches  110  to perform layer 2 forwarding functions used to determine how to switch the packets (examples of such embodiments are provided in  FIGS. 7-10 ). 
     It is noted that throughout this disclosure, drawing features identified by the same reference number (e.g., distribution-layer switches  110 A- 110   n ) are collectively referred to by that reference number alone (e.g., distribution-layer switches  110 ). Furthermore, while the present invention is described in the context of the particular examples illustrated in  FIGS. 1-12 , the invention is not limited to use in these contexts. 
     Distribution-layer switches  110  are coupled to each other by network  100 . Distribution-layer switches  110  can be coupled to each other directly (e.g., one distribution-layer switch is directly coupled to communicate with another distribution-layer switch) or by core-layer switches (not shown) (e.g., a pair of distribution-layer switches is coupled to communicate with each other via a core-layer switch). 
     Satellite switches  150  are each coupled to at least two distribution-layer switches  110  by links  102 . Many of the distribution-layer switches are included to provide redundancy. For example, distribution-layer switches  110 A and  110 B are redundant with each other. If distribution-layer switch  110 A fails, satellite switches  150 A and  150 B can still communicate with the distribution layer via distribution-layer switch  110 B. Links  102  are Ethernet links in one embodiment. 
     The data received and forwarded by switches  110  and  150  is logically grouped into one or more packets. Throughout this disclosure, the term “packet” is used to refer to a logical grouping of information sent as a data unit over a transmission medium. Packets may include header and/or trailer information that surrounds user data contained in the data unit. For purposes of this disclosure, a “packet” may include a cell, datagram, frame, message, segment, or any other logical group of information. 
     In the illustrated example, each satellite switch (e.g. satellite switch  150 A) is coupled to two distribution-layer switches (e.g., distribution-layer switches  110 A and  110 B) and each distribution-layer switch (e.g., distribution-layer switch  110 A) is coupled to two satellite switches (e.g., satellite switches  150 A and  150 B). In other embodiments, each satellite switch can be coupled to a different number (other than 2) of distribution-layer switches and vice versa. Furthermore, the number of satellite switches per distribution-layer switch can differ from the number of distribution-layer switches per satellite switch. For example, each satellite switch can be coupled to three distribution-layer switches while each distribution-layer switch is coupled to four satellite switches. Additionally, the number of links  102  per satellite switch and/or per distribution-layer switch may vary within the same embodiment (e.g., one satellite switch can have three uplinks to the distribution-layer while another satellite switch has five uplinks). Network  100  can also include different numbers of satellite switches  150  and distribution-layer switches  110  (e.g., the number n of distribution-layer switches can differ from the number n of satellite switches). 
     Having multiple links  102  coupling each satellite switch  150  to the distribution layer provides redundancy in case a link  102  or distribution-layer switch  110  fails. For example, if the link coupling satellite switch  150 B to distribution-layer switch  110 B fails, or if distribution-layer switch  110 B fails, satellite switch  150 B is still able to communicate with the distribution layer via the link to distribution-layer switch  110 A. 
     Each satellite switch  150  uses a port-based loadsharing scheme to utilize the redundant links coupling that satellite switch to the distribution layer. Implementation of the port-based loadsharing scheme involves each satellite switch selecting one of several links  102  on which to send a packet based on which satellite switch port (coupled to one or more network client devices, such as workstations) received that packet. For example, if satellite switch  150 A receives a packet from a workstation, satellite switch  150 A determines whether to send the packet to the distribution layer via the link to distribution-layer switch  110 A or via the link to distribution-layer switch  110 B based on which port received the packet. This determination is independent of which VLAN (Virtual Local Area Network) includes the workstation that sent the packet to satellite switch  150 A. 
     Since port-based loadsharing does not depend on VLAN, all of the redundant links coupling a given satellite switch to the distribution layer can be used even if all of that satellite switch&#39;s ports are coupled to network client devices in the same VLAN. In other words, packets received via different satellite switch ports, each coupled to network client devices in the same VLAN, can be sent to the distribution layer via different links  102 . 
     In some embodiments, a satellite switch  150  implements port-based loadsharing through the use of virtual linecards. The use of virtual linecards prevents bridging loops that could otherwise arise due to usage of the redundant links between satellite switches and the distribution layer. Virtual linecards are described in more detail below with respect to  FIGS. 3A-3B . 
     The satellite switches  150  can be relatively simple switches that do not implement OSI layer 2 forwarding functionality. Instead, satellite switches  150  can depend on distribution-layer switches  110  to perform OSI layer 2 and/or layer 3 forwarding functions and to provide satellite switches  150  with forwarding information indicating the outcome of those forwarding functions. Satellite switches  150  then switch packets based on this forwarding information received from the distribution layer. In such embodiments, satellite switches  150  forward all packets received from network client devices to the distribution layer. The distribution layer determines how those packets will be forwarded through the network (e.g., by deciding whether to forward those packets to other distribution-layer switches  110 , core-layer switches (not shown), or to a set of one or more network client devices via a particular satellite switch  150 . Each distribution-layer switch  110  can perform forwarding functions to select ports in that distribution-layer switch  110  from which to output the packet. These forwarding functions can also select ports in a satellite switch  150  coupled to that distribution-layer switch  110  from which to output the packet. 
     In embodiments in which distribution-layer switches  110  perform OSI layer 2 and/or layer 3 forwarding for satellite switches  150 , satellite switches  150  effectively act as additional ports of distribution-layer switches  110 . For example, if satellite switch  150 A includes eight ports, each coupled to one or more network client devices, that are configured to forward packet to distribution layer switch  110 A via an uplink, the eight ports in satellite switch  150 A are effectively acting as ports of distribution-layer switch  110 A. The use of satellite switches  150 , which can be less expensive than the distribution-layer switches if the satellite switches do not perform layer 2 forwarding, may provide decreased per-port cost relative to the increased features provided by the more-complex distribution-layer switches  110 . Additionally, since more of the high-level functionality is concentrated in the distribution-layer switches  110 , distribution-layer switches  110  provide a more centralized point of management for the layer 2 functionality of network  100 . For example, distribution-layer switches  110  can be located in the same area of the campus linked by the campus area network. In contrast, the satellite switches  150  are likely to be distributed across the campus in various wiring closets. If the layer 2 functionality of the network is concentrated in the distribution-layer switches, patches and upgrades to this functionality can more easily and/or quickly be applied to the distribution-layer switches than they could be applied to both distribution-layer switches  110  and the access-layer satellite switches  150 . For example, a technician could simply apply an upgrade to each of the distribution-layer switches, which can be located in the same building, without also having to go to each wiring closet on the campus to upgrade each access-layer satellite switch. 
       FIG. 2  illustrates satellite switch  150  coupled to the distribution layer by two links, link  102 A and link  102 B. Link  102 A couples satellite switch  150  to distribution-layer switch  110 A, while link  102 B couples satellite switch  150  to distribution-layer switch  110 B. In this example, distribution-layer switches  110 A and  110 B are coupled by redundant links  122 . 
     Distribution-layer switches  110  each include several ports  112 . In this example, distribution-layer switch  110 A includes port  112 A 1  and  112 A 2 , which interface to redundant links  122 , and port  112 A 3 , which interfaces to link  102 A. Collectively, ports  112 A 1 - 112 A 3  are referred to as ports  112 A. Distribution-layer switch  110 B similarly includes ports  112 B 1  and  112 B 2 , which interface to redundant links  122 , and port  112 B 3 , which interfaces to link  102 B. Ports  112 B 1 - 112 B 3  are collectively referred to as ports  112 B. 
     In the illustrated embodiment, satellite switch  150  includes two uplink interfaces  153 A and  153 B (collectively, uplink interfaces  153 ), local target agent  155 , and six ports  151 A- 151 F (collectively, ports  151 ). Local target agent  155  is an example of a means for conveying a packet between ports  151  and uplink interfaces  153 . Ports  151  and uplink interfaces  153  are each examples of means for sending and receiving packets. Each port  151  is coupled to a respective one of network client devices  190 A- 190 F. As used herein, a port in a satellite switch is an interface configured to send and receive packets to and from a network client device  190 A- 190 F. 
     In some embodiments, network client devices  190  each include one or more of various types of computing devices. For example, network client devices  190  can each include one or more of: a switch, a router, a personal computer, a workstation, an Internet server, a network appliance, a handheld computing device such as a cell phone or PDA (Personal Data Assistant), or any other type of computing device. Network client devices  190 A- 190 F each have a unique MAC (Media Access Control) identifier MAC A-MAC F. 
     Each uplink interface  153  is coupled to a respective one of links  102 . Uplink interface  153 A is coupled to communicate with distribution-layer switch  110 A via link  102 A, and uplink interface  153 B is coupled to communicate with distribution-layer switch  110 B via link  102 B. As used herein, an uplink interface in a satellite switch is an interface configured to send and receive packets and associated forwarding information to and from a distribution-layer switch. Note that the configuration of uplink interfaces  153  and ports  151  can be substantially similar. In some embodiments, the same satellite switch interface can be selectively configured (and reconfigured) as either a port or an uplink interface. 
     It is noted that the network configuration shown in  FIG. 2  is provided as an example. In other embodiments, more than one device  190  can be coupled to one of ports  151 . Similarly, other embodiments can implement fewer or additional ports  151  and/or uplink interfaces  153 . 
     To implement port-based loadsharing on links  102 A and  102 B, satellite switch  150  associates each port  151  with one of uplink interfaces  153 . For example, satellite switch  150  can associate ports  151 A,  151 B, and  151 D with uplink interface  153 A, and ports  151 C,  151 E, and  151 F with uplink interface  153 B. In one embodiment, for each port  151 , an association with one of uplink interfaces  153  can be created by setting a register associated with that port to a value that identifies the uplink interface  153  with which that port is associated. 
     Whenever a packet is received from one of devices  190  via one of ports  151 , satellite switch  150  selects an uplink interface from which to output that packet based on which uplink interface is associated with the port received that packet. Thus, if a packet is received via port  151 A and port  151 A is associated with uplink interface  153 A, satellite switch  150  outputs that packet to the distribution layer via uplink interface  153 A. 
     In some embodiments, the associations between uplink interfaces  153  and port  151  can be updated at various times during the operation of satellite switch  150 . For example, if link  102 B fails and ports  151 C,  151 E, and  151 F are associated with uplink interface  153 B, satellite switch  150  may reassociate those ports with uplink interface  153 A, which is coupled to non-failed link  102 A. 
     When satellite switch  150  outputs a packet to the distribution layer via uplink interface  153 A or uplink interface  153 B, satellite switch  150  can also append information identifying which of ports  151  received that packet. This information can be used by distribution-layer switches  110  to learn the configuration of network  100  and to subsequently make forwarding decisions for satellite switches  150 , as described in more detail below. 
     Each distribution-layer switch  110  includes a respective forwarding agent  114  and a respective local target agent  116 . Forwarding agent  114 A is configured to make forwarding decisions for distribution-layer switch  110 A, and forwarding agent  114 B is configured to make forwarding decisions for distribution-layer switch  110 B. In one embodiment, forwarding agents  114  perform OSI layer 2 forwarding based on MAC identifiers. Forwarding agent  114 B tracks which port  112 B of distribution-layer switch  110 B is used to communicate with a network client device having a particular MAC address by observing which port  112 B receives packets sent by that network client device. For example, forwarding agent  114 B can assign one or more unique forwarding indexes or other forwarding information to each port  112 B. This assignment is tracked by local target agent  116 B. If a packet is received from the network client device having a particular MAC address via port  112 B 3 , forwarding agent  114 B associates the forwarding index assigned to port  112 B 3  with the MAC address (e.g., the forwarding index is stored in a forwarding table entry indexed by the MAC address). If a subsequent packet is received that specifies that MAC address as its destination, forwarding agent  114 B outputs the associated forwarding index to local target agent  116 B. Since the forwarding index is assigned to port  112 B 3 , local target agent  116 B outputs the subsequent packet from port  112 B 3 . 
     In this example, satellite switch  150  includes local target agent  155 , which may operate similarly to local target agents  116 . Unlike local target agents  116  in distribution-layer switches  110 A and  110 B, however, local target agent  155  does not include any layer 2 forwarding functionality. Instead, satellite switch  150  relies on distribution-layer switches  110 A and  110 B to make forwarding decisions. Each distribution-layer switch  110  configures satellite switch  150  to respond properly to forwarding decisions made by the forwarding agent  114  in that distribution-layer switch. For example, forwarding agents  114 A and  114 B in distribution-layer switches  110 A and  110 B can each assign a forwarding index to each port  151  in satellite switch  150 . Local target agent  155  in satellite switch  150  maintains these assignments. Each distribution-layer switch  110  appends the appropriate forwarding index to each packet sent to satellite switch  150 . When satellite switch  150  receives the packet and the associated forwarding index, local target agent  155  causes the packet to be output from the port (or ports)  151  associated with that forwarding index. 
     It is noted that local target agent  155  and local target agents  116  are each “local” in the sense that each forwards packets to a switch&#39;s output ports based on how forwarding indices are assigned to ports that are local to (i.e., physically included within) that switch. Thus, local target agent  116 A maintains forwarding index assignments for ports  112 A 1 - 112 A 3  (collectively, ports  112 A) within distribution-layer switch  110 A. Similarly, local target agent  116 B maintains forwarding index assignments for ports  112 B 1 - 112 B 3  (collectively, ports  112 B) within distribution-layer switch  110 B. Local target agent  155  in satellite switch  150  maintains forwarding index assignments for uplink interfaces  153  and ports  151 . Local target agent  155  differs from local target agents  116  included in distribution-layer switches  110  because local target agent  155  stores forwarding index assignments generated by multiple different forwarding agents  114 , each of which is included in a different physical switch than local target agent  155 . In contrast, each local target agent  116  maintains forwarding index assignments generated by a single forwarding agent  114  that is included in the same switch as that local target agent  116 . 
     As an example of how a forwarding agent  114  in a distribution-layer switch  110  can perform forwarding decisions for a satellite switch, assume forwarding agent  114 A in distribution-layer switch  110 A assigns forwarding index  1  to port  151 B of satellite switch  150  (this assignment is maintained by local target agent  155  in satellite switch  150 ) and to port  112 A 3  of distribution-layer switch  110 A (this assignment is maintained by local target agent  116 A in distribution-layer switch  110 A). Since forwarding index  1  identifies satellite switch port  151 B and port  112 A 3 , forwarding agent  114 A will associate this forwarding index with the MAC addresses of devices that communicate with port  151 B of satellite switch  150 . For example, satellite switch  150  can append information identifying port  151 B to a packet received via port  151 B from device  190 B. Forwarding agent  114 A can then associate forwarding index  1  with MAC B of device  190 B in response to receiving, via port  112 A 3 , a packet and the information identifying port  151 B from satellite switch  150 . If distribution-layer switch  110 A receives a subsequent packet addressed to MAC B, forwarding unit  114 A causes index  1  to be appended to the packet due to index  1 &#39;s association with MAC B. In response to index  1  being appended to the packet and index  1  being assigned to port  112 A 3 , local target agent  116 A in distribution-layer switch  110 A outputs the packet and the appended forwarding index via port  112 A 3 . Uplink interface  153 A of satellite switch  150  receives the packet and appended forwarding index  1  via link  102 A. In response to forwarding index  1  being assigned to port  151 B, local target agent  155  outputs the packet to device  190 B via port  151 B. Satellite switch  150  may remove the appended forwarding index before outputting packets to devices  190 . 
     Since each distribution-layer switch  110 A and  110 B assigns a forwarding index to each port  151  in satellite switch  150 , the possibility exists that each distribution-layer switch will assign the same forwarding index to a different port or set of ports in satellite switch  150 . For example, distribution-layer switch  110 A can assign forwarding index  1  to port  151 A while satellite switch  110 B assigns forwarding index  1  to port  151 C. In some embodiments, distribution-layer switches  110  are configured to negotiate forwarding index assignments between each other to avoid conflicting assignments. In other embodiments, satellite switch  150  is configured to handle forwarding indices in a way that allows conflicting assignments. In such embodiments, satellite switch  150  uses the same forwarding index differently depending on which uplink interface  153  received a packet to which that forwarding index was appended. For example, assuming the above conflicting assignment of forwarding index  1 , if a packet to which forwarding index  1  is appended is received via uplink interface  153 A, local target agent  155  uses the assignment generated by distribution-layer switch  110 A and causes the packet to be output via port  151 A. If instead a packet to which forwarding index  1  is appended is received via uplink interface  153 B, local target agent  155  uses the assignment generated by distribution-layer switch  110 B and causes the packet to be output via port  151 C. Various techniques for handling conflicting forwarding index assignments in satellite switch  150  are described below with respect to  FIGS. 7-10   
     In some embodiments, associations between satellite switch ports and satellite switch uplink interfaces are created by assigning each port and uplink interface to a virtual linecard.  FIG. 3A  is a block diagram of satellite switch  150  showing how satellite switch  150  is partitioned into several virtual linecards  300 A and  300 B (collectively, virtual linecards  300 ), each of which acts as a virtual linecard of a different distribution-layer switch  110 . In this embodiment, satellite switch  150  associates each of ports  151  with one of uplink interfaces  153  by assigning each port and each uplink interface to a particular virtual linecard. For example, satellite switch  150  associates port  151 A with uplink interface  153 A by assigning port  151 A to the same virtual linecard  300 A as uplink interface  153 A. As mentioned above, such an association between a port and an uplink interface allows the satellite-switch to implement port-based loadsharing. 
     In the example of  FIG. 3A , each port  151 A- 151 F is associated with a respective register  310 A- 310 F. Each port  151  is assigned to a virtual linecard  300 A or  300 B by setting a value in the register  310  associated with that port. For example, port  151 C can be assigned to virtual linecard  300 A by setting register  310 C to a value indicative of virtual linecard  300 A. An example of the values that can be stored in registers  310  is described below with respect to  FIG. 3C . Registers  310 A- 310 F are examples of means for associating a port with an uplink interface. 
     Each virtual linecard  300  is associated with a particular distribution-layer switch  110 . The number of virtual linecards  300  that can be implemented by satellite switch  150  depends on the number of uplink interfaces included in that satellite switch. The maximum number of virtual linecards  300  is implemented when each uplink interface  153  is coupled to a different distribution-layer switch. The minimum number of virtual linecards  300  is implemented when all uplink interfaces are coupled to the same distribution-layer switch (or when the only uplink interfaces not coupled to the same distribution-layer switch are unused). The assignment of uplink interfaces to virtual linecards thus depends on which distribution-layer switch each uplink interface is coupled to communicate with. For example, if uplink interface  153 A is coupled to a different distribution-layer switch  110  than uplink interface  153 B, then uplink interface  153 A is assigned to a different virtual linecard than uplink interface  153 B. If instead uplink interface  153 A had been coupled to communicate with the same distribution-layer switch as uplink interface  153 B, both uplink interfaces would be assigned to the same virtual linecard. 
     Satellite switch  150  can dynamically reassign ports  151  to different virtual linecards. For example, port  151 A can be reassigned to virtual linecard  300 B by setting register  310 A to a value indicating virtual linecard  300 B. Reassignment can occur for a variety of different reasons. In some embodiments, satellite switch  150  reassigns ports  151  to another virtual linecard in response to the failure of a link or distribution-layer switch. For example, if distribution-layer switch  110 A, which is coupled to uplink interface  153 A, fails, ports  151 A- 151 C can be reassigned to virtual linecard  300 B. Reassignment can also occur in response to traffic conditions in some embodiments. For example, if virtual linecard  300 A is experiencing more traffic than virtual linecard  300 B for an extended period of time, one or more ports currently assigned to virtual linecard  300 A can be reassigned to virtual linecard  300 B. 
     As shown in  FIG. 3B , each virtual linecard of satellite switch  150  can be logically viewed as a linecard of a respective distribution-layer switch. While both virtual linecards share the same local target agent (as shown in  FIG. 2 ) and are implemented in the same physical access-layer satellite switch, the virtual linecards behave as if they are physically included in different distribution-layer switches. 
     Each distribution-layer switch  110  is configured to control the satellite switch ports and uplink interfaces included in a respective virtual linecard within satellite switch  150 . For example, distribution-layer switch  110 A controls ports  151 A- 151 C and uplink interface  153 A in virtual linecard  300 A. A distribution-layer switch  110  controls satellite switch ports and uplink interfaces by, among other things, assigning a forwarding index to each port and uplink interface in that virtual linecard and by making forwarding decisions for packets received via satellite switch ports in that virtual linecard. It is noted that a distribution-layer switch can control a virtual linecard in each of several satellite switches. 
     The use of virtual linecards allows conflicting forwarding index assignments to be handled by providing local target agent  155  (as shown in  FIG. 2 ) with a mechanism for distinguishing between forwarding assignments generated by different distribution-layer switches. For example, local target agent  155  can maintain separate forwarding index assignments for each virtual linecard. Whenever a packet is received from the distribution layer, local target agent  155  can decide which set of forwarding index assignments to use based on which virtual linecard includes the uplink interface that received the packet. In an alternative embodiment, forwarding index assignments for the different virtual linecards are collectively maintained, and a virtual-linecard-specific mask is used to handle conflicting forwarding index assignments (this embodiment is described with respect to  FIGS. 7-8 ). In yet another embodiment, satellite switch  150  may map a forwarding index into a virtual-linecard-specific forwarding index space dependent on which virtual linecard includes the uplink interface that received the forwarding index from the distribution layer (this embodiment is described with respect to  FIGS. 9A-10 ). 
     Using virtual linecards can also prevent erroneous packet deliveries and/or bridging loops that might otherwise occur if copies of the same packet are received from the distribution layer via more than one of the satellite switch&#39;s uplink interfaces. For example, assume port  151 B receives from device  190 B a packet having a destination MAC address that the distribution-layer switch forwarding agent  114 A has not yet been associated with a port (e.g., the device having that MAC address may not have sent any packets yet) and that all ports  151  in satellite switch  150  are associated with the same VLAN (and thus all of ports  151  are identified by the flood index for that VLAN). Because port  151 B is associated with uplink  153 A by their inclusion in the same virtual linecard, satellite switch  150  outputs the packet via uplink interface  153 A. When distribution-layer switch  110 A (as shown in  FIG. 2 ) receives the packet, forwarding agent  114 A outputs the flood index for the VLAN in which device  190 B is included. This flood index may cause local target logic  116 A in distribution-layer switch  110 A to output the packet from port  112 A 3  and from one of ports  112 A 1  and  112 A 2 . When distribution-layer switch  110 B receives the packet, its forwarding agent  114 B may also append a flood index for the VLAN to the packet, which in turn causes local target logic  116 B to output the packet and flood index via port  112 B 3  to satellite switch  150 . Thus, satellite switch  150  may receive two copies of the packet—one copy via uplink interface  153 A and the other copy via uplink interface  153 B. If the satellite switch does not handle the packet differently depending on which virtual linecard received the packet, and if all of the satellite switch ports are assigned to the same VLAN, local target agent  155  will respond to the flood index appended to each copy of the packet by outputting each copy of the packet from all of the ports  151  (other than the original port that received the packet from device  190 B). If a sequence of packets is being sent, this could result in packets being output to devices  190  out of order (e.g., this situation could arise if one uplink interface receives a copy of a particular packet in the sequence before the other uplink interface receives a copy of an earlier packet in the sequence). Additionally, the packet could be resent to distribution layer (e.g., the copy received via uplink interface  153 A could be output via uplink interface  153 B and the copy received via uplink interface  153 B could be output via uplink interface  153 A), causing undesirable bridging loops. 
     To avoid these potential problems, forwarding of a packet from one of uplink interfaces  153  to one of ports  151  is conditioned on whether the uplink interface that received the packet is included in the same virtual linecard as the port. If the uplink is included in the same virtual linecard as the port, the packet can be forwarded to the port. Otherwise, the packet cannot be forwarded to the port. Thus, using the above example, when the copy of the packet and the associated flood index are received via uplink interface  153 A, local target agent  155  only outputs the packet from ports  151 A and  151 C, which are included in the same virtual linecard as uplink interface  153 A (port  151 B, which originally received the packet from device  190 B, and uplink interface  153 A, which received the packet from the distribution layer, are excluded from the set of destinations by normal forwarding techniques). Similarly, when the copy of the packet and the associated flood index are received via uplink interface  153 B, local target agent  155  only outputs the packet from ports  151 D- 151 F included in the same virtual linecard as uplink interface  153 B (again, uplink interface  153 B, which received the packet from the distribution layer, is excluded from the set of destinations by normal forwarding techniques). Thus, through the use of virtual linecards, bridging loops are avoided and each network client device  190  is only sent one copy of the packet. 
       FIG. 3C  shows an example of the content of a port-specific register  310  used to assign a port  151  to a particular virtual linecard. In this example, register  310  includes a value  312  indicative of the forwarding index assigned to the port  151  with which register  310  is associated. This forwarding index can be assigned by a forwarding agent  114  in a distribution-layer switch  110  (since each port can only be included in one virtual linecard at a given time, only one distribution-layer switch can assign a forwarding index to that port at any given time). Register  310  also includes a value  314  identifying the uplink with which the port  151  is associated. This value  314  assigns the port  151  to the same virtual linecard as the identified uplink interface and also assigns that uplink interface to the same virtual linecard as the port. 
       FIG. 4  is a flowchart of one embodiment of a method of performing port-based loadsharing in a satellite switch. At  401 , each of the satellite switch&#39;s ports are associated with one of the satellite switch&#39;s uplink interfaces. This involves setting a register associated with each port to a value identifying the uplink interface with which that port is to be associated in some embodiments. Associating satellite switch ports with satellite switch uplink interfaces is independent of VLAN; a port coupled to devices in one VLAN can be associated with the same uplink interface as another port that is coupled to devices in a different VLAN. 
     In one embodiment, an association between a port and an uplink interface is created by assigning the port to the same virtual linecard as the uplink interface with which the port is to be associated. In one embodiment, if fewer than all of the ports in a satellite switch are used (e.g., coupled to send and receive packets to and from devices), associations with uplink interfaces are not created for the unused ports. Similarly, some embodiments do not associate any ports with unused uplink interfaces. 
     As indicated at  403 , packet communication is allowed between associated ports and uplink interfaces. For example, if a packet is received from a network client device via a port, that packet may be forwarded to the distribution layer by the uplink interface with which the receiving port is associated. If a packet and its associated forwarding information (e.g., a forwarding index) are received via an uplink interface, and if that forwarding information indicates that the packet should be output from a particular port, the packet will be output from the indicated port as long as the port is associated with the uplink interface. 
     Packet communication between non-associated ports and uplink interfaces is blocked, as indicated at  405 . For example, if a packet is received via particular port, that packet will not be output via any uplink interface that is not associated with the port that received the packet. Similarly, if a packet and associated forwarding information are received via an uplink interface, that packet will not be output via any port or uplink interface that is not associated with that uplink interface, even if the forwarding information identifies non-associated ports and/or uplink interfaces. 
       FIG. 5  shows how satellite switch ports can be associated with satellite switch uplink interfaces (as shown in function  401  of  FIG. 4 ) in order to implement port-based loadsharing. At  501 , each port in a satellite switch is assigned to a virtual linecard. Each uplink interface is assigned to a virtual linecard at  503 . Together, functions  501  and  503  operate to create an association between a port and an uplink interface; if a port is assigned to the same virtual linecard as an uplink interface, that port is associated with that uplink interface for purposes of port-based loadsharing. If a port is assigned to a different virtual linecard than an uplink interface, that port is not associated with that uplink interface for port-based loadsharing purposes. A port can be assigned to a virtual linecard by setting a register value associated with the port to identify a particular uplink interface. An uplink interface is assigned to a virtual linecard based on which ports have registers identifying that uplink interface and which other uplink interfaces, if any, are coupled to communicate with the same distribution-layer switch as that uplink interface. For example, an uplink interface is assigned to the same virtual linecard as any port whose associated register identifies the uplink interface and to the same virtual linecard as any other uplink interface coupled to communicate with the same distribution-layer switch. 
       FIG. 6A  is a flowchart of a method of forwarding a packet from a satellite switch to a distribution-layer switch, according to one embodiment. In this example, a satellite switch receives a packet via one of several ports, as indicated at  603 . Dependent on which port received the packet, an uplink interface is selected from which to output the packet to the distribution layer. An uplink interface in the same virtual linecard as the port that received the packet is selected, as indicated at  605 . The packet is blocked from being output from any uplink interface that is not included in the same virtual linecard as (or otherwise associated with) the port that received the packet. 
       FIG. 6B  is a flowchart of a method of forwarding a packet from a satellite switch to a client device, according to one embodiment. Here, a packet and appended forwarding information (e.g., a forwarding index as described above) are received from the distribution-layer-via an uplink interface, as indicated at  613 . The packet is then output from one or more ports (which are identified by port-identifying information, maintained within the satellite switch, that is selected by the appended forwarding information) included in the same virtual linecard as the uplink interface that received the packet, as indicated at  615 . The packet is blocked from being output from any port that is not included in the same virtual linecard as (or otherwise associated with) the uplink interface that received the packet, even if such ports are included in the port-identifying information selected by the forwarding information appended to the packet. 
       FIG. 7  is a block diagram of local target agent  155  included in satellite switch  150 . In this example, local target agent  155  includes local target table  756  and local target masks  757 . Local target table  756  stores associations between groups of one or more ports and forwarding indices generated by forwarding agents  114 A and  114 B of distribution-layer switches  110 A and  110 B (as shown in  FIG. 2 ). It is noted that in other embodiments, local target table  756  may store associations between ports and forwarding indices generated by more than two different distribution-layer switches  110 . 
     In this example, the associations are stored as bitmaps that are indexed by the various forwarding indices, Index  1 -Index  12  (other embodiments can use significantly more forwarding indices). Each bitmap includes a bit for each port  151 A- 151 F and uplink interface  153 A- 153 B. When a bit is set in a particular bitmap, it indicates that the corresponding port or uplink interface is associated with the forwarding index that indexes that bitmap in the local target table  756 . For example, in the bitmap associated with Index  1 , the bit corresponding to port  151 A is set, indicating that Index  1  is associated with port  151 A. When a packet having forwarding information that includes Index  1  is received via an uplink interface, local target agent  155  looks up which ports correspond to Index  1  in local target table  756 . Since local target table indicates that port  151 A is associated with Index  1  in local target table  756 , local target agent causes that packet to be output from port  151 A (assuming that the uplink interface is in the same virtual linecard as (or otherwise associated with) port  151 A). 
     Each distribution-layer switch can be configured to only generate forwarding indices for ports included in the virtual linecard associated with that distribution-layer switch. For example, distribution-layer switch  110 A (as shown in  FIG. 2 ) is configured to only generate forwarding indices for ports  151 A,  151 B, and  151 C, which are included in virtual linecard  300 A, and distribution-layer switch  110 B (as shown in  FIG. 2 ) is configured to only generate forwarding indices for ports  151 D,  151 E, and  151 F, which are included in virtual linecard  300 B. Local target agent  155  can enforce this rule by preventing each distribution-layer switch from setting bits in local target table  756  that identify ports that are not included in a virtual linecard controlled by that distribution-layer switch. 
     Different distribution-layer switches can associate the same forwarding index with a different port or group of ports. For example, as shown in  FIG. 7 , distribution-layer switch  110 A may assign Index  2  to port  151 B, and distribution-layer switch  110 B can assign Index  2  to a multicast group that includes ports  151 D and  151 F. In one embodiment, local target agent  155  logically ORs the distribution-layer switch-specific bitmaps associated with the same forwarding index, and thus Index  2  has a resulting bitmap in which the bits for ports  151 B,  151 D, and  151 F are set. The distribution-layer switches  110  can, in at least some embodiments, use the same forwarding index as a flood index. For example, both distribution-layer switch  110 A and distribution-layer-switch  110 B can use Index  8  as a flood index for a VLAN that includes network client devices coupled to ports  151 A,  151 B,  151 C, and  151 E. Similarly, both distribution-layer switches can use Index  9  as a flood index for a VLAN that includes network client devices coupled to ports  151 D and  151 F. The bitmap for each VLAN-specific flood index will include each port that is coupled to a network client device  190  in that VLAN, regardless of which virtual linecard includes that port. 
     In  FIG. 7 , twelve forwarding indices and their associated bitmaps are shown in local target table  756 . It is noted that other embodiments can support different numbers of forwarding indices than are shown here, and that the bitmaps illustrated in this figure are merely provided as an example. In this example, Index  1  is associated with a bitmap that selects port  151 A in virtual linecard  300 A. No ports in virtual linecard  300 B are selected by Index  1 . Index  2  selects port  151 B in virtual linecard  300 A and ports  151 D and  151 F in virtual linecard  300 B. Index  3  selects port  151 C in virtual linecard  300 A and port  151 D in virtual linecard  300 B (e.g., because distribution-layer switch  110 A assigned Index  3  to port  151 C and distribution-layer switch  110 B assigned Index  3  to port  151 D). Index  4  selects a multicast group that includes ports  151 B and  151 C in virtual linecard  300 A. Index  4  also selects port  151 E in virtual linecard  300 B. Index  5  selects port  151 F in virtual linecard  300 B. Index  6  is unused in this example. Index  7  selects a multicast group that includes ports  151 A and  151 C in virtual linecard  300 A. In this example, Index  8  is a flood index for a VLAN. Ports  151 A,  151 B,  151 C, and  151 E are included in that VLAN. Index  9  is the flood index for another VLAN, which includes ports  151 D and  151 F. Index  10  selects uplink interface  153 B in virtual linecard  300 B. Index  11  selects uplink interface  153 A in virtual linecard  300 A. 
     Local target agent  155  includes a storage  757  that stores a local target mask for each virtual linecard (VLC)  300  implemented by satellite switch  150 . The local target mask for virtual linecard  300 A selects, ports  151 A- 151 C and uplink interface  153 A. The local target mask for virtual linecard  300 B selects ports  151 D- 151 F and uplink interface  153 B. 
     In situations in which the same forwarding index is used differently by different distribution-layer switches, local target agent  155  uses local target masks  757  to modify the bitmap associated with that forwarding index in order to isolate the bitmap generated by a particular distribution-layer switch. For example, if a packet having forwarding Index  2  is received via uplink interface  153 A from distribution-layer switch  110 A, local target agent  155  may retrieve the bitmap associated with Index  2  from local target table  756  and select the mask associated with the virtual linecard  300 A that includes uplink interface  153 A from local target masks  252 . Local target agent  155  then bitwise logically ANDs the mask associated with virtual linecard  300 A with the bitmap associated with Index  2 . The resulting bitmap has a single set bit, associated with port  151 B, (the bits associated with ports  151 D and  151 F are cleared by the application of the mask associated with virtual linecard  300 A). Based on this resulting bitmap, local target agent  155  causes the received packet to be output from port  151 B. If instead the packet had been received via uplink interface  153 B, local target agent  155  would have selected and applied the mask associated with virtual linecard  300 B, which includes uplink interface  153 B, to the bitmap selected by Index  2 . In this situation, the bits associated with ports  151 D and  151 F would be set in the resulting bitmap and the bit associated with port  151 B would be cleared. In response, local target agent  155  would have caused the packet to be output from ports  151 D and  151 F. Local target agent  155  can process other forwarding indices similarly. 
     In alternative embodiments, local target agent  155  can maintain a separate local target table  756  for each virtual linecard implemented by that satellite switch. Local target agent  155  selects which local target table to access based on which uplink interface received a packet and appended forwarding index. Local target agent  155  uses the appended forwarding index to select a bitmap in the local target table associated with the virtual linecard that includes the uplink interface that received the packet to which the forwarding index is appended. In such an embodiment, local target masks  757  may not be needed. 
       FIG. 8  is a flowchart of a method of operating a satellite switch that implements port-based loadsharing by using virtual-linecard-specific masks to ensure that ports and uplinks included in different virtual linecards do not directly communicate packets. At  801 , a satellite switch receives a packet and appended forwarding information (e.g., a forwarding index). As mentioned above, in at least some embodiments, the satellite switch lacks any OSI Layer 2 forwarding logic; as a result, the satellite switch relies on a distribution-layer switch to performing Layer 2 forwarding operations and to append forwarding information to each packet to indirectly indicate the ports selected by the forwarding operations. 
     At  803 , the satellite switch uses the forwarding information appended to the packet to select one of several bitmaps (or other sets of port-identifying information usable to identify the ports from which the packet should be output) maintained within the satellite switch. The appended forwarding information identifies the bitmap to select (e.g., an appended forwarding index can select a bitmap in a lookup table). In one embodiment, each bitmap includes a bit for each port and each uplink interface in the satellite switch. If a particular bit in a bitmap selected by the forwarding information is set, it indicates that the port or uplink represented by that bit is a destination port or uplink of the packet (assuming that port or uplink is included in the same virtual linecard as the uplink that received the packet). 
     Dependent on which virtual linecard includes the uplink interface that received the packet, at  805  one of several masks is selected to apply to the bitmap or other port-identifying information selected at  803 . For example, each virtual linecard can have an associated mask that, when applied to a bitmap, selects only those ports and uplink interfaces included in that virtual linecard. By masking out ports and uplink interfaces identified in the bitmap but not included in the same virtual linecard as the uplink interface that received the packet, port-identifying information identified by the same forwarding information but generated for another virtual linecard can be removed. This allows different distribution-layer switches to use the same forwarding information to identify different sets of port-identifying information, which can simplify distribution-layer switch overhead. For example, distribution-layer switches can assign forwarding information to identify sets of port-identifying information independently without needing to coordinate assignments with each other. 
     At  807 , the mask, selected at  805 , is applied to the bitmap, selected at  803 , to produce a masked bitmap. The masked bitmap identifies the destination ports for the packet. These destination ports are those ports that are both identified in the bitmap selected by the forwarding information and included in the same virtual linecard as the uplink interface. The packet is then output from the ports identified by the masked bitmap at  809 . 
     Other embodiments can handle conflicting forwarding information assignments without using masks.  FIG. 9A  is a block diagram of a local target agent  155  included in a satellite switch, according to another embodiment. In this embodiment, index modification unit  958  in local target agent  155  is configured to modify the forwarding indices received with packets from the distribution-layer switches before using the forwarding indices to select bitmaps in the local target table. The modification to apply to a given forwarding index depends on which distribution-layer switch generated the forwarding index. After forwarding index modification, no forwarding indices input to local target table  756  are shared between multiple distribution-layer switches. For example, distribution-layer switch  110 A may assign Index  1  to one port and distribution-layer switch  110 B may assign Index  1  to a different port. Index modification unit  958  can be configured to remap Index  1  to Index  11  if Index  1  is appended to a packet received from distribution-layer switch  110 A and to not remap Index  1  if Index  1  is appended to a packet received from distribution-layer switch  110 B. Index  11  can select the port-identifying information (e.g., a bitmap in local target table  756 ) associated with Index  1  by distribution-layer switch  110 A and Index  1  can select the port-identifying information associated with Index  1  by distribution-layer switch  110 B. 
       FIG. 9B  provides an example of how forwarding indices generated by two distribution-layer switches, switches  110 A and  110 B, can be modified by index modification unit  958  in satellite switch  150 . Here, forwarding indices are remapped in blocks of 4K. There are five 4K-sized regions of forwarding indices used by each distribution-layer switch: the region beginning at 0x8000 corresponds to unicast flood, the region beginning at 0x9000 corresponds to multicast flood without router, the region beginning at 0xA000 corresponds to unicast flood protection, the region beginning at 0xC000 corresponds to multicast flood, the region beginning at 0xE000 corresponds to multicast flood, and the regions beginning at 0xB000, 0xD000, and 0xF000 are unused. In this example, the regions corresponding to broadcast flood and multicast flood without router always have the same port selections, and thus, for each distribution-layer switch, these two regions (beginning respectively at 0x8000 and 0x9000) are mapped to the same region within the satellite switch. 
     For the indices generated by distribution-layer switch  110 A, index modification unit  958  maps the regions beginning at 0x8000 and 0x9000 (which each have identical port selections, as described above) to the region beginning at 0x8000. For distribution-layer switch  110 B, these same regions are mapped to the region beginning at 0xC000. Index modification unit  958  maps indices in the region beginning at 0xA000 and generated by distribution-layer switch  110 A to the region beginning at 0x9000. Indices generated by distribution-layer switch  110 B in the same region are remapped to the region beginning at 0xD000. Index modification unit  958  maps indices in the region beginning at 0xC000 and generated by distribution-layer switch  110 A to the region beginning at 0xA000. Indices generated by distribution-layer switch  110 B in the same region are remapped to the region beginning at 0xE000. Index modification unit  958  maps indices in the region beginning at 0xE000 and generated by distribution-layer switch  110 A to the region beginning at 0xB000. Indices generated by distribution-layer switch  110 B in the same region are remapped to the region beginning at 0xF000. The remapped indices are then used by local target agent  155  to index into a local target table. Since each remapped index is unique to a given virtual linecard, there is no need for local target masks like those shown in  FIG. 7 . 
     In embodiments such as the one described with respect to  FIGS. 9A and 9B , the coordination of forwarding index assignment can be simplified by restricting the number of distribution-layer switches that can be simultaneously coupled to a given satellite switch. For example, in one embodiment, no more than two distribution-layer switches are allowed to couple to the same satellite switch at a given time. This allows the local target agent  155  in the satellite switch to be configured to more efficiently handle remapping or otherwise modifying forwarding indices generated by the different distribution-layer switches. For example, index modification unit  958  will not need to be able to generate and apply mappings for variable numbers of distribution-layer switches. Thus, instead of including complex logic and/or software configured to handle two, three, four, or more distribution-layer switches, index modification unit  958  can be configured with simpler and/or more efficient logic and/or software configured to handle at most two distribution-layer switches. 
       FIG. 10  is another flowchart of a method of operating a satellite switch that implements port-based loadsharing and that handles conflicting forwarding index assignments by mapping each distribution-layer switches forwarding index assignments to a particular range of forwarding indices. At  1001 , a packet and appended forwarding information (e.g., a forwarding index) are received via an uplink interface in a satellite switch. The forwarding information is modified dependent upon which virtual linecard includes the uplink interface that received the packet, as shown at  1003 . For example, if the forwarding information is a forwarding index, the forwarding index can be remapped differently depending on the virtual linecard. In the example of  FIG. 9 , a forwarding index in the region 0x8000 can be remapped to either a corresponding forwarding index in the region 0x8000 if the forwarding index is received by an uplink interface in the virtual linecard controlled by distribution-layer switch  110 A or to an index in the region 0xC000 if the forwarding index is received by an uplink interface in the virtual linecard controlled by distribution-layer switch  110 B. 
     At  1005 , the modified forwarding information (e.g., the remapped forwarding index) is used to select one of several bitmaps or other sets of port-identifying information. Each bitmap or other set of port-identifying information identifies a set of one or more ports. The packet to which the forwarding information is appended is output from the one or more ports identified in the bitmap or other port-identifying information selected by the modified forwarding information, as indicated at  1007 . 
     The embodiment described with respect to FIGS.  7  and  9 A- 9 B allow distribution-layer switches to assign forwarding indices to satellite switch ports without needing to coordinate forwarding index assignment with other distribution-layer switches. Other embodiments involve distribution-layer switches  110 A and  110 B that are coupled to a particular satellite switch  150  coordinating forwarding index assignment for that satellite switch among each other. This coordination can take place directly between distribution-layer switches that are coupled to the same satellite switch or indirectly by coordinating with a centralized forwarding index manager (e.g., implemented in the local target agent of the satellite switch for which the forwarding index assignment is being coordinated). In one such embodiment, when a distribution-layer switch is coupled to a satellite switch, the distribution-layer switch determines the local target index range used for satellite switch ports controlled by other distribution-layer switches. The distribution-layer switch can, for example, query the local target agent in the satellite switch for information about which ranges of forwarding indices are currently assigned to other distribution-layer switches. The distribution-layer switch then allocates its own range of local target indices by requesting a block of local target indices from the local target agent. If this block overlaps with any range of local target indices used by another distribution-layer switch, the distribution-layer switch requests another range of local target indices from the local target agent (the overlapping block is not released, however). This process repeats until the distribution-layer switch finds a non-overlapping block of local target indices or until the local target manager no longer has any free local target indices. Upon allocating a range of local target indices (or upon discovering that no non-overlapping range exists), the overlapping blocks are released back to the local target agent. 
       FIG. 11A  is a block diagram of a satellite switch in which multiple uplinks are assigned to the same virtual linecard, according to one embodiment. In this embodiment, the assignment of uplink interfaces  153  and ports  151  to virtual linecards  300  is the same as that shown in  FIG. 3A , except that an additional uplink interface  153 C has been assigned to virtual linecard  300 B. The two uplink interfaces  153 B and  153 C included in virtual linecard  300 B form an uplink group to the same distribution-layer switch (e.g., distribution-layer switch  110 B as shown in  FIG. 2 ). Multiple uplink interfaces can be coupled to the same distribution-layer switch to provide additional bandwidth and/or reliability between that distribution-layer switch and satellite switch  150 . 
     For port-based loadsharing purposes, uplink interfaces  153 B and  153 C are associated with ports  151 D- 151 F by virtue of being assigned to the same virtual linecard  300 B. Assignment to the same virtual linecard can involve: setting a register associated with each of ports  151 D- 151 F to a value identifying either or both uplink interfaces  153 B and  153 C, setting a register associated with each of uplink interfaces  153 B and  153 C to a value indicating that both uplink interfaces are coupled to the same distribution-layer switch, and/or associating the same local target mask with each uplink interface  153 B and  153 C. As shown in  FIG. 11B , the local target mask associated with uplink interfaces  153 B and  153 C selects all of the ports and uplink interfaces assigned to virtual linecard  300 B: port  151 D, port  151 E, port  151 F, uplink interface  153 B, and uplink interface  153 C. 
     Traffic in virtual linecard  300 B can be configured so that packets received via a particular port  151 D- 151 F are forwarded to the distribution layer via a single uplink interface  153 B or  153 C. For example, a register (e.g., such as register  310 D shown in  FIG. 3A ) associated with port  151 D can be set to a value identifying uplink interface  153 B, and registers respectively associated with ports  151 E- 151 F can be set to a value identifying uplink interface  153 C. Thus, whenever a packet is received via port  151 D, the packet will be forwarded to the distribution layer via uplink interface  153 B, and whenever a packet is received by either port  151 E or  151 F, the packet will be forwarded to the distribution layer via uplink interface  153 C. Alternatively, the uplink interface from which to forward packets received via any of ports  151 D- 151 E can be dynamically selected from uplink interfaces  153 B and  153 C (e.g., the selection can be random or based on past forwarding history). The distribution-layer switch coupled to both uplink interfaces  153 B and  153 C is configured to send packets to satellite switch  150  in such a way that each packet is sent to only one of the uplink interfaces  153 B- 153 C. 
       FIG. 12  is a block diagram of satellite switch  150  illustrating how a local target agent  155  can be implemented in software executing on the switch (in alternative embodiments, all or part of local target agent  155  can be implemented in hardware). As illustrated, switch  150  includes one or more processors  1201  (e.g., microprocessors, PLDs (Programmable Logic Devices), or ASICs (Application Specific Integrated Circuits)) configured to execute program instructions stored in memory  1220 . Memory  1220  can include various types of RAM (Random Access Memory), ROM (Read Only Memory), flash memory, MEMS (Micro Electro-Mechanical Systems) memory, and the like. Processor  1201  and memory  1220  are coupled to send and receive data and control signals by a bus or other interconnect. 
     Memory  1220  stores program instructions executable by processor  1201  to implement local target agent  155 . Memory  1220  can also be used to store local target tables  756  used and maintained by local target agent  155 . In some embodiments, memory  1220  also stores local target masks  757  (as shown in  FIG. 7 ) and/or program instructions executable to implement index modification unit  958  (as shown in  FIG. 9A ). 
     Memory  1220  can also store various virtual linecard configuration information  1222 . Configuration information  1222  can include copies of the values in each register  310  (as shown in  FIG. 3C ) used to assign a satellite switch port to a virtual linecard or to otherwise associate a satellite switch port with one or more uplink interfaces for port-based loadsharing purposes. 
     In some embodiments in which local target agent is implemented in a combination of hardware and software, configuration information  1222  can also include, for example, virtual-linecard-specific local target tables. Each virtual-linecard-specific local target table can include associations between forwarding indices and satellite switch ports and uplink interfaces generated by a particular distribution-layer switch. Local target agent  155  can combine the virtual-linecard-specific local target tables (e.g., by logically ORing each bit) to generate a local target table that includes all of the associations generated by all of the distribution-layer switches controlling a virtual linecard in the satellite switch. This comprehensive local target table can be stored for use by local target agent hardware that performs packet forwarding. By maintaining virtual-linecard-specific local target tables, local target agent  155  can update the comprehensive local target table if, for example, one of the distribution-layer switches fails, causing the ports and uplink interfaces included in the virtual linecard controlled by the failed distribution-layer switch to be transferred to one or more other virtual linecards. 
     The program instructions and data implementing local target agent  155  can be stored upon various computer readable media such as memory  1220 . In some embodiments, local target agent  155  software is stored on a computer readable medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), hard disk, optical disk, tape device, floppy disk, and the like). In order be executed by processor  1201 , the instructions and data implementing local target agent  155  are loaded into memory  1220  from the other computer readable medium. The instructions and/or data implementing can also be transferred to switch  150  via a network such as the Internet or upon a carrier medium. In some embodiments, a computer readable medium is a carrier medium such as a network and/or a wireless link upon which signals such as electrical, electromagnetic, or digital signals, on which the data and instructions implementing local target agent  155  are encoded, are conveyed. 
     Although the present invention has been described with respect to specific embodiments thereof, various changes and modifications may be suggested to one skilled in the art. It is intended such changes and modifications fall within the scope of the appended claims.