Why Spanning Tree Should Be Dead But Isn’t

cloudroadforest08027Spanning Tree Protocol (STP) is dead, or at least it should be. It’s too slow to converge when there’s a change, and it causes issues with performance because there is only one forwarding path. It was developed in 1985 by Radia Perlman at Digital Equipment Corporation to allow for redundant paths within a Layer 2 topology, which was great in 1985. In fact, it was huge! So much so, that it was later standardized by the IEEE as 802.1D, and we’ve been living with it ever since.

There have been a bunch of modifications, including the addition of Rapid STP and Multiple STP to try to make things better. The problem is that the base timers really haven’t changed over the years, but the way that we use them has. STP still only has one focal point (root) and can only have one forwarding path toward that one device. Yes, we can use technologies like EtherChannel to help hide portions of the topology for STP, but STP does NOT do multipath forwarding! The amount of time for convergence with STP (even Rapid) is significant with higher-speed technologies like GigabitEthernet, TenGigabitEthernet, 40 and 100 GigabitEthernet and even TeraBitEthernet. The amount of loss during the time it takes for STP to converge with these high-speed networks is unacceptable in a lot of cases.

The bottom line is that STP has outlived its welcome. It’s time to move on. But to what? That’s the $64,000 question and why most switches today still have STP enabled (either traditional or Rapid).

There are a few contenders out there trying to position themselves to replace the aged STP. Let’s looks at the main three: TRILL, FabricPath and Shortest Path Bridging.

What is TRILL and FabricPath?
In 2006, Radia (yes, the same Radia who came up with STP) and J. Touch introduced the concept of a Routing Bridge (RBridge) based on the principals of Layer 3 routing, but moving the concept to Layer 2 using a modified version of IS-IS. This evolved into RFC 6325, which is the base protocol specification for Transparent Interconnection of Lots of Links (TRILL). The development has been slow and Cisco — being Cisco — took the opportunity to create a pre-release version of TRILL they called FabricPath in June of 2010. Instead of RBridges, Cisco FabricPath refers to them as D-Bridges. Both use a modified IS-IS as the underlying protocol to give use to Layer 2 Multipath forwarding (L2MP). Currently FabricPath has limited support in the Cisco Nexus series of switches, the 5000, 6000 and 7000 Series, depending on the version of NX-OS and IO modules.

TRILL
FabricPath
Can transit a classic Ethernet environment by inserting its Next Hop Header Terminates the FabricPath and reverts to traditional STP forwarding
Single topology Multiple topologies for more granular control of traffic
All RBridges get complete MAC address tables Edge D-Bridge learns MAC from conversations and passes to other edge D-Bridges. Core switches do not have MAC address from the edge, just Switch IDs of all switches in the fabric
VLAN Pruning is not available FabricPath switches will signal to their peers VLANs they have member ports in to dynamically prune unnecessary broadcast traffic from the links

What is Shortest Path Bridging (IEEE 802.1aq)?
Shortest Path Bridging (SPB), specified in the IEEE 802.1aq standard, is the IEEE intended replacement to STP. IEEE 802.1aq supports L2MP, allowing all paths to be active with multiple equal cost paths, providing much larger Layer 2 topologies (up to 16 million compared to the 4096 VLANs limit) and faster convergence times, and improving the use of the mesh topologies through increased bandwidth and redundancy between all devices by allowing traffic to load share across all paths of a mesh network. It is similar to TRILL and FabricPath in that it uses IS-IS as the underlying protocol. But, the traffic is passed by either encapsulation at the edge of the topology from a classic Ethernet link within an 802.1ah MAC-in-MAC header for Metro Ethernet or by using an 802.1Q/802.1ad frames for the Enterprise and then transported to other members of the topology across symmetric routed shortest paths. For whatever reason, Cisco and other vendors are not on board with this protocol and are focusing more on TRILL.

Current State of the Protocols
802.1aq was finalized March 2012, but it has limited support.

FabricPath is available today and works well, but it is Cisco proprietary and in limited deployment on some Cisco Nexus switches.

Per the IETF, TRILL is still in development. There are some foundational components that are done, like the RFC for RBridge and TRILL Adjacency (RFC 7177). There are also several draft RFCs trying to resolve issues that have come up in the process of developing this protocol, including a new draft RFC for Active Active connections with TRILL dated May 14, 2014.

Conclusion
Which option is promising for you depends on whether you’re a Cisco shop. FabricPath works today, but being a Cisco protocol, it is limited. In addition, even within the Cisco world, it’s only available on some Nexus switches. TRILL is a set of RFCs and therefore open to all vendors. It will be supported by Cisco “once it is more complete” (that’s their statement and so far they are sticking to it). Once it gets more completed, Cisco has committed to support TRILL and FabricPath (maybe renamed to TRILL+) and give their customers the choice. SPB is done and available, but there seems to be little interest. There is no word as to when or if Cisco will ever support SPB.

Spanning Tree needs to die, but until we get a replacement protocol that all the vendors agree to, we’re stuck with it. One will win out as the replacement; hopefully it will be sooner rather than later. I suppose you could do Layer 3 everywhere, but that’s another can of worms.

Related Courses
DCNX7K — Configuring Cisco Nexus 7000 Switches v2.1
DCUFI — Implementing Cisco Data Center Unified Fabric v5.0
DCUFD — Designing Cisco Data Center Unified Fabric 5.0

Please support our Sponsors here :