Summary

The Spanning Tree Protocol was originally designed to work on bridged networks, which in turn were designed to segment LANs to allow for additional growth—remember that collision domains have some upper limits, largely based upon the back-off algorithm inside Ethernet, which gradually nibbles away at the available bandwidth. These networks carried slow applications data, often FTP or e-mail, and although redundancy was planned to cover for bridge failures, slow convergence was readily accepted.

Modern-day switches have replaced bridges, and the design criteria have shifted dramatically. Now we have expectations of almost instant recovery from network failures because the applications themselves place those demands on the network. With so many applications having an interactive or multimedia component, and with business relying so heavily on the LAN infrastructure, slow legacy STP no longer meets our needs and expectations.

You should now be familiar with all of the bells and whistles that bring STP into the 21st century. Whether they be proprietary implementations of PortFast, UplinkFast, or BackboneFast, or their soon-to-happen replacement by standards-based alternatives such as 802.1s and 802.1w, we need their help to get STP to work the way we want. Related to this, you have several configuration options for changing the STP timers to speed up convergence in a legacy network.

These days it’s possible to configure separate spanning trees on different VLANs, giving us the multiple benefits of planning optimal topologies while also creating faster converging and smaller (hence more efficient) spanning trees. Finally, it is often advantageous to increase bandwidth at certain places in the network using port aggregation protocols such as EtherChannel. These “channelizing” protocols provide an inexpensive and simple mechanism for increasing bandwidth on point-to-point links using existing interfaces.