26 mins read

RSVP – soft-preemption/adaptive

1. Intro

Essentially, we are discussing here about the make before break (MBB) feature. You will see MBB is enabled by default for some features, like periodic re-optimization of LSPs. By default, MBB is disabled for LSP preemption, but we can change this with either soft-preemption or adaptive.

Soft preemption attempts to establish a new path for a preempted LSP before tearing down the original LSP. The default behavior is to tear down a preempted LSP first, signal a new path, and then reestablish the LSP over the new path. In the interval between when the path is taken down and the new LSP is established, any traffic attempting to use the LSP is lost. Soft preemption prevents this type of traffic loss. The trade-off is that during the time when an LSP is being soft preempted, two LSPs with their corresponding bandwidth requirements are used until the original path is torn down.

You can configure an LSP to be adaptive when it is attempting to reroute itself. When it is adaptive, the LSP holds onto existing resources until the new path is successfully established and traffic has been cut over to the new LSP. To retain its resources, an adaptive LSP will ensure:

  • that the existing path is not torn down prematurely to allows the current traffic to continue flowing while the new path is being set up,
  • will avoid double-counting for links that share the new and old paths (using the shared explicit allocation style).

The adaptive feature changes the LSP reservation style. By default, Junos is using the FF (fixed filter) reservation style, which means that if one LSP has two established paths through the network and if both cross the same link, the LSP bandwidth is reserved twice over that link. This might cause an issue if there is not enough logical bandwidth left for the LSP to be established. The adaptive feature changes the reservation to SE (shared explicit). This way the bandwidth will be shared and only accounted once on the common links.

The topology we will use for testing:

RSVP preemption

Note:

  • Based on the addressing being used you will be able to identify the link.
  • For example. 17.6.7.7 is a link between router 6 and 7, and this is Router 7.
  • Second example. 17.1.2.1 is a link between router 1 and 2, and this is Router 1.

We will start with the following config:

2. By default, no MBB for preemption

We are adding a new LSP R1-to-R7-GOLD, so that it will away R1-to-R7-BEST-EFFORT to an alternate path.

If we check the LSP logs, we can see what is happening:

  • the LSP is preempted
  • torn down
  • a new path is computed
  • the new path is signaled and up.

Let’s rollback the config:

3. soft-preemption

Configure soft-preemption and test again:

If we check the LSP logs, we can see what is happening:

  • the LSP is soft preempted
  • a new path is computed
  • MBB is called
  • the new path is signaled and up
  • switch traffic to new path
  • wait 30 seconds (the default), then clean up old instance

4. Adaptive vs preemption

Let’s rollback and do the same using the adaptive feature:

If adaptive will not do MBB when preemption an LSP, then when to use it? See next section.

5. adaptive correct use

We will leave only the Best Effort LSP configured with no adaptive (we will delete the GOLD LSP).

### Delete GOLD LSP
### Disable link to R2
### Delete adaptive 

root@R1# show | compare 
[edit interfaces ge-0/0/1]
-   disable;
[edit protocols mpls label-switched-path R1-to-R7-BEST-EFFORT]
-    adaptive;
[edit protocols mpls]
     label-switched-path R1-to-R7-BEST-EFFORT { ... }
-    label-switched-path R1-to-R6-GOLD {
-        to 17.0.0.6;
-        bandwidth 600m;
-        priority 3 3;
-    }

[edit]
root@R1# commit 
commit complete

### We will use the Best-Effort LSP to demonstrate adaptive, notice the path that is used: 

root@R1# run show mpls lsp name R1-to-R7-BEST-EFFORT extensive ingress    
Ingress LSP: 1 sessions

17.0.0.7
  From: 17.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R7-BEST-EFFORT, LSPid: 33
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Follow destination IGP metric
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
  LSP Self-ping Status : Enabled
 *Primary                    State: Up
    Priorities: 5 5
    Bandwidth: 600Mbps
    OptimizeTimer: 30
    SmartOptimizeTimer: 180
    Flap Count: 1
    MBB Count: 0
    Reoptimization in 25 second(s).
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 12000)
 17.1.3.3 S 17.3.6.6 S 17.6.7.7 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          17.1.3.3(Label=302448) 17.3.6.6(Label=302224) 17.6.7.7(Label=3)
   28 Jul 30 08:10:38.566 Selected as active path
   27 Jul 30 08:10:38.564 Self-ping ended successfully
   26 Jul 30 08:10:37.894 Up
   25 Jul 30 08:10:37.893 Self-ping started
   24 Jul 30 08:10:37.893 Self-ping enqueued
   23 Jul 30 08:10:37.893 Record Route:  17.1.3.3(Label=302448) 17.3.6.6(Label=302224) 17.6.7.7(Label=3)
   22 Jul 30 08:10:37.860 LSP-ID: 2 created
   21 Jul 30 08:10:37.860 Originate Call
   20 Jul 30 08:10:37.860 CSPF: computation result accepted  17.1.3.3 17.3.6.6 17.6.7.7
   19 Jul 30 08:10:23.840 CSPF failed: no route toward 17.0.0.7
   18 Jul 30 08:10:23.840 CSPF: link down/deleted: 17.1.2.1(17.0.0.1:357)(17.0.0.1)->17.1.2.2(17.0.0.2:0)(17.0.0.2)

### We will decrease the bandwidth on the R3-R6 link: 

root@R3# show | compare 
[edit protocols rsvp interface ge-0/0/2.0]
+    bandwidth 500m;

[edit]
root@R3# commit 
commit complete

### At this point RSVP should navigate around this link: 

root@R3# run show rsvp interface 
RSVP interface: 4 active
                          Active  Subscr- Static      Available   Reserved    Highwater
Interface          State  resv    iption  BW          BW          BW          mark
ge-0/0/1.0             Up       1   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/2.0             Up       1   100%  500Mbps     -100Mbps    600Mbps     950Mbps    
ge-0/0/3.0             Up       0   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/4.0             Up       0   100%  1000Mbps    1000Mbps    0bps        600Mbps 

### There a valid path to use: R1-R3-R4-R5-R8-R7, but we RSVP can't set it up. 
### This is the issue adaptive is solving. We are still using the R3-R6 link:

root@R1# run show mpls lsp name R1-to-R7-BEST-EFFORT extensive ingress    
Ingress LSP: 1 sessions

17.0.0.7
  From: 17.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R7-BEST-EFFORT, LSPid: 33
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Follow destination IGP metric
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
  LSP Self-ping Status : Enabled
 *Primary                    State: Up
    Priorities: 5 5
    Bandwidth: 600Mbps
    OptimizeTimer: 30
    SmartOptimizeTimer: 180
    Flap Count: 1
    MBB Count: 0
    Reoptimization in 22 second(s).
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 12000)
 17.1.3.3 S 17.3.6.6 S 17.6.7.7 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          17.1.3.3(Label=302448) 17.3.6.6(Label=302224) 17.6.7.7(Label=3)
   29 Jul 30 08:11:35.913 CSPF failed: no route toward 17.0.0.7[2 times, first Jul 30 08:11:06.767]
   28 Jul 30 08:10:38.566 Selected as active path
   27 Jul 30 08:10:38.564 Self-ping ended successfully
   26 Jul 30 08:10:37.894 Up
   25 Jul 30 08:10:37.893 Self-ping started
   24 Jul 30 08:10:37.893 Self-ping enqueued
   23 Jul 30 08:10:37.893 Record Route:  17.1.3.3(Label=302448) 17.3.6.6(Label=302224) 17.6.7.7(Label=3)
   22 Jul 30 08:10:37.860 LSP-ID: 2 created
   21 Jul 30 08:10:37.860 Originate Call
   20 Jul 30 08:10:37.860 CSPF: computation result accepted  17.1.3.3 17.3.6.6 17.6.7.7
   19 Jul 30 08:10:23.840 CSPF failed: no route toward 17.0.0.7
   18 Jul 30 08:10:23.840 CSPF: link down/deleted: 17.1.2.1(17.0.0.1:357)(17.0.0.1)->17.1.2.2(17.0.0.2:0)(17.0.0.2)

We have an LSP R1-R3-R6-R7 and we need to set up a new one R1-R3-R4-R5-R8-R7. The problem is the R1-R3 link, our Best Effort LSP it is already using 600 Mpbs on that link. Setting up a new path for the same Best Effort LSP would mean to double allocate 600 Mbps.

You may say that the old and new path is for the same Best Effort LSP, and should not be double counted, but still is. Well, adaptive was created for this exact scenario:

### Configure adaptive:

root@R1# show | compare 
[edit protocols mpls label-switched-path R1-to-R7-BEST-EFFORT]
+    adaptive;

[edit]
root@R1# commit 
commit complete

### Redo the same test, exactly as we previously did in this section:
### We can see the the old and new LSP can coexist now: 

root@R1# run show rsvp session ingress 
Ingress RSVP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
17.0.0.7        17.0.0.1        Up       0  1 SE       -   302480 R1-to-R7-BEST-EFFORT
17.0.0.7        17.0.0.1        Up       0  1 SE       -   302496 R1-to-R7-BEST-EFFORT
Total 2 displayed, Up 2, Down 0

### The bandwidth is no longer double counted: 

root@R1# run show rsvp interface 
RSVP interface: 2 active
                          Active  Subscr- Static      Available   Reserved    Highwater
Interface          State  resv    iption  BW          BW          BW          mark
ge-0/0/1.0           Down       0   100%  1000Mbps    1000Mbps    0bps        600Mbps    
ge-0/0/2.0             Up       1   100%  1000Mbps    400Mbps     600Mbps     950Mbps 

### The recomputed path is UP and MBB was used: 

root@R1# run show mpls lsp name R1-to-R7-BEST-EFFORT extensive ingress    
Ingress LSP: 1 sessions

17.0.0.7
  From: 17.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R7-BEST-EFFORT, LSPid: 34
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Follow destination IGP metric
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
  LSP Self-ping Status : Enabled
 *Primary                    State: Up
    Priorities: 5 5
    Bandwidth: 600Mbps
    OptimizeTimer: 30
    SmartOptimizeTimer: 180
    Flap Count: 0
    MBB Count: 2
    Reoptimization in 13 second(s).
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 5000)
 17.1.3.3 S 17.3.4.4 S 17.4.5.5 S 17.5.8.8 S 17.7.8.7 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          17.1.3.3(Label=302496) 17.3.4.4(Label=301632) 17.4.5.5(Label=301552) 17.5.8.8(Label=301216) 17.7.8.7(Label=3)
   39 Jul 30 08:32:08.593 CSPF: computation result ignored, new path no benefit[2 times, first Jul 30 08:31:40.454]
   38 Jul 30 08:31:40.454 Originate make-before-break call: Add skipped CSPF run
   37 Jul 30 08:31:40.454 Make-before-break: Cleaned up old instance: Hold dead expiry
   36 Jul 30 08:31:39.664 Pending old path instance deletion[3 times, first Jul 30 08:30:41.234]
   35 Jul 30 08:30:13.092 Make-before-break: Switched to new instance
   34 Jul 30 08:30:13.090 Self-ping ended successfully
   33 Jul 30 08:30:12.324 Up
   32 Jul 30 08:30:12.324 Self-ping started
   31 Jul 30 08:30:12.324 Self-ping enqueued
   30 Jul 30 08:30:12.324 Record Route:  17.1.3.3(Label=302496) 17.3.4.4(Label=301632) 17.4.5.5(Label=301552) 17.5.8.8(Label=301216) 17.7.8.7(Label=3)
   29 Jul 30 08:30:12.271 LSP-ID: 3 created
   28 Jul 30 08:30:12.271 Originate make-before-break call
   27 Jul 30 08:30:12.271 CSPF: computation result accepted  17.1.3.3 17.3.4.4 17.4.5.5 17.5.8.8 17.7.8.7
   26 Jul 30 08:30:12.271 CSPF: Reroute due to re-optimization

### After 30 seconds the old path is deleted: 

root@R1# run show rsvp session ingress                                    
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
17.0.0.7        17.0.0.1        Up       0  1 SE       -   302496 R1-to-R7-BEST-EFFORT
Total 1 displayed, Up 1, Down 0

Adaptive may also help in a different scenario, when we have primary/secondary standby paths, it will not double count bandwidth:

### Configure primary/secondary paths:

root@R1# show | compare 
[edit protocols mpls label-switched-path R1-to-R7-BEST-EFFORT]
+     primary BLUE-PATH;
+     secondary RED-PATH {
+         standby;
+     }

[edit]
root@R1# commit 
commit complete

root@R1# show protocols mpls | display set | match BEST 
set protocols mpls label-switched-path R1-to-R7-BEST-EFFORT to 17.0.0.7
set protocols mpls label-switched-path R1-to-R7-BEST-EFFORT bandwidth 600m
set protocols mpls label-switched-path R1-to-R7-BEST-EFFORT priority 5 5
set protocols mpls label-switched-path R1-to-R7-BEST-EFFORT adaptive
set protocols mpls label-switched-path R1-to-R7-BEST-EFFORT primary BLUE-PATH
set protocols mpls label-switched-path R1-to-R7-BEST-EFFORT secondary RED-PATH standby

### Both primary and secondary paths are UP:

root@R1# run show mpls lsp name R1-to-R7-BEST-EFFORT extensive ingress | match state 
  From: 17.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R7-BEST-EFFORT, LSPid: 34
 *Primary   BLUE-PATH        State: Up
  Standby   RED-PATH         State: Up

### Configured like this, adaptive will not double count parimary/secondary paths: 

root@R1# run show rsvp interface 
RSVP interface: 2 active
                          Active  Subscr- Static      Available   Reserved    Highwater
Interface          State  resv    iption  BW          BW          BW          mark
ge-0/0/1.0           Down       0   100%  1000Mbps    1000Mbps    0bps        600Mbps    
ge-0/0/2.0             Up       1   100%  1000Mbps    400Mbps     600Mbps     950Mbps

6. Putting all together

We will keep it short this time, but let’s reconfigure the network so it look like this:

Our Best-Effort LSP will be configured from R2-to-R8. In our test we will add new GOLD LSP that has a higher priority, and this will force the Best-Effort LSP to find a new path. We will study the effects soft-preemption/adaptive has on the Best-Effort LSP:

  • With adaptive configured:
  • Redo the same test with soft-preemption configured:
  • Redo the test with both soft-preemption and adaptive:
### Both 'soft-preemption' and 'adaptive' are configured:

set protocols mpls label-switched-path R2-to-R8-BEST-EFFORT to 17.0.0.8
set protocols mpls label-switched-path R2-to-R8-BEST-EFFORT soft-preemption
set protocols mpls label-switched-path R2-to-R8-BEST-EFFORT bandwidth 600m
set protocols mpls label-switched-path R2-to-R8-BEST-EFFORT priority 5 5
set protocols mpls label-switched-path R2-to-R8-BEST-EFFORT adaptive

### Now there is no more impact: 

    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 6000)
 17.2.4.4 S 17.4.5.5 S 17.5.6.6 S 17.6.7.7 S 17.7.8.8 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          17.2.4.4(Label=302080) 17.4.5.5(Label=302000) 17.5.6.6(Label=302864) 17.6.7.7(Label=299936) 17.7.8.8(Label=3)
   25 Jul 31 03:40:05.296 CSPF: computation result ignored, new path no benefit
   24 Jul 31 03:40:05.296 Originate make-before-break call: Add skipped CSPF run
   23 Jul 31 03:40:05.296 Make-before-break: Cleaned up old instance: due to path down
   22 Jul 31 03:39:56.279 Pending old path instance deletion
   21 Jul 31 03:39:35.715 Make-before-break: Switched to new instance
   20 Jul 31 03:39:35.714 Self-ping ended successfully
   19 Jul 31 03:39:35.326 Up
   18 Jul 31 03:39:35.326 Self-ping started
   17 Jul 31 03:39:35.326 Self-ping enqueued
   16 Jul 31 03:39:35.326 Record Route:  17.2.4.4(Label=302080) 17.4.5.5(Label=302000) 17.5.6.6(Label=302864) 17.6.7.7(Label=299936) 17.7.8.8(Label=3)
   15 Jul 31 03:39:35.276 LSP-ID: 2 created
   14 Jul 31 03:39:35.276 Originate make-before-break call
   13 Jul 31 03:39:35.276 CSPF: computation result accepted  17.2.4.4 17.4.5.5 17.5.6.6 17.6.7.7 17.7.8.8
   12 Jul 31 03:39:35.276 17.5.6.6: Reroute request due to soft preemption received.

### Adaptive helped by not double counting the bandwidth, 
### Soft-preemption called for make-before-break. 
### Notice we had a graceful transition from old to new path, with no traffic impact. 

Conclusion

  • soft-preemption will activate the MBB behavior for preempted LSPs.
  • Some events like newly configured LSP or link down will trigger LSP Preemption.
  • Other event like automatic re-optimization (OptimizeTimer, if enabled) will not cause preemption (to reduce the ripple effect of preemption causing more preemption).
  • adaptive will avoid double counting bandwidth, and will switch over traffic using MBB (e.g. during re-optimization).
  • But, adaptive will not enable MBB for preempted LSPs.
  • Adaptive will not double count Primary/Secondary paths.
  • soft-preemption and adaptive can work in conjunction.

External Resources: