Blog

In control with RSVP

October 26, 2016 8:37 am

Controlling traffic flows is one of the benefits you get when using RSVP to signal LSPs. Using Junos OS, you are able to do this in quite a number of ways. This article aims to explain some of these options. After a brief CSPF recap, we’ll have a look at how we can exercise control over the path an LSP takes.

 

When an RSVP signaled LSP needs to be set up, the ingress LSR computes the path the LSP should take. This path is computed using information that is stored inside the Traffic Engineering Database, or TED. Information inside the TED is provided by an IGPs traffic engineering extensions. These traffic engineering extensions can be provided by OSPF or IS-IS.

The computation of the LSPs is done using the Constrained Shortest Path First algorithm, or CSPF. When an LSR computes an LSP using this CSPF, it takes into account what the constraints of an LSP are. The LSR first prunes the links that do not meet these constraints from the TED. After all relevant links are pruned, the shortest path is computed based on the remaining links still present in the TED.  

An LSR will compute LSPs one at a time, starting with the highest priority LSP (equal priority LSPs are computed in alphabetical order). For every LSP, CSPF will follow these steps:

  1. Prune the TED of links that do not have enough bandwidth available
  2. Prune the TED of links that lack the necessary colors
  3. Prune the TED of links that contain a color that should be excluded
  4. If the remaining paths are equal cost paths, choose the one whose last-hop address is the same as the LSPs destination
  5. If several paths remain, select the path with the fewest hops
  6. If multiple equal-cost paths remain, apply the CSPF load-balancing rule to the LSPs

As soon as the computations for an individual LSP are completed, the calculated path is written down in a list called ‘ERO’ (Explicit Route Object). The ERO is a list of all the links that the LSP should traverse. This list is then put into an RSVP path message and this RSVP path message is used to signal the LSP.

in-control-with-rsvp-0

 

The RSVP path message travels from the ingress LSR downstream to the egress LSR. Every router along the way inspects the ERO inside path message and removes its own IP address from that list. After this, the message is send further downstream to the router that is next on this list.

For an RSVP path message, the egress LSR is the last stop. The egress router will send an RSVP Resv message in return to the Path message. The path that the Resv message takes is the same as the Path message, only in reverse. The Resv message is used to reserve the resources for the LSP. Every router will use the Resv message to tell the upstream router what label to install into their LIB.

After an LSP is signaled, there are two easy ways to find out what the content of the ERO is. You can issue a ‘show mpls lsp name xx extensive’ and look for the ‘Computed ERO’. Additionally, you can issue a ‘show rsvp session name xx extensive’ and look for the ‘Explct route’ information.  

 

 

Default computed ERO behavior:

 

Let’s look at the default behavior of the most basic RSVP signaled LSP first. The most basic configuration for an LSP from R1 towards R8 could be the following: 

set protocols mpls label-switched-path to-r8-default to 172.30.5.8

This LSP will follow the lowest IGP cost to the destination. In our scenario, there is a link directly connecting R1 to R8. Since all links in our scenario have the same metric (10), this will be the shortest path.

in-control-with-rsvp-1

To verify how the LSP was set up, we issue the following command: 

lab@vmx1-sun# show mpls lsp ingress name to-r8-default detail    
Ingress LSP: 4 sessions

172.30.5.8
  From: 172.30.5.1, State: Up, ActiveRoute: 0, LSPname: to-r8-default
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 10)
 172.30.0.10 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.30.0.10
Total 1 displayed, Up 1, Down 0

The LSP was signaled across the path that had the lowest cumulative cost according to our IGP. 

 

 

Changing the ERO by changing the metric:

 

A quick and easy way to force the LSP to take another route would be by changing the metric of this link. When we choose to do so, we can alter the cost for the link in all IGP related calculations or we can change the cost of this link for RSVP-TE purposes only. Let’s change the link cost in ISIS for RSVP-TE purposes only like this: 

set protocols isis interface ge-0/0/4.118 level 1 te-metric 100 

 After committing this change, we force the router to signal the LSP again. We do this by clearing the LSP. After the LSP is cleared using the ‘clear mpls lsp’ command, it is automatically set up again using the new metrics:

in-control-with-rsvp-2

To verify that the computed ERO now differs from our previous output, we issue the same show command again:

lab@vmx1-sun# show mpls lsp ingress name to-r8-default detail   
Ingress LSP: 4 sessions

172.30.5.8
  From: 172.30.5.1, State: Up, ActiveRoute: 0, LSPname: to-r8-default
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
 172.30.0.6 S 172.30.0.30 S 172.30.0.38 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.30.0.6 172.30.0.30 172.30.0.38
Total 1 displayed, Up 1, Down 0

By altering the te-metric, we only alter the cost of the link for calculations done by the CSPF algorithm. We can verify this by looking at the information in the TED. We can look at the information stored in the TED by issuing the following command (the IP address is the router-id of the ingress LSR):

lab@vmx8-procyon# show ted database extensive 172.30.5.1    
TED database: 9 ISIS nodes 9 INET nodes
NodeID: vmx1-sun.00(172.30.5.1)
  Type: Rtr, Age: 1 secs, LinkIn: 3, LinkOut: 3
  Protocol: IS-IS(1)
   172.30.5.1
    To: vmx8-procyon.00(172.30.5.8), Local: 172.30.0.9, Remote: 172.30.0.10
      Local interface index: 332, Remote interface index: 325
      Color: 0 
      Metric: 100
      IGP metric: 10
      Static BW: 1000Mbps
      Reservable BW: 1000Mbps
      Available BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    

The metric that is listed first is the TE-metric. This metric was used for the CSPF calculations. The IGP metric, used to calculate the routes in the inet.0 table, remains unaltered. Both OSPF and IS-IS allow us to do this.

As an alternative to the ‘show ted database extensive’ command, we could have also used the ‘show isis database’ with the extensive option to verify the same thing (‘show ospf database opaque-area extensive’ when running OSPF).

 

 

Imposing bandwidth constraints:

 

The previously configured te-metric has been removed from the configuration. We now want to signal an RSVP LSP and influence the path by manipulating the available bandwidth.

By default, a Juniper router allows you to use 100% of the bandwidth of an RSVP enabled link. In our scenario, all of the links are 1Gbit: 

lab@vmx1-sun# 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.101Up         4   100%  1000Mbps    1000Mbps    0bps        900Mbps    
ge-0/0/4.114Up         2   100%  1000Mbps    1000Mbps    0bps        900Mbps    
ge-0/0/4.118Up         1   100%  1000Mbps    1000Mbps    0bps        900Mbps    

 Before imposing a bandwidth constraint on the LSP, we first reduce the available bandwidth on the link between R1 and R8: 

set protocols rsvp interface ge-0/0/4.118 subscription 89

The subscription configuration command reduces the available bandwidth from 1Gbit to 890Mbps. 

lab@vmx1-sun# show rsvp interface ge-0/0/4.118       
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
ge-0/0/4.118Up         0    89%  1000Mbps    890Mbps     0bps        900Mbps

To demonstrate that we can use the bandwidth to control the path the LSP will follow, let’s configure an LSP like this: 

set protocols mpls label-switched-path to-r8-bandwidth to 172.30.5.8
set protocols mpls label-switched-path to-r8-bandwidth bandwidth 900m

The LSP was configured to reserve 900m on every link ( an LSP does not require any bandwidth by default) . Because of the previous configuration, CSPF will only consider links that have 900m or more bandwidth available.  As a result of this configuration, the LSP will not be able to  traverse the direct link towards R8.  After the LSP is set up, we can observe the following:

lab@vmx1-sun# show mpls lsp name to-r8-bandwidth detail 
Ingress LSP: 4 sessions

172.30.5.8
  From: 172.30.5.1, State: Up, ActiveRoute: 0, LSPname: to-r8-bandwidth
  ActivePath:  (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
    Bandwidth: 900Mbps
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
 172.30.0.6 S 172.30.0.30 S 172.30.0.38 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.30.0.6 172.30.0.30 172.30.0.38
Total 1 displayed, Up 1, Down 0

Because of the imposed bandwidth constraint, the LSP was not signaled across the direct link. It took the following path instead:

in-control-with-rsvp-3

 

 

Using link colors.

 

Before we can manipulate the path of an LSP using link colors, we need to configure the colors (a.k.a. administrative groups) on every router: 

set protocols mpls admin-groups red 0
set protocols mpls admin-groups blue 2

 After this, we can start assigning colors to the interfaces. We assign the following colors to the links in our topology (no admin-groups are assigned to the black links):

in-control-with-rsvp-4

As an example, we’ll look at the configuration that is applied to R8, where we leave the ge-0/0/4.158 interface colorless: 

set protocols mpls interface ge-0/0/4.118 admin-group red
set protocols mpls interface ge-0/0/4.178 admin-group blue
set protocols mpls interface ge-0/0/4.158

To verify the result of this configuration, we can issue the following command: 

lab@vmx8-procyon# show mpls interface 
Interface        State       Administrative groups (x: extended)
ge-0/0/4.118     Up          red
ge-0/0/4.158     Up         
ge-0/0/4.178     Up          blue

Let’s create an LSP from R1 to R8 and use colors to influence the paths of that LSP. What we want is to end up with a path that crosses only blue links, and a second path that excludes all red links:

in-control-with-rsvp-5

set protocols mpls label-switched-path to-r8-color to 172.30.5.8
set protocols mpls label-switched-path to-r8-color primary no-red admin-group exclude red
set protocols mpls label-switched-path to-r8-color secondary blue standby
set protocols mpls label-switched-path to-r8-color secondary blue admin-group include-all blue

set protocols mpls path no-red
set protocols mpls path blue

This configuration will make R1 signal an LSP with two paths. For the primary path, the constraint is that no red links can be used. After pruning all red links in the network, this path will be computed based on the lowest IGP cost. Note that the path will only exclude red links. CSPF will not prune the blue links or the links without any color.

The secondary path, which will be signaled due to the standby keyword, will only consider blue links.

The configuration of the named paths, under the [ protocols mpls path], serves no real purpose in this example. I just wanted a path name that corresponds to the link color referenced in the LSP configuration.  The paths could have been configured with any other name.

Let’s have a look at the result of our configuration: 

lab@vmx1-sun# show mpls lsp ingress name to-r8-color detail 
Ingress LSP: 4 sessions

172.30.5.8
  From: 172.30.5.1, State: Up, ActiveRoute: 0, LSPname: to-r8-color
  ActivePath: no-red (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   no-red           State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
          Exclude: red
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
 172.30.0.2 S 172.30.0.18 S 172.30.0.46 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.30.0.2 172.30.0.18 172.30.0.46
  Standby   blue             State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
          Include All: blue
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 70)
 172.30.0.2 S 172.30.0.14 S 172.30.0.22 S 172.30.0.30 S 172.30.0.34 S 172.30.0.42 S 172.30.0.46 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.30.0.2 172.30.0.14 172.30.0.22 172.30.0.30 172.30.0.34 172.30.0.42 172.30.0.46
Total 1 displayed, Up 1, Down 0

 

 

Configuring the ERO.

 

Another way to manipulate the path of an RSVP-signaled LSP is through the manual configuration of the ERO. This is a very straightforward and deterministic way to configure an LSP. Let’s configure an LSP with a ‘strict’ primary path and a ‘loose’ secondary path.

A manually configured strict path is a list of IP addresses that specify the path on a hop-by-hop basis. Every hop must be connected to the previous hop.

A loose path is a list of IP addresses that the LSP needs to visit somewhere along the way. The routing-table is used to determine the path towards a loose hop.

In the following example, we configure the primary path go through the routers ‘r2-r3-r6-r7-r8’ in this exact order.  The secondary path is configured with a loose path that MUST visit R5 somewhere. For this path, the router will first calculate the lowest cost path to R5. After that, it will calculate the lowest cost path towards the egress LSP.

These requirements can be achieved by applying the following configuration:

set protocols mpls label-switched-path to-r8-ero to 172.30.5.8
set protocols mpls label-switched-path to-r8-ero primary r2-r3-r6-r7-r8
set protocols mpls label-switched-path to-r8-ero secondary via-r5 standby

set protocols mpls path r2-r3-r6-r7-r8 172.30.5.2 strict
set protocols mpls path r2-r3-r6-r7-r8 172.30.5.3 strict
set protocols mpls path r2-r3-r6-r7-r8 172.30.5.6 strict
set protocols mpls path r2-r3-r6-r7-r8 172.30.5.7 strict

set protocols mpls path via-r5 172.30.5.5 loose

The manual configuration of the ERO takes place in the path stanza. A tip to make things easier is to use the loopback IP addresses of the routers when configuring the path. This is what was done here as well. Keep in mind that even though the loopback IP addresses were configured, the IP addresses you’ll see listed in the ERO will correspond to the IP addresses that are encountered on the links in the network.

The LSPs that are signaled as a result of this configuration should be the following:

in-control-with-rsvp-6

 

To verify this, we issue the following command: 

lab@vmx1-sun# show mpls lsp name to-r8-ero detail    
Ingress LSP: 4 sessions

172.30.5.8
  From: 172.30.5.1, State: Up, ActiveRoute: 0, LSPname: to-r8-ero
  ActivePath: r2-r3-r6-r7-r8 (primary)
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   r2-r3-r6-r7-r8   State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 50)
 172.30.0.2 S 172.30.0.14 S 172.30.0.26 S 172.30.0.42 S 172.30.0.46 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.30.0.2 172.30.0.14 172.30.0.26 172.30.0.42 172.30.0.46
  Standby   via-r5           State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
 172.30.0.6 S 172.30.0.30 S 172.30.0.38 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.30.0.6 172.30.0.30 172.30.0.38
Total 1 displayed, Up 1, Down 0

In this example, we configured a strict and a loose path. Note that it is possible to mix strict and loose in the same path.

 

 

RSVP puts you in control and lets you determine how traffic should flow across your MPLS network. In this post, we covered some of the basic ways in which we can exercise control over RSVP signaled paths. We changed the link metric, configured a bandwidth constraint, colored links and manually configured the ERO.

Note that in addition to imposing constraints on an LSP, Junos OS has many additional options available to achieve an even higher degree of control. Junos OS allows you to map traffic onto specific RSVP signaled LSPs based on numerous characteristics. and there are lots of additional options that can be activated on a per-LSP basis. Link-protection, policing, altering the setup and hold-priority just to name a few.

RSVP puts you in control of the network. To test yourself and to see how well-versed you are configuring and troubleshooting RSVP signaled LSPs, consider using the iNET ZERO JNCIE-SP books and labs.

 

Said van de Klundert

Said van de Klundert

Netherlands based networking enthusiast and Juniper Networks ambassador. Has spent most of his career on the service-providers’ side of things. Known to lab up and write about whatever sparked his interest networking wise. Other than that, he is a father to his son, husband to his wife and he enjoys long dinners with friends.

More Posts - Website - Twitter

Categorised in:

Leave a Reply

Your email address will not be published. Required fields are marked *