Technical Documentation

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:

  1. In configuration mode, go to the following hierarchy level:
    [edit]user@R1# edit protocol mpls
  2. 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
  3. 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.


Published: 2010-01-30