When changes occur in a network topology because of the failure or restoration of a link or a network device, IP Fast Reroute enables rapid network convergence by moving traffic to precomputed backup paths until regular convergence mechanisms move traffic to a newly computed best path, also known as a post-convergence path. This network convergence may cause short microloops between two directly or indirectly connected devices in the topology. Microloops are caused when different nodes in the network calculate alternate paths at different times and independently of each other. For instance, if a node converges and sends traffic to a neighbor node, which has not converged yet, traffic may loop between the two nodes.

Microloops may or may not result in traffic loss. If the duration of a microloop is short, that is the network converges quickly, packets may loop for a short duration before their TTL expires. Eventually, the packets will get forwarded to the destination. If the duration of the microloop is long, that is one of the routers in the network is slow to converge, packets may expire their TTL or the packet rate may exceed the bandwidth, and packets may get dropped.

Microloops that are formed between a failed device and its neighbors are called local uloops, whereas microloops that are formed between devices that are multiple hops away are called remote uloops. The ISIS Local Microloop Protection feature helps networks avoid local uloops. Local uloops are usually seen when there is no local loop-free alternate (LFA) path available, especially in ring or square topologies. In such topologies, remote LFAs provide backup paths for the network. However, the fast-convergence benefit of the remote LFA is at risk because of the high probability of uloop creation. The ISIS Local Microloop Protection feature can be used to avoid microloops or local uloops in such topologies.

The ISIS Local Microloop Protection feature supports the following local link down events

• Interface-down events
• Adjacency-down events due to BFD sessions going down.
• Adjacency-down events due to neighbor holdtime expiration

The ISIS Local Microloop Protection feature can be used whether or not a topology is supported by loop-free alternates (LFAs). When you use this feature for prefixes that have repair paths installed in the forwarding plane, this feature will support interface-down events and adjacency-down events if bidirectional forwarding detection (BFD) sessions are down. If this feature is used whether or not a repair path has been installed in the forwarding plane, this feature will also support adjacency-down events caused by neighbor holdtime expiration.

The value of using this feature also depends on whether the remote event that caused loss of adjacency on the neighbor is detectable by the local forwarding plane; that is whether the forwarding plane will react and switch to using preprogrammed repair paths. For instance, when a link fails, the reaction time of the local forwarding plane depends on the media. If the media is optical, the failure is likely to be detected within milliseconds, in which case microloop avoidance is useful. If the media is copper, the local detection will be much slower or nonexistent, in which case using microloop avoidance is disadvantageous. However, if the timeout of the neighbor adjacency is due to reasons other than link failure, such as local congestion, lack of CPU time, and long input queues, these reasons are undetectable by the local forwarding plane and therefore, are not good candidates for microloop avoidance.

Note	When remote loop-free alternates (RLFAs) are enabled in a network, microloop avoidance is enabled by default for all protected prefixes (prefixes that have repair paths).