Configuring RSVP-TE Tunnels

Enable the dedicated RSVP-TE Tunnel configuration mode by entering the router traffic-engineering command to enter the router traffic-engineering mode and then the rsvp command to enter the RSVP sub-mode. 
switch# config 
switch(config)# router traffic-engineering 
switch(config-te)# rsvp 
switch(config-te-rsvp)#
In this submode, the configuration has several components for P2P tunnels:
  • Global configuration: All settings apply to all configured tunnels.
  • Path specifications: Describes a set of constraints for paths. These can be referenced from tunnel specifications to describe which path each tunnel can take.
  • Tunnel specifications: Per-tunnel configuration.
  • Tunnel profiles: A common set of tunnel configurations that can be associated with tunnel specifications.

Local Interface

A local interface is used to derive the source IP address for RSVP-TE tunnels. If this is not configured, then a loopback interface is picked automatically. Note that the configured local interface must have an IP address.
switch(config-te-rsvp)# local-interface Loopback0

Path Specifications

Path specifications can be explicit or dynamic. Dynamic uses a Constrained Shortest Path First (CSPF) search procedure to find a path in the network topology known to the headend. A path specification of a certain name can only be either explicit or dynamic.

Explicit Path Specifications

In an explicit path specification, the operator provides all hops in the path. The given path is used directly as the Explicit Route Object (ERO) in RSVP Path messages. All hops are implicitly strict hops. Explicit loose hops are not supported. The hop list must therefore contain the incoming interface IP for each node.

The submode to configure explicit paths is entered by specifying the name and the explicit keyword. 
switch(config-te-rsvp)# path MyPath explicit 
switch(config-te-rsvp-path-expl-MyPath)#
Each hop is specified explicitly in order. 
switch(config-te-rsvp-path-expl-MyPath)# hop 10.0.12.2 
switch(config-te-rsvp-path-expl-MyPath)# hop 10.0.34.4
The keywords before and after allow the insertion of new hops in an existing path by indicating the relative position. This unique internal ordering will be displayed when using the show running-config command. 
switch(config-te-rsvp-path-expl-MyPath)# hop 10.0.23.3 before 10.0.34.4 
switch(config-te-rsvp-path-expl-MyPath)# hop 10.0.45.5 after 10.0.34.4
A hop can be removed using the keyword no hop. 
switch(config-te-rsvp-path-expl-MyPath)# no hop 10.0.12.2

The submode has abort/commit semantics. That is, changes in the submode only take effect when the submode is exited normally. Changes can be discarded when exiting the submode by running the abort command. The currently active configuration can be retrieved with show active. The pending configuration that would become active upon exiting the submode can be retrieved with show pending. The difference between these two can be retrieved with show diff.

Dynamic Path Specification

A dynamic path specification provides the constraints that a CSPF procedure uses to find a path in the network topology. Effectively, the path specification serves as a template that is instantiated along with other tunnel constraints. The CSPF result is a list of strict hops that form the Explicit Route Object (ERO).

The submode to configure dynamic paths is entered by specifying the name and the dynamic keyword. The submode has the same commit/abort semantics and show commands as the submode for explicit paths. 
switch(config-te-rsvp)# path MyPath dynamic 
switch(config-te-rsvp-path-dyn-MyPath)#

Exclude hop constraints specify that CSPF must not choose the specified address on the path. Each exclude hop expresses that neither end of a link in the path may have the specified address. Exclude hops can be configured with the exclude keyword.

Note:Other interfaces on the same node may be used. 
switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.56.6 exclude
Include hop constraints specify hops that have to be included in the computed path in a certain order. By default, a hop is strict, meaning that it has to appear directly after the previously specified hop. Strict include hops can be configured just with the hop keyword. 
switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.56.6
Alternatively, an include hop can be loose, allowing other hops to be filled by the CSPF procedure to reach it from the previously defined hop (or the ingress if the loose hop is the first include hop). The destination of a tunnel is always treated as a loose hop at the end of a path. Loose include hops can be configured with the loose keyword. 
switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.56.6 loose

The keywords include hops will include the specified hops in the computed path in the order they are configured. The keywords before and after work as in the submode for explicit paths for ordering include hops relative to already configured hops.

Each include hop indicates a node rather than a specific interface that the path must go through; a computed path can pass through a different interface on the same node as an include hop and still satisfy the constraint. The specified address can be an interface address, a TE router ID, or a loopback address. If there are multiple routers configured with the same loopback address, then no path will be returned by CSPF.

Administrative group constraints can be specified to restrict CSPF paths to links that match a set of admin groups. Their IDs are globally significant, and the specification contains lists and ranges of admin groups to include or exclude. Every chosen link for a dynamic path must be in all of the admin groups specified in the include all range, must be in one of the admin groups specified in the include any range, and must not be in any of those in the exclude range. The admin group range starts at 0 and ends at 511. Administrative group constraints can be configured with the administrative-group keyword. 
switch(config-te-rsvp-path-dyn-MyPath)# administrative-group include all 1  include any 2-4 exclude 7,9

Administrative groups can alternatively be specified by name as aliases mapped to numerical values. The mapping can be configured under the global TE mode. Please refer to IS-IS Traffic-Engineering TOI for details.

These names can be used directly to configure administrative group constraints, in addition to the numerical format. The list of administrative groups should be comma-separated, with no spaces. 
switch(config-te-rsvp-path-dyn-MyPath)# administrative-group include all blue  include any 2-4,red exclude green,7

The list of administrative groups should be provided as a comma-separated input without spaces.

Tunnel Specifications

To configure a tunnel, enter the tunnel specification submode with the tunnel keyword followed by the name of the tunnel.
switch(config-te-rsvp)# tunnel MyTunnel 
switch(config-te-rsvp-tunnel-MyTunnel)#

Similar to the path specification submodes, the tunnel specification submode has abort/commit semantics. Changes in the submode only take effect when the submode is exited normally. To leave the submode without committing changes, the abort keyword can be used. The show active, show pending, and show diff commands function the same way as they do for the path submodes.

Basic Tunnel Configuration

Each tunnel must have a destination IP address. The specified address can be an interface address, a TE router ID, or a loopback address. If there are multiple routers configured with the same loopback address, then no path will be returned by CSPF. 
switch(config-te-rsvp-tunnel-MyTunnel)# destination ip 10.2.2.2
By default, a tunnel is not enabled, so it needs to be enabled explicitly.
switch(config-te-rsvp-tunnel-myTunnel)# no shutdown

Adding Path Specifications

A tunnel must specify the path along which its LSPs should be established. For this, a path specification is referenced by name, which configures the primary LSP. 
switch(config-te-rsvp-tunnel-myTunnel)# path MyPath

A secondary LSP may be specified as a fallback if the primary LSP is unavailable. The secondary LSP provides an alternative way to reach the tunnel endpoint. The secondary LSP is either established on-demand (cold standby) once the primary is unavailable or pre-signaled (hot standby). Configuring a secondary path is optional.

Note: Only one secondary path can be configured per tunnel. 
switch(config-te-rsvp-tunnel-myTunnel)# path MyOtherPath secondary pre-signaled

Operationally, a primary LSP is preferred if it is up and running without error. If the primary LSP is down or encounters an error, the tunnel will switch to the secondary LSP. If the secondary LSP is in use and the primary LSP comes up, the tunnel switches to the primary LSP after a 10-second stabilization period.

Bandwidth Specification

A tunnel can be used to reserve bandwidth along the path with an explicit configuration. Available units are bps, kbps, mbps, gbps, and tbps. By default, no bandwidth reservation is signaled. 
switch(config-te-rsvp-tunnel-myTunnel)# bandwidth 10 mbps
An alternative to explicit bandwidth configuration is to use the auto command, which specifies the minimum and maximum bandwidth for the tunnel and adjusts the bandwidth with an adjustment period based on observed traffic over the tunnel. The adjustment period is an optional parameter measured in seconds. The default adjustment period is 0, a special value indicating that the algorithm decides when to adjust the bandwidth based on statistical measurements (the actual adjustment cannot occur more frequently than the sampling interval, which occurs every 30 seconds). 
switch(config-te-rsvp-tunnel-myTunnel)# bandwidth auto min 1 mbps max 5 mbps adjustment-period 60
The sensitivity of the auto bandwidth algorithm can also be configured. Sensitivity is either an integer from 1 to 10 or a dynamic keyword. The number reflects how sensitive automatic bandwidth adjustment is to changes in bandwidth. 1 means “least sensitive”, that is, the algorithm will be most reluctant to adjust bandwidth when the flow rate changes - only when the flow rate change lasts long, the algorithm will initiate resignalling with a new bandwidth. 10 means “most sensitive” - the algorithm is more eager to react to flow rate changes and re-signal bandwidth reservation. 
switch(config-te-rsvp-tunnel-myTunnel)# bandwidth auto min 1 kbps max 1 gbps sensitivity 9

Tunnel priorities

Setup and hold priorities from 0 to 7 can be configured for the tunnel, with 0 meaning most preferred and 7 least preferred.

Note: The hold priority should have a lower value (i.e., more preferred) than the setup priority to avoid cycles in which an LSP is continuously established and immediately preempted. 
switch(config-te-rsvp-tunnel-myTunnel)# priority setup 5 hold 3

Color Attributes

A color attribute can be assigned to publish the tunnel to the system-colored-tunnel-rib instead of the system-tunnel-rib. This helps steer traffic into the tunnel, just as one can with SR-TE tunnels.

Note: This color attribute is strictly a local attribute. 
switch(config-te-rsvp-tunnel-myTunnel)# color 60

Tunnel Participation in IGP Shortcuts and LDP over RSVP

The igp shortcut command can be used to specify whether an RSVP tunnel should participate in IGP shortcuts.
switch(config-te-rsvp-tunnel-myTunnel)# igp shortcut
Note: Refer to the IGP Shortcut in ISIS TOI for more information.
LDP traffic can be tunneled through RSVP-TE tunnels by enabling the tunneling ldp command. 
switch(config-te-rsvp-tunnel-myTunnel)# tunneling ldp
UCMP with LDP over RSVP can be configured using the tunneling ldp ucmp command. 
switch(config-te-rsvp-tunnel-myTunnel)# tunneling ldp ucmp
Note: Refer to the LDP over RSVP TOI for more information.

Tunnel Optimization

Tunnels using a dynamic path are initially established with the optimal path provided by CSPF that fulfills the constraints. By default, such a tunnel will not re-optimize if network conditions change and a more optimal path becomes available.

Periodic tunnel optimization can be configured globally or individually for a specific tunnel. For global periodic tunnel optimization, the optimization interval is configured in config-te-rsvp mode. 
switch(config-te-rsvp)# optimization interval 3600 seconds
The optimization interval can also be individually configured on a tunnel by entering the command in tunnel sub-mode. The optimization interval configured in the tunnel sub-mode overrides the optimization interval configured globally. 
switch(config-te-rsvp)# tunnel myTunnel 
switch(config-te-rsvp-tunnel-myTunnel)# optimization interval 3600 seconds
Optimization can also be disabled on a specific tunnel. If optimization needs to be enabled for all the tunnels with a common interval, but disabled on a specific tunnel, the disabled keyword can be used. 
switch(config-te-rsvp)# tunnel myTunnel 
switch(config-te-rsvp-tunnel-myTunnel)# optimization disabled
Tunnels can be optimized on demand without adding any configuration. This on-demand optimization can either be performed on a specific tunnel or on all the tunnels. This is done by executing the following commands. 
switch# refresh rsvp tunnel optimization all 
switch# refresh rsvp tunnel optimization name myTunnel
On-demand optimization can also be used to move a tunnel between different equal-cost options. A set of links can be passed to CSPF to avoid while finding another equal-cost path. This operation works only on equal-cost paths and will not switch the tunnel to a less optimal path. If there’s a massive imbalance of tunnels, rebalancing them would require firing this command multiple times. Note that this command does nothing if least-fill is enabled. 
switch# refresh rsvp tunnel optimization name myTunnel avoid ecmp hop 5.5.5.5

Tunnel Endpoint Aliases

Configuring alias IPv4 and IPv6 endpoints allows these additional next hops to be resolved using the existing tunnel. Up to 15 alias endpoints can be configured per tunnel. 
switch(config-te-rsvp-tunnel-myTunnel)# alias endpoint 5.5.5.5 
switch(config-te-rsvp-tunnel-myTunnel)# alias endpoint 2001::10

Split-Tunnel

RSVP split-tunnel allows splitting a tunnel's bandwidth across multiple sessions. With this feature enabled, RSVP will automatically create multiple tunnels (referred to as sub-tunnels) with smaller bandwidth reservations for a single tunnel. This is mainly useful if there is currently no single path in the network that can satisfy the total bandwidth requirement of the tunnel, but there are multiple paths with smaller bandwidths that, together, can satisfy the total bandwidth requirement by load balancing traffic across these multiple paths.

Quantum Split-Tunnel

Quantum split-tunnel allows a user to configure a constant bandwidth (referred to as quantum) for which each sub-tunnel will be created, until the overall bandwidth requirement is reached or the sub-tunnel limit is hit. In the following example, the quantum is set to 10 kbps, meaning each sub-tunnel will have a bandwidth requirement of 10 kbps. 
switch(config-te-rsvp-tunnel-myTunnel)# split-tunnel quantum 10 kbps

Adaptive Split-Tunnel

The RSVP adaptive split-tunnel feature allows each sub-tunnel to grow and shrink based on measured bandwidth. Configuring the adaptive split-tunnel feature involves setting min/max values in the split-tunnel configuration. Each sub-tunnel grows and shrinks between these values, as opposed to being of a fixed size in the quantum split tunnel case.

Note: Adaptive split-tunnels cannot be configured with explicit fixed bandwidth configuration, and instead, auto-bandwidth must be used. 
switch(config-te-rsvp-tunnel-myTunnel)# split-tunnel min 1 gbps max 50 gbps
If bandwidth has reduced enough that it could be satisfied by fewer sub-tunnels than what currently exists, sub-tunnels are not deleted immediately. There is a delay after which these extra sub-tunnels get removed. The reduction-delay command is configurable and defaults to 1 hour. 
switch(config-te-rsvp-tunnel-myTunnel)# split-tunnel min 1 gbps max 50 gbps reduction-delay 30 minutes 

switch(config-te-rsvp-tunnel-myTunnel)# split-tunnel min 1 gbps max 50 gbps reduction-delay 15 seconds 

switch(config-te-rsvp-tunnel-myTunnel)# split-tunnel min 1 gbps max 50 gbps reduction-delay 12 hours

Number of Sub-Tunnels

Users can optionally configure the minimum, maximum, and initial number of sub-tunnels to be created as part of a split-tunnel. If these values are not provided, the system defaults to:
  • Minimum: 1 sub-tunnel
  • Maximum: 10 sub-tunnels
  • Initial: 1 sub-tunnel

Each of these parameters must be in the range 1 to 100, inclusive. The minimum number of sub-tunnels will be created regardless of whether they are strictly needed to meet the requested bandwidth. Even if more sub-tunnels are required to satisfy bandwidth demands, the total number will still be capped at the configured maximum.

When a split-tunnel is first created, it starts with at least the configured initial number of sub-tunnels, and this level is maintained for the first 10 minutes. After that, the number may drop to the configured minimum.

These parameters can be configured for both quantum and adaptive split-tunnels, as illustrated below: 
switch(config-te-rsvp-tunnel-myTunnel)# split-tunnel quantum 10 kbps sub-tunnels minimum 2 limit 10 initial 5
switch(config-te-rsvp-tunnel-myTunnel)# split-tunnel min 1 gbps max 50 gbps sub-tunnels minimum 2 limit 10 initial 5

Split-Tunnel and MPLS Tunnel Counters

Depending on the configuration in tunnel-counters mode, traffic through RSVP-TE split-tunnels may be counted against the overall tunnel or the sub-tunnels. Traffic will only be counted for one if they are used in the same hierarchy.

When using auto-bandwidth, it is important to prioritize counting traffic against the sub-tunnels over the overall tunnel. If this is not done, then auto-bandwidth will not function correctly for RSVP-TE split tunnels. In the following example, RSVP sub-tunnels are given a priority for counting over overall tunnels (a smaller number means higher priority): 
switch(config)# tunnel-counters
switch(config-tunnel-counters)# transmit
switch(config-tunnel-counters-transmit)# source-protocol rsvp ler sub priority 1
switch(config-tunnel-counters-transmit)# source-protocol rsvp ler priority 100
Note: Refer to the Granular Control for MPLS Tunnel Counters TOI for more information.

Tunnel Metric

The tunnel metric feature configures a per-RSVP tunnel metric so that specific tunnels to a Tunnel End Point (TEP) can take precedence over other tunnels to the same TEP when forming ECMP. The tunnel metric is published in the tunnel RIB, so it can also be used in BGP cost calculations. 
switch(config-te-rsvp-tunnel-myTunnel)# metric 10
A dynamic metric mode that follows the IGP metric is also available. Note that the dynamic IGP metric requires IS-IS as the underlying IGP protocol. 
switch(config-te-rsvp-tunnel-myTunnel)# metric igp

Per-tunnel Fast-Reroute Configuration

By default, RSVP tunnels’ fast-reroute options are inherited from the global RSVP configuration. If tunnels need options different from the global one, per-tunnel FRR configuration can be set with the fast-reroute mode command. The options for this are the same as those for the fast-reroute mode configuration in the mpls rsvp mode. For example, if FRR should be explicitly disabled for a tunnel, use the following command. 
switch(config-te-rsvp-tunnel-myTunnel)# fast-reroute mode none

Note that this only modifies the type of protection requested by the tunnel. If the global RSVP Fast-Reroute configuration differs, then the protection requested by the tunnel might not actually be created locally. For example, if a tunnel requests node-protection but the global RSVP configuration is only link-protection, then on the headend node, only a link-protection bypass LSP will be created. Other routers along the path may still provide node-protection. Similarly, if the global configuration is set to none, then no protection will be created on the headend node.

Tunnel Profiles

Tunnel profiles contain common sets of configurations to be applied to different tunnel specifications. This helps to simplify the configuration of tunnels by cutting down on repetition of config commands, which also minimizes errors.

Tunnel Profile Configuration

Tunnel profiles are configured in their own submode, similar to tunnel specifications, using the tunnel profile keywords followed by the profile name. 
switch(config-te-rsvp)# tunnel profile MyProfile 
switch(config-te-rsvp-tunnel-profile-MyProfile)#
Configuration within the tunnel profile is done using the same syntax as commands in the tunnel specification. For example, if creating a profile with a common bandwidth configuration, it can be set the same way as in the tunnel specification: 
switch(config-te-rsvp-tunnel-profile-MyProfile)# bandwidth auto min 100 mbps max 500 mbps

Note that not all of the configurations in the tunnel specification are supported in the tunnel profile. For instance, destination, path, and shutdown cannot be configured in the profile. The supported commands can be seen by running ? in the profile configuration submode, which will display the available commands and the help description for each.

Tunnel Profile Association

Tunnel profiles can be associated with tunnel specifications using the profile configuration under the tunnel specification submode. 
switch(config-te-rsvp)# tunnel MyTunnel 
switch(config-te-rsvp-tunnel-MyTunnel)# profile MyProfile

In the example above, MyTunnel will inherit the configured values from MyProfile. If MyProfile is configured with bandwidth 500 mbps then the resulting tunnel for MyTunnel will have a bandwidth of 500 Mbps.

If a profile is desired for some configuration but not all, values inherited from an associated profile can be overridden by explicitly configuring the value in the tunnel specification. For instance, if an associated profile configures bandwidth 500 mbps but the tunnel specification has bandwidth 200 mbps explicitly configured, then the resulting tunnel will have a bandwidth of 200 mbps. If we want a tunnel to have no bandwidth but also use an associated profile that configures some other value for it, then bandwidth 0 mbps can be set in the tunnel specification. In configurations where there is no numerical default, such as color, the disabled keyword can be used in the tunnel specification to explicitly turn off the feature, overriding any value that would otherwise be inherited from an associated profile. 
switch(config-te-rsvp-tunnel-MyTunnel)# color disabled

Removing a command from the tunnel specification with the no or default keyword will revert to the default behavior of the value being inherited from an associated profile if there is one. If a configuration is not set in the tunnel specification or in an associated profile, then it will be inherited from the global configuration if one exists, or the default configuration will be used.

ECMP Bandwidth Least-fill

Bandwidth least-fill is switched on by default. It can be disabled under config-te-rsvp by setting the tie-break mode to random. 
switch(config-te-rsvp)# cspf ecmp tie-break random
Least-fill is turned on again by setting the mode to least-fill.
switch(config-te-rsvp)# cspf ecmp tie-break least-fill

It serves as a path-selection method to compare multiple potential paths that are otherwise equal (based on SRLG, TE-Metric, number of hops, etc.) by assigning tunnels to paths with the greatest available bandwidth. It does this by calculating the percentage of the link's bandwidth that will be used if the tunnel goes over that link (anticipated utilization percentage) and comparing path candidates beginning with their most heavily used link and proceeding down towards their least heavily used links if these are equal.

When deciding whether to switch from an already established path, it computes the sum of the anticipated utilization percentages of the links on the new path candidate and will only switch if the new path is more than 10% better than the existing path.

Least-fill is not guaranteed to produce optimally distributed paths immediately, particularly after initial bring-up when paths are computed before the IGP has converged. For best results, it is recommended to use the least fill with a re-optimization timer.

LSP Self-Ping

For RSVP-TE tunnels, a headend may begin sending traffic through an LSP as soon as it receives a RESV message, before the forwarding state has been installed on all downstream nodes, which can lead to traffic loss. The LSP self-ping feature verifies end-to-end establishment of the LSP by sending a self-ping message through an LSP before sending regular traffic to verify that all downstream forwarding state has been installed. With the LSP self-ping feature enabled, an LSP created by an RSVP-TE tunnel will only be considered up and ready to carry traffic when a self-ping message successfully returns to the headend.

The lsp self-ping configuration enables the LSP self-ping feature. When enabled, all new LSPs created by RSVP-TE tunnels will perform self-ping. 
switch(config-te-rsvp)# lsp self-ping
Least-fill is turned on again by setting the mode to least-fill. 
switch(config-te-rsvp)# cspf ecmp tie-break least-fill

A maximum of 5 self-ping messages will be sent in 2-second intervals. If the fifth and final self-ping message does not return after 2 seconds, the LSP will be torn down, and the headend will create a new one.

LSPs that have sent a self-ping message but are waiting for it to return will show a state of establishing (waiting for self-ping) in the output for show traffic-engineering rsvp tunnel lsp. This state is logged in the LSP state history, which can serve as an indicator that self-ping has been performed for an LSP.

Configuring a Tunable RSVP LSP Preservation Time after MBB Failure

The Tunable RSVP LSP Preservation Time after MBB Failure feature allows network administrators to control how long the system maintains an original (old) Label Switched Path (LSP) if a Make-Before-Break (MBB) attempt fails.

MBB is a process in which the headend router establishes a new LSP path before removing the old one. This is done in cases such as when bandwidth changes, the path is re-optimized, or if FRR occurs on a node in the path. For RSVP tunnels using dynamic paths, if CSPF fails to find a new path to the destination, the router must decide how long to keep the old path alive.

By configuring a preservation timer, the duration the old LSP remains in use can be controlled without blackholing traffic. If CSPF is unable to return a path, a longer preservation timer keeps the old path as the active forwarding engine. At the end of the preservation time, the tunnel may go down if no secondary LSP is available. A small value may be desirable for scenarios in which other means to reach the tunnel endpoint are available in the system, whereas a large value may be preferable if a secondary path is configured as a cold standby and needs some time to be established.

In the following example, the Preservation Timer is configured to 300 seconds: 
switch(config-te-rsvp)# lsp no-path preservation-timer 300 seconds

The timer is disabled using the infinite keyword, which means that the existing LSP is kept up indefinitely. The default is 0 seconds, which means that the existing LSP is taken down immediately if no new path is found

RSVP-TE Tunnels Limitations

  • The maximum number of hops in each path is 100.
  • The total number of configured tunnels to the same destination IP is limited to 600.
  • Auto-bandwidth needs tunnel counters, which are only available when hardware counter feature mpls tunnel is configured.
  • Streaming Tunnel and LSP history via TerminAttr is not currently supported.
  • LSP ping is currently not supported with split-tunnels.
  • Anycast Loopbacks are not supported as destinations or include-hop.
  • Secondary Loopbacks as tunnel endpoints are not supported in OSPF.
  • When using dynamic paths with IS-IS, only a single IS-IS instance is supported.