tch B and start sending its own BPDUs to Switch B. When Switch B receives the BPDUs from Switch C, it will understand that there is a path to Switch A (the more desirable root bridge) through Switch C, and accepts Switch A as the root bridge again. This process takes upward of 50 seconds with the default spanning tree timers. BackboneFast adds functionality that detects indirect link failures. It actively discovers paths to the root by sending out root link query PDUs after a link failure. When it discovers a path, it sets the max_age timer to 0 SO the port can cycle through the normal listening, learning, and forwarding states without waiting an additional 20 seconds. Additional Spanning Tree Features If BackboneFast is used, it must be enabled on every switch in the network. Enabling BackboneFast on an IOS switch is as simple as using the spanning-tree back bonefast global command: Cat-3550(config)#spanning-tree backbonefast Cat-3550(config)# Negating the command disables the feature. To enable BackboneFast on a CatOS switch, use the set spantree backbonefast enable command: Catos-6509: (enable) set spantree backbonefast enable Backbonefast enabled for all VLANs To disable this feature, change the enable keyword to disable. Common Spanning Tree Problems Spanning tree can be a bit of a challenge when it misbehaves. More to the point, span- ning tree problems can be hard to diagnose if the network is not properly designed. Here are a couple of common problems and how to avoid them. Duplex Mismatch A bridge still receives and processes BPDUs on ports, even when they are in a blocked state. This allows the bridge to determine that a path to the root bridge is still available should the primary path fail. If a port in the blocking state stops receiving BPDUs, the bridge no longer considers the port to be a path to the root bridge. In this case, the port should no longer blocked, SO the bridge puts the port into the forwarding state. Would this ever happen in the real world? It's happened to me more than once. A comm