ON THIS PAGE
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.
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.
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:
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.
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.
If no manual bypass LSPs are available and if the
max-bypassesstatement 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 themax-bypassesstatement), 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.
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.
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
- LSP Protection Types Comparison
- One-to-One Backup Implementation
- Facility Backup Implementation
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.
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 |
|
|
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.
In the example, the protected LSP is R1-R2-R3-R4-R5, and the following detours are established:
Router R1—
R1-R6-R7-R8-R3Router R2—
R2-R7-R8-R4Router R3—
R3-R8-R9-R5Router 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.
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:
link-protection {
disable;
admin-group
exclude group-names;
include-all group-names;
include-any group-names;
}
bandwidth bps;
bypass bypass-name {
bandwidth bps;
description text;
hop-limit number;
no-cspf;
path address <strict | loose>;
priority setup-priority reservation-priority;
to address;
}
class-of-service cos-value;
hop-limit number;
max-bypasses number;
no-cspf;
no-node-protection;
optimize-timer seconds;
path address <strict | loose>;
priority setup-priority reservation-priority;
subscription percent {
ct0 percent;
ct1 percent;
ct2 percent;
ct3 percent;
}
}
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
- Configuring Administrative Groups for Bypass LSPs
- Configuring the Bandwidth for Bypass LSPs
- Configuring Class of Service for Bypass LSPs
- Configuring the Hop Limit for Bypass LSPs
- Configuring the Maximum Number of Bypass LSPs
- Disabling CSPF for Bypass LSPs
- Disabling Node Protection for Bypass LSPs
- Configuring the Optimization Interval for Bypass LSPs
- Configuring Unreserved bandwidth Optimization for Bypass LSPs
- Configuring an Explicit Path for Bypass LSPs
- Configuring the Amount of Bandwidth Subscribed for Bypass LSPs
- Configuring Priority and Preemption for Bypass LSPs
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.
bypass bypass-name { bandwidth bps; description text; class-of-service cos-value; hop-limit number; no-cspf; path address <strict | loose>; priority setup-priority reservation-priority; to address; }
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:
admin-group { exclude group-names; include-all group-names; include-any group-names; }
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:
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:
bandwidth bps;
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:
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:
class-of-service cos-value;
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:
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:
hop-limit number;
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:
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:
max-bypasses number;
You can include this statement at the following hierarchy levels:
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:
no-cspf;
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:
no-node-protection;
You can include this statement at the following hierarchy levels:
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-groupstatement 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
groupstatement 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
overloadstatement 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:
optimize-timer seconds;
You can include this statement at the following hierarchy levels:
Configuring Unreserved bandwidth Optimization for Bypass LSPs
The default approach of RSVP bypass produces a bypass method that optimizes traffic engineering (TE) metric. The Constrained Shortest Path First (CSPF) can optionally use a different approach to protect a link or a node by leveraging the computation based on unreserved bandwidths on (TE) links.
To enable this feature, use the optimize bandwidth configuration
statement at the edit protocols rsvp interface interface
link-protection hierarchy level. Enabling the new configuration
statement maximizes the end-to-end unreserved bandwidth.
To apply optimize bandwidth configuration statement, enable the set protocols isis l3-unicast-topology configuration.
link-protection {
optimize {
bandwidth;
}
}For configuring bandwidth optimization algorithm for bypass LSPs, include the
optimize bandwidth statement at the following hierarchy
levels:
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:
path address <strict | loose>;
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:
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:
subscription percentage { ct0 percentage; ct1 percentage; ct2 percentage; ct3 percentage; }
You can include this statement at the following hierarchy levels:
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:
priority setup-priority reservation-priority;
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:
node-link-protection;
You can include this statement at the following hierarchy levels:
[edit protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
To configure link protection on a router for a specified LSP, include the link-protection statement:
link-protection;
You can include this statement at the following hierarchy levels:
[edit protocols mpls label-switched-path lsp-name][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
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.
Configuring Inter-AS Node and Link Protection
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:
no-node-id-subobject;
You can include this statement at the following hierarchy levels:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Configuring Constraint Aware Bypass LSPs
You can configure RSVP bypass LSPs to be aware of and inherit all the path constraints from the primary LSPs. You can also explicitly configure bypass constraints for individual LSPs.
Benefits of Constraint Aware RSVP Bypass LSPs
-
Control the MPLS path and prevent bypass LSPs from traversing through a specific geographical area in a global MPLS RSVP network
You can configure constraint aware RSVP bypass LSPs with link-protection, node-link-protection, and containerized for primary LSPs.
To configure constraint aware bypass LSPs, the inherit-lsp constraints and
bypass-constraints statements are introduced at the [edit
protocols mpls label-swithed-path lsp-name link-protection]
and at the [edit protocols mpls label-swithed-path lsp-name
node-link-protection] hierarchy levels.
To configure constraint aware bypass LSPs on an ingress LER, you can either inherit the bypass constraints or explicitly define separate constraints for bypass.
To inherit the bypass constraints, include the inherit-lsp constraints
statement at the [edit protocols mpls label-swithed-path lsp-name
link-protection] and at the [edit protocols mpls label-swithed-path
lsp-name node-link-protection] hierarchy levels.
To define separate constraints for bypass LSPs, include the
bypass-constraints statement at the [edit protocols mpls
label-swithed-path lsp-name link-protection] and at the
[edit protocols mpls label-swithed-path lsp-name
node-link-protection] hierarchy levels. You can configure the options inside the
bypass-constraints statement hierarchy to either inherit all the
constraints from the primary LSP or specific constraints for that LSP’s bypass.
Configuring transport-class statement is not mandatory while configuring constraint aware bypass LSPs. The constraint aware bypass LSP feature works with or without transport-class statement configured for the LSP.
On PLRs, you need to include the constraint-aware-bypass statement at the
[edit protocols rsvp interface interface-name
link-protection] hierarchy level to support constraint aware bypass LSPs.
If you have multiple LSPs at a particular ingress LER and you decide to enable the
constraint aware bypass feature only on a small subset of LSPs, then the
bypass-constraints statement helps in enabling the feature only on those
specific LSPs.
If you do not configure bypass-constraints statement at the ingress for a
particular LSP, then that LSP continues to have the current non-constraint aware bypass
association. The transit LSRs and PLR automatically establishes constraint aware bypass LSPs
only for the LSPs for which the bypass-constraints statement is configured
at the ingress under MPLS and at PLR under RSVP.
When you modify the constraint aware bypass LSPs configuration on the ingress, then such configuration changes are handled in the make before break (MBB) fashion for the LSP. That is, a new instance of the LSP is signaled with the new bypass constraint objects. When the PLR receives the path message for the new instance of the LSP, the PLR establishes the appropriate bypass LSP that satisfies those constraints.
Similarly, when you modify the constraint aware bypass configuration at PLR, all the bypass LSPs are recomputed and re-associated with the primary LSPs at that PLR.
Dynamic link-protection bypass LSPs are created along the path at the PLRs which follows the same CSPF constraints like excluding a specific admin-group.
The constraint aware bypass LSP feature does not work when:
-
LSPs are configured with no-cspf statement at the ingress.
-
LSPs are configured with pop-and-forward functionality.
-
Bypass LSPs are manually configured at PLR.
-
max-bypassesstatement is configured at PLR
If there are any changes to the resource affinities signaled for the LSP, then each individual LSR along the LSP’s path automatically recomputes the bypasses as required.
When the bypass-constraints statement is configured at the ingress
indicating the intent to signal constraint aware bypass LSPs, the ingress LER includes the
FAST_REROUTE object in the RSVP path message for the LSP. Ingress sets the Flags field to
0x02 indicating Facility Backup as the type of protection. Ingress also populates all the
constraints as configured for that bypass LSP.
On receipt of the FAST_REROUTE object in the RSVP path message, every PLR router creates and maintains a lsp-affinities-profile which stores all the received constraints. PLR performs a lookup amongst existing bypass LSPs to see if any of the existing bypass LSPs satisfy the constraint requirements. If existing bypass LSPs satisfies the constraints, then that bypass LSP is associated with the primary LSP. Otherwise, if the constraints are not satisfied by existing bypass LSP, then PLR proceeds to establish a new bypass matching all the constraints received in the incoming RSVP path message.
The outputs of show rsvp session and show rsvp session
bypass commands have been enhanced to display the bypass constraints inherited
from the primary LSPs and the resource affinities signaled for the LSP.
The following is a sample output of show rsvp session extensive command
displaying the bypass constraints information:
user@host> show rsvp session extensive
8.8.8.8
From: 1.1.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: lsp-R1-R8-1, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 299984
Resv style: 1 SE, Label in: -, Label out: 299984
Time left: -, Since: Sun Nov 19 02:46:26 2023
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 3 receiver 18914 protocol 0
Link protection desired
Type: Link protected LSP, using Bypass->22.1.9.9
6 Nov 20 15:16:04 Link protection up, using Bypass->22.1.9.9
5 Nov 20 15:16:03 Bypass in down state, Bypass->22.1.9.9[3 times, first Nov 20 15:16:01 ]
Bypass constraints for LSP:
Hop Limit : 9
Include Any: green Include All: Brown Exclude: Red
Enhanced FRR: Enabled (Downstream), LP-MP is 9.9.9.9
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 22.1.9.9 (ge-0/0/2.0) 4 pkts
outgoing message state: refreshing, Message ID: 180, Epoch: 11062187
RESV rcvfrom: 22.1.9.9 (ge-0/0/2.0) 6 pkts, Entropy label: Yes
incoming message handle: R-82/6, Message ID: 170, Epoch: 11062161
Explct route: 22.1.9.9 22.9.10.10 22.8.10.8
Record route: <self> 9.9.9.9 (node-id) 22.1.9.9 10.10.10.10 (node-id) 22.9.10.10 8.8.8.8 (node-id) 22.8.10.8
The following is a sample output of show rsvp session bypass extensive
command displaying the bypass constraints information:
user@host> show rsvp session bypass extensive
9.9.9.9
From: 1.1.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->22.1.9.9
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 300048
Resv style: 1 SE, Label in: -, Label out: 300048
Time left: -, Since: Mon Nov 20 15:16:03 2023
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 40332 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
Number of protected LSP instances: 1
Bypass constraints for LSP:
Hop Limit : 9
Include Any: green Include All: Brown Exclude: Red
Enhanced FRR: Enabled (Downstream)
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 22.1.5.5 (ge-0/0/1.0) 1 pkts