Configure Fast Reroute
Fast reroute provides a mechanism for automatically rerouting traffic on an LSP if a node or link in an LSP fails, thus reducing the loss of packets traveling over the LSP. Fast rerouting is accomplished by precomputing and pre-establishing a number of detours along the LSP. Figure 14 illustrates an LSP from Router A to Router F, showing some of the detours that are established for the LSP. Each detour is established by an upstream node with the intent of avoiding the link toward the immediate downstream node and the immediate downstream node itself. Each detour might traverse through one or more label-switched routers that are not shown in the figure.
If a node detects that a downstream link has failed (using a link-layer-specific liveness detection mechanism) or that a downstream node has failed (for example, using the RSVP neighbor hello protocol), the node quickly switches the traffic to the detour and, at the same time, signals the ingress router about the link or node failure. Figure 15 illustrates the detour taken when the link between Router B and Router C fails.
If the network topology is not rich enough (there are insufficient routers with insufficient links to other routers), some of the detours might not succeed. For example, the detour from Router A to Router C in Figure 14 cannot traverse link A-B and Router B. If such a path is not possible, the detour does not occur.
Note that after the node switches traffic to the detour, it might switch the traffic again to a newly calculated detour soon after. The initial detour route might not be the best route. Rather than verifying whether it is currently valid, the node simply switches traffic onto that route. After the node switches traffic to the initial detour, it recomputes the detour. If the node determines that the initial detour is still valid, traffic continues to flow over this detour. If the node determines that the initial detour is no longer valid, it again switches the traffic to the newly computed detour.
The time required for a fast-rerouting detour to take effect depends on two independent time intervals:
- Amount of time to detect that there is a link or node failure—This interval depends greatly on the link layer in use and the nature of the failure. For example, failure detection on an SDH/SONET link typically is much faster than on a Gigabit Ethernet link, and both are much faster than detection of a router failure.
- Amount of time required to splice the traffic onto the detour—This interval is primarily the CPU time required to switch traffic to the initial detour. The amount of time depends on the current CPU load and how busy the other routing protocols sharing the CPU are.
Fast reroute is a short-term patch to reduce packet loss. Because detour computation might not reserve adequate bandwidth, the detours might introduce congestion on the alternate links. The ingress router is the only router that is fully aware of LSP policy constraints and, therefore, is the only router able to come up with adequate long-term alternate paths.
Fast reroute protects traffic against any single point of failure between the ingress and egress routers. If there are multiple failures along an LSP, it is possible that fast reroute itself might fail. Also, fast reroute does not protect against failure of the ingress or egress routers.
Detours are created using RSVP and, like all RSVP sessions, they require extra state and overhead in the network. For this reason, each node establishes at most one detour for each LSP that has fast reroute enabled. Creating more than one detour for each LSP increases the overhead, but serves no practical purpose.
To reduce network overhead further, each detour attempts to merge back into the LSP as soon as possible after the failed node or link. If you can consider an LSP that travels through N router nodes, it is possible to create N - 1 detours. For instance, in Figure 16, the detour tries to merge back into the LSP at Router D instead of at Router E or Router F. Merging back into the LSP makes the detour scalability problem more manageable. If topology limitations prevent the detour from quickly merging back into the LSP, detours merge with other detours automatically.
