Configuring RSVP-TE Fast Rerouting with RSVP-TE Bypass Tunnels

The fast reroute extensions to RSVP-TE enable you to create a single LSP, known as a bypass tunnel, to back up a set of LSPs by bypassing specific links in the LSP. In the event of a failure in any link of the protected RSVP-TE LSP (the primary LSP), MPLS redirects traffic to the associated bypass tunnel in tens of milliseconds.

You must statically configure the bypass tunnel for each link that you want to protect on each router in the LSP. The bypass tunnel must intersect the protected LSP at two locations. The start of the bypass tunnels is the point of local repair (PLR), which is the head end of the protected link. The bypass tunnel terminates downstream of the PLR on the node that represents the end of the bypassed link on the primary LSP.

Each bypass tunnel provides 1:N local protection; that is, each bypass tunnel can protect one or more links depending on where you have configured it. The protected primary LSPs are stacked over the bypass tunnel to redirect their traffic around the failure.

The bypass tunnel naturally protects all LSPs that share the bypassed link (the LSP segment from the PLR to the downstream node) and that have requested protection. Consider the network shown in Figure 63.

Figure 63: Bypass Tunnel

Bypass Tunnel

Suppose you have configured both LER 1 and LER 2 to request bypass protection, and have configured the following two bypass tunnels:

LSR 5 –> LSR 8 –> LSR 6
LSR 6 –> LSR 9 –> LSR 7

If link LSR 5 –> LSR 6 fails, RSVP-TE redirects traffic through LSR 5 –> LSR 8 –> LSR 6. If link LSR 6 –> LSR 7 fails, RSVP-TE redirects traffic through LSR 6 –> LSR 9 –> LSR 7. These two bypass tunnels therefore protect all LSPs routed from LER 1 or LER 2 through LSRs 5, 6, and 7. Notice in Figure 63 that if both protected links fail, traffic is still safely redirected through LSR 5 –> LSR 8 –> LSR 6 –> LSR 9 –> LSR 7.

If you want to protect an LSP that traverses N nodes against a failure in any link, then you must configure N-1 bypass tunnels. As shown in Figure 63, each of those bypass tunnels in turn can protect multiple tunnels.

On detecting the link failure, the PLR redirects traffic arriving on all of the protected primary tunnels to the bypass tunnel that protects the failed link. An additional label representing the bypass tunnel is stacked on the redirected packets. This label is popped either at the router that is the remote end of the protected link or at the penultimate hop. The merge point therefore sees traffic with the original label representing the primary tunnel.

When the ingress router learns by RSVP-TE signaling that local protection (a bypass tunnel) is in use, it attempts to find a new optimal path for the tunnel, based on the configured path options. The ingress router sets up the new tunnel before it tears down the old tunnel with the failed link, and switches its traffic to the new tunnel.

You can use the tunnel mpls path-option command to configure path options on the bypass tunnel. However, the link being protected by the bypass tunnel must not be in the path if you specify an explicit path.

Configuration Example

The following steps show a partial configuration using the topology in Figure 63:

  1. On LSR 5, create a bypass tunnel to protect the link between LSR 5 and LSR 6. If you configure path options, you can specify the explicit path for the bypass tunnel either statically or to be dynamically calculated by the IGP traffic engineering mechanism.
    host1(config)#interface tunnel mpls:bypass56 host1(config-if)#tunnel mpls path-option 1 explicit name bypass host1(config-if)#tunnel destination 172.20.1.1 host1(config-if)#exit
  2. On LSR 5, enable the explicit path, if configured.
    host1(config)#mpls explicit-path name bypass enable host1(config-expl-path)#next-address 10.10.9.2 host1(config-expl-path)#exit
  3. On LSR 5, assign the bypass tunnel to the interface being protected.
    host1(config)#interface atm 4/0.1 host1(config-if)#mpls backup-path bypass56
  4. On LER 1 (the tunnel ingress), specify that local protection is required for the primary tunnel.
    host1(config)#interface tunnel mpls:primary1 host1(config-if)#tunnel mpls fast-reroute

Fast Reroute over SONET/SDH

If you are using MPLS fast reroute over a SONET/SDH interface, reduce the times that the router uses to convert a defect to an alarm. Use the path trigger delay command to reduce the time for the path layer and the trigger delay command to reduce the time for the section and line layers. Use the following guidelines to set the times:

For more information about these commands, see JunosE Physical Layer Configuration Guide.

Related Documentation