Configuring RSVP-TE

The basic configuration is required to globally enable RSVP-TE.

Basic Configuration

Note: There is no per-interface knob to enable/disable RSVP; however, RSVP is enabled only on interfaces with MPLS enabled.

The device must be in MPLS RSVP mode. Enter the MPLS RSVP configuration Mode:
```
switch(config)# mpls rsvp 
switch(config-mpls-rsvp)# 
```
Enable RSVP-TE globally by issuing the no shutdown command in the MPLS RSVP configuration mode.
```
switch(config-mpls-rsvp)# no shutdown
```

The following sections describe some of the many configuration settings available. For a list of all available RSVP-TE commands, refer to RSVP-TE Commands.

Refresh Configuration

The state refresh interval dictates how often refresh messages are sent for LSPs and is configurable. With a refresh interval of R, refresh messages are sent at a randomly chosen time between 0.5*R and 1.5*R seconds after the last refresh. The interval parameter is in seconds. The default value is 30 seconds.

switch(config-mpls-rsvp)# refresh interval 30

The refresh method can be configured to be either bundled or explicit. The default is bundled. With explicit refresh messages, LSPs will send Path and Resv messages individually to refresh. With bundled, Refresh Overhead Reduction will be enabled, and the refreshes for several LSPs will be bundled together in refresh messages using message IDs.

The bundled refresh method should be selected when using RSVP-TE at scale.

switch(config-mpls-rsvp)# refresh method bundled

Hello Configuration

Hello messages are used to detect failures between RSVP-TE neighbors. The hello interval and timeout multiplier are configurable. In the following example, the hello messages are sent to all known neighbors every 10 seconds. If no hello responses are received from a neighbor during the interval multiplied by the multiplier value (4*10=40 seconds), the communication with the neighbor is considered lost, and the neighborship is reset.

switch(config-mpls-rsvp)# hello interval 10 multiplier 4

Cryptographic Authentication Extension

Enable Cryptographic Authentication by configuring the authentication type to md5 and adding an active password. The default is none, which disables cryptographic authentication.

switch(config-mpls-rsvp)# authentication type md5

Authentication secrets are configured with an index. The index refers to the globally configured list of authentication passwords. Select one of the indices as the password:

switch(config-mpls-rsvp)# authentication index 1 password s3cr3t 
switch(config-mpls-rsvp)# authentication index 1 active

The active password is used to authenticate outgoing messages. All configured passwords are accepted for authenticating incoming packets, allowing smooth key rollover.

The size of the sequence number reorder window can be increased to accommodate more out-of-order packets. A value of N means that a packet is accepted if all earlier received packets with a higher sequence number are within the preceding N-1 packets. The default value is 5. A value of 1 effectively turns off support for packet reordering.

(config-mpls-rsvp)# authentication sequence-number window 5

Per-neighbor authentication is also supported and is configured by prefixing the authentication commands with the neighbor's interface IP. The index refers to the globally configured list of authentication passwords. If authentication is configured for a neighbor, then it takes precedence over the global authentication configuration. This can also be used to disable authentication for specific neighbors if it is enabled globally.

switch(config-mpls-rsvp)# neighbor 10.0.0.1 authentication type md5
switch(config-mpls-rsvp)# neighbor 10.0.0.1 authentication index 1 active

Password Obfuscation

Password obfuscation can be configured with the following command.

switch(config-mpls-rsvp)#authentication index 1 password ?

0 = Indicates that the key string is not encrypted.
7 = Specifies that a HIDDEN key will follow.
8a = Specifies that a AES-256-GCM encrypted key will follow.
LINE = Unobfuscated key string.

With a 7 or 8a, the password will be obfuscated in different formats. For example:

switch(config-mpls-rsvp)# authentication index 1 password 7 07092E43

Configuring Fast Reroute Extension

Note: Fast Reroute requires that the TE router ID of each router along the path match the IP address of a loopback interface on that router.

Fast ReRoute (FRR) may be enabled by setting the Fast Reroute mode to either link-protection or node-protection.

link-protection: Protects against the failure of the next link. Bypass tunnels are created from the current node to the next node if a path is available that does not traverse the protected link.

switch(config-mpls-rsvp)# fast-reroute mode link-protection

node-protection: Protects against the failure of the next node. Bypass tunnels are created from the current node to the next-next node if a path is available that does not traverse the protected node. If no such path is available, a link-protection bypass tunnel will be used instead.

switch(config-mpls-rsvp)# fast-reroute mode node-protection

This setting only applies to the Point of Local Repair (PLR) behavior, meaning that the router is the upstream node relative to a to-be-protected link or node for routing an LSP. Merge Point (MP) behavior is not affected by this setting. In addition to affecting PLR behavior, this setting at the headend determines the local protection mode requested by LSPs originating from that node.

For backup tunnels to be programmed in hardware, hardware fast-failover must be configured. If this is not done, fast reroute will only be implemented in software, leading to slower convergence times in the event of a link or node failure.

switch(config)# router general
switch(config-router-general)# hardware next-hop fast-failover

The reversion behavior of FRR can also be configured to either global revertive mode or local revertive mode. The default is global revertive mode.

In global revertive mode, an LSP that is rerouted over a bypass tunnel when the downstream link fails continues to use the bypass tunnel even after the link recovers. In this mode, the headend router is expected to establish a new LSP upon receiving a notification that the bypass tunnel is in use.

switch(config-mpls-rsvp)# fast-reroute reversion global

In local revertive mode, the LSP switches back to using the primary link if the link recovers. Note that in local revertive mode, the headend may still set up a new LSP to replace the old one if it has been notified that the bypass tunnel was in use, even if the primary link recovers. Local revertive mode is not supported for node-protection bypass tunnels; if local reversion is configured, global reversion will be used instead.

switch(config-mpls-rsvp)# fast-reroute reversion local

Bypass Re-optimization Interval

Bypass tunnel paths are re-optimized by default every 30 seconds. That interval can be changed using the following command:

switch(config-mpls-rsvp)# fast-reroute bypass tunnel optimization interval 45 seconds

Administrative Group Constraints for Bypass LSPs

Administrative group constraints restrict CSPF path computation to links that match a set of administrative groups. When specified for an interface, they apply to all LSPs that bypass that interface, including both link and node protection. The range of administrative group constraints can be configured, in the range of 0-511 interfaces, using the following command from the interface config mode:

switch(config)# interface Et1 
switch(config-if-Et1)# rsvp bypass administrative-group include all 1 include  any 2-4 exclude 7,9

The list of administrative groups should be provided as a comma-separated input with no spaces. Administrative group constraints are represented by a single 32-bit value, with each bit corresponding to a single admin group. These values can also be directly used in the command in hexadecimal format:

switch(config-if-Et1)# rsvp bypass administrative-group exclude 0x280

Administrative group constraints can alternatively be specified using a name as an alias mapped to a numerical value. These names can be directly used to configure administrative group constraints in addition to the existing numerical format:

switch(config-if-Et1)# rsvp bypass administrative-group include all blue  include any 2-4,red exclude green,7

Configuring Shared Risk Link Groups

The srlg command specifies if the link SRLGs of a primary LSP are to be considered as constraints when creating a fast-reroute bypass tunnel. This applies to both link and node protection. When using srlg with the strict keyword, a bypass tunnel will not be created if a path that excludes the SRLGs of the next-hop interface of the primary LSP cannot be found. When the srlg command is used without the strict keyword, a bypass tunnel is set up with as many links as possible that exclude the SRLGs of the next-hop interface of the primary LSP.

switch(config-mpls-rsvp) # srlg
and
switch(config-mpls-rsvp) # srlg strict

By default SRLG processing is turned off. The SRLGs of an interface can be configured using the following commands:

switch(config)# interface Et1 
switch(config-if-Et1)# traffic-engineering srlg 100 
switch(config)# interface Et2  
switch(config-if-Et2)# traffic-engineering srlg 200

Note: Although a large number of SRLGs can be configured on an interface, Constrained Shortest Path First (CSPF) considers only up to 16 SRLGs when finding a path that satisfies the SRLG constraints.

Configuring Constrained Shortest Path First (CSPF)

RSVP-TE uses CSPF to compute the FRR backup path. CSPF can be configured to avoid frequent path changes when network events occur frequently. Use the Router Traffic Engineering configuration mode to specify how frequently CSPF runs after a network event by setting the initial wait interval, back-off interval, and maximum wait interval. For example, using the following command configures CSPF to an initial wait interval of 600 milliseconds, a back-off interval of 60000 milliseconds, and a maximum wait interval of 10000 milliseconds:

switch(config)# router traffic-engineering 
switch(config-te)# cspf delay initial 60000 back-off 60000 max 10000

The switch defaults to 100 for the initial wait interval, 200 for the back-off interval, and 1000 for the maximum wait interval, with all values in milliseconds.

Configuring Traffic Engineering

For CSPF to compute the FRR backup path to a particular destination, enable traffic-engineeringon all IGP-enabled interfaces and globally enable the traffic engineering extensions. For IS-IS, enable traffic-engineering under the Router ISIS configuration mode, and for OSPFv2, enable it in the Router OSPFv2 configuration mode. This is required for the IGP to start exchanging TE-related attributes with peers and build the topology database.

In addition, CSPF needs a router ID to uniquely identify a router, so that it can find a path to it. CSPF also uses the self router ID as a source for running SPF. A router ID must be configured under therouter traffic-engineering mode for CSPF to function properly.

Configuring MTU Signaling

With MTU signaling, RSVP can discover the lowest Maximum Transmission Unit (MTU) used along an LSP.

switch(config-mpls-rsvp)# mtu signaling

The MTU will be evaluated and updated at each hop that has MTU signaling enabled. The value is updated by taking the minimum of the downstream interface MTU and the composed MTU value from the incoming Path message. On hops that do not have MTU signaling enabled, the composed MTU from the incoming Path message will be carried over into the outgoing Path message without update.

If MTU signaling is disabled at the headend, MTU discovery will not be performed for LSPs originating there.

Configuring a Preemption Method

The preemption method is configured using the preemption method command. Soft preemption defers RSVP-TE LSP failures caused by link oversubscription. With soft preemption, LSPs are brought down after a set period following preemption. When a link is oversubscribed, LSPs are preempted in order of priority from lowest to highest until the link is no longer oversubscribed. The soft preemption timer is configurable. The default timer value is 30 seconds. The following example uses the preemption method soft timer command to configure soft preemption with a timer value of 10 seconds.

switch(config-mpls-rsvp)# preemption method soft timer 10

The preemption method can also be configured for hard preemption. With hard preemption, LSPs are brought down immediately when the link is oversubscribed. Similar to soft preemption, LSPs are preempted in order of priority, from lowest to highest.

switch(config-mpls-rsvp)# preemption method hard

The preemption method configured on the headend determines the requested preemption method by an LSP. If an LSP does not have soft preemption enabled on the headend, then hard preemption will be used along the path for that LSP. If an LSP requests soft preemption but soft preemption is disabled at a transit node, hard preemption will be used.

Configuring Graceful Restart

Graceful Restart preserves data plane traffic when the RSVP agents restart and has two modes:

Helper Mode only helps to restart RSVP neighbors.
Speaker Mode allows the local node to restart gracefully with the help of RSVP neighbors.

If the Hello Messages feature is not enabled, Graceful Restart will be inactive. RSVP nodes participating in Graceful Restart exchange a new object in their Hello messages that advertise both Graceful Restart phases' time values: the restart phase and the recovery phase.

The restart phase begins after a Hello time-out, indicating that RSVP communication with a neighbor has been lost. If a neighbor advertises a non-zero restart time value, a timer starts after detecting a communication loss from that neighbor. During the restart phase, the Hello timeout is effectively delayed, allowing the neighbor a chance to restart before bringing down the LSPs for that neighbor. Path and Resv messages towards that neighbor are quieted.

If an RSVP node does not receive a Hello message from the neighbor before the end of the restart phase, Hello communication loss procedures begin for that neighbor.
If an RSVP node receives a Hello message from a neighbor with the same source instance before the end of the restart phase, normal RSVP procedures resume, and no LSPs are brought down due to the Hello timeout.
If an RSVP node receives a Hello message from a neighbor with a different source instance and a non-zero recovery period. The recovery phase begins for that neighbor. Source instances are allocated for the lifetime of an RSVP agent, so receiving a different source instance from a neighbor indicates that the neighbor's RSVP instance has restarted.

During the recovery phase, outgoing RSVP Resv messages are paused until the neighbor receives a Path message for the same LSP from the restarted neighbor. After receiving a Path message, the LSP's usual RSVP procedures restart. At the end of the recovery period, RSVP clears any data-plane and control-plane states for the neighbor that were not re-advertised since the neighbor was restarted.

Note: In order for Graceful Restart (GR) to work correctly, a helper needs to detect restart on the speaker through a hello time-out before the LSP state expires. This is particularly relevant for Stateful Switchover (SSO), where a restart may take longer. In the worst case, the last refresh message for an LSP may have been sent 1.5R seconds before the restart, with R being the refresh interval. Since the lifetime of an LSP without refresh is 5.25R seconds before expiring, that leaves 3.75R seconds before LSPs potentially start timing out if restart is not detected. When GR is enabled, the configured hello timeout (the hello interval multiplied by the hello multiplier) should be less than 3.75 times the refresh interval: Hello_Interval x Hello_Multiplier < 3.75 x Refresh_Interval. A warning will be issued if the configuration does not respect this.

Configuring Helper Mode

Use the following commands to enable Helper mode and configure the maximum accepted restart and recovery values. By default, all restart and recovery values are accepted.

switch(config)# mpls rsvp 
switch(config-mpls-rsvp)# graceful-restart role helper 
switch(config-mpls-rsvp-gr-helper)# timer restart maximum 160 seconds
 switch(config-mpls-rsvp-gr-helper)# timer recovery maximum 320 seconds

Configuring Speaker Mode

Use the following commands to enable Speaker mode and configure the restart and recovery values. By default, both restart and recovery are set to 90 seconds.

switch(config)# mpls rsvp 
switch(config-mpls-rsvp)# graceful-restart role speaker 
switch(config-mpls-rsvp-gr-speaker)# timer restart 160 seconds 
switch(config-mpls-rsvp-gr-speaker)# timer recovery 320 seconds

Graceful Restart Limitations

Some RSVP features and extensions are not supported across restarts.
Graceful Restart does not support Fast-Reroute events during restart or recovery.
Refresh Overhead Reduction states are cleared across restarts.
Two neighbors restarting at the same time is not supported.
Node-based hello messages are not supported.

Configuring Hitless Restart

Hitless Restart allows RSVP agents to be restarted without data-plane interruptions. Unlike Graceful Restart, this does not require neighbors configured in a helper role. During a Hitless Restart, the installed RSVP state will be preserved until either it is refreshed by its neighbors or the recovery period ends. At the end of the recovery period, any state that has not been refreshed will be cleared.

The neighbors of a restarting node using Hitless Restart cannot tell that the local node has restarted, and the source instance used in Hello messages remains the same across restarts. If Hello messages are enabled, a Hitless Restart that lasts longer than the configured Hello timeout will cause neighbors to consider communication with the local node as lost. By default, the recovery period is set to 90 seconds.

switch(config-mpls-rsvp)# hitless-restart

The recovery period is configurable under the RSVP Hitless Restart configuration mode.

switch(config-mpls-rsvp-hr)# timer recovery 40 seconds

Hitless Restart Limitations

Some RSVP features and extensions are not supported across restarts.
Hitless Restart does not support Fast-Reroute events during recovery.
Refresh Overhead Reduction states are cleared across restarts.

Explicit-Null

The RSVP explicit-null feature enables an egress node to advertise an IPv4 explicit-null label (Label 0) to its upstream router. By default, an egress node always advertises implicit-null, but that can be changed using the following command.

switch(config-mpls-rsvp)# label local-termination explicit-null

Sample RSVP-TE Configuration

ip routing 
! 
mpls ip 
! 
interface Ethernet1 
 no switchport 
 ip address 10.0.0.1/24 
 isis enable instance1 
 traffic-engineering 
 traffic-engineering bandwidth 100 percent 
 traffic-engineering metric 5 
! 
router traffic-engineering 
 router-id ipv4 0.1.1.1 
! 
router isis instance1 
 net 49.0000.0000.0000.1111.00 
 is-type level-2 
 ! 
 address-family ipv4 unicast 
 maximum-paths 32 
 ! 
 traffic-engineering 
 no shutdown 
 is-type level-2 
! 
mpls rsvp 
 no shutdown 
 refresh interval 60 
 refresh method bundled 
 hello interval 10 multiplier 4 
 authentication type md5 
 authentication sequence-number window 5 
 authentication index 1 password 7 141A0B1B0D17393C2B3A37 
 authentication index 1 active 
 neighbor 1.2.3.4 authentication index 1 active 
 fast-reroute mode link-protection 
 fast-reroute reversion global  
 fast-reroute bypass tunnel optimization interval 3600 seconds 
 srlg strict 
 label local-termination explicit-null
 preemption method soft timer 30 
 mtu signaling

EOS 4.36.1F User Manual - Configuring RSVP-TE Print