t 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 be 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 common spanning tree problem is shown in Figure 8-8. Here, two switches are connected with two links: F0/0 on Switch A is connected to F0/0 on Switch B, and F0/1 on Switch A is connected to F0/1 on Switch B. Switch A is the root bridge. All ports are in the forwarding state, except for F0/1 on Switch B, which is blocking. The network is stable because spanning tree has broken the potential loop. The arrows show BPDUs being sent. Auto (100/Half) 100/Full Forwarding Forwarding Forwarding Blocking Switch A Switch B 100/Full 100/Full Figure 8-8. Spanning tree half-duplex problem Port F0/0 on Switch A is the only port that is set to auto-negotiation. Auto- negotiation has determined that the port should be set to 100 Mbps and half-duplex mode. The other ports are all hardcoded to 100/full. Spanning tree is sending BPDUs out of all ports and is receiving them on all ports-even the one that is blocking. Always make sure that both sides of an Ethernet link are configured the same way regarding speed and duplex. See Chapter 3 for details. When a port is in half-duplex mode, it listens for collisions before transmitting. A port in full-duplex mode does not. When a half-duplex port is connected with a full- duplex port, the full-duplex port will send continuously, causing the half-duplex port to encounter many collisions. After a collision, the port will perform the back-off algorithm, and wait to resend the packet that collided. In our example, the half- duplex port is the active link with data being sent across it. When the data rate gets high, the collision problem gets worse, resulting in frames-including BPDUs being dropped. Common Spanning Tree Problem