Distributed spanning tree protocol on a multi chassis port channel

Embodiments of the present disclosure generally relate to networking and, more particularly, to controlling the flow of network traffic.

A Multi Chassis Port Channel (MCPC) or Multi Chassis Ether Channel (MCEC) has two ends of a port channel termination on two different switches. These switches are commonly referred to as Aggregation Switches. Having multiple ends of a port channel terminate on different channels provides redundancy, not only across link failure, but also across a single switch failure.

In contrast, in a regular Port Channel, all links belonging to the Port Channel terminate on a single switch. The Port Channel is treated as a single logical link by Spanning Tree Protocol (STP), and any hardware operations like setting the port state or MAC flush/Age are applied on all member links of the Port Channel. As such, STP does not pose any issues on a regular Port Channel.

However, operating STP on an MCPC complex presents some challenges, as member links of the Port Channel are terminating on different switches. One of these challenges is that STP may block a port used to establish a multi-channel trunk (MCT) between MCPC switches. If an MCT port is blocked, the desirable redundancy offered by an MCPC topology may be lost.

Overview

One embodiment provides a method. The method generally includes maintaining a multi-chassis port channel (MCPC) priority vector for a port of a switch of an MCPC complex, wherein the MCPC priority vector includes a field whose value is determined based on whether or not the port is used to establish a multi-chassis trunk (MCT) in the MCPC and performing spanning tree protocol operations, based on the MCPC priority vector, to determine whether or not to allow forwarding on the port.

One embodiment provides a switching device. The switching device generally includes a first port for establishing a multi-chassis trunk (MCT) with another switching device for use in multi-chassis port channel (MCPC) communications, at least a second port for communicating with a device external to the MCPC, logic for maintaining a multi-chassis port channel (MCPC) priority vector for a port of a switch of an MCPC complex, wherein the MCPC priority vector includes a field whose value is determined based on whether or not the port is used to establish a multi-chassis trunk (MCT) in the MCPC, and logic for performing spanning tree protocol operations, based on the MCPC priority vector, to determine whether or not to allow forwarding on the port.

One embodiment provides a switching device. The switching device generally includes at least a first port for establishing a multi-chassis trunk (MCT) with another switching device for use in multi-chassis port channel (MCPC) communications, at least a second port for communicating with a device external to the MCPC, means for maintaining a multi-chassis port channel (MCPC) priority vector for a port of a switch of an MCPC complex, wherein the MCPC priority vector includes a field whose value is determined based on whether or not the port is used to establish a multi-chassis trunk (MCT) in the MCPC, and means for performing spanning tree protocol operations, based on the MCPC priority vector, to determine whether or not to allow forwarding on the port.

So that features of the present disclosure can be understood in detail, a particular description of the disclosure may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this disclosure and are therefore not to be considered limiting of its scope, for the disclosure may admit to other equally effective embodiments.

FIG. 1 illustrates a physical view of a network with an MCPC complex, according to one embodiment of the present disclosure.

FIG. 2 illustrates a logical view of the network of FIG. 1 , according to one embodiment of the present disclosure.

FIG. 3 is a flowchart of example operations, according to one embodiment of the present disclosure

FIGS. 4A-4E illustrate configuration STP operations in an MCPC complex, according to one embodiment of the present disclosure.

FIGS. 5A-5B illustrate the routing of BPDUs sent from an MCPC complex, according to one embodiment of the present disclosure.

FIGS. 6A-6B illustrate the routing of BPDUs sent to an MCPC, according to one embodiment of the present disclosure.

FIGS. 7A-7B illustrate link and switch failure handling, according to one embodiment of the present disclosure.

Embodiments of the present disclosure provide techniques for routing traffic in networks represented by logical topologies, such as Multi Chassis Port Channel (MCPC) or Multi Chassis Ether Channel (MCEC) topologies. By modifying a port priority vector (PPV) to include an additional “Switch ID” field that identifies a designated bridge ID or a local switch ID, depending on whether the corresponding port is used as an MCT, a routing protocol designed to avoid loops in routing paths, such as STP, may avoid blocking MCT ports.

An Example Network

FIG. 1 illustrates a physical representation of a network in which techniques provided in the present disclosure may be utilized. The network includes a first arrangement of switches 120 (S 1 , S 4 , and S 5 ), interconnected via a second arrangement of switches 130 (S 2 and S 3 ).

As illustrated, S 2 and S 3 may be connected, via a multi-chassis trunk 132 , to form an MCPC complex 110 . Each switch in the MCPC complex 110 may participate independently in data forwarding. Because S 1 , S 4 , and S 5 all have a physical link to each of the switches S 2 and S 3 , the MCPC 110 provides redundant paths for traffic between S 1 , S 4 , and S 5 .

As illustrated in FIG. 2 , logical MCPC ports MCPC 1 and MCPC 2 are formed between S 4 and S 5 , respectively, and MCPC 110 . Although each MCPC port terminates on both MCPC switches, each MCPC port appears as a single logical link for STP purposes.

In the illustrated example, it is assumed that S 2 owns the MCPC, meaning that traffic on logical ports MCPC 1 and MCPC 2 will be routed through S 2 . As such, S 2 may regularly synchronize MCPC parameters to S 3 via the MCT connection. This regular synchronization may allow S 3 to seamlessly take over control (ownership) of the MCPC in the event that S 2 fails. Configuration parameters, as well as runtime parameters associated with the MCPC, may be synchronized to facilitate this switchover.

It may be desirable to run the STP protocol on the illustrated MCPC network topology, for example, to allow efficient routing and prevent undesirable loops. Unfortunately, conventional application of the STP protocol to an MCPC may result in blocking of ports used to establish the MCT between the MCPC switches. The present disclosure presents a technique to allow STP computations, while still maintaining MCT link forwarding.

In other words, as illustrated in FIG. 2 , the techniques presented herein may allow STP operations to be run that result in the blocking of port P 1 of S 3 rather than the blocking of port P 2 , which would prevent MCT link forwarding. Thus, the techniques presented herein may provide the advantages of both MCPC (redundancy in the event of physical link and/or switch failure) and STP. Further, blocking P 2 would be insufficient to prevent loops, as traffic could still be routed between S 4 to S 1 via the secondary MCPC 1 connection with S 3 .

Embodiments of the present disclosure may facilitate the running of STP on MCPC networks by utilizing a modified form of an STP port priority vector (PPV), referred to herein as an MCPC PPV. The MCPC PPV may include an additional field whose value may be determined based on whether or not the corresponding port is used for MCT. The format for a conventional PPV is as follows:

conventional PPV={RootBridgeID: RootPathCost: DesignatedBridgeID: DesignatedPortID: BridgePortID}

The MCPc PPV includes an additional field (SwitchID), for example, as shown:

MCPC PPV={RootBridgeID: SwitchID: RootPathCost: DesignatedBridgeID: DesignatedPortID: BridgePortID}

The value of the Switch ID field may be determined based on whether the corresponding port is used for an MCT link. For example, if the port is used for an MCT link Switch ID may be set to the DesignatedBridgeID. If the port is not used for an MCT link the SwitchID may be set to the Local Switch ID. In other words:

SwitchID=DesignatedBridgeID (for MCT ports) SwitchID=LocalSwitchID (for non-MCT ports)

As will be described in greater detail below, instances of STP running on MCPC switches may utilize this modified PPV value may be used to prevent blocking an MCT port.

FIG. 3 illustrates example operations 300 for performing STP on an MCPC topology in accordance with embodiments of the present disclosure. The operations 300 begin, at 302 , by performing an initialization (“Port Bringup”) using an MCPC PPV. MCPC parameters may be periodically synchronized between MCPC switches, at 304 . If a switch (or link failure) is detected, at 306 , a switchover to a non-owning switch occurs, at 308 .

FIGS. 4A-4E illustrate example initialization operations using an MCPC PPV (e.g., operation 302 of FIG. 3 ). As illustrated in FIG. 4A , S 1 may send a Bridge Protocol Data Unit (BPDU). A BPDU is an STP “hello” packet that is typically sent out at configurable intervals to exchange information among bridges in the network.

In an initialized state, all ports may be blocked, with ports transitioning to unblocked states that allow forwarding as STP is run and converges. The BPDU packet sent from S 1 may include a proposal bit set to change a port that is currently blocking to forwarding, for example, to establish a path between S 3 and S 1 . Upon receiving the proposal, before sending back an agreement to S 1 , S 3 may synchronize port P 2 .

For example, as illustrated in FIG. 4B , S 3 may send out a proposal message on P 2 (to allow forwarding on P 2 ). This proposal message may include modified port priority vectors (MCPC PPVs) for P 1 and P 2 as follows:

MCPC PPV (P 1 )={Root ID=S 1 : SwitchID=S 3 : Cost=1: Designated Bridge ID=S 1 } MCPC PPV (P 2 )={Root ID=S 1 : SwitchID=S 2 : Cost=2: Designated Bridge ID=S 2 }

In this example, because the port P 2 is utilized in MCT, the Switch ID field for the PPV for P 2 may be set to the DesignateBridgeID (S 2 in this example). The PPV for P 1 , on the other hand, that is not involved in MCT, may be set to the Local Switch ID (S 3 ).

Internal logic running STP on the MCPC switches may determine the difference in the local switch ID and the Switch ID field is an indication that the corresponding port (P 2 ) is used in MCT. Conversely, the internal logic may determine the same values of the local switch ID and the Switch ID field is an indication that the corresponding port (P 1 ) is not used in MCT. Based on these determination, this logic may select the role for port P 2 to be the root port and select the role for port P 1 to be Alternate, despite the higher root cost associated with port P 2 relative to port P 1 (2 versus 1).

As illustrated in FIG. 4C , S 2 may block the MCPC 1 ports and send an agreement back to S 3 . As illustrated in FIG. 4D , upon receiving the agreement from S 2 , S 3 may send an agreement back to S 1 , accepting S 1 's proposal to make its blocking port forwarding. Upon receiving the Agreement from S 3 , S 1 unblocks its port, making its port Forwarding. A final “converged” state is shown in FIG. 4E , with port P 1 of S 3 blocking and the MCPC ports unblocked. By blocking port P 1 of S 3 , an unwanted loop through S 3 that would have been created through the alternate MCPC 1 connection (between S 4 and S 3 ) is prevented.

As previously described, the MCPC switches S 2 and S 3 may periodically synchronize parameters allowing S 3 to take over control of the MCPC in the event of a switch failure to S 2 or a link failure. Communications, on the MCT established between S 2 and S 3 may be accomplished utilizing an internal protocol (VSL INBAND) with messages encapsulated with a header (e.g., a DBUS header). For communications between the MCPC switches, there is no need to strip off this header, but for external communications, the DBUS header may be stripped.

BPDU Handling on MCPC

To maintain current spanning trees, devices running STP periodically exchange BPDUs. In the case of MCPC topologies running STP, BPDUs may need to be transmitted, not only between the MCPC switches, but also on the logical ports (MCPC 1 and MCPC 2 ). However, to prevent confusion, it may be desirable to transmit BPDUs for a logical port on the same physical link each time.

For example, as illustrated in FIG. 5A , BPDUs for MCPC 1 may always be sent on the physical link between S 2 and S 4 , while BPDUs for MCPC 2 may always be sent on the physical link between S 2 and S 5 . Using the same physical interface each time may prevent confusion, for example, by allowing a Packet Manager to get the same selection value (such as a hash value) on a port channel for BPDU Tx when querying an interface database. The same selection value may help guarantee the same port channel member will be selected.

STP logic on S 2 may send a BPDU to MCPC 1 using some type of packet manager API. This logic may query an interface database and set values of a DBUS header for the MCPC 1 destined BPDU (S 2 as the source index and MCPC 1 as the destination index). If these header values result in the selection of the port linking S 2 to S 4 , the DBUS header may be stripped and the BDPU sent to S 4 as shown in FIG. 5A . If for some reason the port linking S 2 and S 4 is down, however, the BPDU may be forwarded out on the MCT port, as illustrated in FIG. 5B . S 3 may receive the BPDU packet (with the DBUS header), strip the DBUS header, and send the MCPC 1 BDPU to S 4 .

For BPDUs transmitted between the MCPC switches on the MCT, internal source and destination indexes may be utilized in DBUS headers. For example, STP logic on S 2 may send a BPDU on its MCT port, with a DBUS header having a source index (e.g., “S 2 _SUP”) used to indicate the BPDU came on the local MCT port. The DBUS header may also include a destination index (e.g., “S 3 _SUP”) to ensure the message will be routed correctly on S 3 . To allow this approach of BPDU transport over the MCT, Destination indexes may be unique across the MCPC switches.

FIGS. 6A-6B illustrate example handling of BPDUs received by the MCPC. As illustrated in FIG. 6A , the MCPC may receive a BPDU on port P 3 of S 3 . This BPDU should be delivered to STP logic running on S 2 as having been received on the logical port MCPC 1 . To accomplish this, logic for port P 3 may set the source index to MCPC 1 , which may cause the BPDU to be routed to internal S 2 logic (e.g., destination S 2 _SUP). A packet manager for the logical port on S 2 _SUP may deliver the BPDU to STP logic as being received on MCPC 1 , thereby allowing STP to operate as a single chassis port channel.

When the MCPC receives a BPDU on a switch that does not have ownership, the BPDU may be relayed to the peer switch that does have ownership with the source index preserved. As illustrated in FIG. 6B , still assuming S 2 owns MCPC 1 , a BPDU received via an alternate link (e.g., received on port P 4 of S 3 ) should eventually be delivered to S 2 (DBUS+BPDU) as having been received on MCPC 1 . In this case, when the BPDU is received on P 4 of S 3 , port logic may realize that MCPC 1 is owned by S 2 and forward the BPDU on the MCT. The BPDU may be forwarded with a DBUS header indicating MCPC 1 as the Source index and S 1 _SUP as the destination index. As a result, upon receiving this BPDU, logic on S 2 may forward it to STP logic as being received on MCPC 1 .

As illustrated above in FIG. 5B , in the event of a link failure, the MCPC may transmit BPDUs utilizing the alternate physical link allowing the MCPC to continue to operate. In the event of a switch failure, the MCPC may also continue to operate with the peer switch taking over ownership.

FIGS. 7A and 7B illustrate a switchover to a non-owning switch in the event of a failure of an owning switch. As illustrated in FIG. 7A , as long as the owning-switch is active, BPDUs for both MCPC 1 and MCPC 2 may be sent by the owning switch. The current STP parameters for the illustrated example with S 2 active are listed in table 750 A, with S 2 designated as a root and, for switch S 3 , port p 2 is designated as a root port (despite a higher cost than the port directly connected to S 1 ).

As illustrated in FIG. 7B , once switch S 2 fails, S 3 will take over ownership and begin sending BPDUs for both MCPC 1 and MCPC 2 . The STP parameters are updated to reflect this change in ownership. These updated STP parameters for S 3 are shown in table 750 B, with S 3 designated as the root, and the SwitchID fields of priority vectors for MCPC 1 , MCPC 2 are updated to reflect this. In some cases, the root cost may also need to be updated depending on the topology. In the illustrated example, however, the root cost for MCPC 1 and MCPC 2 remains the same as S 3 has a direct link to root node S 1 .

By allowing STP to run on MCPC topologies, embodiments of the present disclosure provide the advantages of both technologies. For example, the MCPC allows redundant switching paths between devices, while running STP provides optimum path selection, while avoiding loops.

While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the disclosure may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.