Configuring and Verifying an Adaptive LSP
When you include the adaptive statement in the configuration, the LSP becomes adaptive and is established with the SE reservation style. The adaptive statement can be configured at two hierarchy levels:
- The [edit protocols mpls label-switched-path lsp-path-name] hierarchy level, which keeps the RSVP session information the same for all primary and secondary paths.
- The [edit protocols mpls label-switched-path lsp-path-name secondary secondary-name] hierarchy level, resulting in different Tunnel ID values for each path and causes the paths to be viewed as separate RSVP sessions, that may not share the same bandwidth reservation and possibly double-count resources.
Using an adaptive LSP at the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level provides two advantages. The first advantage is the prevention of double-counting of bandwidth for links that share old and new paths. Double-counting occurs when an intermediate router does not recognize that the new and old paths belong to the same LSP and counts them as two separate LSPs, requiring separate bandwidth allocations. If some links are close to saturation, double-counting might cause the setup of the new path to fail. When the adaptive statement is included at the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level, a standby secondary path is established, sharing physical links in common with the LSP’s primary path.
The second advantage is the prevention of disruption to subscriber traffic by performing a make-before-break operation. When an established path attempts to reroute onto a new path, the ingress router maintains existing paths and allocated bandwidths, ensuring that the existing path is not prematurely torn down and allowing the current traffic to continue flowing while the new path is set up.
The following steps describe the process of configuring an adaptive LSP that keeps the RSVP session information the same for all primary and secondary paths. Before you can configure an adaptive LSP, you must have an LSP already configured with the primary and secondary paths you want to use, and any other options. For information on configuring a LSP with a primary path and secondary path, see Checklist for Path Protection.
Action
To configure an adaptive LSP, follow these steps:
- In configuration mode, go to the following hierarchy level:[edit]user@R1# edit protocol mpls
- Configure adaptive mode for the LSP:[edit protocols mpls]user@R1# set label-switched-path lsp-path-name adaptive
For example:
[edit protocols mpls]user@R1# set label-switched-path lsp1 adaptive - Verify and commit the configuration:[edit protocols mpls]user@R1# show user@R1# commit
Sample Output
[edit protocols mpls]
user@R1# show
bandwidth 75m;
label-switched-path lsp1 {
to 192.168.5.1;
adaptive;
primary via-r2;
secondary via-r7 {
standby;
}
}
path via-r7 {
10.0.17.14 strict;
10.0.27.1 strict;
10.0.24.14 strict;
10.0.49.2 strict;
}
path via-r2 {
10.0.12.14 strict;
10.0.24.14 strict;
}
interface fe-0/1/0.0;
interface fe-0/1/1.0;
interface so-0/0/3.0;
[edit protocols mpls]
user@R1# commit
commit complete
Meaning
Sample output from R1 for the show command shows bandwidth of 75 Mbps, the adaptive statement, and strict primary and secondary paths. 75 Mbps of bandwidth for each path is more combined bandwidth than the Fast Ethernet link fe-0/1/2 can accommodate. Because lsp1 is adaptive, both paths are up, indicating that the bandwidth is not double-counted, as shown in the following output for the show mpls lsp extensive command.
Sample Output
[edit protocols mpls]
user@R1# run show mpls lsp extensive
Ingress LSP: 1 sessions
192.168.5.1
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: lsp1
ActivePath: via-r2 (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary via-r2 State: Up
Bandwidth: 75Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.0.12.14 S 10.0.24.14 S 10.0.45.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.0.12.14 10.0.24.14 10.0.45.2
5 Jul 21 14:34:16 Selected as active path
4 Jul 21 14:34:16 Record Route: 10.0.12.14 10.0.24.14 10.0.45.2
3 Jul 21 14:34:16 Up
2 Jul 21 14:34:16 Originate Call
1 Jul 21 14:34:16 CSPF: computation result accepted
Standby via-r7 State: Up
Bandwidth: 75Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 5)
10.0.17.14 S 10.0.27.1 S 10.0.24.14 S 10.0.49.2 S 10.0.59.1 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node ...
10.0.17.14 10.0.27.1 10.0.24.14 10.0.49.2 10.0.59.1
4 Jul 21 14:34:45 Record Route: 10.0.17.14 10.0.27.1 10.0.24.14 10.0.49.2 10.0.59.1
3 Jul 21 14:34:45 Up
2 Jul 21 14:34:45 Originate Call
1 Jul 21 14:34:45 CSPF: computation result accepted
Created: Fri Jul 21 14:34:15 2006
Total 1 displayed, Up 1, Down 0
Meaning
The sample output from R1 for the show mpls lsp extensive command shows that lsp1 is up with an active primary path that is up (*Primary via-r2 State: Up), and a standby secondary path that is also up (Standby via-r7 State: Up). Both paths have 75 Mbps of bandwidth, which is not double-counted because the adaptive statement ensures that new and old paths are recognized as belonging to the same LSP lsp1, as shown in the following sample output for the show rsvp session detail command. You can also use the show rsvp interface command to show the reserved and available bandwidth.
Sample Output
user@R1> show rsvp session detail Ingress RSVP: 2 sessions 192.168.5.1 From: 192.168.1.1 , LSPstate: Up, ActiveRoute: 0 LSPname: lsp1, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 102736 Resv style: 1 SE, Label in: -, Label out: 102736 Time left: -, Since: Fri Jul 21 14:34:16 2006 Tspec: rate 75Mbps size 75Mbps peak Infbps m 20 M 1500 Port number: sender 1 receiver 60167 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.0.12.14 (fe-0/1/0.0) 7 pkts RESV rcvfrom: 10.0.12.14 (fe-0/1/0.0) 7 pkts Explct route: 10.0.12.14 10.0.24.14 10.0.45.2 Record route: <self> 10.0.12.14 10.0.24.14 10.0.45.2 192.168.5.1 From: 192.168.1.1 , LSPstate: Up, ActiveRoute: 0 LSPname: lsp1, LSPpath: Secondary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 102608 Resv style: 1 SE , Label in: -, Label out: 102608 Time left: -, Since: Fri Jul 21 14:34:45 2006 Tspec: rate 75Mbps size 75Mbps peak Infbps m 20 M 1500 Port number: sender 2 receiver 60167 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.0.17.14 (fe-0/1/1.0) 5 pkts RESV rcvfrom: 10.0.17.14 (fe-0/1/1.0) 5 pkts Explct route: 10.0.17.14 10.0.27.1 10.0.24.14 10.0.49.2 10.0.59.1 Record route: <self> 10.0.17.14 10.0.27.1 10.0.24.14 10.0.49.2 10.0.59.1 Total 2 displayed, Up 2, Down 0 [...Output truncated...]
Meaning
The sample output from R1 for the show rsvp session detail command shows two RSVP sessions for lsp1. Both sessions originate on R1 (192.168.1.1) and end in R5 (192.168.5.1). The first session is for the primary path and the second session is for the secondary path. Both paths are in the SE reservation style. The port number is the protocol ID and sender/receiver port used in this RSVP session. In the port number field, the primary session shows sender 1, while the secondary session shows sender 2, indicating that two senders are using the LSP tunnel.
