Prioritizing LSPs

Problem

You want to give higher priority to the more important LSPs so that they can always be established.

Solution

Configure the more important LSP so that it is more likely to be set up and remain up:

[edit protocols mpls] aviva@R1# set label-switched-path R1-to-R5 priority 0 0

Then configure intermediate priority LSPs, those less likely to be set up and remain up:

[edit protocols mpls] aviva@R1# set label-switched-path R1-to-R6 priority 1 3 aviva@R1# set label-switched-path R1-to-R4 priority 4 5

Finally, set up the least important LSP, the one least like to be set up and most likely to be torn down if there is insufficient bandwidth:

[edit protocols mpls] aviva@R1# set label-switched-path R1-to-R5-low priority 7 7

Discussion

When you offer a higher level of service for some customers, you want RSVP to be able to establish those customers LSP at all times, even when there might not be enough bandwidth available on some links because other LSPs are already established. To provide this level of service, you can prioritize each customers LSP so that some are more important than others. Then, when RSVP calculates the path and sets up the LSP, RSVP will always be able to establish the more important LSPs, even at the cost of tearing down a less important LSP. The relative LSP priorities are determined in advance, when RSVP is establishing the LSP, not when traffic is being forwarded. If a link has insufficient bandwidth, RSVP establishes the more important (higher-priority) LSPs first and tears down lower-priority LSPs if necessary.

This recipe prioritizes the four LSPs that originate on router R1. To configure an LSPs priority, you include two values in the priority statement, the setup priority and the hold priority. You express these two priorities with a number from 0 through 7, where 0 is best and 7 is worst. A setup priority of 0 means that this LSP can preempt any other LSP whose hold priority is worse than 0. Similarly, a hold priority of 0 means that once the LSP is set up, it cannot be preempted. A hold priority of 1 means that it can be preempted only by an LSP with a setup priority of 0. The default setup priority is 7, which means that one LSP cannot preempt another. The default hold priority is 0, which means that another LSP cannot preempt this one.

The four LSPs configured in this recipe have different priorities. The LSP R1-to-R5 is the one being used for the most important customer. It will always be set up (setup priority of 0) and can never be preempted (hold priority of 0) when RSVP is setting up another LSP. The other three LSPs, in order from highest to lowest priority, are R1-to-R6 (setup priority of 1, hold priority of 3), R1-to-R4 (setup priority of 4, hold priority of 5), and R1-to-R5-low (setup priority of 7, hold priority of 7). The setup and hold priority values for the different LSP are all evaluated relative to each other.

To understand how preemption works, set up LSPs sequentially and observe how they are established. First, set up the lowest-priority LSP, R1-to-R5-low:

[edit protocols mpls] aviva@R1# set label-switched-path R1-to-R5-low to 10.0.0.5 aviva@R1# set label-switched-path R1-to-R5-low bandwidth 80m aviva@R1# set label-switched-path R1-to-R5-low to priority 7 7

Because this is the first and only LSP on the ingress router, you expect RSVP to set it up even though it has the lowest setup priority. Look at the LSP to check that RSVP has set it up:

aviva@R7# show mpls lsp Ingress LSP: 1 sessions To From State Rt ActivePath P LSPname 10.0.0.5 10.0.0.1 Up 0 * R1-to-R5-low Total 1 displayed, Up 1, Down 0

The State column confirms that the LSP is up. Then check that RSVP has reserved the requested bandwidth for the LSP:

aviva@R7# show rsvp interface RSVP interface: 2 active Active Subscr- Static Available Reserved Highwater Interface State resv iption BW BW BW mark so-0/0/0.0 Up 1 100% 155.52Mbps 75.52Mbps 80Mbps 80Mbps so-0/0/2.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 100Mbps

You see that RSVP has reserved 80 Mbps on the so-0/0/0 interface for this LSP. Finally, look at the details about the LSP:

aviva@R7# show mpls lsp ingress extensive Ingress LSP: 1 sessions 10.0.0.5 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R5-low ActivePath: (primary) LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 7 7 Bandwidth: 80Mbps SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.12.2 S 10.1.26.2 S 10.1.56.1 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 10.1.12.2 10.1.26.2 10.1.56.1 10 Oct 14 10:39:39 Record Route: 10.1.12.2 10.1.26.2 10.1.56.1 9 Oct 14 10:39:39 Up 8 Oct 14 10:39:39 Originate Call … Created: Fri Oct 14 10:35:55 2005 Total 1 displayed, Up 1, Down 0

This output confirms that the LSP is up and shows the configured priority values and bandwidth request.

Next, configure the higher-priority LSP R1-to-R4:

[edit protocols mpls] aviva@R1# set label-switched-path R1-to-R4 to 10.0.0.4 aviva@R1# set label-switched-path R1-to-R4 to priority 4 4 aviva@R1# set label-switched-path R1-to-R4 bandwidth 90m

Check that the second LSP is set up:

aviva@R7# show mpls lsp ingress Ingress LSP: 2 sessions To From State Rt ActivePath P LSPname 10.0.0.4 10.0.0.1 Up 0 * R1-to-R4 10.0.0.5 10.0.0.1 Up 0 * R1-to-R5-low Total 2 displayed, Up 2, Down 0

This output confirms that RSVP was able to establish both LSPs. Then, look at the bandwidth reservations:

aviva@R7# show rsvp interface RSVP interface: 2 active Active Subscr- Static Available Reserved Highwater Interface State resv iption BW BW BW mark so-0/0/0.0 Up 1 100% 155.52Mbps 75.52Mbps 80Mbps 80Mbps so-0/0/2.0 Up 1 100% 155.52Mbps 65.52Mbps 90Mbps 100Mbps

You see here that RSVP has reserved 90 Mbps for LSP R1-to-R4 on the so-0/0/2 interface and has left the previously established reservation for LSP R1-to-R5-low of 80 Mbps on unchanged. The two SONET interfaces on the router have sufficient bandwidth for both LSPs, so RSVP can create both without preempting one of them. Check the details of the two LSPs to see the paths that RSVP has established for them:

aviva@R7# show mpls lsp ingress extensive Ingress LSP: 2 sessions 10.0.0.4 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R4 ActivePath: (primary) LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 4 4 Bandwidth: 90Mbps SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 10.1.13.2 S 10.1.34.2 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 10.1.13.2 10.1.34.2 5 Oct 14 10:43:13 Selected as active path 4 Oct 14 10:43:13 Record Route: 10.1.13.2 10.1.34.2 3 Oct 14 10:43:13 Up 2 Oct 14 10:43:13 Originate Call 1 Oct 14 10:43:13 CSPF: computation result accepted Created: Fri Oct 14 10:43:12 2005 10.0.0.5 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R5-low ActivePath: (primary) LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 7 7 Bandwidth: 80Mbps SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.12.2 S 10.1.26.2 S 10.1.56.1 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 10.1.12.2 10.1.26.2 10.1.56.1 10 Oct 14 10:39:39 Record Route: 10.1.12.2 10.1.26.2 10.1.56.1 9 Oct 14 10:39:39 Up 8 Oct 14 10:39:39 Originate Call Created: Fri Oct 14 10:35:55 2005 Total 2 displayed, Up 2, Down 0

The record route objects in this output confirm that RSVP has directed the LSP R1-to-R5-low to R2 (12.1.12.2), over the so-0/0/0 interface, and has set up LSP R1-to-R4 to R3 (12.1.13.2), over so-0/0/2.

Finally, configure an even higher-priority LSP on the ingress router, R1-to-R6:

[edit protocols mpls] aviva@R1# set label-switched-path R1-to-R6 to 10.0.0.6 aviva@R1# set label-switched-path R1-to-R6 to priority 2 2 aviva@R1# set label-switched-path R1-to-R6 bandwidth 90m

You are requesting 90 Mbps for this LSP, in addition to the 80 Mbps for LSP R1-to-R5-low and 90 Mbps for LSP R1-to-R4. At this point, not enough bandwidth is available on the router, because each of the two SONET interfaces can carry only 155.52 Mbps. To see how RSVP handles this, first look at the status of the LSPs on the ingress router:

aviva@R7# show mpls lsp ingress Ingress LSP: 3 sessions To From State Rt ActivePath P LSPname 10.0.0.4 10.0.0.1 Up 0 * R1-to-R4 10.0.0.5 10.0.0.1 Dn 0 - R1-to-R5-low 10.0.0.6 10.0.0.1 Up 1 * R1-to-R6 Total 3 displayed, Up 2, Down 1

You see that while MPLS has created three LSPs, RSVP has established only two of them, R1-to-R4 and R1-to-R6. The LSP R1-to-R5-low is down. Check how RSVP has reserved bandwidth for the two LSPs:

aviva@R7# show rsvp interface RSVP interface: 2 active Active Subscr- Static Available Reserved Highwater Interface State resv iption BW BW BW mark so-0/0/0.0 Up 1 100% 155.52Mbps 65.52Mbps 90Mbps 90Mbps so-0/0/2.0 Up 1 100% 155.52Mbps 65.52Mbps 90Mbps 100Mbps

Use the show mpls lsp ingress extensive command to look at the LSPs on the ingress router to see what has happened. First, look at LSP R1-to-R6, which has the highest priority of the three LSPs:

aviva@R7# show mpls lsp ingress extensive Ingress LSP: 3 sessions … 10.0.0.6 From: 10.0.0.1, State: Up, ActiveRoute: 1, LSPname: R1-to-R6 ActivePath: (primary) LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 2 2 Bandwidth: 90Mbps SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 10.1.13.2 S 10.1.36.2 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 10.1.13.2 10.1.36.2 5 Oct 14 10:51:20 Selected as active path 4 Oct 14 10:51:20 Record Route: 10.1.13.2 10.1.36.2 3 Oct 14 10:51:20 Up 2 Oct 14 10:51:20 Originate Call 1 Oct 14 10:51:20 CSPF: computation result accepted Created: Fri Oct 14 10:51:20 2005 Total 3 displayed, Up 2, Down 1

RSVP has set up this LSP with the requested bandwidth of 90 Mbps, routing it through 10.1.13.2 (R3) on interface so-0/0/2. Next, look at the medium-priority LSP, R1-to-R4:

aviva@R7# show mpls lsp ingress extensive Ingress LSP: 3 sessions … 10.0.0.4 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R4 ActivePath: (primary) LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 4 4 Bandwidth: 90Mbps SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 10.1.12.2 S 10.1.24.2 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 10.1.12.2 10.1.24.2 15 Oct 14 10:51:20 Selected as active path 14 Oct 14 10:51:20 Record Route: 10.1.12.2 10.1.24.2 13 Oct 14 10:51:20 Up 12 Oct 14 10:51:20 Originate Call 11 Oct 14 10:51:20 Clear Call 10 Oct 14 10:51:20 CSPF: computation result accepted 9 Oct 14 10:51:20 Deselected as active 8 Oct 14 10:51:20 Requested bandwidth unavailable 7 Oct 14 10:51:20 Session preempted 6 Oct 14 10:51:20 Down 5 Oct 14 10:43:13 Selected as active path 4 Oct 14 10:43:13 Record Route: 10.1.13.2 10.1.34.24 3 Oct 14 10:43:13 Up 2 Oct 14 10:43:13 Originate Call 1 Oct 14 10:43:13 CSPF: computation result accepted Created: Fri Oct 14 10:43:12 2005 … Total 3 displayed, Up 2, Down 1

Line 4 of the LSP history shows the original route of the LSP, through 10.1.13.2 (out of interface so-0/0/2). When you configure the higher-priority R1-to-R6 LSP, RSVP preempted LSP R1-to-R4 because of insufficient bandwidth (shown in lines 7 and 8 of this history). However, the LSP was reestablished later (reflected in lines 13 and 14), when RSVP determined it could route the LSP through 10.1.12.2, out of interface so-0/0/0.

Finally, look at the lowest-priority LSP, R1-to-R5-low, which is now down:

aviva@R7# show mpls lsp ingress extensive Ingress LSP: 3 sessions … 10.0.0.5 From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: R1-to-R5-low ActivePath: (none) LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Primary State: Dn Priorities: 7 7 Bandwidth: 80Mbps SmartOptimizeTimer: 180 Will be enqueued for recomputation in 24 second(s). 16 Oct 14 10:52:18 CSPF failed: no route toward 10.0.0.5[3 times] 15 Oct 14 10:51:20 Clear Call 14 Oct 14 10:51:20 Deselected as active 13 Oct 14 10:51:20 Requested bandwidth unavailable 12 Oct 14 10:51:20 Session preempted 11 Oct 14 10:51:20 Down 10 Oct 14 10:39:39 Record Route: 10.1.12.2 10.1.26.2 10.1.56.1 9 Oct 14 10:39:39 Up 8 Oct 14 10:39:39 Originate Call Created: Fri Oct 14 10:35:55 2005 … Total 3 displayed, Up 2, Down 1

Lines 12 and 13 show that the LSP was preempted by a higher-priority one because not enough bandwidth was available for all the LSPs. Line 16 indicates that CSPF made three attempts to calculate a path for the LSP but was unable to compute one, which means that RSVP could not establish the LSP.