Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Link Protection for MPLS LSPs

 

Link Protection

Link protection helps to ensure that traffic going over a specific interface to a neighboring router or switch can continue to reach this router (switch) if that interface fails. When link protection is configured for an interface and an LSP that traverses this interface, a bypass LSP is created that will handle this traffic if the interface fails. The bypass LSP uses a different interface and path to reach the same destination. The path used can be configured explicitly, or you can rely on CSPF. The RSVP metric for the bypass LSP is set in the range of 20,000 through 29,999 (this value is not user configurable).

If a link-protected interface fails, traffic is quickly switched to the bypass LSP. Note that a bypass LSP cannot share the same egress interface with the LSPs it monitors.

In Figure 1, link protection is enabled on Interface B between Router 1 and Router 2. It is also enabled on LSP A, an LSP that traverses the link between Router 1 and Router 2. If the link between Router 1 and Router 2 fails, traffic from LSP A is quickly switched to the bypass LSP generated by link protection.

Figure 1: Link Protection Creating a Bypass LSP for the Protected Interface
Link Protection Creating a Bypass LSP
for the Protected Interface

Although LSPs traversing an interface can be configured to take advantage of link protection, it is important to note that it is specifically the interface that benefits from link protection. If link protection is enabled on an interface but not on a particular LSP traversing that interface, then if the interface fails, that LSP will also fail.

Note

Link protection does not work on unnumbered interfaces.

To protect traffic over the entire route taken by an LSP, you should configure fast reroute. For more information, see Configuring Fast Reroute.

Multiple Bypass LSPs for Link Protection

By default, link protection relies on a single bypass LSP to provide path protection for an interface. However, you can also specify multiple bypass LSPs to provide link protection for an interface. You can individually configure each of these bypass LSPs or create a single configuration for all of the bypass LSPs. If you do not configure the bypass LSPs individually, they all share the same path and bandwidth constraints.

The following algorithm describes how and when an additional bypass LSP is activated for an LSP:

  1. If any currently active bypass can satisfy the requirements of the LSP (bandwidth, link protection, or node-link protection), the traffic is directed to that bypass.

  2. If no active bypass LSP is available, scan through the manual bypass LSPs in first-in, first-out (FIFO) order, skipping those that are already active (each manual bypass can only be activated once). The first inactive manual bypass that can satisfy the requirements is activated and traffic is directed to that bypass.

  3. If no manual bypass LSPs are available and if the max-bypasses statement activates multiple bypass LSPs for link protection, determine whether an automatically configured bypass LSP can satisfy the requirements. If an automatically configured bypass LSP is available and if the total number of active automatically configured bypass LSPs does not exceed the maximum bypass LSP limit (configured with the max-bypasses statement), activate another bypass LSP.

For information about how to configure multiple bypass LSPs for link protection, see Configuring Bypass LSPs.

Node Protection

Node protection extends the capabilities of link protection. Link protection helps to ensure that traffic going over a specific interface to a neighboring router can continue to reach this router if that interface fails. Node protection ensures that traffic from an LSP traversing a neighboring router can continue to reach its destination even if the neighboring router fails.

When you enable node protection for an LSP, you must also enable link protection. Once enabled, node protection and link protection establish the following types of bypass LSPs:

  • Next-hop bypass LSP—Provides an alternate route for an LSP to reach a neighboring router. This type of bypass LSP is established when you enable either node protection or link protection.

  • Next-next-hop bypass LSP—Provides an alternate route for an LSP to get around a neighboring router en route to the destination router. This type of bypass LSP is established exclusively when node protection is configured. If a next-next-hop bypass LSP cannot be created, an attempt is made to signal a next-hop bypass LSP.

In Figure 2, node protection is enabled on Interface B on Router 1. Node protection is also enabled on LSP A, an LSP that traverses the link transiting Router 1, Router 2, and Router 3. If Router 2 suffers a hardware or software failure, traffic from LSP A is switched to the next-next-hop bypass LSP generated by node protection.

Figure 2: Node Protection Creating a Next-Next-Hop Bypass LSP
Node Protection Creating a Next-Next-Hop
Bypass LSP

The time needed by node protection to switch traffic to a next-next-hop bypass LSP can be significantly longer than the time needed by link protection to switch traffic to a next-hop bypass LSP. Link protection relies on a hardware mechanism to detect a link failure, allowing it to quickly switch traffic to a next-hop bypass LSP.

Node failures are often due to software problems on the node router. Node protection relies on the receipt of hello messages from a neighboring router to determine whether it is still functioning. The time it takes node protection to divert traffic partly depends on how often the node router sends hello messages and how long it takes the node-protected router to react to having not received a hello message. However, once the failure is detected, traffic can be quickly diverted to the next-next-hop bypass LSP.

Note

Node protection provides traffic protection in the event of an error or interruption of the physical link between two routers. It does not provide protection in the event of control plane errors. The following provides an example of a control plane error:

  • A transit router changes the label of a packet due to a control plane error.

  • When the ingress router receives the packet, it considers the label change to be a catastrophic event and deletes both the primary LSP and the associated bypass LSP.

Fast Reroute, Node Protection, and Link Protection

This document discusses the following sections:

LSP Protection Overview

RSVP-TE extensions establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable immediate re-direction of traffic onto backup LSP tunnels, in the event of a failure.

RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels, describes two different types of traffic protection for RSVP-signaled LSPs:

  • One-to-one backup—In this method, detour LSPs for each protected LSP is created at each potential point of local repair.

  • Facility backup—In this method, a bypass tunnel is created to protect a set of LSPs that have similar backup constraints at a potential failure point, by taking advantage of the MPLS label stacking.

The one-to-one backup and the facility backup methods protect links and nodes during network failure, and can co-exist in a mixed network.

LSP Protection Types Comparison

In the Junos OS, the one-to-one backup of traffic protection is provided by fast reroute. Each LSP requires a protecting LSP to be signaled at each hop except the egress router. This method of LSP protection cannot be shared.

In the facillity backup method, the LSP traffic protection is provided on the node and link. Unlike fast reroute, this protecting LSP can be shared by other LSPs.

Table 1 summarizes the traffic protection types.

Table 1: One-to-One Backup Compared with Facility Backup

Comparison

One-to-One Backup

Facility Backup

Name of the protecting LSP

Detour LSP

Bypass LSP

Sharing of the protecting LSP

Cannot be shared

Can be shared by multiple LSPs

Junos configuration statements

fast-reroute

node-link-protection and link-protection

One-to-One Backup Implementation

In the one-to-one backup method, the points of local repair maintain separate backup paths for each LSP passing through a facility. The backup path terminates by merging back with the primary path at a node called the merge point. In this approach, the merge point can be any node downstream from the protected facility.

In the one-to-one backup method, an LSP is established that intersects the original LSP downstream of the point of link or node failure. A separate backup LSP is established for each LSP that is backed up.

One-to-one backup is appropriate under the following circumstances:

  • Protection of a small number of LSPs relative to the total number of LSPs.

  • Path selection criteria, such as bandwidth, priority, and link coloring for detour paths is critical.

  • Control of individual LSPs is important.

In Figure 3, Routers R1 and R5 are the ingress and egress routers, respectively. A protected LSP is established between the two routers transiting Routers R2, R3, and R4. Router R2 provides user traffic protection by creating a partial backup LSP that merges with the protected LSP at Router R4. This partial one-to-one backup LSP is called a detour. Detours are always calculated to avoid the immediate downstream link and node, providing against both link and node failure.

Figure 3: One-to-One Backup
One-to-One Backup

In the example, the protected LSP is R1-R2-R3-R4-R5, and the following detours are established:

  • Router R1—R1-R6-R7-R8-R3

  • Router R2—R2-R7-R8-R4

  • Router R3—R3-R8-R9-R5

  • Router R4—R4-R9-R5

To protect an LSP that traverses N nodes fully, there can be as many as (N - 1) detours. The point of local repair sends periodic refresh messages to maintain each backup path, as a result maintaining state information for backup paths protecting individual LSPs is a significant resource burden for the point of local repair. To minimize the number of LSPs in the network, it is desirable to merge a detour back to its protected LSP, when feasible. When a detour LSP intersects its protected LSP at an LSR with the same outgoing interface, it is merged.

Facility Backup Implementation

In the facility backup approach, a point of local repair maintains a single backup path to protect a set of primary LSPs traversing the point of local repair, the facility, and the merge point. The facility backup is based on interface rather than on LSP. While fast reroute protects interfaces or nodes along the entire path of a LSP, the facility backup protection can be applied on interfaces as needed. As a result, fewer states need to be maintained and refreshed which results in a scalable solution. The facility backup method is also called many-to-one backup.

The facility backup method takes advantage of the MPLS label stack. Instead of creating a separate LSP for every backed-up LSP, a single LSP is created that serves to back up a set of LSPs. Such an LSP tunnel is called a bypass tunnel. In this method, a router immediately upstream from a link failure uses an alternate interface to forward traffic to its downstream neighbor, and the merge point should be the node immediately downstream to the facility. This is accomplished by preestablishing a bypass path that is shared by all protected LSPs traversing the failed link. A single bypass path can safeguard a set of protected LSPs. When an outage occurs, the router immediately upstream from the link outage switches protected traffic to the bypass link, then signals the link failure to the ingress router.

The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the point of local repair. This constrains the set of LSPs being backed up through that bypass tunnel to those that pass through some common downstream nodes. All LSPs that pass through the point of local repair and through this common node, and that do not also use the facilities involved in the bypass tunnel are candidates for this set of LSPs.

The facility backup method is appropriate in the following situations:

  • The number of LSPs to be protected is large.

  • Satisfying path selection criteria (priority, bandwidth, and link coloring) for bypass paths is less critical.

  • Control at the granularity of individual LSPs is not required.

In Figure 4, Routers R1 and R5 are the ingress and egress routers, respectively. Router R2 has established a bypass tunnel that protects against the failure of Router R2-R3 link and Router R3 node. A bypass tunnel is established between Routers R6 and R7. There are three different protected LSPs that are using the same bypass tunnel for protection.

Figure 4: Facility Backup
Facility Backup

The facility backup method provides a scalability improvement, wherein the same bypass tunnel is also used to protect LSPs from any of RoutersR1, R2, or R8 to any of Routers R4, R5, or R9.

Configuring Link Protection on Interfaces Used by LSPs

When you configure node protection or link protection on a router for LSPs as described in Configuring Node Protection or Link Protection for LSPs, you also must configure the link-protection statement on the RSVP interfaces used by the LSPs.

To configure link protection on the interfaces used by the LSPs, include the link-protection statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

All the statements under link-protection are optional.

The following sections describe how to configure link protection:

Configuring Bypass LSPs

You can configure specific bandwidth and path constraints for a bypass LSP. Each manual bypass LSP on a router should have a unique “to” IP address. You can also individually configure each bypass LSP generated when you enable multiple bypass LSPs. If you do not configure the bypass LSPs individually, they all share the same path and bandwidth constraints (if any).

If you specify the bandwidth, hop-limit, and path statements for the bypass LSP, these values take precedence over the values configured at the [edit protocols rsvp interface interface-name link-protection] hierarchy level. The other attributes (subscription, no-node-protection, and optimize-timer) are inherited from the general constraints.

To configure a bypass LSP, specify a name for the bypass LSP using the bypass statement. The name can be up to 64 characters in length.

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

Configuring the Next-Hop or Next-Next-Hop Node Address for Bypass LSPs

If you configure a bypass LSP, you must also configure the to statement. The to statement specifies the address for the interface of the immediate next-hop node (for link protection) or the next-next-hop node (for node-link protection). The address specified determines whether this is a link protection bypass or a node-link protection bypass. On multiaccess networks (for example, a LAN), this address is also used to specify which next-hop node is being protected.

Configuring Administrative Groups for Bypass LSPs

Administrative groups, also known as link coloring or resource class, are manually assigned attributes that describe the “color” of links, such that links with the same color conceptually belong to the same class. You can use administrative groups to implement a variety of policy-based LSP setups. You can configure administrative groups for bypass LSPs. For more information about configuring administrative groups, see Configuring Administrative Groups for LSPs.

To configure administrative groups for bypass LSPs, include the admin-group statement:

To configure an administrative group for all of the bypass LSPs, include the admin-group statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

To configure an administrative groups for a specific bypass LSP, include the admin-group statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name]

Configuring the Bandwidth for Bypass LSPs

You can specify the amount of bandwidth allocated for automatically generated bypass LSPs or you can individually specify the amount of bandwidth allocated for each LSP.

If you have enabled multiple bypass LSPs, this statement is required.

To specify the bandwidth allocation, include the bandwidth statement:

For automatically generated bypass LSPs, include the bandwidth statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

For individually configured bypass LSPs, include the bandwidth statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name]

Configuring Class of Service for Bypass LSPs

You can specify the class-of-service value for bypass LSPs by including the class-of-service statement:

To apply a class-of-service value to all the automatically generated bypass LSPs, include the class-of-service statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

To configure a class-of-service value for a specific bypass LSPs, include the class-of-service statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name]

Configuring the Hop Limit for Bypass LSPs

You can specify the maximum number of hops a bypass can traverse. By default, each bypass can traverse a maximum of 255 hops (the ingress and egress routers count as one hop each, so the minimum hop limit is two).

To configure the hop limit for bypass LSPs, include the hop-limit statement:

For automatically generated bypass LSPs, include the hop-limit statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

For individually configured bypass LSPs, include the hop-limit statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name]

Configuring the Maximum Number of Bypass LSPs

You can specify the maximum number of dynamic bypass LSPs permitted for protecting an interface using the max-bypasses statement at the [edit protocols rsvp interface interface-name link-protection] hierarchy level. When this statement is configured, multiple bypasses for link protection are enabled. Call admission control (CAC) is also enabled.

By default, this option is disabled and only one bypass is enabled for each interface. You can configure a value of between 0 through 99 for the max-bypasses statement. Configuring a value of 0 prevents the creation of any dynamic bypass LSPs for the interface. If you configure a value of 0 for the max-bypasses statement, you need to configure one or more static bypass LSPs to enable link protection on the interface.

If you configure the max-bypasses statement, you must also configure the bandwidth statement (discussed in Configuring the Bandwidth for Bypass LSPs).

To configure the maximum number of bypass LSPs for a protected interface, include the max-bypasses statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

Disabling CSPF for Bypass LSPs

Under certain circumstances, you might need to disable CSPF computation for bypass LSPs and use the configured Explicit Route Object (ERO) if available. For example, a bypass LSP might need to traverse multiple OSPF areas or IS-IS levels, preventing the CSPF computation from working. To ensure that link and node protection function properly in this case, you have to disable CSPF computation for the bypass LSP.

You can disable CSPF computation for all bypass LSPs or for specific bypass LSPs.

To disable CSPF computation for bypass LSPs, include the no-cspf statement:

For a list of hierarchy levels where you can include this statement, see the statement summary for this statement.

Disabling Node Protection for Bypass LSPs

You can disable node protection on the RSVP interface. Link protection remains active. When this option is configured, the router can only initiate a next-hop bypass, not a next-next-hop bypass.

To disable node protection for bypass LSPs, include the no-node-protection statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

Configuring the Optimization Interval for Bypass LSPs

You can configure an optimization interval for bypass LSPs using the optimize-timer statement. At the end of this interval, an optimization process is initiated that attempts to either minimize the number of bypasses currently in use, minimize the total amount of bandwidth reserved for all of the bypasses, or both. You can configure an optimization interval from 1 through 65,535 seconds. A default value of 0 disables bypass LSP optimization.

When you configure the optimize-timer statement, bypass LSPs are reoptimized automatically when you configure or change the configuration of any of the following:

  • Administrative group for a bypass LSP—The configuration for an administrative group has been changed on a link along the path used by the bypass LSP. Configure an administrative group using the admin-group statement at the [edit protocols rsvp interface interface-name link-protection] hierarchy level.

  • Fate sharing group—The configuration for a fate sharing group has been changed. Configure a fate sharing group using the group statement at the [edit routing-options fate-sharing] hierarchy level.

  • IS-IS overload—The configuration for IS-IS overload has been changed on a router along the path used by the bypass LSP. Configure IS-IS overload using the overload statement at the [edit protocols isis] hierarchy level.

  • IGP metric—The IGP metric has been changed on a link along the path used by the bypass LSP.

To configure the optimization interval for bypass LSPs, include the optimize-timer statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

Configuring an Explicit Path for Bypass LSPs

By default, when you establish a bypass LSP to an adjacent neighbor, CSPF is used to discover the least-cost path. The path statement allows you to configure an explicit path (a sequence of strict or loose routes), giving you control over where and how the bypass LSP is established. To configure an explicit path, include the path statement:

For automatically generated bypass LSPs, include the path statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

For individually configured bypass LSPs, include the path statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name]

Configuring the Amount of Bandwidth Subscribed for Bypass LSPs

You can configure the amount of bandwidth subscribed to bypass LSPs. You can configure the bandwidth subscription for the whole bypass LSP or for each class type that might traverse the bypass LSP. You can configure any value between 1 percent and 65,535 percent. By configuring a value less than 100 percent, you are undersubscribing the bypass LSPs. By configuring a value greater than 100 percent, you are oversubscribing the bypass LSPs.

The ability to oversubscribe the bandwidth for the bypass LSPs makes it possible to more efficiently use network resources. You can configure the bandwidth for the bypass LSPs based on the average network load as opposed to the peak load.

To configure the amount of bandwidth subscribed for bypass LSPs, include the subscription statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name link-protection]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection]

Configuring Priority and Preemption for Bypass LSPs

When there is insufficient bandwidth to establish a more important LSP, you might want to tear down a less important existing LSP to release the bandwidth. You do this by preempting the existing LSP.

For more detailed information on configuring setup priority and reservation priority for LSPs, see Configuring Priority and Preemption for LSPs.

To configure the bypass LSP’s priority and preemption properties, include the priority statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Configuring Node Protection or Link Protection for LSPs

When you configure node protection or link protection on a router or switch, bypass LSPs are created to the next-hop or next-next-hop routers (switches) for the LSPs traversing the router (switch). You must configure node protection or link protection for each LSP that you want protected. To extend protection along the entire path used by an LSP, you must configure protection on each router that the LSP traverses.

You can configure node protection or link protection for both static and dynamic LSPs.

To configure node protection on a router for a specified LSP, include the node-link-protection statement:

You can include this statement at the following hierarchy levels:

To configure link protection on a router for a specified LSP, include the link-protection statement:

You can include this statement at the following hierarchy levels:

Note

To complete the configuration of node or link protection, you must also configure link protection on all unidirectional RSVP interfaces that the LSPs traverse, as described in Configuring Link Protection on Interfaces Used by LSPs.

To interoperate with other vendors’ equipment, the Junos OS supports the record route object (RRO) node ID subobject for use in inter-AS link and node protection configurations. The RRO node ID subobject is defined in RFC 4561, Definition of a Record Route Object (RRO) Node-Id Sub-Object. This functionality is enabled by default in Junos OS Release 9.4 and later.

If you have Juniper Networks routers running Junos OS Release 9.4 and later releases in the same MPLS-TE network as routers running Junos OS Release 8.4 and earlier releases, you might need to disable the RRO node ID subobject by configuring the no-node-id-subobject statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Related Documentation