To create a dynamic LSP (Label Switched Path) using RSVP (Resource Reservation Protocols) in JunOS, you define a name that uniquely identifies the LSP and, at minimum, you specify the address of the egress router.
EXAMPLE: set label-switched-path R1=>R4 to 4.4.4.4
There are several other options, including the bandwidth that you want the routers along the path to reserve for your LSP. In this article, we are going to focus on the bandwidth option. For more information on the other options, I recommend checking the following document:
After you configure your LSP and commit, CSPF (Constrained Shortest Path First) which is enabled by default, calculates a path that can satisfy the bandwidth requirement of your LSP. For this purpose, CSPF uses the Traffic Engineering information provided by either OSPF or ISIS and collected in the TED (Traffic Engineering Database). The result of CSPF calculation is a complete ERO (Explicit Route Object) that lists the nodes along the path the LSP should traverse. RSVP then signals the LSP along that path, and as result labels are assigned at each node, and bandwidth is reserved for the LSP.
Features such as Automatic Bandwidth Allocation, and LSP optimization, might require re-signaling of an LSP, to request a different amount of bandwidth (based on traffic statistics), or to reroute the LSP through a different path to optimize the overall use of bandwidth in the network.
Now, when rerouting the LSP if the current path is torn down, before the new one is created, traffic will be dropped. This can be avoided by using a MBB (Make Before Break) approach, which creates the new path before tearing down the old one.
When LSP is optimization is enabled, the MBB approach is implemented. The optimized path might failed to be set up, if you have topology like the one shown below, where the current path and the optimized path are sharing the link between R4 and R5.
The solution for this situation is to enable the adaptive option under the LSP configuration.
adaptive prevents double-counting bandwidth on links shared by the old and new paths, and configures RSVP to use Shared Explicit (SE) reservation style instead of the default Fixed Filter (FF) reservation style.
But, what is the difference between these two styles?
To answer this question, consider the topology shown in the diagram:
The BLUE dotted line represents the OLD path for an LSP configured between R1 and R8. The RED dotted line represents the NEW path after optimization. You can see that both the NEW and OLD paths go across the link between R4 and R5.
With the default Fixed Filter reservation style, if the LSP is configured to request a bandwidth reservation of 5Gbps, for example, R4 will reserve 10Gbps on the interface facing R5 during the transition from the OLD path to the NEW path. As a result, these extra 5Gbps will be unavailable for any other LSP trying to go across the same link. Furthermore, if the LSP is configured to request a reservation of 8Gbps, and the interface is a 10G Ethernet interface, the NEW path will not come up, as there is not sufficient bandwidth for both the OLD and NEW paths to be up at the same time, in an MBB fashion, .
With Share Explicit reservation style, which is enabled when you configure adaptive, the OLD and NEW paths shared the bandwidth reservation across the interface between R4 and R5. Thus, during the transition only 5Gbps will be reserved, instead of 10Gbps.
A similar situation might occur when you configure an LSP with a primary and a secondary path with the standby option enabled (secondary path is signaled and ready should the primary path fails). Using the same topology in the previous example, the LSP from R1 to R8 is configured with a primary path R1 => R2 => R4 => R5 => R6 => R8, and a secondary path R1 => R3 => R4 => R5 => R7 => R8.
Without the adaptive option, the interface between R4 and R5 will again be reserving 5Gbps for the primary and 5Gbps for the secondary. If the LSP is configured with a bandwidth requirement of 8Gbps, and the interface is 10Gbps, there would not be enough bandwidth to bring up both the primary and the secondary paths at the same time. Configuring the adaptive option causes the bandwidth reservation to be shared between the primary and the secondary paths.
EXAMPLE:
In this example, we have LSPs between vMX3 and vMX6 with a primary path across vMX1 and vMX5, and a secondary path across vMX1 and vMX2. There is only one link between vMX3 and vMX1, and both the primary and secondary path will traverse this link. We will see the effect of configuring the LSP with and without a bandwidth reservation and with and without the adaptive option.
vMX3 and vMX6 are configured as follows:
[edit protocols mpls] jcluser@vMX3# show | display set relative set label-switched-path vMX3=>vMX6 to 6.6.6.6 set label-switched-path vMX3=>vMX6 bandwidth 265k set label-switched-path vMX3=>vMX6 standby set label-switched-path vMX3=>vMX6 primary PATH1 set label-switched-path vMX3=>vMX6 secondary PATH2 set path PATH2 10.1.13.1 strict set path PATH2 10.1.12.2 strict set path PATH2 10.1.26.6 strict set path PATH1 10.1.13.1 strict set path PATH1 10.1.15.5 strict set path PATH1 10.1.56.6 strict set interface ge-0/0/0.0 set interface lo0.0 [edit protocols isis] jcluser@vMX3# show | display set relative set level 1 disable set interface ge-0/0/0.0 set interface lo0.0 [edit protocols rsvp] jcluser@vMX3# show | display set relative set interface lo0.0 set interface ge-0/0/0.0 [edit protocols mpls] jcluser@vMX6# show | display set relative set label-switched-path vMX6=>vMX3 to 3.3.3.3 set label-switched-path vMX6=>vMX3 standby set label-switched-path vMX6=>vMX3 primary PATH1 set label-switched-path vMX6=>vMX3 secondary PATH2 set path PATH1 10.1.56.5 strict set path PATH1 10.1.15.1 strict set path PATH1 10.1.13.3 set path PATH2 10.1.26.2 strict set path PATH2 10.1.12.1 strict set path PATH2 10.1.13.3 strict set interface lo0.0 set interface ge-0/0/2.0 set interface ge-0/0/0.0 [edit protocols rsvp] jcluser@vMX6# show | display set relative set interface lo0.0 set interface ge-0/0/2.0 set interface ge-0/0/0.0 [edit protocols isis] jcluser@vMX6# show | display set relative set level 1 disable set interface ge-0/0/0.0 set interface ge-0/0/2.0 set interface lo0.0
The rest of the routers are configured with MPLS, RSVP, and ISIS on all interfaces.
Initially, the LSPs are configured without any bandwidth reservation requirements. The standby option has been configured so that the secondary path is brought up immediately. For now, the adaptive option will NOT be included.
Let’s check the status of the LSP from vMX6 => vM3 with the show mpls lsp ingress extensive command:
jcluser@vMX6> show mpls lsp ingress extensive Ingress LSP: 1 sessions 3.3.3.3 From: 6.6.6.6, State: Up, ActiveRoute: 0, LSPname: vMX6=>vMX3 ActivePath: PATH1 (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 PATH1 State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.56.5 S 10.1.15.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.56.5(Label=299840) 10.1.15.1(Label=299920) 10.1.13.3(Label=3) 8 Dec 11 03:35:55.225 Self-ping ended successfully 7 Dec 11 03:35:54.818 Selected as active path 6 Dec 11 03:35:54.817 Up 5 Dec 11 03:35:54.817 Self-ping started 4 Dec 11 03:35:54.817 Self-ping enqueued 3 Dec 11 03:35:54.817 Record Route: 10.1.56.5(Label=299840) 10.1.15.1(Label=299920) 10.1.13.3(Label=3) 2 Dec 11 03:35:54.749 Originate Call 1 Dec 11 03:35:54.749 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 Standby PATH2 State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.26.2 S 10.1.12.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.26.2(Label=299856) 10.1.12.1(Label=299936) 10.1.13.3(Label=3) 7 Dec 11 03:35:56.227 Self-ping ended successfully 6 Dec 11 03:35:55.253 Up 5 Dec 11 03:35:55.253 Self-ping started 4 Dec 11 03:35:55.253 Self-ping enqueued 3 Dec 11 03:35:55.253 Record Route: 10.1.26.2(Label=299856) 10.1.12.1(Label=299936) 10.1.13.3(Label=3) 2 Dec 11 03:35:55.226 Originate Call 1 Dec 11 03:35:55.226 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 Created: Wed Dec 11 03:35:54 2019 Total 1 displayed, Up 1, Down 0
You can see that both the primary and secondary path are up, and that the primary path is ACTIVE, which means traffic for the LSP will be sent across the primary path.
Let’s not check the RSVP interface status on the transit router vMX1. Focus on the outbound interface towards vMX3 (ge-0/0/0.0):
jcluser@vMX1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/0.0 Up 2 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/1.0 Up 1 100% 1000Mbps 999.735Mbps 265kbps 265kbps
ge-0/0/2.0 Up 1 100% 1000Mbps 999.735Mbps 265kbps 265kbps
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
You can see that NO bandwidth has been reserved.
Let’s now add a bandwidth requirement for the vMX6=>vMX3 LSP:
[edit protocols mpls label-switched-path vMX6=>vMX3] jcluser@vMX6# set bandwidth 256k [edit protocols mpls label-switched-path vMX6=>vMX3] jcluser@vMX6# commit commit complete
We check the status of the LSP again, and we notice that both the primary and the secondary paths are UP, and both have a bandwidth value.
jcluser@vMX6# run show mpls lsp ingress extensive Ingress LSP: 1 sessions 3.3.3.3 From: 6.6.6.6, State: Up, ActiveRoute: 0, LSPname: vMX6=>vMX3 ActivePath: PATH1 (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 PATH1 State: Up Priorities: 7 0 Bandwidth: 256kbps SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.56.5 S 10.1.15.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.56.5(Label=299856) 10.1.15.1(Label=299968) 10.1.13.3(Label=3) 18 Dec 11 03:41:16.364 Selected as active path: due to 'primary' 17 Dec 11 03:40:15.651 Self-ping ended successfully 16 Dec 11 03:40:15.132 Up 15 Dec 11 03:40:15.132 Self-ping started 14 Dec 11 03:40:15.132 Self-ping enqueued 13 Dec 11 03:40:15.132 Record Route: 10.1.56.5(Label=299856) 10.1.15.1(Label=299968) 10.1.13.3(Label=3) 12 Dec 11 03:40:15.108 Deselected as active 11 Dec 11 03:40:15.080 Originate Call 10 Dec 11 03:40:15.080 Clear Call 9 Dec 11 03:40:15.080 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 8 Dec 11 03:35:55.225 Self-ping ended successfully 7 Dec 11 03:35:54.818 Selected as active path 6 Dec 11 03:35:54.817 Up 5 Dec 11 03:35:54.817 Self-ping started 4 Dec 11 03:35:54.817 Self-ping enqueued 3 Dec 11 03:35:54.817 Record Route: 10.1.56.5(Label=299840) 10.1.15.1(Label=299920) 10.1.13.3(Label=3) 2 Dec 11 03:35:54.749 Originate Call 1 Dec 11 03:35:54.749 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 Standby PATH2 State: Up Priorities: 7 0 Bandwidth: 256kbps SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.26.2 S 10.1.12.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.26.2(Label=299872) 10.1.12.1(Label=299952) 10.1.13.3(Label=3) 17 Dec 11 03:41:16.364 Deselected as active: due to 'primary' 16 Dec 11 03:40:15.651 Self-ping ended successfully 15 Dec 11 03:40:15.108 Selected as active path 14 Dec 11 03:40:15.106 Up 13 Dec 11 03:40:15.106 Self-ping started 12 Dec 11 03:40:15.106 Self-ping enqueued 11 Dec 11 03:40:15.106 Record Route: 10.1.26.2(Label=299872) 10.1.12.1(Label=299952) 10.1.13.3(Label=3) 10 Dec 11 03:40:15.081 Originate Call 9 Dec 11 03:40:15.080 Clear Call 8 Dec 11 03:40:15.080 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 7 Dec 11 03:35:56.227 Self-ping ended successfully 6 Dec 11 03:35:55.253 Up 5 Dec 11 03:35:55.253 Self-ping started 4 Dec 11 03:35:55.253 Self-ping enqueued 3 Dec 11 03:35:55.253 Record Route: 10.1.26.2(Label=299856) 10.1.12.1(Label=299936) 10.1.13.3(Label=3) 2 Dec 11 03:35:55.226 Originate Call 1 Dec 11 03:35:55.226 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 Created: Wed Dec 11 03:35:54 2019 Total 1 displayed, Up 1, Down 0
If we go back to vMX1, and check the RSVP interface status, we notice that now there are 512Kbps reserved on the ge-0/0/0.0 interface (double the bandwidth requirement of the LSP).
jcluser@vMX1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/0.0 Up 2 100% 1000Mbps 999.488Mbps 512kbps 512kbps
ge-0/0/1.0 Up 1 100% 1000Mbps 999.735Mbps 265kbps 265kbps
ge-0/0/2.0 Up 1 100% 1000Mbps 999.735Mbps 265kbps 265kbps
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
Now we change the reservation requirement to 800Kbps and again check the status of the LSP on vMX6, and the status on the RSVP interface on vMX1.
[edit protocols mpls label-switched-path vMX6=>vMX3] jcluser@vMX6# set bandwidth 800k [edit protocols mpls label-switched-path vMX6=>vMX3] jcluser@vMX6# commit commit complete
On vMX1 we notice that once again the bandwidth reserved for the LSP is double the bandwidth requirement configured under the LSP.
[edit protocols rsvp] jcluser@vMX1# 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/0.0 Up 2 100% 1000Mbps 998.4Mbps 1.6Mbps 1.6Mbps ge-0/0/1.0 Up 1 100% 1000Mbps 999.735Mbps 265kbps 265kbps ge-0/0/2.0 Up 1 100% 1000Mbps 999.735Mbps 265kbps 265kbps lo0.0 Up 0 100% 0bps 0bps 0bps 0bps jcluser@vMX6# run show mpls lsp ingress extensive Ingress LSP: 1 sessions 3.3.3.3 From: 6.6.6.6, State: Up, ActiveRoute: 0, LSPname: vMX6=>vMX3 ActivePath: PATH1 (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 PATH1 State: Up Priorities: 7 0 Bandwidth: 800kbps SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.56.5 S 10.1.15.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.56.5(Label=299872) 10.1.15.1(Label=300000) 10.1.13.3(Label=3) 26 Dec 11 03:47:36.636 Self-ping ended successfully 25 Dec 11 03:47:36.492 Up 24 Dec 11 03:47:36.491 Self-ping started 23 Dec 11 03:47:36.491 Self-ping enqueued 22 Dec 11 03:47:36.491 Record Route: 10.1.56.5(Label=299872) 10.1.15.1(Label=300000) 10.1.13.3(Label=3) 21 Dec 11 03:47:36.464 Originate Call 20 Dec 11 03:47:36.463 Clear Call 19 Dec 11 03:47:36.463 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 18 Dec 11 03:41:16.364 Selected as active path: due to 'primary' 17 Dec 11 03:40:15.651 Self-ping ended successfully 16 Dec 11 03:40:15.132 Up 15 Dec 11 03:40:15.132 Self-ping started 14 Dec 11 03:40:15.132 Self-ping enqueued 13 Dec 11 03:40:15.132 Record Route: 10.1.56.5(Label=299856) 10.1.15.1(Label=299968) 10.1.13.3(Label=3) 12 Dec 11 03:40:15.108 Deselected as active 11 Dec 11 03:40:15.080 Originate Call 10 Dec 11 03:40:15.080 Clear Call 9 Dec 11 03:40:15.080 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 8 Dec 11 03:35:55.225 Self-ping ended successfully 7 Dec 11 03:35:54.818 Selected as active path 6 Dec 11 03:35:54.817 Up 5 Dec 11 03:35:54.817 Self-ping started 4 Dec 11 03:35:54.817 Self-ping enqueued 3 Dec 11 03:35:54.817 Record Route: 10.1.56.5(Label=299840) 10.1.15.1(Label=299920) 10.1.13.3(Label=3) 2 Dec 11 03:35:54.749 Originate Call 1 Dec 11 03:35:54.749 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 Standby PATH2 State: Up Priorities: 7 0 Bandwidth: 800kbps SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.26.2 S 10.1.12.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.26.2(Label=299888) 10.1.12.1(Label=299984) 10.1.13.3(Label=3) 25 Dec 11 03:47:36.636 Self-ping ended successfully 24 Dec 11 03:47:36.492 Up 23 Dec 11 03:47:36.492 Self-ping started 22 Dec 11 03:47:36.492 Self-ping enqueued 21 Dec 11 03:47:36.492 Record Route: 10.1.26.2(Label=299888) 10.1.12.1(Label=299984) 10.1.13.3(Label=3) 20 Dec 11 03:47:36.464 Originate Call 19 Dec 11 03:47:36.464 Clear Call 18 Dec 11 03:47:36.464 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 17 Dec 11 03:41:16.364 Deselected as active: due to 'primary' 16 Dec 11 03:40:15.651 Self-ping ended successfully 15 Dec 11 03:40:15.108 Selected as active path 14 Dec 11 03:40:15.106 Up 13 Dec 11 03:40:15.106 Self-ping started 12 Dec 11 03:40:15.106 Self-ping enqueued 11 Dec 11 03:40:15.106 Record Route: 10.1.26.2(Label=299872) 10.1.12.1(Label=299952) 10.1.13.3(Label=3) 10 Dec 11 03:40:15.081 Originate Call 9 Dec 11 03:40:15.080 Clear Call 8 Dec 11 03:40:15.080 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 7 Dec 11 03:35:56.227 Self-ping ended successfully 6 Dec 11 03:35:55.253 Up 5 Dec 11 03:35:55.253 Self-ping started 4 Dec 11 03:35:55.253 Self-ping enqueued 3 Dec 11 03:35:55.253 Record Route: 10.1.26.2(Label=299856) 10.1.12.1(Label=299936) 10.1.13.3(Label=3) 2 Dec 11 03:35:55.226 Originate Call 1 Dec 11 03:35:55.226 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 Created: Wed Dec 11 03:35:54 2019 Total 1 displayed, Up 1, Down 0
So far so good!!!! But what if we change the bandwidth requirement to 800Mbps?
[edit protocols mpls label-switched-path vMX6=>vMX3] jcluser@vMX6# set bandwidth 800m [edit protocols mpls label-switched-path vMX6=>vMX3] jcluser@vMX6# commit commit complete
We check the LSP status on vMX6, and the RSVP interface on vMX1, once again:
This time we see that only 800 Mbps had been reserved. The interface is only 1Gbps, so the router cannot reserve the requested amount times 2.
[edit protocols rsvp] jcluser@vMX1# 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/0.0 Up 1 100% 1000Mbps 200Mbps 800Mbps 800Mbps ge-0/0/1.0 Up 1 100% 1000Mbps 999.735Mbps 265kbps 265kbps ge-0/0/2.0 Up 1 100% 1000Mbps 999.735Mbps 265kbps 265kbps lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
When we check the LSP status we notice that ONLY the primary path is UP. The secondary path is down, and the following message is displayed: “CSPF failed: no route toward 10.1.26.2 [5 times]”. What this message means is that CSPF could not find a route that satisfies the bandwidth requirement for the secondary path.
jcluser@vMX6# run show mpls lsp ingress extensive Ingress LSP: 1 sessions 3.3.3.3 From: 6.6.6.6, State: Up, ActiveRoute: 0, LSPname: vMX6=>vMX3 ActivePath: PATH1 (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 PATH1 State: Up Priorities: 7 0 Bandwidth: 800Mbps SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.56.5 S 10.1.15.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.56.5(Label=299888) 10.1.15.1(Label=300016) 10.1.13.3(Label=3) 34 Dec 11 03:51:54.381 Self-ping ended successfully 33 Dec 11 03:51:53.932 Up 32 Dec 11 03:51:53.932 Self-ping started 31 Dec 11 03:51:53.932 Self-ping enqueued 30 Dec 11 03:51:53.932 Record Route: 10.1.56.5(Label=299888) 10.1.15.1(Label=300016) 10.1.13.3(Label=3) 29 Dec 11 03:51:53.886 Originate Call 28 Dec 11 03:51:53.885 Clear Call 27 Dec 11 03:51:53.885 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 26 Dec 11 03:47:36.636 Self-ping ended successfully 25 Dec 11 03:47:36.492 Up 24 Dec 11 03:47:36.491 Self-ping started 23 Dec 11 03:47:36.491 Self-ping enqueued 22 Dec 11 03:47:36.491 Record Route: 10.1.56.5(Label=299872) 10.1.15.1(Label=300000) 10.1.13.3(Label=3) 21 Dec 11 03:47:36.464 Originate Call 20 Dec 11 03:47:36.463 Clear Call 19 Dec 11 03:47:36.463 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 18 Dec 11 03:41:16.364 Selected as active path: due to 'primary' 17 Dec 11 03:40:15.651 Self-ping ended successfully 16 Dec 11 03:40:15.132 Up 15 Dec 11 03:40:15.132 Self-ping started 14 Dec 11 03:40:15.132 Self-ping enqueued 13 Dec 11 03:40:15.132 Record Route: 10.1.56.5(Label=299856) 10.1.15.1(Label=299968) 10.1.13.3(Label=3) 12 Dec 11 03:40:15.108 Deselected as active 11 Dec 11 03:40:15.080 Originate Call 10 Dec 11 03:40:15.080 Clear Call 9 Dec 11 03:40:15.080 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 8 Dec 11 03:35:55.225 Self-ping ended successfully 7 Dec 11 03:35:54.818 Selected as active path 6 Dec 11 03:35:54.817 Up 5 Dec 11 03:35:54.817 Self-ping started 4 Dec 11 03:35:54.817 Self-ping enqueued 3 Dec 11 03:35:54.817 Record Route: 10.1.56.5(Label=299840) 10.1.15.1(Label=299920) 10.1.13.3(Label=3) 2 Dec 11 03:35:54.749 Originate Call 1 Dec 11 03:35:54.749 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 Standby PATH2 State: Dn Priorities: 7 0 Bandwidth: 800Mbps SmartOptimizeTimer: 180 Flap Count: 1 MBB Count: 0 Will be enqueued for recomputation in 0 second(s). 27 Dec 11 03:59:49.690 CSPF failed: no route toward 10.1.26.2[5 times] 27 Dec 11 03:59:49.690 CSPF failed: no route toward 10.1.26.2[5 times] 26 Dec 11 03:51:53.886 Clear Call: CSPF computation failed 25 Dec 11 03:47:36.636 Self-ping ended successfully 24 Dec 11 03:47:36.492 Up 23 Dec 11 03:47:36.492 Self-ping started 22 Dec 11 03:47:36.492 Self-ping enqueued 21 Dec 11 03:47:36.492 Record Route: 10.1.26.2(Label=299888) 10.1.12.1(Label=299984) 10.1.13.3(Label=3) 20 Dec 11 03:47:36.464 Originate Call 19 Dec 11 03:47:36.464 Clear Call 18 Dec 11 03:47:36.464 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 17 Dec 11 03:41:16.364 Deselected as active: due to 'primary' 16 Dec 11 03:40:15.651 Self-ping ended successfully 15 Dec 11 03:40:15.108 Selected as active path 14 Dec 11 03:40:15.106 Up 13 Dec 11 03:40:15.106 Self-ping started 12 Dec 11 03:40:15.106 Self-ping enqueued 11 Dec 11 03:40:15.106 Record Route: 10.1.26.2(Label=299872) 10.1.12.1(Label=299952) 10.1.13.3(Label=3) 10 Dec 11 03:40:15.081 Originate Call 9 Dec 11 03:40:15.080 Clear Call 8 Dec 11 03:40:15.080 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 7 Dec 11 03:35:56.227 Self-ping ended successfully 6 Dec 11 03:35:55.253 Up 5 Dec 11 03:35:55.253 Self-ping started 4 Dec 11 03:35:55.253 Self-ping enqueued 3 Dec 11 03:35:55.253 Record Route: 10.1.26.2(Label=299856) 10.1.12.1(Label=299936) 10.1.13.3(Label=3) 2 Dec 11 03:35:55.226 Originate Call 1 Dec 11 03:35:55.226 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 Created: Wed Dec 11 03:35:54 2019 Total 1 displayed, Up 1, Down 0
We can also check the status of the RSVP session on vMX1 with the show rsvp session command, and here we can see that the bandwidth reservation style is Fixed Filter. As explained before, with Fixed Filter, the primary and secondary are both requesting their own bandwidth reservation.
jcluser@vMX1# run show rsvp session name vMX6=>vMX3 extensive transit Transit RSVP: 3 sessions 3.3.3.3 From: 6.6.6.6, LSPstate: Up, ActiveRoute: 0 LSPname: vMX6=>vMX3, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 FF, Label in: 300016, Label out: 3 Time left: 6090, Since: Wed Dec 11 03:51:52 2019 Tspec: rate 800Mbps size 800Mbps peak Infbps m 20 M 1500 Port number: sender 7 receiver 52176 protocol 0 Enhanced FRR: Enabled (Upstream) Enhanced FRR: Enabled (Downstream) PATH rcvfrom: 10.1.15.5 (ge-0/0/1.0) 1 pkts incoming message handle: P-58/1, Message ID: 44, Epoch: 992372 Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.13.3 (ge-0/0/0.0) 1 pkts outgoing message state: refreshing, Message ID: 77, Epoch: 992366 RESV rcvfrom: 10.1.13.3 (ge-0/0/0.0) 1 pkts, Entropy label: Yes incoming message handle: R-59/1, Message ID: 37, Epoch: 998313 RESV outgoing message state: refreshing, Message ID: 78, Epoch: 992366 Explct route: 10.1.13.3 Record route: 10.1.56.6 10.1.15.5 <self> 10.1.13.3 Total 1 displayed, Up 1, Down 0
So here we are, with Fixed Filter reservation style, our LSPs’s secondary path is NOT coming up. How do we fix it? Yes, you know the answer already! Change the reservation style to Shared Explicit.
We go back to the LSP and add the adaptive option:
[edit protocols mpls label-switched-path vMX6=>vMX3] jcluser@vMX6# set adaptive [edit protocols mpls label-switched-path vMX6=>vMX3] jcluser@vMX6# commit commit complete
And when we check the status of the LSP we find that now the primary AND the secondary are up.
jcluser@vMX6# run show mpls lsp ingress extensive Ingress LSP: 1 sessions 3.3.3.3 From: 6.6.6.6, State: Up, ActiveRoute: 0, LSPname: vMX6=>vMX3 ActivePath: PATH1 (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 PATH1 State: Up Priorities: 7 0 Bandwidth: 800Mbps SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.56.5 S 10.1.15.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.56.5(Label=299904) 10.1.15.1(Label=300032) 10.1.13.3(Label=3) 9 Dec 11 04:06:20.466 Self-ping ended successfully 8 Dec 11 04:06:20.446 Selected as active path 7 Dec 11 04:06:20.445 Up 6 Dec 11 04:06:20.445 Self-ping started 5 Dec 11 04:06:20.445 Self-ping enqueued 4 Dec 11 04:06:20.444 Record Route: 10.1.56.5(Label=299904) 10.1.15.1(Label=300032) 10.1.13.3(Label=3) 3 Dec 11 04:06:20.214 Originate Call 2 Dec 11 04:06:20.214 CSPF: computation result accepted 10.1.56.5 10.1.15.1 10.1.13.3 1 Dec 11 04:05:50.924 CSPF failed: no route toward 10.1.56.5 Standby PATH2 State: Up Priorities: 7 0 Bandwidth: 800Mbps SmartOptimizeTimer: 180 Flap Count: 0 MBB Count: 0 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.26.2 S 10.1.12.1 S 10.1.13.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.1.26.2(Label=299904) 10.1.12.1(Label=300048) 10.1.13.3(Label=3) 8 Dec 11 04:06:50.510 Self-ping ended successfully 7 Dec 11 04:06:50.035 Up 6 Dec 11 04:06:50.035 Self-ping started 5 Dec 11 04:06:50.035 Self-ping enqueued 4 Dec 11 04:06:50.035 Record Route: 10.1.26.2(Label=299904) 10.1.12.1(Label=300048) 10.1.13.3(Label=3) 3 Dec 11 04:06:50.006 Originate Call 2 Dec 11 04:06:50.006 CSPF: computation result accepted 10.1.26.2 10.1.12.1 10.1.13.3 1 Dec 11 04:06:20.215 CSPF failed: no route toward 10.1.26.2 Created: Wed Dec 11 04:05:50 2019 Total 1 displayed, Up 1, Down 0
Going back to vMX1 we check the RSVP session and validate the reservation style is indeed Shared Explicit.
jcluser@vMX1# run show rsvp session name vMX6=>vMX3 extensive transit Transit RSVP: 4 sessions 3.3.3.3 From: 6.6.6.6, LSPstate: Up, ActiveRoute: 0 LSPname: vMX6=>vMX3, LSPpath: Secondary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 SE, Label in: 300048, Label out: 3 Time left: 6167, Since: Wed Dec 11 04:06:48 2019 Tspec: rate 800Mbps size 800Mbps peak Infbps m 20 M 1500 Port number: sender 2 receiver 52178 protocol 0 Enhanced FRR: Enabled (Upstream) Enhanced FRR: Enabled (Downstream) PATH rcvfrom: 10.1.12.2 (ge-0/0/2.0) 1 pkts incoming message handle: P-63/1, Message ID: 49, Epoch: 992372 Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.13.3 (ge-0/0/0.0) 1 pkts outgoing message state: refreshing, Message ID: 82, Epoch: 992366 RESV rcvfrom: 10.1.13.3 (ge-0/0/0.0) 1 pkts, Entropy label: Yes incoming message handle: R-64/1, Message ID: 39, Epoch: 998313 RESV outgoing message state: refreshing, Message ID: 83, Epoch: 992366 Explct route: 10.1.13.3 Record route: 10.1.26.6 10.1.12.2 <self> 10.1.13.3 3.3.3.3 From: 6.6.6.6, LSPstate: Up, ActiveRoute: 0 LSPname: vMX6=>vMX3, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 SE, Label in: 300032, Label out: 3 Time left: 6138, Since: Wed Dec 11 04:06:19 2019 Tspec: rate 800Mbps size 800Mbps peak Infbps m 20 M 1500 Port number: sender 1 receiver 52178 protocol 0 Enhanced FRR: Enabled (Upstream) Enhanced FRR: Enabled (Downstream) PATH rcvfrom: 10.1.15.5 (ge-0/0/1.0) 1 pkts incoming message handle: P-61/1, Message ID: 47, Epoch: 992372 Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.13.3 (ge-0/0/0.0) 1 pkts outgoing message state: refreshing, Message ID: 80, Epoch: 992366 RESV rcvfrom: 10.1.13.3 (ge-0/0/0.0) 1 pkts, Entropy label: Yes incoming message handle: R-62/1, Message ID: 38, Epoch: 998313 RESV outgoing message state: refreshing, Message ID: 81, Epoch: 992366 Explct route: 10.1.13.3 Record route: 10.1.56.6 10.1.15.5 <self> 10.1.13.3 Total 2 displayed, Up 2, Down 0
In summary:
When you configure an LSP in Junos, the default RSVP reservation style is Fixed Filter, which means that when creating a new path for the LSP after optimization, or when creating the primary and secondary path for an LSP, the requested bandwidth reservation will be doubled, potentially causing the second path to fail.
To avoid the double counting, the ADAPTIVE option can be added.
Recent Comments