e CPU utilization on network devices can quickly reach 100 percent, causing outages. The first thing inexperienced engineers try is rebooting one or more devices in the network. In the case of a unidirectional link, rebooting will not resolve the issue. When that fails, the loop is usually detected, and the engineer shuts down one of the links. But when he shuts down the link, the proof of the unidirectional link is often lost. Physical layer first! Always suspect that something physical is wrong when diagnosing connectivity problems. It can save you hours of head- aches, especially if all the other clues don't seem to add up to anything substantial. Also, don't assume that it works today just because it worked yesterday. It doesn't take much for someone to crush a fiber strand when closing a cabinet door. Chapter 8: Spanning Tree With the latest versions of IOS and CatOS, unidirectional link problems are handled by a protocol called Unidirectional Link Detection (UDLD). UDLD is enabled by default and should be left on. If you see UDLD errors, look for issues similar to what I've just described. Bridge Assurance Nexus includes a fun little enhancement called bridge assurance (BA), which is designed to prevent loops in your topology. Wait, isn't spanning tree designed for this purpose? Yes, it is, but bridge assurance makes your network foolproof! If you believe that, I've got a bridge to sell you, along with a book on why nerds shouldn't use puns. Bridge assurance is designed to prevent unidirectional links, but it behaves differently than Unidirectional Link Detection (UDLD). Let's start with this blurb from the Cisco Nexus documentation: Bridge Assurance is enabled by default and can only be disabled globally. Also, Bridge Assurance can be enabled only on spanning tree network ports that are point-to-point links. Finally, both ends of the link must have Bridge Assurance enabled. With Bridge Assurance enabled, BPDUs are sent out on all operational network ports, including alternate and backup ports, for each hel