End of Support

LDP Graceful Restart

Label Distribution Protocol (LDP) Graceful Restart allows devices to preserve MPLS LDP LFIB entries in the forwarding plane during the loss of a TCP connection or the LDP agent restarts. The Graceful Restart helper negotiates on a per-session during session initialization, and if a peer fails, maintains the MPLS LDP LFIB entries providing the underlying IGP links to reach the peer remain active.

A Graceful Restart speaker maintains the MPLS LDP LFIB entries if the LDP agent unexpectedly restarts. Changing the Gracecul Restart role of a peer from disabled to helper or to speaker impacts traffic as the session must renegotiate the connection.

The peers advertise the LDP Graceful Restart capability through the LDP session initialization and creates an additional TLV called Fault Tolerant Session TLV and includes it in the LDP initialization message. The TLV contains the following :

A set of flags as defined in Section 8.2 of RFC3479 and the Learn-From-Network flag must be set.
A Fault Tolerant Reconnect timer
A Fault Tolerant Recovery timer

When two peers exchange LDP initialization messages, the Graceful Restart considers the maximum time between those timers and the configured thresholds to initiate a restart.

LDP Graceful Restart Conditions

An LDP Graceful Restart may occur with the following conditions:

The LDP Agent initializes and sets Graceful Restart as active locally. Any session established with active Graceful Restartalso becomes Graceful Restart active.
Manually shutting down the LDP agent using the CLI command, shutdown does not trigger Graceful Restart.
An expiring LDP adjacency hold timer, as in the case of not receiving Hello messages, triggers a Graceful Restart.
An expiring LDP session keep alive timer, as in the case of not receiving session KeepAlive messages,triggers a Graceful Restart.
If the LDP agent restarts after a non-graceful restart, such as receiving an agentLdpAgent terminate, a Graceful Restart triggers on the switch.

Configuring an LDP Graceful Restart Speaker

Enabling the speaker role also enables the helper role which preserves the entire MPLS LDP LFIB entries if the LDP agent restarts, and also acts as a helper to preserve the LFIB entries of peer with the restarted LDP agent.

Use the following commands to configure an LDP Graceful Restart Speaker role:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart speaker

Configuring Graceful Restart Speaker Parameters

The LDP Graceful Restart Speaker Configuration Mode configures additional parameters for a Speaker such as reconnection timers and length of time to preserve MPLS LDP LFIB entries when the local LDP agent restarts.

The timer reconnect parameter defines the time that a Helper preserves MPLS LDP LFIB entries when a particular session unexpectedly becomes unavailable. The Helper uses a default value of 90 seconds.

Use the following commands to configure a timer connect value of 500 seconds:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart speaker
switch(config-mpls-ldp-gr-speaker)# timer connect 500

The timer state-holding parameter defines the time for the LDP Restarting Speaker to preserve the MPLS LDP LFIB entries if its LDP agent restarts unexpectedly. The timer starts when the LDP Restarting Speaker recovers and becomes active again. The Fault Tolerant Session TLV uses the state holding time out value as the recovery timeout value during session reinitialization. By default, the state holding timeout uses 90 seconds.

Use the following commands to configure a timer state-holding value of 500 seconds:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart speaker
switch(config-mpls-ldp-gr-speaker)# timer state-holding 500

Configuring an LDP Graceful Restart Helper

Enabling the Helper role does not enable the Speaker role. If LDP agent restarts, the device cannot preserve the MPLS LDP LFIB entries, but can only preserve the LFIB entries for a peer with the restarted LDP agent.

Use the following commands to configure an LDP Graceful Restart Speaker role:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart helper

Configuring Graceful Restart Helper Parameters

The LDP Graceful Restart Helper Configuration Mode configures additional parameters for a Helper such as length of time to preserve and recover MPLS LDP LFIB entries.

The timer neighbor-liveness parameter defines the maximum time the Graceful Restart Helper preserves the MPLS LDP LFIB entries for a session unexpectedly disconnected. The Helper preserves the MPLS LDP LFIB entries for the lower Maximum Recovery timeout value and the received Recovery timeout value in seconds.

Use the following commands to configure a timer neighbor-liveness value of 500 seconds:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart helper
switch(config-mpls-ldp-gr-speaker)# timer neighbor-liveness 500

The timer recovery parameter defines the time for a Helper to preserve the MPLS LDP LFIB entries for a session once the session with restarting Speaker re-establishes on the switch. The Helper preserves the MPLS LDP LFIB entries for the lower Maximum Recovery timeout value and the received Recovery timeout value in seconds.

Use the following commands to configure a timer recovery value of 500 seconds:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart helper
switch(config-mpls-ldp-gr-helper)# timer recovery 500

The pseudowire parameter supports LDP-signaled pseudowires and preserves the bindings when the LDP session goes down for a peer.

Use the following commands to configure a pseudowire for a Helper:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart helper
switch(config-mpls-ldp-gr-helper)# pseudowire

RSVP-TE Commands

RSVP-TE LER Commands

administrative-group
alias endpoint
bandwidth
color
cspf delay
cspf ecmp tie-break
destination ip
fast-reroute mode (RSVP tunnel)
fast-reroute mode
hop (dynamic path)
hop (explicit path)
igp shortcut
local-interface
lsp self-ping
metric
optimization interval
path (path specification)
path (RSVP tunnel)
priority
refresh rsvp tunnel optimization
router traffic-engineering – not an RSVP command
rsvp
show traffic-engineering cspf path
show traffic-engineering database
show traffic-engineering rsvp tunnel history
show traffic-engineering rsvp tunnel lsp
show traffic-engineering rsvp tunnel name
show traffic-engineering rsvp tunnel sub-tunnel summary
show traffic-engineering rsvp tunnel summary
show traffic-engineering rsvp tunnel
show traffic-engineering rsvp
shutdown (MPLS RSVP)
shutdown (tunnel)
split-tunnel
srlg
traffic-engineering srlg
tunneling ldp
tunnel

Related Topics:

administrative-group

The administrative-group command specifies the inclusion or exclusion of links that are part of an administrative group. The administrative group IDs are global 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 or must be in one of the admin groups specified in the include any range. A chosen link must not be in the exclude range. The administrative group range is 0 to 511.

Administrative groups can be specified using a name as an alias mapped to a numerical value. The mapping can be configured under the global Traffic-Engineering (TE) mode. For more information ,refer to the IS-IS Traffic-Engineering TOI.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

default administrative-group

no administrative-group

Parameters

exclude - Excludes the specified administrative group identified by either a group name or number.

include all - Includes the specified administrative groups identified by either a group name or number.

include any - Includes any of the specifiedrange of administrative groups identified by either a group name or number.

Example

The following example states the path must include links from administrative group 1 and any link from an administrative group within groups 2, 3, or 4. The path must exclude links from administrative groups 7 and 9.

switch(config-te-rsvp-path-dyn-MyPath)# administrative-group include all 1 include any 2-4 exclude 7,9

alias endpoint

The alias endpoint command configures a tunnel endpoint alias for both IPv4 and IPv6 endpoints and allows the additional next-hops to resolve using the existing tunnel. Use this command in the Router Traffic Engineering RSVP Tunnel Configuration Mode. Configure a maximum of 15 alias endpoints per tunnel.

Command Mode

Traffic Engineering RSVP Tunnel Configuration Mode

Command Syntax

alias endpoint [ ipv4_address | ipv6_address]

no alias endpoint

default alias endpoint

Parameters

alias endpoint - Specify adding a tunnel endpoint.
ipv4_address - Specify an IPv4 address in the format A.B.C.D.
ipv6_address - Specify an IPv4 address in the format A:B:C:D:E:F:G:H.

Example

Use the following commands to enter the Router Traffic Engineering RSVP Tunnel Configuration Mode, and add an alias endpoint, 192.168.11.5 to the existing MyTunnel configuration:

switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)# tunnel MyTunnel
switch(config-te-rsvp-tunnel-MyTunnel)# alias endpoint 192.168.11.5
switch(config-te-rsvp-tunnel-MyTunnel)#

authentication index

The authentication index command configures the MPLS RSVP cryptographic authentication password globally for outgoing messages to the specified neighbor.Note that per-neighbor authentication takes precedence over global authentication.

The command authentication index index_num active is used to set the active password which is used when sending a message. The command authentication index index_num password is used to create the password with a given index.All configured passwords are used to authenticate incoming messages.

Command Mode

MPLS RSVP Configuration

Command Syntax

authentication index <num> password<WORD>

[no|default] authentication index <num> password <WORD> password

[no|default] authentication index <num> password<WORD> active

Parameters

<num> index number chosen as the password for cryptographic authentication for messages sent to the specified neighbor.

<WORD> can be a plaintext password or a number that specifies the obfuscation method followed by the obfuscated password.

Example

The following commands globally enable cryptographic authentication (RFC 2747) for MPLS RSVP messages sent from the switch and establish the authentication index 755 and the password s3cr3t for outgoing messages:

switch(config)#mpls rsvp
switch(config-mpls-rsvp)# authentication type md5
switch(config-mpls-rsvp)# authentication index 755 password s3cr3t
switch(config-mpls-rsvp)# authentication index 755 active

authentication sequence-number window

The authentication sequence-number window command configures the size of the sequence number reorder window for incoming MPLS RSVP messages. Increasing the size of the window allows RSVP to accommodate a larger number of out-of-order packets. A value of N means that a packet is accepted if all previously 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.

Note: This command only has an effect if the authentication type is not none.

The no authentication sequence-number window and default authentication sequence-number window commands reset the size of the window to 5.

Command Mode

MPLS RSVP Configuration

Command Syntax

authentication sequence-number window size_num

no authentication sequence-number window

default authentication sequence-number window

Parameters

size_num - Sequence-number window size. Values range from 1-255. The default value is 5. A value of 1 disables packet reordering.

Example

The following commands set the sequence-number window to 50:

switch(config)#mpls rsvp
switch(config-mpls-rsvp)# authentication sequence-number window 50
switch(config-mpls-rsvp)#

authentication type

The authentication type command configures the MPLS RSVP cryptographic authentication type globally. Setting the type to md5 enables cryptographic authentication (RFC 2747) for MPLS RSVP messages sent from the switch. Setting the type to none disables authentication globally. Note that per-neighbor authentication settings takes precedence over global settings.

The no authentication type and default authentication type commands disable authentication. Cryptographic authentication is disabled by default. These commands are functionally the same as authentication type none.

Command Mode

MPLS RSVP Configuration

Command Syntax

authentication type {md5 | none}

no authentication type {md5 | none}

default authentication type {md5 | none}

Parameters

md5 = enables MPLS RSVP cryptographic authentication (RFC 2747) for the specified neighbor. A password for outgoing messages must also be configured using the authentication index command.
none - disables MPLS RSVP cryptographic authentication for messages sent to the specified neighbor.

Examples

The following commands globally enable cryptographic authentication (RFC 2747) for MPLS RSVP messages sent from the switch and establish index 755 as the password for outgoing messages:

switch(config)#mpls rsvp
switch(config-mpls-rsvp)# authentication type md5
switch(config-mpls-rsvp)# authentication index 755  password s3cr3t 
switch(config-mpls-rsvp)# authentication index 755 active

The following commands disable cryptographic authentication globally:

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

bandwidth

The bandwidth command configures the reserve bandwidth within the tunnel. The bandwidth can be set explicitly by setting a bandwidth value and the unit. When a bandwidth value of 0 is entered no bandwidth reservation is signalled. An alternative to explicit bandwidth configuration is to use the autobandwidth feature which specifies the minimum and maximum bandwidth to be used for the tunnel and otherwise adjusts bandwidth with an adjustment period based on the observed traffic going over the tunnel. The adjustment period is an optional parameter measured in seconds. The default adjustment period is 0 - a special value meaning that the algorithm decides when to adjust bandwidth based on statistical measurements (the actual adjustment cannot happen more frequently than the sampling, which occurs every 30 seconds).

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

bandwidth 0-1000 (bps | kbps | mbps | gbps)

bandwidth signaling[ disabled ]

no bandwidth 0-1000 (bps | kbps | mbps | gbps)

default bandwidth 0-1000 (bps | kbps | mbps | gbps)

no bandwidth auto

default bandwidth auto

no bandwidth signaling

default bandwidth signaling

Parameters

[bps | kbps | mbps | gbps] - Bandwidth values require the units of the value. The range of available units are bps, kbps, mbps, or gbps.

auto - Using the auto keyword configures autobandwidth within the configured minimum and maximum bandwidth and unit values. The tunnel adjusts the bandwidth based on the observed traffic going over the tunnel. This happens at adjustment interval, if configured. The default adjustment interval is 30 seconds, if no value is configured.

The min sets the minimum value and max sets the maximum value for the autobandwidth range. Each of the values require a unit to be selected.

The signaling keyword is used to enable signalling of the bandwidth reservation. A bandwidth of 0 returns signalling to the default of no signalling.

Example

The following command explicitly configure the bandwidth of the tunnel to 10 mbps.
```
switch(config-te-rsvp-tunnel-myTunnel)# bandwidth 10 mbps
```
The following command configures autobandwidth with a minimum of 1 mbps and maximum of 5 mbps. The bandwidth is set to be evaluated every 60 seconds.
```
switch(config-te-rsvp-tunnel-myTunnel)# bandwidth auto min 1 mbps max 5 mbps adjustment-period 60
```

clear mpls rsvp counters

The clear mpls rsvp counters command clears RSVP message counters. The clear mpls rsvp counters ( ip | ipv6 ) access-list command clears the ACL counters.

Command Mode

MPLS RSVP Configuration

Command Syntax

clear mpls rsvp counters

clear mpls rsvp counters ( ip | ipv6 ) access-list

Parameters

ipv4 - Filter by IPv4.
ipv6 - Filter by IPv6.

Example

The following commands place the switch in Traffic Engineering RSVP configuration mode:

switch(config)#mpls rsvp 
switch(config-mpls-rsvp)# clear mpls rsvp counters

clear mpls rsvp session

The clear mpls rsvp session command can be used to clear RSVP sessions. Clearing a session will remove the current state for the LSPs and send the appropriate TEAR messages. This can be useful for cleaning up stale sessions, renegotiating a session immediately after a config change, or forcing a recreation of an LSP that could be in an error state.

Command Mode

EXEC

Command Syntax

clear mpls rsvp session ( <filters> | all ) [ detail ]

Parameter

With <filters> being a list of one or more of: ( destination <ipv4> | id <id> ) ( name <name> | lsp <lsp> | bypass ) ( role <role> ) ( state <state> )

all - Clears all RSVP sessions.

bypass - Filter for bypass LSPs.

destination - Filter by destination address.

id - Filter by Session ID.

lsp-Filter by LSP number.

name - Filter by session name.

role - Filter by router role.

state - Filter by LSP state.

detail - Can be specified after all or any filters. When the command is run with detail the names of the sessions which are cleared are displayed, not just the count.

Examples

The following examples are on a switch with two RSVP sessions (sessionA and sessionB).

This command clears all RSVP sessions on the switch.

switch# clear mpls rsvp session all
Cleared 2 sessions

The detail keyword can be added to the end of the command to output the session name of all sessions being cleared.
```
switch# clear mpls rsvp session all detail
Clearing sessionA
Clearing sessionB
Cleared 2 sessions
```
The all keyword can be replaced with filters to clear specific sessions. In the following example, the name sessionA filter is used to clear just sessionA.
```
switch# clear mpls rsvp session name sessionA detail
Clearing sessionA
Cleared 1 sessions
```

The following is a list of the supported filters for the clear command. Some filters can be combined in a single command. For example, both the bypass and state up filters can be used in the same command to clear all bypass sessions which are in the up state.

switch# clear mpls rsvp session ?
  all          Clear all RSVP sessions
  bypass       Filter for bypass LSPs
  destination  Filter by destination address
  id           Filter by Session ID
  lsp          Filter by LSP#
  name         Filter by session name
  role         Filter by router role
  state        Filter by LSP state

color

The color command assigns a color to a tunnel to publish the tunnel to the system-colored-tunnel-rib, to help steer traffic into the tunnel.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

color ( <color value> | disabled )

default color - would inherit the color from the profile if one is configured

no color

color disabled - explicitly disables the color configuration irrespective of a profile being configured

Parameters

<color value> - numerical value in the range of 0 - 4292967295.

disable - disable the color attribute.

Example

The following example assigns color 60 to the MyTunnel:

switch(config-te-rsvp-tunnel-MyTunnel)# color 60

cspf delay

RSVP-TE uses CSPF to compute the FRR backup path. CSPF can be throttled to avoid frequent path changes when frequent network events occur. The cspf delay command configures the frequency of CSPF running after a network event by specifying the initial wait interval, back-off interval, and maximum wait interval for CSPF. The no form of the command removes the CSPF delay. The default cspf delay values are 100 for initial wait interval, 200 for back-off interval, and 1000 for maximum wait interval.

Command Mode

Router traffic engineering mode

Command Syntax

cspf delay [initial n back-off n] max n

no cspf delay

default cspf delay

Parameters

initial - Specify initial wait interval for CSPF.
- n - Specify the time in milliseconds. 1-300000.
  - back-off - Specify the back-off interval for CSPF.
    - n - Specify the time in milliseconds. 1-300000.
max - Specify the maximum wait interval for CSPF.
- n - Specify the time in milliseconds. 1-300000.

Example

The following commands configure an initial wait interval, back-off interval, and maximum wait interval of 200, 400, and 2000 milliseconds respectively for CSPF delay:


switch(config)#router traffic-engineering
switch(config-te)#cspf delay initial 200 back-off 400 max 2000
switch(config-te)#

cspf ecmp tie-break

The cspf ecmp tie-break command disables bandwidth least-fill when the random option is selected, and enables bandwidth least-fill when least-fill is selected. Bandwidth least-fill is enabled by default.

The no and default forms of the command restore bandwidth least-fill.

Command Mode

Traffic Engineering RSVP Configuration

Command Syntax

cspf ecmp tie-break (least-fill|random)

no cspf ecmp tie-break

default cspf ecmp tie-break

Parameters

least-fill - Enables bandwidth least-fill.
random -Disables bandwidth least-fill. Least-fill is enabled by default.

Example

The following command disables bandwidth least-fill on the switch:

switch(config-te-rsvp)#cspf ecmp tie-break random
switch(config-te-rsvp)#

destination ip

Each tunnel requires a destination IP to function. The destination ip command assigns a destination IP to the command-mode tunnel. For P2MP, this can be set multiple times, one for each of the multicast destinations.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

destination ip IP_address

no destination ip

default destination ip

Parameters

IP_address - The destination IPv4 address is required for the tunnel.

Example

The following command assigns destination IP 10.2.2.2 to the tunnel named MyTunnel:

switch(config-te-rsvp-tunnel-MyTunnel)# destination ip 10.2.2.2

ecmp shrinkage disable

The ecmp shrinkage disable command in the Hardware Nexthop Failover Configuration Mode disables the recalculation of ECMP paths on the switch.

The no | default version of the command enables the feature.

Command Mode

Hardware Nexthop Failover Configuration

Command Syntax

ecmp shrinkage disable

no ecmp shrinkage disable

default ecmp shrinkage disable

Parameters

ecmp shrinkage disable - Disable recalculating ECMP paths on the switch.

Example

Use the following commands to disable ECMP shrinkage:

switch(config)# router general
switch(config-router-general)# hardware next-hop fast-failover
switch#(config-router-general-hw-nexthop-fast-failover)# ecmp shrinkage disable
switch#(config-router-general-hw-nexthop-fast-failover)#

fast-reroute bypass tunnel optimization interval

The fast-reroute bypass tunnel optimization interval command configures the interval at which paths used for bypass tunnels are re-optimized. Paths are re-optimized every 30 seconds by default.

The no fast-reroute bypass tunnel optimization interval and default fast-reroute bypass tunnel optimization interval commands return the optimization interval to the default value of 30 seconds.

Command Mode

MPLS RSVP Configuration

Command Syntax

fast-reroute bypass tunnel optimization interval < number of seconds > seconds

no fast-reroute bypass tunnel optimization interval

default fast-reroute bypass tunnel optimization interval

Parameters

seconds - The time between re-optimizations of bypass tunnel paths in seconds.The values range from 1 to 65535. Default is 30.

Example

The following commands set the bypass tunnel optimization interval to 45 seconds:

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

fast-reroute mode (RSVP tunnel)

The fast-reroute mode command by default, RSVP tunnels inherit fast-reroute settings from the global RSVP configuration.The fast-reroute mode can also be configured for a specific RSVP tunnel by issuing the command in Traffic Engineering RSVP Tunnel configuration mode. Note that this only modifies the type of protection requested by the tunnel. If the requested protection is not enabled by the global RSVP configuration, it may not be provided to the tunnel.

The link-protection option protects against failure of the next link, the node-protection option protects against failure of the next node, and the none option disables the feature.

The default is no fast-reroute mode whichmeans that the inherit fast-reroute settings from the global RSVP configuration.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

fast-reroute mode ( link-protection | node-protection | none }

no fast-reroute mode

default fast-reroute mode

Parameters

fast-reroute mode link-protection - Protect against failure of the next link.

fast-reroute mode node-protection - Protect against failure of the next node.

fast-reroute mode none - Disable fast reroute.

Example

The following command enables fast reroute (FRR) link protection:

switch(config-te-rsvp-tunnel-MyTunnel)# fast-reroute mode link-protection

The following command enables fast reroute (FRR) node protection:

switch(config-te-rsvp-tunnel-MyTunnel)# fast-reroute mode node-protection

The following command disables FRR:

switch(config-te-rsvp-tunnel-MyTunnel)# fast-reroute mode none

fast-reroute mode

The fast-reroute mode command configures fast-reroute (FRR) (RFC 4090). The link-protection option protects against failure of the next link, the node-protection option protects against failure of the next node, and the none option disables the feature. Fast reroute is disabled by default.

On the headend, this knob acts as the global configuration which determines the type of protection requested by any LSPs originating there. This is superseded if the tunnels have a fast-reroute mode specified in the tunnel configuration (see fast-reroute mode (RSVP tunnel)) or in an associated profile.

On transit and headend, it also determines which type of bypass tunnels will be created at that node.

If node-protection is configured and requested by the LSP, then both node and link protection bypass tunnels will be created, with the node bypass being preferred if it's available.

If link-protection is configured or requested by the LSP, then only link-protection bypasses are created and used.

If the FRR mode is set to none or not requested at all by the LSP, then no bypass tunnels are created.

The no and default versions of the command disable fast reroute.

Command Mode

MPLS RSVP Configuration

Command Syntax

fast-reroute mode (link-protection | node-protection | none)

no fast-reroute mode

default fast-reroute mode

Parameters

link-protection - Protects against failure of the next link.
node-protection - Protects against failure of the next node.
none - Disables fast reroute.

Examples

The following command enables fast reroute (FRR) link protection/NHOP (RFC 4090):
```
switch(config-mpls-rsvp)# fast-reroute mode link-protection
```
The following command enables fast reroute (FRR) node protection/NNHOP (RFC 4090):
```
switch(config-mpls-rsvp)# fast-reroute mode node-protection
```

The following command disables FRR:

switch(config-mpls-rsvp)# fast-reroute mode none

fast-reroute reversion

You can change the revertive behavior of the FRR from the global revertive mode to the local revertive mode. In the global revertive mode, an LSR re-routed over a bypass tunnel because the downstream link became unavailable keeps using the bypass tunnel after the link recovers. This expects the headend router to set up a new LSP upon notification that a link became unavailable. In the local revertive mode, the LSR switches back to using the primary link after recovery.

The default for reversion is global.

Command Mode

MPLS RSVP Configuration

Command syntax

fast-reroute reversion (global | local)

default fast-reroute reversion

no fast-reroute reversion

Parameters

global - Global revertive mode.
local - Local revertive mode.

Examples

Set the fast-reroute reversion to local:

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

The default for reversion is global.

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

graceful-restart role

The graceful-restart role command enables a graceful-restart role for RSVP (helper or speaker) and enters the configuration mode for that role. Graceful restart is disabled by default, and requires hello messages to be enabled.

The no graceful-restart role and default graceful-restart role commands disable the feature.

The helper mode is enabled under the RSVP configuration mode, graceful-restart role helper.

The maximum accepted restart time value is configurable under the RSVP Graceful Restart helper configuration mode, timer restart maximum <t> seconds.

The maximum accepted recovery time value is configurable under the RSVP Graceful Restart helper configuration mode, timer recovery maximum <t> seconds.

The speaker mode is enabled under the RSVP configuration mode, graceful-restart role speaker.

The restart time value is configurable under the RSVP Graceful Restart speaker configuration mode, graceful-restart role speaker.

The recovery time value is configurable under the RSVP Graceful Restart speaker configuration mode. timer recovery <t> seconds.

Command Mode

MPLS RSVP Configuration Mode

Command Syntax

graceful-restart role (helper | speaker)

no graceful-restart role (helper | speaker)

default graceful-restart role(helper | speaker)

timer restart maximum <t> seconds- The maximum accepted restart time value is configurable under helper configuration mode.

default timer restart maximum

no timer restart maximum

timer recovery maximum <t> seconds - The maximum accepted recovery time value, configured under helper configuration mode.

default timer recovery maximum

no timer recovery maximum

timer restart <t> seconds - The restart time value is configurable under thespeaker configuration mode.

default timer restart

no timer restart

timer recovery <t> seconds - The recovery time value is configurable under the speaker configuration mode.

default timer recovery

no timer recovery

Parameters

helper - Enables graceful restart in the helper role (assists with RSVP neighbor restarts) and enters Graceful Restart Helper configuration mode.
speaker - Enables graceful restart in the speaker role (allows the local node to restart gracefully) and enters Graceful Restart Speaker configuration mode.

Example

The following commands enable graceful restart in the helper role and enter the configuration mode for that role:

switch(config)#mpls rsvp
switch(config-mpls-rsvp)#graceful-restart role helper
switch(config-mpls-rsvp-gr-helper)#

hello interval

The hello interval command sets the time between the hello packets. The no form of the command explicitly disables the Hello messages, while the default form of the command resets to the default setting of 10 seconds with a multiplier of 4.

Command Mode

MPLS RSVP Configuration

Command Syntax

hello interval<sec>multiplier <num>

no hello interval

default hello interval

Parameters

interval sec - The interval in units of seconds.
- multiplier num - The value that is multiplied by the interval value.

Examples

In this example, EOS sends hello messages to all known neighbors every 10 seconds. If the switch does not receive hello responses from a neighbor for 4*10=40 seconds, the switch loses communication and the neighbor resets.
```
switch(config-mpls-rsvp)# hello interval 10 multiplier 4
```
In this example, the default of 10 seconds with multiplier 4 resets.
```
switch(config-mpls-rsvp)# default hello interval
```
In this example, explicitly disable the Hello messages.
```
switch(config-mpls-rsvp)# no hello interval
```

hardware next-hop fast-failover

The hardware next-hop fast-failover command enables hardware-accelerated next-hop failover on the switch. This should be enabled in every case where FRR is desired, especially for sub-50ms in the case of link protection and sub-150ms in the case of node protection.

It is disabled by default. Bypass tunnels can still be created even without this knob and FRR will still work on the software side, but on the hardware this is necessary for fast convergence.

The no and default forms of the command disable hardware-accelerated next-hop failover and fast-reroute bypass tunnels.

Command Mode

Router General Configuration

Command Syntax

hardware next-hop fast-failover

no hardware next-hop fast-failover

default hardware next-hop fast-failover

Example

The following commands enable hardware-accelerated next-hop failover on the switch:

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

hello-redundancy

The hello-redundancy command is suggested for Hello Redundancy when used with LDP over RSVP. Both peers require the configuration.

The neighbor hello-redundancy command configures Hello Redundancy on all platforms under the LDP configuration mode. Hello Redundancy means if a Link Hello Adjacency is lost it will not drop the sessions right away, but will continue to maintain a Targeted Hello adjacency for up to the configured time. Then, if Link Hello adjacency is NOT restored within the duration, it will drop the Targeted Hello adjacency and the session associated with it. The timeout can be configured using the duration option of the command. An infinite value for the duration disables the timeout.

Note: This configuration may not be required because the targeted adjacency will be established automatically by both peers based on the RSVP tunnel configuration.

Command Mode

MPLS-LDP Configuration

Command Syntax

neighbor hello-redundancy [duration seconds]

default neighbor hello-redundancy

no neighbor hello-redundancy

Parameter

Examples

These commands enable Targeted Hello redundancy with a duration of 300 seconds.

switch(config-mpls-ldp)# neighbor hello-redundancy
switch(config-mpls-ldp)# neighbor hello-redundancy duration 300

Use either of the following commands to disable Hello Redundancy.

switch(config-mpls-ldp)# neighbor hello-redundancy none
switch(config-mpls-ldp)# default neighbor hello-redundancy

hitless-restart

The hitless-restart command enables RSVP hitless restart. Hitless restart allows RSVP agents to restart without interrupting data-plane traffic. When hitless restart is enabled, the switch observes a recovery period after RSVP restarts.The switch preserves existing installed RSVP states until they are refreshed by neighbors. If RSVP states have not been refreshed before the expiration of the recovery period, they are cleared. The recovery period is 90 seconds by default, but can be configured using the timer recovery command.Hitless restart is disabled by default.

The no hitless-restart and default hitless-restart commands disable hitless restart.

The recovery time value timer recovery <t> seconds is configurable under the hitless-restart mode. .

The maximum accepted recovery time value timer recovery maximum <t> seconds is configurable under the hitless-restart mode, .

Command Mode

MPLS RSVP Configuration

Command Syntax

hitless-restart

no hitless-restart

default hitless-restart

timer recovery maximum <t> seconds - The maximum accepted recovery time value, configured under hitless-restart configuration mode.

default timer recovery maximum

no timer recovery maximum

timer recovery <t> seconds - The recovery time value is configurable under the hitless-restart configuration mode.

default timer recovery

no timer recovery

Parameters

Example

The following command enables RSVP hitless restart:

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

hop (dynamic path)

The hop command adds a hop to the configuration-mode dynamic path. If entered without options, it is configured as a strict hop by default. A strict hop places the specified hop after the the previously specified hop. The before and after options can be used to insert the specified hop in relation to another hop in an existing path.

The no and default forms of the command remove

Command Mode

Traffic Engineering RSVP Explicit Path Configuration

Command Syntax

hop <IPv4_address> [ [exclude] | [loose] [ [before <IPv4_address> | after <IPv4_address>] ] ]

default hop <IPv4_address> - If no address is supplied then all hops are removed.

no hop [<IPv4_address>] - If no address is supplied then all hops are removed.

Parameters

exclude - Specifies that CSPF must not choose the specified address on the path.
loose - Defines the hop as a loose hop, which allows other hops to be filled by the CSPF procedure.
before - Specifies the hop before which this hop will be placed.
after - Specifies the hop after which this hop will be placed.

Example

The following example excludes 10.0.56.6 from being used as a hop.
```
switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.56.6 exclude
```
The following example configures 10.0.56.6 as the hop. Hop 10.0.45.5 uses the loose keyword, which allow other hops to be filled in before it. Hop 10.0.12.2 uses the before keyword to placed it before hop 10.0.23.3.
```
switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.23.3
switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.45.5 loose
switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.12.2 before 10.0.23.3
```

hop (explicit path)

The hop command adds a hop to the configuration-mode explicit path. If entered without options, the command places the specified hop in the order listed. The before and after options can be used to insert the specified hop in relation to another hop in an existing path.

Command Mode

Traffic Engineering RSVP Explicit Path Configuration

Command Syntax

hop <IPv4_address> [before IPv4_address | after <IPv4_address>]

default hop [ <IPv4_address>] - If no address is supplied then all hops are removed.

no hop [<IPv4_address>] - If no address is supplied then all hops are removed.

Parameters

before - Specifies the hop before which this hop will be placed.
after - Specifies the hop after which this hop will be placed.
no - Removes the specifed hop.

Example

The following commands create hop 10.0.12.2 and then places hop 10.0.34.4 after it.

switch(config-te-rsvp)# path MyPath explicit
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 following example places hop 10.0.23.3 before hop 10.0.34.4 and hop 10.0.45.5 is placed after hop 10.0.34.4.

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

label local-termination

The label local-termination command enables an egress LSR to advertise an IPv4 explicit-null label (Label 0) to its upstream router by using the explicit-null option.

The no label local-termination or default label local-termination or label local-termination implicit-null commands can be used to return the switch to the default state of advertising implicit-null labels (Label 3).

Note: When another label (e.g., VPN) is present, only switches that support multiple label termination can add an explicit-null label. These switches include the 7800R3, 7500R3 and 7280R3.

Command Mode

MPLS RSVP Configuration

Command Syntax

label local-termination (explicit-null | implicit-null)

no label local-termination

default label local-termination

Parameters

explicit-null - Advertises an explicit-null label to upstream RSVP router.
implicit-null - Advertises an implicit-null label. This is the default.

Example

The following command configures the switch to advertise an explicit null label to its upstream RSVP router:

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

igp shortcut

The igp shortcut command is used to specify whether a RSVP tunnel should participate in Interior Gateway Protocol (IGP) shortcuts.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

igp shortcut

default igp shortcut

no igp shortcut

Parameters

disabled - disables the igp shortcut command.

Example

The following example configures the tunnel named MyTunnel to participate in IGP shortcuts.

switch(config-te-rsvp-tunnel-MyTunnel)# igp shortcut

local-interface

The local-interface command specifies a local interface from which to derive the source IP address for RSVP-TE tunnels.

Command Mode

Traffic Engineering RSVP Configuration

Command Syntax

local-interface int_type int_num

no local-interface

default local-interface

Parameters

int_type Interface type for the local interface. Values include Ethernet, Fabric, Loopback , Management, Port-Channel, Recirc-Channel, Tunnel, Vlan, and Vxlan.
int_num Interface number for the local interface.

Example

The following command specifies loopback interface 0 as the local interface:


switch(config-te-rsvp)#local-interface Loopback 0
switch(config-te-rsvp)#

lsp no-path preservation timer

The preservation timer command in the Traffic-Engineering RSVP Configuration Mode configures a timer to control how long the switch maintains an original Label Switched Path (LSP) if a Make-Before-Break (MBB) attempt fails.

The [no | default] versions of the command removes the configuration from the running-config.

Command Mode

Traffic-Engineering RSVP Configuration

Command Syntax

lsp no-path preservation timer seconds seconds

no lsp no-path preservation timer

default lsp no-path preservation timer

Parameters

seconds seconds - Specify the time in seconds, 1 - 600, to preserve the old LSP instance after an MBB failure.

Example

Configure the Preservation Timer using the following commands to set the timer to 300 seconds:

switch(config)# router traffic-engineering
 switch(config-te)# rsvp
 switch(config-te-rsvp)# lsp no-path preservation timer 300 seconds
 switch(config-te-rsvp)#

lsp self-ping

The lsp self-ping command enables LSP self-ping (RFC 7746). When enabled, all new LSPs created by RSVP-TE LER tunnels will perform self-ping. LSP self-ping verifies end-to-end establishment of the LSP by sending a self-ping message through the LSP before sending regular traffic. When LSP self-ping is 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 head end. LSP self-ping is disabled by default.

The no and default forms of the command disable LSP self-ping.

Command Mode

Global Configuration

Command Syntax

lsp self-ping

default lsp self-ping

no lsp self-ping

Parameters

Example

The following command enables LSP self-ping:

switch(config-te-rsvp)#lsp self-ping
switch(config-te-rsvp)#

metric

The metric command configures a per RSVP tunnel metric to allow specific tunnels to a tunnel endpoint take precedence over other tunnels to the same tunnel endpoint when forming ECMP. The tunnel metric publishes to the tunnel RIB for BGP cost calculations.

The tunnel metric can also dynamically track the IGP SPF metric for the tunnel destination IP regardless of the changes in the Constrain-based Shortest Path First (CSPF) path to the destination.

Command Mode

Router Traffic Engineering RSVP Tunnel Configuration Mode

Command Syntax

metric ( igp | metric_value)

default metric

no metric

Parameters

metric - Specify a metric for the tunnel.
- igp - Specify to use the IPG SPF metric.
- metric_value - Specify a static metric value between 0 and 4294967295.

Example

Use the following commands to enter the Router Traffic Engineering RSVP Tunnel Configuration Mode, and add a static metric, 10 to the existing MyTunnel configuration:

switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)# tunnel MyTunnel
switch(config-te-rsvp-tunnel-MyTunnel)# metric 10
switch(config-te-rsvp-tunnel-MyTunnel)#

Use the following commands to enter the Router Traffic Engineering RSVP Tunnel Configuration Mode, and add the IGP SPF metric, igp, to the existing MyTunnel configuration:

switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)# tunnel MyTunnel
switch(config-te-rsvp-tunnel-MyTunnel)# metric igp
switch(config-te-rsvp-tunnel-MyTunnel)#

mpls rsvp

The mpls rsvp command places the switch in MPLS RSVP configuration mode.

Command Mode

Global Configuration

Command Syntax

mpls rsvp

default mpls rsvp - Will wipe the configuration in the mode and disable RSVP.

no mpls rsvp - Will wipe the configuration in the mode and disable RSVP.

Commands Available in MPLS RSVP Configuration Mode

authentication index
authentication sequence-number window
authentication type
fast-reroute bypass tunnel optimization interval
fast-reroute mode
fast-reroute reversion
graceful-restart role
hello interval
hitless-restart
ip access-group
ipv6 access-group
label local-termination
mtu signaling
neighbor authentication index
neighbor authentication type
p2mp
preemption method
refresh interval
refresh method
shutdown (MPLS RSVP)
srlg

Example

The following command places the switch in MPLS RSVP configuration mode:

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

mtu signaling

The mtu signaling command configures RSVP to enable MTU discovery. MTU signaling is disabled by default. The MTU is discovered with the AdSpec object in the Path message, which contains the minimum MTU seen in the path so-far, and is then reported back in the Resv message. If the config knob is not set on a transit node, then the MTU in the AdSpec is not updated on the node (essentially ignoring the node for MTU discovery). If it is not set on the ingress node, then MTU discovery is not done for any LSPs originating at that node.

The no mtu signaling, default mtu signaling, anddefault mtu signaling commands disable MTU signaling, preventing the updating of composed MTUs.

Command Mode

MPLS RSVP Configuration

Command Syntax

mtu signaling

no mtu signaling

default mtu signaling

Example

The following command enables MTU signaling on the switch:

switch(config-mpls-rsvp)#mtu signaling
switch(config-mpls-rsvp)#

neighbor authentication index

The neighbor authentication index command configures the MPLS RSVP cryptographic authentication password for outgoing messages to the specified neighbor.Per-neighbor authentication takes precedence over global authentication.

The no neighbor authentication index and default neighbor authentication index commands remove neighbor-specific authentication password configuration; the neighbor then inherits the global configuration.

Command Mode

MPLS RSVP Configuration

Command Syntax

neighbor neighbor_address authentication index index_num active

no neighbor neighbor_address authentication index index_num active

default neighbor neighbor_address authentication index index_num active

Parameters

neighbor_address - address of the MPLS RSVP neighbor.
index_num - index number chosen as the password for cryptographic authentication for messages sent to the specified neighbor.

Examples

The following commands enable cryptographic authentication for the neighbor at 172.16.0.0 and establishes index 755 as the password for outgoing messages to that neighbor:

switch(config)#mpls rsvp
switch(config-mpls-rsvp)# neighbor 172.16.0.0 authentication type md5
switch(config-mpls-rsvp)# neighbor 172.16.0.0 authentication index 755 active
switch(config-mpls-rsvp)#

neighbor authentication type

The neighbor authentication type command configures the MPLS RSVP cryptographic authentication type for the specified neighbor. Setting the type to md5 enables cryptographic authentication (RFC 2747) for MPLS RSVP messages sent to the specified neighbor.Setting the type to none disables authentication for the neighbor. Note that per-neighbor authentication takes precedence over global authentication.

The no neighbor authentication and default neighbor authentication commands remove neighbor-specific authentication type configuration; the neighbor then inherits global configuration.

Command Mode

MPLS RSVP Configuration

Command Syntax

neighbor neighbor_address authentication type (md5 | none)

no neighbor neighbor_address authentication type

default neighbor neighbor_address authentication type

Parameters

neighbor_address - address of the MPLS RSVP neighbor.
md5 - enables MPLS RSVP cryptographic authentication (RFC 2747) for the specified neighbor. A password for outgoing messages must also be configured using the neighbor authentication index command.
none - disables MPLS RSVP cryptographic authentication for messages sent to the specified neighbor.

Examples

The following commands enable cryptographic authentication for the neighbor at 172.16.0.0 and establishes index 755 as the password for outgoing messages to that neighbor:

switch(config)#mpls rsvp
switch(config-mpls-rsvp)# neighbor 172.16.0.0 authentication type md5
switch(config-mpls-rsvp)# neighbor 172.16.0.0 authentication index 755 active
switch(config-mpls-rsvp)#

The following commands disable cryptographic authentication for the neighbor at 172.16.0.0:

switch(config)#mpls rsvp
switch(config-mpls-rsvp)# neighbor 172.16.0.0 authentication type none
switch(config-mpls-rsvp)#

optimization interval

Periodic tunnel optimization can be configured globally or individually for a specific tunnel using the optimization interval command. This configuration is applied to all RSVP tunnels.

The optimization interval can also be configured on an individual tunnel by entering the command in tunnel sub-mode. The optimization interval configured in the tunnel sub-mode overrides the optimization interval configured globally.

Optimization can also be disabled on a specific tunnel or globally, which is the default.

Command Mode

Traffic Engineering RSVP Configuration

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

optimization interval <numerical value> seconds

default optimization

no optimization

Parameters

numerical value - enter the optimization interval in seconds.

Example

The following command configures all RSVP tunnels to be re-optimized every 3600 seconds:
```
switch(config-te-rsvp)#optimization interval 3600 seconds
```
The following commands configured an optimization interval of 3600 seconds on the tunnel named myTunnel. This tunnel-specific configuration overrides the global optimization configuration.
```
switch(config-te-rsvp)#tunnel myTunnel
switch(config-te-rsvp-tunnel-myTunnel)#optimization interval 3600 seconds
```

The following commands configure an optimization interval of 3600 seconds for all tunnels but disable automatic optimization on the tunnel named myTunnel:

switch(config-te-rsvp)#optimization interval 3600 seconds
switch(config-te-rsvp)#tunnel myTunnel
switch(config-te-rsvp-tunnel-myTunnel)#optimization disabled
switch(config-te-rsvp-tunnel-myTunnel)#

p2mp

From the config-mpls-rsvp configuration mode, the p2mp command places the switch in mpls-rsvp-p2mp configuration mode.

Command Mode

MPLS-RSVP Configuration Mode

Command Syntax

p2mp

default p2mp

no p2mp

Parameter

p2mp - Enables RSVP P2MP.

no p2mp - Disables RSVP P2MP.

default p2mp - Disables RSVP P2MP.

Examples

RSVP P2MP signaling functionality is enabled using the p2mp command.

switch# config
switch(config)# mpls rsvp
switch(config-mpls-rsvp)# no shutdown
switch(config-mpls-rsvp)# p2mp
switch(config-mpls-rsvp-p2mp)#

P2MP functionality is disabled by issuing the disabled command in the p2mp submode. This allows disabling RSVP P2MP without wiping any active configuration in the p2mp sub-mode.
```
switch(config-mpls-rsvp-p2mp)# disabled
switch(config-mpls-rsvp-p2mp)#
```
The no p2mp will both remove the p2mp sub-mode configuration and also disable RSVP P2MP.

switch(config-mpls-rsvp)# no p2mp
switch(config-mpls-rsvp)#

The exit command will leave the sub-mode but will retain the configuration in it.
```
switch(config-mpls-rsvp-p2mp)# exit
switch(config-mpls-rsvp)#
```

path (path specification)

The path command in Traffic Engineering RSVP Tunnel P2P configuration mode specifies the configuration mode for the path. If the path does not already exist, it creates it. Path configuration modes are group-change modes: changes take effect only when exiting the mode. To exit the mode without saving changes, use the abort command.

The no path and default path commands delete the specified path.

Note: A path of a specific name can only be explicit or dynamic, and once a path is created its type cannot be changed. To change a named path from explicit to dynamic or vice versa, delete the path by using the no form of the command and create it again.

Command Mode

Traffic Engineering RSVP Configuration

Command Syntax

path spec_name (dynamic | explicit)

no path spec_name

default path spec_name

Parameters

spec_name - Specification name for the path.
dynamic - Establishes a dynamic path.
explicit - Establishes an explicit path.

Example

The following commands creates an explicit path named spec1 for the tunnel tunnel7 and enters the configuration mode for that path.

switch(config-te-rsvp)#tunnel tunnel7 
switch(config-te-rsvp-tunnel-tunnel7)# path spec1

path (RSVP tunnel)

The path command in Traffic Engineering RSVP Tunnel configuration mode specifies a primary or secondary path along which the LSPs are established for the configuration-mode RSVP tunnel.

The no and default forms of the command remove the named path.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

path spec_name (secondary pre-signaled)

no path spec_name (secondary)

default path spec_name(secondary)

Example

The following commands create a path named path6 for the tunnel named tunnel13:

switch(config-te-rsvp)#tunnel tunnel13
switch(config-te-rsvp-tunnel-tunnel13)#path path6
switch(config-te-rsvp-tunnel-tunnel13)#

The following commands create a pre-signaled secondary path named path7 for the tunnel named tunnel13:

switch(config-te-rsvp)#tunnel tunnel13
switch(config-te-rsvp-tunnel-tunnel13)#path path7 secondary pre-signaled
switch(config-te-rsvp-tunnel-tunnel13)#

ping mpls rsvp session

The ping mpls rsvp session command allows the user to check if the remote endpoint of an RSVP session is reachable through the LSP. Running ping on an RSVP LSP creates an LSP Ping Request packet with the label programmed by RSVP and that packet will follow the MPLS path until it reaches the end of the tunnel. If the node that receives this Request is the intended destination, it replies with an RSVP Ping Reply through normal IP routing. When the source receives the Reply it indicates that there are no apparent data plane failures and that the endpoint of that LSP is reachable.

Command Mode

Privileged EXEC mode

Command Syntax

ping mpls rsvp session ([id num [lsp lspId ] | name word)] [pad-reply] [repeat <num_repeat> ] [ source (IPv4_address | IPv6_address) ] [ standard (arista|ietf) ] | [ tos (<tos_value> | dscp <dscp_value>) ] [ traffic-class<traffic_class> ] [ interval <interval_value> ]

Parameters

id - Specifies the session by ID
- num - RSVP session ID.
  - lsp - Specifies LSP. This parameter can only be specified with the id parameter.
  - pad-reply - Indicates that the reply should copy the pad TLV.
  - repeat - Specifies repeat count.
  - source - Specifies source address.
  - standard - Sets the standard to comply with.
  - tos - Specifies ToS value.
  - traffic-class - Specifies MPLS traffic class field.
  - interval - Specify interval between requests
  - size - Specify packet size in bytes
name - Specifies session by name.
- word - RSVP session name.
  - pad-reply - Indicates that the reply should copy the pad TLV.
  - repeat - Specifies repeat count.
  - source - Specifies source address.
  - standard - Sets the standard to comply with.
  - tos - Specifies ToS value.
  - traffic-class - Specifies MPLS traffic class field.
  - interval - Specify interval between requests
  - size - Specify packet size in bytes

Examples

In the following example, the ping utility checks if the remote endpoint of an RSVP session is reachable through the LSP.

switch# ping mpls rsvp session id 1 lsp 1 repeat 3
LSP ping to RSVP session #1 LSP #1
   timeout is 5000ms, interval is 1000ms
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=1, time=53.294ms, success: egress ok
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=2, time=75.329ms, success: egress ok
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=3, time=85.574ms, success: egress ok

--- RSVP target fec 0.4.4.4 : lspping statistics ---
Via 10.0.12.2, Ethernet1, label 100000
   3 packets transmitted, 3 received, 0% packet loss, time 2272ms
   3 received from 10.0.34.4, rtt min/max/avg 53.294/85.574/71.399 ms

For the ping mpls rsvp session command, the argument lsp is optional. If unspecified, the utility pings all LSPs within that session.

switch# ping mpls rsvp session id 1 repeat 2
LSP ping to RSVP session #1
   timeout is 5000ms, interval is 1000ms
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=1, time=60.28ms, success: egress ok
LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   Reply from 10.0.34.4: seq=1, time=81.701ms, success: egress ok
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=2, time=52.807ms, success: egress ok
LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   Reply from 10.0.34.4: seq=2, time=62.814ms, success: egress ok

--- RSVP target fec 0.4.4.4 : lspping statistics ---
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   2 packets transmitted, 2 received, 0% packet loss, time 1262ms
   2 received from 10.0.34.4, rtt min/max/avg 52.807/60.280/56.544 ms

LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   2 packets transmitted, 2 received, 0% packet loss, time 1262ms
   2 received from 10.0.34.4, rtt min/max/avg 62.814/81.701/72.257 ms

In the following example, the session is specified by name and the utility pings all the LSPs within that session.

switch# ping mpls rsvp session name Session1to4 repeat 2
LSP ping to session Session1to4
   timeout is 5000ms, interval is 1000ms
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=1, time=63.314ms, success: egress ok
LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   Reply from 10.0.34.4: seq=1, time=75.639ms, success: egress ok
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=2, time=60.875ms, success: egress ok
LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   Reply from 10.0.34.4: seq=2, time=77.135ms, success: egress ok

--- RSVP target fec 0.4.4.4 : lspping statistics ---
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   2 packets transmitted, 2 received, 0% packet loss, time 1262ms
   2 received from 10.0.34.4, rtt min/max/avg 60.875/63.314/62.094 ms

LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   2 packets transmitted, 2 received, 0% packet loss, time 1262ms
   2 received from 10.0.34.4, rtt min/max/avg 75.639/77.135/76.387 ms

preemption method

The preemption method command enables deferred failure of RSVP-TE LSPs on link oversubscription. Hard preemption will result in the LSP being torn down without any delay. Use a preemption timer value to configure a delay, before tearing down an LSP due to losing its bandwidth reservation, on a transit router to support LSPs signaled with soft preemption enabled by the headend (RFC 5712).

The default preemption method is soft preemption with a timer value of 30 seconds.

Command Mode

MPLS RSVP Configuration

Command Syntax

preemption method (hard | soft ) [timer <seconds>]

no preemption method

default preemption method

Parameters

hard - Hard preemption. The timer value is ignored.
soft - Soft preemption.
- timer - Time limit for LSP teardown. Only applies to soft-preemption. If the timer keyword is not used the default timer of 30 seconds is used.
  - <seconds> 1-65535 - Timer value in units of seconds.

Examples

In this example, the preemption method is soft preemption with a timer value of 10 seconds.
```
switch(config-mpls-rsvp)# preemption method soft timer 10
```
Setting the preemption method to hard preemption results in a timer value of 0 seconds and disables the feature.
```
switch(config-mpls-rsvp)# preemption method hard
```

priority

The priority command configures the tunnel priority. The setup keyword is used to set the priority of the setup. The hold keyword sets the priority of the tunnel hold. The priority value range is 0 (highest priority) to 7 (lowest priority). The setup priority can be used without a hold priority, but a hold priority requires a setup priority to be set.

When both setup and hold priorities are configured, the hold value should be a higher priority (lower value) than the setup priority to avoid cycles where an LSP is continuously established and immediately preempted.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

priority 0-7

no priority - Default setting and will inherit from profile. The default profile values are: priority setup 7 hold 0

default priority

Parameters

setup - requires a priority value 0-7
hold - requires a priority value 0-7

Example

The following example configures a setup priority 5 and a hold priority 3. The hold priority is a lower value, meaning it has a higher priority.

switch(config-te-rsvp-tunnel-myTunnel)# priority setup 5 hold 3

refresh interval

The refresh interval command configures the interval at which MPLS RSVP Path and Resv messages are sent to refresh the state. State is refreshed at a randomly selected interval between 0.5 and 1.5 times the configured value. The default value is 30 seconds.

The no and default versions of the command reset the refresh interval to 30 seconds.

Command Mode

MPLS RSVP Configuration

Command Syntax

refresh interval seconds

no refresh interval

default refresh interval

Parameters

seconds - Refresh interval in seconds. The actual refresh interval is randomly generated in the range of 0.5 to 1.5 times this value. Values range from 1 to 65535. Default value is 30.

Example

The following command configures an interval of 100 seconds at which MPLS RSVP Path and Resv messages are sent to refresh the state:

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

refresh method

Using the Srefresh method command with the bundled keyword enables the Refresh Overhead Reduction that supports the sending of message IDs and refreshing state with refresh messages.

Command Mode

MPLS RSVP Configuration

Command Syntax

Srefresh method [bundled | explicit ]

no Srefresh method - More tokens allowed but ignored.

default Srefresh method - More tokens allowed but ignored.

Parameters

bundled - Refresh states using message identifiers lists. This is the default setting.
explicit - Send each refresh message individually.

Examples

Use the bundled keyword to enable the Refresh Overhead Reduction.
```
switch(config-mpls-rsvp)# refresh method bundled
```
To turn off refresh overhead reduction, use the explicit keyword.
```
switch(config-mpls-rsvp)# refresh method explicit
```

refresh rsvp tunnel optimization

When periodic tunnel optimization is not configured, tunnels will not re-optimize automatically, but they can be optimized on demand by using the refresh rsvp tunnel optimization command.

Command Mode

Privileged Exec

Command Syntax

refresh rsvp tunnel optimization (all | name tunnel_name [avoid ecmp hop ecmp_hops] )

Parameters

all Optimizes all tunnels.
name tunnel_name Optimizes the named tunnel.
avoid ecmp hop ecmp_hops The 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. The variable ecmp_hops is a list of IP(v4) addresses.

Example

The following command optimizes the tunnel named myTunnel:

switch# refresh rsvp tunnel optimization name myTunnel
switch#

The following command optimizes the tunnel named myTunnel and recomputes the tunnel path to avoid 198.51.100.17:
```
switch# refresh rsvp tunnel optimization name myTunnel avoid ecmp hop 198.51.100.17
switch#
```
The following command performs optimization on all tunnels:
```
switch# refresh rsvp tunnel optimization all
switch#
```

router traffic-engineering – not an RSVP command

The router traffic-engineeing command places the switch in Traffic Engineering configuration mode.

Command Mode

Global Configuration

Command Syntax

router traffic-engineering

Parameters

Example

The following command places the switch in Traffic Engineering configuration mode:

switch(config)# router traffic-engineering
switch(config-te)#

rsvp

The rsvp command places the switch in Traffic Engineering RSVP configuration mode.

Note: Use caution when using the no and default rsvp versions of this command. The whole mode will be removed. Use with care.

Command Mode

Traffic Engineering Configuration

Command Syntax

rsvp

default rsvp

no rsvp

Commands Available in RSVP Configuration Mode

cspf ecmp tie-break
local-interface Loopback
lsp self-ping
optimization interval <NumberofSeconds> seconds
path <PathName> dynamic
path <PathName> explicit
show active
tunnel <TunnelName>

Example

The following commands place the switch in Traffic Engineering RSVP configuration mode:

switch(config)#router traffic-engineering
switch(config-te)#rsvp
switch(config-te-rsvp)#

rsvp bypass administrative-group

The rsvp bypass administrative-group command specifies administrative groups that must be included in, or excluded from, the links used for CSPF path computation. The restrictions specified for an interface apply to all LSPs that bypass that interface. This includes both link and node protection. A single command can incorporate ranges for include any, include all, and exclude.

The no rsvp bypass administrative-group and default rsvp bypass administrative-group commands remove bypass restrictions for the interface.

Command Mode

Interface Configuration

Command Syntax

no rsvp bypass administrative-group

default rsvp bypass administrative-group

Parameters

exclude - Excludes the specified administrative group identified by either a group name or number.

include all - Includes the specified administrative groups identified by either a group name or number.

include any - Includes any of the specifiedrange of administrative groups identified by either a group name or number.

Example

The following commands specify that links used for CSPF path computation on Ethernet interface 1/1 must include all administrative groups in the range from 5 to 16 and any group from the range from 8 to 75, and must exclude groups 82, 93, 115 to 168, and 255:

switch(config)#interface ethernet 1/1
switch(config-if-Et1/1)#rsvp bypass administrative-group include all 5-16 include any 8-75 exclude 82,93,115-168,255
switch(config-if-Et1/1)#

show mpls rsvp

Use the show mpls rsvp to display the overall state of the RSVP.

Command Mode

EXEC

Command Syntax

Parameters

bandwidth - Displays RSVP bandwidth information.
counters - Displays RSVP message counters.
ip - Displays details related to IPv4 ACLs.
ipv6 - Displays details related to IPv6 ACLs.
neighbor - Displays RSVP neighbor information.
session - Displays RSVP session information.

Example

The following example display the overall state of the RSVP.

switch> show mpls rsvp   	 
Administrative state: enabled
Operational state: up
Refresh interval: 30 seconds
Refresh reduction: enabled
Hello messages: enabled
   Hello interval: 10 seconds
   Hello multiplier: 4
Fast Re-Route: disabled
   Mode: none
   Hierarchical FECs: enabled
Cryptographic authentication: disabled
MTU signaling: disabled
Number of sessions: 1
   Ingress/Transit/Egress: 0/1/0
Number of LSPs: 1
   Operational: 1
   Ingress/Transit/Egress: 0/1/0
   Currently using bypass tunnels: 0
Number of bypass tunnels: 0
Number of neighbors: 2
Number of interfaces: 2

show mpls rsvp counters

Use the show mpls rsvp counters command to display RSVP message counters, per interface. The address family filter has to be specified first, if it is specified. Then the interface filter is specified, if it is specified. This cannot be done in the opposite order.

Command Mode

EXEC

Command Syntax

Parameters

Note: The available interface filters are dependent on the platform support. Available filters may be different than the following examples.

interface Filter by interface.
- Ethernet - Hardware Ethernet interface.
- Fabric - Fabric interfaces.
- Loopback - Hardware interface used for looping packets.
- Management - Management interface.
- Port-Channel - Lag interface.
- Switch - Switch interface.
- Tunnel - Tunnel interface.
- Vlan - Logical interface into a VLAN.
- Vxlan - VXLAN tunnel interface.
ipv4 - Filter by IPv4.
ipv6 - Filter by IPv6.

Example

The following example displays RSVP message counters for each interface.

switch> show mpls rsvp counters
Received Messages:

Interface  Path  PathTear  PathErr  Resv  ResvTear  ResvErr  Srefresh  Other  Errors  
---------  ----  --------  -------  ----  --------  -------  --------  -----  ------  
Ethernet1  5     0         0        0     0         0        8         51     1  	 
Ethernet2  0     0         0        14    0         0        0         0      0  	 

Sent Messages:

Interface  Path  PathTear  PathErr  Resv  ResvTear  ResvErr  Srefresh  Other  Errors  
---------  ----  --------  -------  ----  --------  -------  --------  -----  ------  
Ethernet1  0     0         0        4     0         0        9         49     0  	 
Ethernet2  13    0         0        0     0         0        0         4      0

show mpls rsvp neighbor

Use the show mpls rsvp neighbor command to display information about all RSVP neighbors, or for a specific neighbor.

Command Mode

EXEC

Command Syntax

show mpls rsvp neighbor [A.B.C.D | A:B:C:D:E:F:G:H | summary]

Parameters

A.B.C.D - IP (v4 or v6) address of neighbor.
A:B:C:D:E:F:G:H - IP (v4 or v6) address of neighbor.
summary - Displays summarized information.

Examples

Use the show mpls rsvp neighbor command to display information about all RSVP neighbors.

switch> show mpls rsvp neighbor
Neighbor 10.0.1.1
   Upstream for
      Session #1 LSP #1
   Downstream for
   Neighbor uptime: 00:01:24
   Authentication type: disabled
   Last hello received: 1 seconds ago
   Last hello sent: 1 seconds ago
   Bypass tunnel: not requested
Neighbor 10.0.2.2
   Upstream for
   Downstream for
  	Session #1 LSP #1
   Neighbor uptime: 00:01:24
   Authentication type: disabled
   Last hello received: -
   Last hello sent: 31 seconds ago
   Bypass tunnel: not requested

Use the show mpls rsvp neighbor summary command to display summarized information.

switch> show mpls rsvp neighbor summary
Neighbor             Role       Sessions LSPs
==================== ========== ======== ========
10.0.1.1             Upstream   1    	1
10.0.2.2             Downstream 1    	1

show mpls rsvp session

The show mpls rsvp session command displays RSVP session information.

Command Mode

EXEC

Command Syntax

show mpls rsvp session ( <filters> | all ) [ detail ]

Parameter

With <filters> being a list of one or more of: ( destination <ipv4> | id <id> ) ( name <name> | lsp <lsp> | bypass ) ( role <role> ) ( state <state> )

all - Clears all RSVP sessions.

bypass - Filter for bypass LSPs.

destination - Filter by destination address.

id - Filter by Session ID.

lsp- Filter by LSP number.

name - Filter by session name.

role - Filter by router role.

state - Filter by LSP state.

detail - Can be specified after all or any filters. When the command is run with detail the names of the sessions which are cleared are displayed, not just the count.

Examples

The following command displays RSVP session information:

switch>show mpls rsvp session
Session #1
   Destination address: 4.4.4.4
   Tunnel ID: 0
   Extended Tunnel ID: 1.1.1.1
   Role: transit
  	LSP #1
        State: up
        Type: primary
        Source address: 1.1.1.1
        LSP ID: 1
        LSP uptime: 00:02:38
        Session name: Session1
        Local label: 100000
        Downstream label: 100000
        Upstream neighbor: 10.0.1.1
           Last refresh received: 17 seconds ago
           Last refresh sent: 10 seconds ago
        Downstream neighbor: 10.0.2.2
           Last refresh received: 7 seconds ago
           Last refresh sent: 9 seconds ago
        Bypass tunnel: not requested
switch>

The following command displays detailed RSVP session information:

switch>show mpls rsvp session detail
Session #1
   Destination address: 4.4.4.4
   Tunnel ID: 0
   Extended Tunnel ID: 1.1.1.1
   Role: transit
   LSP #1
        State: up
        [...]
        MTU Signaling: enabled
           Received Path MTU: 1800 bytes
           Sent Path MTU: 1500 bytes
  [...]
switch>

The following command displays history information for RSVP sessions and LSPs:

switch>show mpls rsvp session history
Session #0, Session1
Tue 2024-06-04 17:25:33.708 Session created
Tue 2024-06-04 17:25:33.708 LSP #2 added
LSP #2
Tue 2024-06-04 17:25:33.714 State change: down (path: received-only, resv: down)
Tue 2024-06-04 17:25:33.721 Bandwidth state change: pending on Ethernet2
Tue 2024-06-04 17:25:33.721 State change: path-only (path: up, resv: down)
Tue 2024-06-04 17:25:33.767 State change: path-only (path: up, resv: received-only)
Tue 2024-06-04 17:25:33.776 Bandwidth state change: reserved on Ethernet2
Tue 2024-06-04 17:25:33.777 State change: up
Tue 2024-06-04 17:25:33.802 FRR bypass (link): available, via 10.0.25.5
switch>

The following command displays a summary of RSVP session information:

switch>show mpls rsvp session summary
Session  Destination                              LSP      Name               Role    Bypass State
======== ======================================== ======== ================== ======= ====== =========
1        4.4.4.4                                  1        Session1           transit n/req  up
switch>

show rib system-tunneling-ldp-rib route ip

The show rib system-tunneling-ldp-rib route ip command shows RSVP tunnel next hop resolutions for LDP.

Command Mode

EXEC

Command Syntax

show rib system-tunneling-ldp-rib route ip

Examples

This command ccommand shows RSVP tunnel next hop resolutions for LDP.

switch# show rib system-tunneling-ldp-rib route ip
VRF: default
Codes: I L1 - IS-IS level 1, I L2 - IS-IS level 2
Gateway of last resort is not set
 I L2     5.5.5.5/32 [115/20] via 5.5.5.5/32, RSVP LER tunnel index 1
                                 via 10.0.25.5, Ethernet4, label imp-null(3)
                              via 5.5.5.5/32, RSVP LER tunnel index 2
                                 via 10.0.23.3, Ethernet2, label 116384
 I L2     6.6.6.6/32 [115/30] via 5.5.5.5/32, RSVP LER tunnel index 1
                                 via 10.0.25.5, Ethernet4, label imp-null(3)
                              via 5.5.5.5/32, RSVP LER tunnel index 2
                                 via 10.0.23.3, Ethernet2, label 116384
 I L2     10.0.56.0/24 [115/20] via 5.5.5.5/32, RSVP LER tunnel index 1
                                   via 10.0.25.5, Ethernet4, label imp-null(3)
                                via 5.5.5.5/32, RSVP LER tunnel index 2
                                   via 10.0.23.3, Ethernet2, label 116384

show traffic-engineering cspf path

The show traffic-engineering cspf path command displays all the paths counted by CSPF.

Command Mode

EXEC

Command Syntax

show traffic-engineering cspf path [destination-IP <IP address>] [detail]

show traffic-engineering cspf path ( <ipv4> | <path-id> | tunnel-name <name> ) [ detail ] - A path or tunnel name can be specified.

show traffic-engineering cspf path p2mp ( <path-id> | tunnel-name <name> ) [ detail ] - A P2MP version of the command is also available.

show traffic-engineering cspf path <ipv4> links - Displays the link attributes of the links on all the CSPF paths with a given destination IP address.

Parameters

A.B.C.D - CSPF path to this destination IP address.

detail - Shows detailed path information.

links

p2mp

tunnel-name

Example

An example of the output of the show traffic-engineering cspf path command.

switch> show traffic-engineering cspf path
Destination  Path ID  Constraint                                     Path
10.2.2.2     0        bandwidth 150.00 Mbps                          10.0.2.2
                      setup priority 4                               10.0.3.2
                      share bandwidth with path 10.3.3.3 ID 2
                      share bandwidth with path 10.4.4.4 ID 0
10.3.3.3     2        bandwidth 150.00 Mbps                          10.0.4.2
                      setup priority 4                               10.0.5.2
                      share bandwidth with path 10.2.2.2 ID 0
                      share bandwidth with path 10.4.4.4 ID 0
10.4.4.4     0        bandwidth 150.00 Mbps                          10.0.6.2
                      setup priority 4                               10.0.7.2
                      share bandwidth with path 10.2.2.2 ID 0
                      share bandwidth with path 10.3.3.3 ID 2

An example of the output of the show traffic-engineering cspf path detail command.

switch> show traffic-engineering cspf path detail
Destination: 10.2.2.2
  Path ID: 0
   Path Constraint: bandwidth 150.00 Mbps
                    setup priority 4
                    share bandwidth with path 10.3.3.3 ID 2
                    share bandwidth with path 10.4.4.4 ID 0
      Request Sequence number: 1
      Response Sequence number: 1
      Number of times path updated: 3
      Last updated: 0:03:07 ago
      Reoptimize: On request
      Path:    Ingress IP       TE router ID
            ---------------- ------------------
               10.0.2.2         10.5.5.5
               10.0.3.2         10.2.2.2
Destination: 10.3.3.3
  Path ID: 2
   Path Constraint: bandwidth 150.00 Mbps
                    setup priority 4
                    share bandwidth with path 10.2.2.2 ID 0
                    share bandwidth with path 10.4.4.4 ID 0
      Request Sequence number: 1
      Response Sequence number: 1
      Number of times path updated: 3
      Last updated: 0:03:07 ago
      Reoptimize: On request
      Path:    Ingress IP       TE router ID
            ---------------- ------------------
               10.0.4.2         10.6.6.6
               10.0.5.2         10.3.3.3
Destination: 10.4.4.4
  Path ID: 0
   Path Constraint: bandwidth 150.00 Mbps
                    setup priority 4
                    share bandwidth with path 10.2.2.2 ID 0
                    share bandwidth with path 10.3.3.3 ID 2
      Request Sequence number: 1
      Response Sequence number: 1
      Number of times path updated: 3
      Last updated: 0:03:07 ago
      Reoptimize: On request
      Path:    Ingress IP       TE router ID
            ---------------- ------------------
               10.0.6.2         10.7.7.7
               10.0.7.2         10.4.4.4

show traffic-engineering database

Use the show traffic-engineering database to display the topology used for CSPF computations. Starting from EOS Release 4.23.1F, the SRLG group details of a neighbor are shown if it is advertised.

Command Mode

EXEC

Command Syntax

show traffic-engineering database

Special Considerations

Beginning with EOS Release 4.23.1F, the SRLG group details of a neighbor are shown if it is advertised.
Beginning with EOS Release 4.24.2F, information for the OSPFv2 topology is displayed if configured.

Example

switch# show traffic-engineering database

TE Router-ID: 1.0.0.2
  Source: IS-IS Level-1 IPv4 Topology Database
    IS-IS System-ID: 1111.1111.1001
      Number of Links: 2
        Network type: P2P 
          Neighbor: 1111.1111.1002
		 Administrative group (Color): 0x123a
            TE Metric: 30
            IPv4 Interface Addresses:
              20.20.20.1
              192.168.20.1
            IPv4 Neighbor Addresses:
              20.20.20.2
              192.168.20.2
            Maximum link BW: 25.00 Gbps
            Maximum reservable link BW: 10.00 Mbps
            Unreserved BW:
              TE class 0: 9.00 Mbps     TE class 1: 9.00 Mbps
              TE class 2: 8.5.00 Mbps   TE class 3: 8.00 Mbps
              TE class 4: 7.00 Mbps     TE class 5: 7.50 Mbps
              TE class 6: 6.00 Mbps     TE class 7: 6.00 Mbps                                                                                        
        Network Type: LAN  
          Neighbor: 1111.1111.1003.02
            TE Metric: 30    
        	Administrative Group: 0x12     
            IPv4 Local Addresses:
              30.30.30.1                                                                                                      
            Maximum Link BW: 10.00 Gbps                                                                                       
            Maximum Reservable Link BW: 10.50 Gbps                                                                             
            Unreserved BW:                                                                                                     
              TE-Class 0: 8.50 Gbps       TE-Class 1: 8.70 Gbps                                                               
              TE-Class 2: 7.50 Gbps       TE-Class 3: 7.25 Gbps                                                               
              TE-Class 4: 6.50 Gbps       TE-Class 5: 7.30 Gbps                                                               
              TE-Class 6: 3.50 Gbps       TE-Class 7: 7.20 Gbps
  Source: IS-IS Level-2 IPv4 Topology Database  
    IS-IS System-ID: 1111.1111.1003
      Number of Links: 1  
        Network Type: LAN
         Neighbor: 1111.1111.1003.16
           IPv4 Local Addresses:
             40.40.40.1
            Maximum link BW: 10.00 Gbps
            Maximum reservable link BW: 5.00 Gbps
            Unreserved BW:
              TE class 0: 4.00 Gbps     TE class 1: 4.00 Gbps
              TE class 2: 4.00 Gbps     TE class 3: 4.00 Gbps
              TE class 4: 3.00 Gbps     TE class 5: 3.00 Gbps
              TE class 6: 3.00 Gbps     TE class 7: 3.00 Gbps
  Source: OSPFv2 Instance ID 33 Area-ID 0.0.0.0 Topology Database
    OSPFv2 Router-ID: 1.2.3.4
      Number of Links: 2
        Network type: P2P
          Neighbor: 3.4.5.6
            Administrative group (Color): 0x123a
            TE metric: 30
            IPv4 Interface Addresses:
              20.20.20.1
              192.168.20.1
            IPv4 Neighbor Addresses:
              20.20.20.2
              192.168.20.1
            Maximum link BW: 25.00 Gbps
            Maximum reservable link BW: 10.00 Mbps
            Unreserved BW:
              TE class 0: 9.00 Mbps    TE class 1: 9.00 Mbps
              TE class 2: 8.50 Mbps    TE class 3: 8.00 Mbps
              TE class 4: 7.00 Mbps    TE class 5: 7.50 Mbps
              TE class 6: 6.00 Mbps    TE class 7: 6.00 Mbps
        Network type: LAN
          Neighbor: 2.3.4.5
            Administrative group (Color): 0x12
            TE metric: 30
            IPv4 Interface Addresses:
              30.30.30.1
            IPv4 Neighbor Addresses:
              0.0.0.0
            Maximum link BW: 10.00 Gbps
            Maximum reservable link BW: 10.5 Gbps
            Unreserved BW:
              TE class 0: 8.50 Gbps    TE class 1: 8.70 Gbps
              TE class 2: 7.50 Gbps    TE class 3: 7.25 Gbps
              TE class 4: 6.50 Gbps    TE class 5: 7.30 Gbps
              TE class 6: 3.50 Gbps    TE class 7: 7.20 Gbps                                                                                         
TE Router-ID: 1.0.0.3
  Source: IS-IS Level-1 IPv4 Topology Database
    IS-IS System-ID: 1111.1111.1004
      Number of Links: 2
        Network type: P2P
          Neighbor: 1111.1111.1002
          IPv4 Interface Addresses:
              1.0.5.1
            IPv4 Neighbor Addresses:
              1.0.5.2
            Maximum link BW: 50.00 Gbps
            Maximum reservable link BW: 10.00 Gbps
            Unreserved BW:
              TE class 0: 8.00 Gbps     TE class 1: 8.00 Gbps
              TE class 2: 8.00 Gbps     TE class 3: 8.00 Gbps
              TE class 4: 7.00 Gbps     TE class 5: 7.00 Gbps
              TE class 6: 7.00 Gbps     TE class 7: 7.00 Gbps
            Shared Risk Link Group:
              Group: 100
              Group: green-link (150)

show traffic-engineering rsvp tunnel detail

The show traffic-engineering rsvp tunnel detail command shows RSVP tunnel detail including LDP tunneling eligibility.

Command Mode

EXEC

Command Syntax

show traffic-engineering rsvp tunnel detail

Parameters

Examples

The show traffic-engineering rsvp tunnel detail command shows RSVP tunnel detail including LDP tunneling eligibility.

switch>show traffic-engineering rsvp tunnel detail
Tunnel tunnel2to5
   Source: 2.2.2.2
   Destination: 5.5.5.5
   State: up
   Bandwidth: 0.0 bps, mode explicit
      Setup priority: 7
      Hold priority: 0
   MTU signaling: disabled
   Periodic optimization: disabled
   Session #1
   Tunnel index: 1
   LSPs: 1
   LDP tunneling: enabled
   IGP shortcut: disabled
   Active path: primary
   Primary path: path2to5
      State: up, in use
      Path (explicit):
         10.0.25.5
Tunnel tunnel2to5via3
   Source: 2.2.2.2
   Destination: 5.5.5.5
   State: up
   Bandwidth: 0.0 bps, mode explicit
      Setup priority: 7
      Hold priority: 0
   MTU signaling: disabled
   Periodic optimization: disabled
   Session #2
   Tunnel index: 2
   LSPs: 1
   LDP tunneling: enabled
   IGP shortcut: disabled
   Active path: primary
   Primary path: path2to5via3
      State: up, in use
      Path (explicit):
         10.0.23.3
         10.0.35.5

show traffic-engineering rsvp tunnel history

Display the history of a RSVP tunnel.For information about the detail version of this commend, refer to show traffic-engineering rsvp tunnel detail.

Command Mode

EXEC

Command Syntax

show traffic-engineering rsvp tunnel history

Parameters

Example

The following example displays the history of a RSVP tunnel named TestTunnel.

switch> show traffic-engineering rsvp tunnel history
Tunnel TestTunnel
Mon 2020-07-13 07:04:44 CSPF query on primary path
Mon 2020-07-13 07:04:44 State change: down
Mon 2020-07-13 07:04:44 LSP #1 added
Mon 2020-07-13 07:04:44 CSPF reply for primary path, path found
Mon 2020-07-13 07:04:44 LSP #2 added
Mon 2020-07-13 07:04:46 State change: up using primary path
LSP #1
Mon 2020-07-13 07:04:44 LSP created
Mon 2020-07-13 07:04:44 State change: establishing
Mon 2020-07-13 07:04:46 State change: up
LSP #2
Mon 2020-07-13 07:04:44 LSP created
Mon 2020-07-13 07:04:44 State change: establishing
Mon 2020-07-13 07:04:47 State change: up

show traffic-engineering rsvp tunnel lsp

Display RSVP tunnel LSPs using the show traffic-engineering rsvp tunnel lsp command.

Command Mode

EXEC

Command Syntax

show traffic-engineering rsvp tunnel lsp

Parameters

Example

The following example displays RSVP tunnel LSPs.

switch> show traffic-engineering rsvp tunnel lsp
Tunnel TestTunnel
   Source: 10.1.1.1
   Destination: 10.4.4.4
   Color: 60, Metric: 0
   State: up
   Bandwidth: 0.0 bps, mode explicit
   LSPs: 2
   Active path: primary
   LSP 1:
      Path specification: Path2to4, primary
      CSPF Path ID: 10001
      Bandwidth: 0.0 bps
      State: up, in use
      Path (dynamic):
         10.0.12.2
         10.0.23.3
         10.0.34.4
   LSP 2:
      Path specification: Path2to4detour, secondary
      Bandwidth: 0.0 bps
      State: up
      Path (explicit):
         10.0.16.6
         10.0.67.7
         10.0.37.3
         10.0.34.4

show traffic-engineering rsvp tunnel name

Display the status of a specific RSVP tunnel, using the name of the tunnel with the show traffic-engineering rsvp tunnel name command.

A variation of the command is show traffic-engineering rsvp tunnel name MyTunnel which can then be appended with

detail
history
lsp
sub-tunnel
summary - Can be used with or without a filter. With the filter you only get that tunnel, without the filter you get all tunnels.

Command Mode

EXEC

Command Syntax

show traffic-engineering rsvp tunnel name<name of tunnel>

Parameters

Example

The following command displays the status of a specific RSVP tunnel.

switch>show traffic-engineering rsvp tunnel name MyTunnel
! RSVP is not enabled
! MPLS routing is not enabled
! Traffic engineering is not enabled
! Agent RSVP is not running
! Agent MPLS is not running

show traffic-engineering rsvp tunnel sub-tunnel summary

Display split tunnel information in a summarized fashion using the show traffic-engineering rsvp tunnel sub-tunnel summary command.

Command Mode

EXEC

Command Syntax

show traffic-engineering rsvp tunnel sub-tunnel summary

Parameters

Example

The following example displays split tunnel information in a summarized fashion.

switch> show traffic-engineering rsvp tunnel sub-tunnel summary
Tunnel: TestSplitTunnelUp
Sub Tunnel Session ID Index  Active Path Bandwidth LSPs State
========== ========== ====== =========== ========= ==== =====
1          65535      123456 primary     19.2 Kbps 1    up
2          65535      123460 secondary   19.2 Kbps 1    up
Tunnel: TestSplitTunnelUp-2
Sub Tunnel Session ID Index  Active Path Bandwidth LSPs State
========== ========== ====== =========== ========= ==== =====
1          65535      123457 secondary   19.2 Kbps 1    up

show traffic-engineering rsvp tunnel summary

Display a summary of the status of an RSVP tunnel using the show traffic-engineering rsvp tunnel summary command.

Command Mode

EXEC

Command Syntax

show traffic-engineering rsvp tunnel summary

Parameters

Example

The following example displays a summary of the status of an RSVP tunnel.

switch> show traffic-engineering rsvp tunnel summary
Tunnel Name Destination Color Index Active Path Reserved BW LSPs State
=========== =========== ===== ===== =========== =========== ==== =====
TestTunnel  10.4.4.4    60    -     primary     0.0 bps     2    up

show traffic-engineering rsvp tunnel

Display the traffic engineering RSVP tunnel status using the show traffic-engineering rsvp tunnel command.

Command Mode

EXEC

Command Syntax

show traffic-engineering rsvp tunnel

Parameters

Example

The following example displays the traffic engering RSVP tunnel status.

switch> show traffic-engineering rsvp tunnel
Tunnel TestTunnel
   Source: 10.1.1.1
   Destination: 10.4.4.4
   Color: 60, Metric: 0
   State: up
   Bandwidth: 0.0 bps, mode explicit
   LSPs: 2
   Active path: primary
   Primary path: Path2to4
      State: up, in use
      Path (dynamic):
         10.0.12.2
         10.0.23.3
         10.0.34.4
   Secondary path: Path2to4detour
      State: up
      Path (explicit):
         10.0.16.6
         10.0.67.7
         10.0.37.3
         10.0.34.4

show traffic-engineering rsvp

The show traffic-engineering rsvp command displays the current status of traffic engineering RSVP.

Command Mode

EXEC

Command Syntax

show traffic-engineering rsvp

Parameters

Example

The following example displays the current status of traffic engineering RSVP.

switch> show traffic-engineering rsvp
Local interface: 'Loopback0'
IP address: 10.1.1.1
Number of tunnels: 1
Operational: 1
Secondary path enabled: 1
Secondary path in use: 0
Number of LSPs: 2
Operational: 2

shutdown (MPLS RSVP)

The shutdown command disables the RSVP-TE protocol instance. This command allows shutting down RSVP, but retaining the configuration in the MPLS RSVP config mode, as opposed to default mpls rsvp or no mpls rsvp, which would disable RSVP but also wipe the config.

RSVP-TE is enabled globally by issuing no shutdown in the configuration sub-mode. RSVP also needs MPLS to be enabled globally. There is no per-interface knob to enable or disable RSVP. However, RSVP will not work on interfaces on which MPLS is disabled with no mpls ip.

Command Mode

MPLS RSVP Configuration

Command Syntax

shutdown

no shutdown

Examples

The following example enables RSVP-TE globally with the no shutdown command.
```
switch(config-mpls-rsvp)# no shutdown
```
The following example disables RSVP-TE globally with the shutdown command, which is the default.
```
switch(config-mpls-rsvp)# shutdown
```

shutdown (tunnel)

A tunnel is not enabled by default, it must be explicitly enabled using the no shutdown command.

Changes made in the Tunnel submode only take effect when the exited normally, using the exit command. Changes made in the Tunnel submode are discarded using the abort command.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

no shutdown

Parameters

Example

The following example enables a tunnel.

switch(config-te-rsvp-tunnel-MyTunnel)# no shutdown

The following example exits the tunnel and makes changes effective.

switch(config-te-rsvp-tunnel-MyTunnel)# exit
switch(config-te-rsvp)#

The following example discards changes.

switch(config-te-rsvp-tunnel-MyTunnel)# abort
switch(config-te-rsvp)#

split-tunnel

The split-tunnel command enables and configures RSVP sub-tunnels. Using the quantum keyword enables fixed-bandwidth sub-tunnels. Specifying a bandwidth minimum and maximum enables adaptive sub-tunnels which grow or shrink in response to changes in bandwidth.

The no split-tunnel and default split-tunnel commands disable adaptive split tunnels for the configuration-mode tunnel.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

split-tunnel (disabled | (min bandwidth_num bandwidth_units max bandwidth_num bandwidth_units [sub-tunnels limit max_tunnels] [reduction-delay time time_units] ) | (quantum bandwidth_num bandwidth_units [sub-tunnels limit max_tunnels] ))

no split-tunnel

default split-tunnel

Parameters

disabled - Disables adaptive split tunnels for the configuration-mode tunnel.
min bandwidth_num units - Configures the minimum bandwidth for each sub-tunnel. Values range from 0.00 to 1000.00 and the units may be bps, kbps, mbps, or gbps.
max bandwidth_num units - Configures the maximum bandwidth for each sub-tunnel. Values range from 0.00 to 1000.00 and the units may be bps, kbps, mbps, or gbps.
sub-tunnels limit max_tunnels- Optionally limits the number of sub-tunnels to max_tunnels. Values range from 1 to 100. The default value is 10.
reduction-delay time time_units -Optionally configures the amount of time before unused sub-tunnels are removed when traffic drops. Values range from 1 to 9999 and the units may be hours, minutes, or seconds. Default delay is 1 hour.
quantum bandwidth_num units - Enables fixed-bandwidth sub-tunnels and specifies the bandwidth to reserve for each tunnel. Values range from 0.00 to 1000.00 and the units may be bps, kbps, mbps, or gbps.

Examples

The following commands enable a maximum of 20 sub-tunnels with a bandwidth of 500 kilobits per second on RSVP tunnel tunnel17:

switch(config-te-rsvp)#tunnel tunnel17
switch(config-te-rsvp-tunnel-tunnel17)#split-tunnel quantum 500 kbps sub-tunnels limit 20
switch(config-te-rsvp-tunnel-tunnel17)#

The following commands enable a maximum of 75 adaptive sub-tunnels that can vary between 500 kilobits per second and 100 gigabits per second on RSVP tunnel tunnel17

switch(config-te-rsvp)#tunnel tunnel17
switch(config-te-rsvp-tunnel-tunnel17)#split-tunnel min 500 kbps max 100 gbps sub-tunnels limit 75
switch(config-te-rsvp-tunnel-tunnel17)#

srlg

The srlg command specifies if link SRLGs of a primary LSP are to be considered as constraints while creating a fast-reroute bypass tunnel with either link or node protection. When the srlg command is entered with the strict option, then when a path for a bypass tunnel excluding SRLGs of the next-hop interface of the primary LSP can not be found, RSVP does not set up the bypass tunnel. When the srlg command is entered without the strict option, then 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. Where such links are not available, links that have the least number of SRLGs which are to be excluded are used.

The no srlg and default srlg commands restore the default state by turning off SRLG processing.

Command Mode

MPLS RSVP Configuration

Command Syntax

srlg [strict]

no srlg

default srlg

Parameters

strict - Applies strict SRLG constraints.

Example

The following commands enable SRLG processing:

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

neighbor <IP> targeted

The neighbor <IP> targeted command is used to configure a targeted adjacency with a non-adjacent router from the LDP configuration mode. Both peers require the targeted adjacency configuration because a targeted adjacency is not accepted from an unknown LSR by default.

Note: This configuration may not be required because the targeted adjacency will be established automatically by both peers based on the RSVP tunnel configuration.

Command Mode

MPLS-LDP Configuration

Command Syntax

neighbor ip_address targeted

no neighbor ip_address targeted

default neighbor targeted

Parameter

ip_address - The IP address of the neighbor to establish a targeted adjacency with.

Examples

The following example configures a targeted adjacency with a non-adjacent router (neighbor 5.5.5.5).

switch(config-mpls-ldp)# neighbor 5.5.5.5 targeted

timer recovery

This command will have a different behavior depending on the command mode (speaker or helper).

The timer recovery command configures the maximum accepted MPLS RSVP recovery time. This is the set maximum that will be used if the neighbor wants an even higher timer.

The no timer recovery and default timer recovery commands restore the maximum recovery timer value to its default. In speaker mode, the default maximum is 90 seconds. In helper mode, the default is to accept all maximum recovery time values.

Command Mode

MPLS RSVP Graceful Restart Helper Configuration
MPLS RSVP Graceful Restart Speaker Configuration
MPLS RSVP Hitless Restart Configuration

Example to enter configuration mode:

graceful-restart role {helper | speaker}

Command Syntax

timer recovery numseconds

no timer recovery

default timer recovery

Helper Configuration Mode

timer recovery maximum <t> seconds - The maximum accepted recovery time value, configured under helper configuration mode.

default timer recovery maximum <t> seconds

no timer recovery maximum <t> seconds

Speaker Configuration Mode

timer recovery <t> seconds - The requested recovery time value is configurable under the speaker configuration mode.

Parameters

num - Maximum recovery time in seconds. Values range from 1 to 320. The default is 90 seconds in speaker mode.

Example

The following command configures the recovery timer to 45 seconds in RSVP for a switch in MPLS RSVP Graceful Restart Speaker mode:

switch(config-mpls-rsvp-gr-speaker)#timer recovery 45 seconds
switch(config-mpls-rsvp-gr-speaker)#

timer restart

The timer restart command configures a maximum acceptable value for RSVP graceful restart timers received from RSVP neighbors. This is the set maximum that will be used if the neighbor wants an even higher timer.

The no timer restart and no timer restartcommands restore the maximum restart time value to its default. In speaker mode, the default requested is 90 seconds. In helper mode, the default is to accept all maximum restart time values.

Command Mode

MPLS RSVP Graceful Restart Helper Configuration
MPLS RSVP Graceful Restart Speaker Configuration
MPLS RSVP Hitless Restart Configuration

Example to enter configuration mode:

graceful-restart role {helper | speaker}

Command Syntax

Helper Configuration

timer restart maximum <t> seconds - The maximum accepted restart time value is configurable under helper configuration mode.

default timer restart maximum <t> seconds

no timer restart maximum <t> seconds

Speaker Configuration

timer restart <t> seconds - The restart time value is configurable under the speaker configuration mode.

default timer restart <t> seconds

no timer restart <t> seconds

timer recovery <t> seconds - The recovery time value is configurable under the speaker configuration mode.

Parameters

num - Maximum accepted recovery time in seconds. Values range from 1 to 320. The default is 90 seconds in speaker mode.

Example

The following command configures the restart timer to 45 seconds in RSVP for a switch in MPLS RSVP Graceful Restart Speaker mode:

switch(config-mpls-rsvp-gr-speaker)#timer restart 45 seconds
switch(config-mpls-rsvp-gr-speaker)#

traffic-engineering srlg

The traffic-engineering srlg command configures a shared risk link group (SRLG) for the command-mode interface.

The no traffic-engineering srlg and default traffic-engineering srlg commands remove the SRLG configuration from the interface.

Command Mode

Interface Configuration

Command Syntax

traffic-engineering srlg (srlg_name|srlg_group_ID)

no traffic-engineering srlg (srlg_name|srlg_group_ID)

default traffic-engineering srlg (srlg_name|srlg_group_ID)

name

Parameters

srlg_name - Name of the SRLG.
srlg_group_ID - Group ID of the SRLG. Values range from 0 to 4294967295.

Example

The following commands configure SRLG 29975 on Ethernet interface 1/1:

switch(config)#interface ethernet 1/1
switch(config-if-Et1/1)#traffic-engineering srlg 29975
switch(config-if-Et1/1)#

tunnel

The tunnel command enters Traffic Engineering RSVP Tunnel configuration mode for the named tunnel. If the named tunnel does not exist, the command creates it.

Note: The no and default forms of the command delete the named tunnel from running config.

Entering the p2mp keyword after the name of the tunnel places the tunnel into peer-to-multipeer (p2mp) mode.

Note: No P2P and P2MP tunnels with the same name can exist at the same time.

Command Mode

Traffic Engineering RSVP Configuration

Command Syntax

tunnel name [p2mp]

no tunnel name [p2mp]

default tunnel name [p2mp]

Parameters

p2mp - Places the tunnel into peer-to-multipeer (p2mp) mode.

Example

The following example enters the configuration mode for the tunnel named MyTunnel:

switch(config-te-rsvp)# tunnel MyTunnel
switch(config-te-rsvp-tunnel-MyTunnel)#

tunneling ldp

LDP over RSVP is configured by enabling the tunneling ldp command. When enabled, the tunneling ldp command causes the RSVP tunnel to become eligible for LDP over RSVP.

To disable LDP over RSVP on the tunnel use the default tunneling command.

Command Mode

Traffic Engineering RSVP Tunnel Configuration

Command Syntax

tunneling ldp

Parameters

Example

The following example configures LDP over RSVP.

switch(config-te-rsvp-tunnel-MyTunnel)# tunneling ldp

tunneling ldp ucmp

The tunneling ldp ucmp command configures UCMP with LDP over RSVP.

Note: This configuration may not be required because the targeted adjacency will be established automatically by both peers based on the RSVP tunnel configuration .

Command Mode

RSVP tunnel configuration mode

Command Syntax

tunneling ldp ucmp

Parameter

bandwidth 20 gbps - The bandwidth configured on the RSVP tunnel determines the weight associated with this tunnel when traffic to the tunnel endpoint is UCMP load balanced.

bandwidth signalling disabled - The bandwidth configured on RSVP tunnels is both signalled and used as the UCMP weight. Use this command, to specify bandwidths on RSVP tunnels to be used only as the UCMP weight without signalling the bandwidths in RSVP.

Examples

The following example configures a targeted adjacency with a non-adjacent router.
```
switch(config-te-rsvp-tunnel-tunnelABC)# tunneling ldp ucmp
```
The following example configures the RSVP tunnel bandwidth.
```
switch(config-te-rsvp-tunnel-tunnelABC)#bandwidth 20 gbps
```

The following example disables signalling.

switch(config-te-rsvp-tunnel-tunnelABC)#bandwidth signalling disabled

EVPN MPLS Shared ESI Label

In a multihomed EVPN MPLS configuration, broadcast, unknown-unicast, and multicast (BUM) packets sent from a Non-Designated Forwarder (Non-DF) PE to a Designated Forwarder (DF) PE must carry the ESI label advertised by the egress DF PE. When the egress DF PE receives a packet with the advertised ESI label, it does not forward the packet on the Ethernet Segment (ES) corresponding to that ESI label. This avoids sending the packet back to the same ES where the BUM packet originated.

However, if a DF election triggers, a PE may change its role from a Non-DF to a DF. Since the DF election runs on each PE distributively, some PE(s) may not update their view of the new DF PE and doesn't add an ESI label in the BUM packet. In such a case, the BUM packets in transit may get sent back to the same ES where they originated. To overcome this, EOS includes ESI labels to Non-DF PEs as well. This shared ESI label provides a mechanism to achieve sending an ESI label to Non-DF PEs on platforms that cannot support sending different ESI labels to multihomed peers.

Configuring EVPN MPLS Shared ESI Label

An Ethernet-Segment (ES) must be configured with a shared-index to allocate an ESI label value based on the shared-index configuration.

Example

switch(config)# interface Ethernet4
switch(config-if-Et1)# switchport access vlan 1000
switch(config-if-Et1)# evpn ethernet-segment
switch(config-evpn-es)# identifier 0022:2222:2222:2222:2222
switch(config-evpn-es)# mpls shared index 100
switch(config-evpn-es)# route-target import 00:02:00:02:00:02

If all PEs provisioned with the same ES carry the same shared-index value, then they allocate the same ESI label value for that Ethernet Segment.
A consistent configuration on all PEs enables the hardware to encapsulate the ESI label on all BUM packets towards multi-homed peers. This implements split-horizon filtering during DF role change events.
EOS uses the shared index value as an offset into the reserved l2evpn ethernet-segment range where EOS derives the label value as follows:
- ESI label = label-range base value + shared-index value – 1

EOS allocates the ESI labels from the l2evpn ethernet-segment label range with the following default configuration:

switch# show running-config all
mpls label range bgp-sr 900000 65536
mpls label range dynamic 100000 262144
mpls label range isis-sr 900000 65536
mpls label range l2evpn 1036288 12288
mpls label range l2evpn ethernet-segment 1031072 1024
mpls label range srlb 965536 65536
mpls label range static 16 99984

EVPN MPLS Shared ESI Label Show Commands

The following show command displays the operational state when EVPN MPLS shares the ESI label between all the PEs in that Ethernet-Segment:

Example

switch# show bgp evpn instance
EVPN instance: VLAN 1000
  Route distinguisher: 100.0.0.1:1000
  Route target import: Route-Target-AS:64500:1000
  Route target export: Route-Target-AS:64500:1000
  Service interface: VLAN-based
  Local IP address: 100.0.0.1
  Encapsulation type: MPLS
  Label allocation mode: per-instance
  MAC route label: 1040210
  IMET route label: 1042201
  AD route label: 1040210
  Local ethernet segment:
    ESI: 0022:2222:2222:2222:2222
      Interface: Ethernet4
      Mode: all-active
      State: up
      ESI label: 1031171
      Shared ESI label: on
      ES-Import RT: 00:02:00:02:00:02
      Designated forwarder: 100.0.0.1
      Non-Designated forwarder: 100.0.0.2

Shared ESI label state for an ES is ON when the following conditions are satisfied.
- ES is configured with the shared-indexmpls shared index <value>.
- All PEs in that ES carry the same ESI label.

The l2evpn shared ethernet-segment label range space can be looked up using the command below:

switch# show mpls label ranges
Start     End       Size      Usage
------------------------------------------------
0         15        16        reserved
16        99999     99984     static mpls
100000    116383    16384     ldp (dynamic)
116384    132767    16384     bgp (dynamic)
132768    362143    229376    free (dynamic)
362144    899999    537856    unassigned
900000    965535    65536     isis-sr
900000    965535    65536     bgp-sr
965536    1031071   65536     srlb
1031072   1032095   1024      l2evpn shared ethernet-segment
1032096   1036287   4192      unassigned
1036288   1048575   12288     l2evpn

Limitations

When the PE switch multihomes to more than six PEs and each one of those PEs has an Ethernet Segment in the shared ESI configuration, the PE switch may not be able to add the ESI label to the MPLS label stack of BUM packets ingressing on every Ethernet Segment. In such a case, the syslog message, EVPN-3-MPLS_SHARED_ESI_HW_RESOURCE_FULL, appears in the system logs.

LDP Entropy Label

If a network device uses deep packet inspection for load balancing, Arista Networks recommends to use entropy label in LDP to improve load balancing in MPLS networks by providing sufficient entropy in the label stack.

Configuring LDP Entropy Label

Use the entropy-label command to enable the MPLS LDP entropy labelling on the switch. Use the no form of the command to disable the MPLS LDP entropy labelling. By default, the entropy label knob is disabled.

switch(config)# mpls ldp
switch(config-mpls-ldp)# entropy-label
switch(config-mpls-ldp)# exit

Show Commands

The show running-config all command displays the Entropy Label Signaling status.

switch# show running-config all
!
mpls ldp
   ...
   no entropy-label
   ...
!

The show mpls ldp bindings detail command displays whether the ELC is advertised or not for a given FEC for both local/remote bindings.

switch# show mpls ldp bindings 1.1.1.1/32 detail
1.1.1.1/32
     Local binding:    Label: imp-null, ELC: False 
          Uptime:   1:51:14
          Advertised to: 2.2.2.2:0, 3.3.3.3:0
     Remote binding: Peer ID: 2.2.2.2:0, Label: 100001, ELC: True
          Uptime:   1:51:57
     Remote binding: Peer ID: 3.3.3.3:0, Label: 100002, ELC: True
          Uptime:   1:52:05

Following debug commands are modified to incorporate Entropy label and Entropy label indicator information in label stack for debugging on ingress router.

switch> show platform fap fec <idx>
Tunnel Type: Mpop(mpls pop), Mpush(mpls push), Mswap(mpls swap),
             MoG(mpls-over-gre), T(IPv4 tunnels GRE/VXLAN)
 'CW  - Control word',
 'FL  - Flow label',
 'EL  - Entropy label',
 'ELI - Entropy label indicator',
 'D   - ECMP is divergent across switching chips',
 ' -----------------------------------------------------------------------------------',
 '|                                 FEC Entry                                         |',
 '|-----------------------------------------------------------------------------------',
 '|     |      |     |                    |     |       |                   |',
 '| ECMP|  FEC |     |                    |     |       |                   | Tunnel',
 '|Index| Index| Cmd |     Destination    | VID |Outlif |   MAC / CPU Code  |T Value',
 ' ----------------------------------------------------------------------------------',
 '|  -  |353896|ROUTE| Et1/1              |0    |20480  | 00:00:00:00:00:01 |Mpush 501 401 301 ELI EL 201'

B. show platform fap ip route
Tunnel Type: M(mpls), G(gre), MoG(mpls-over-gre),
             VXLAN-o(VXLAN outer-rewrite info), VXLAN-i(VXLAN inner-rewrite info)
 'CW  - Control word',
 'FL  - Flow label',
 'EL  - Entropy label',
 'ELI - Entropy label indicator',
 '*   - Routes in LEM',
 'D   - ECMP is divergent across switching chips',
 ' ---------------------------------------------------------------------------------------------------------',
 '|                                 Routing Table                                           |              |',
 '|---------------------------------------------------------------------------------------------------------',
 '|VRF|   Destination    |     |                    |     |       |                   | ECMP|  FEC | Tunnel',
 '| ID|      Subnet      | Cmd |     Destination    | VID |Outlif |   MAC / CPU Code  |Index| Index|T Value',
 ' ---------------------------------------------------------------------------------------------------------',
 '|0  |192.168.1.3/32    |ROUTE| Et1/2              |100  |8188   | 00:00:00:00:00:02 |  -  |353897|   -   ',
 '|0  |200.0.0.0/24      |ROUTE| Et1/2              |100  |20484  | 00:00:00:00:00:02 |  -  |353898|M 501 401 301 ELI EL 201',
 '|0  |0.0.0.0/0         |TRAP | CoppSystemL3LpmOver|0    |  -    | SlowReceive       |  -  |576815|   -   ',

Limitations

When the Transit LSR is acting as a PHP hop for a given LDP tunnel with entropy label pushed onto it by an Ingress LSR, only the LDP tunnel label will be popped at PHP whenever the Egress LSR has signaled implicit-null in LDP.
Egress LSR should be capable of handling ELI as top label in the label stack like [ ELI, EL, VPN, Payload ].

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.

Related Topics:

RSVP-TE Overview

The configuration for RSVP-TE has two parts:

RSVP-TE Configuration (previously LSR)
Configuring RSVP-TE Tunnels (previously LER)

Core Prerequisites and Global Configuration

For RSVP-TE to function correctly, several global and interface-level settings must be configured:

IP Routing: IP Routing must be enabled globally on the switch.
MPLS Enablement: MPLS must be enabled globally on the switch.
Traffic Engineering: Traffic-engineering must be enabled globally on the switch.
Router ID: A router ID must be configured in either the traffic-engineering configuration or the general routing configuration.
IGP Traffic Engineering: Traffic engineering must be active within the Interior Gateway Protocol (IGP), such as IS-IS or OSPF.
Interface Traffic Engineering: Traffic-engineering must be enabled on interfaces that use RSVP-TE.
Source Interface: A local interface, typically a Loopback interface, is required to derive the source IP address for tunnels.
Protocol Activation: RSVP is globally activated using the no shutdown command within the MPLS RSVP configuration submode.

Supported Scalability

Arista RSVP-TE supports various router roles, with performance capabilities validated through internal testing.

Table 1. Supported Scalability
Role	Description	Scale Highlights
RSVP-TE P2P LSPs	The maximum number of RSVP-TE P2P LSPs Arista supports in any role.	30k LSPs
RSVP-TE P2P Tunnels	The maximum number of RSVP-TE P2P Tunnels Arista supports on a headend.	2k (1k with hot-standby secondary)
RSVP-TE P2MP Sub-LSPs	The maximum number of RSVP-TE P2MP sub-LSPs Arista supports in any role.	10k sub-LSPs
RSVP-TE P2MP Tunnels	The maximum number of RSVP-TE P2MP tunnels Arista supports on a headend.	Up to 60 MVPN tunnels with up to 64 leaves each

RSVP-TE Limitations

Only IPv4 is supported.
Only the default VRF is supported.
Only strict EROs with host hops (/32) are supported.
TE links with secondary IP addresses are not supported.
Subinterface links are not supported.
Changing the RSVP FRR mode while a bypass tunnel is already in use could cause both the primary and bypass tunnels to go down, resulting in traffic loss.
Changing the RSVP SRLG mode while a bypass tunnel is already in use could cause both the primary and bypass tunnels to go down, resulting in traffic loss.
The maximum number of IS-IS/OSPFv2 routers supported by CSPF on a single broadcast network is 30.
The maximum number of IS-IS/OSPFv2 adjacencies supported by CSPF for a single router is 500.
The maximum number of hops supported for an RSVP LSP is 256.
CSPF considers a maximum of 16 SRLGs per TE link when excluding SRLGs during path computation.
Explicit-null label termination does not work on 7500R and 7280R/7280R2 platforms when additional labels (such as VPN labels) are present on the MPLS packet.

Related Topics:

Visibility and Monitoring Services

The Visability and Monitors Services chapter contains the following sections:

Configuring RSVP-TE

This topic contains the following sections:

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 the router 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

Related Topics:

Resource Reservation Protocol for Traffic Engineering (RSVP-TE)

The Resource Reservation Protocol for Traffic Engineering (RSVP-TE) is utilized to distribute Multiprotocol Label Switching (MPLS) labels. This protocol enables steering traffic along defined paths while reserving the necessary bandwidth for them.

RSVP-TE is a signaling protocol for establishing Label Switched Paths (LSPs) with or without specific resource requirements, such as guaranteed bandwidth. RSVP-TE reserves resources along a predetermined path to ensure network performance for critical traffic. RSVP-TE is used for traffic engineering and fast reroute.

RSVP-TE consists of the following main messages:

Path: Sent by the headend router requesting the resources and is forwarded through the network from the headend towards the tailend router.
Resv: Sent by the tailend router in response to the Path message received, confirming the resource reservation and travels from the tailend towards the headend router.
Error Messages: PathErr (Path Error) and ResvErr (Resv Error). PathErrs flow from the error node towards the headend (in the opposite direction of Path messages), and ResvErrs flow from the error node towards the tailend (in the opposite direction of Resv messages).
Tear Messages: PathTear and ResvTear. These messages are used to clear the Path, or Resv states, from the network.

Each Resource Reservation Protocol message is composed of multiple objects that serve specific functions. For instance, a Path message contains objects such as SESSION and SENDER_TEMPLATE, and a Resv message includes objects such as SESSION and FILTER_SPEC.

RSVP-TE Path messages contain an explicit route object that specifies the IP addresses that the LSP must traverse to reach its destination.

All LSPs that have the same SESSION object are part of the same session. LSPs within the same session share resources, such as bandwidth (if using the Shared Explicit style, which is usually the case). Sessions generally correspond to a single tunnel created on the headend. Sessions are uniquely identified by the three values in the SESSION object, which include the destination IP address (or P2MP ID in the case of P2MP sessions), the tunnel-ID (which is just an allocated integer value), and the extended-tunnel-ID (which generally is set to the source IP address).

There are two objects required to uniquely identify an LSP within a session:

The SESSION object consists of the destination IP address, the tunnel ID, and the extended destination ID.
The LSP ID, which comes from the SENDER_TEMPLATE object for Path messages and the FILTER_SPEC object for Resv messages.

Sections in this chapter include:

MPLS Commands

authentication

Use the authentication command to enable cryptographic authentication. The no form and the default form of the command removes the cryptographic authentication.

Command Mode

MPLS RSVP sub-mode (mpls-rsvp)

Command Syntax

authentication [index 1-4294967295 [active | password ]|[sequence-number window 1-255]|[type [md5 | none]]]

no authentication [index 1-4294967295 [active | password ]|[sequence-number window 1-255]|[type [md5 | none]]]

default authentication [index 1-4294967295 [active | password ]|[sequence-number window 1-255]|[type [md5 | none]]]

Parameters

index 1-4294967295 - Specify the password index.
- active - Use index as the active password.
- password - Specify the password.
sequence-number - Specify the index in the sequence.
- window 1-255 - Configure the reorder window size. The default value is 5. A value of 1 turns off support for packet reordering.
type - Specify the authentication mechanism.
- md5 - Add the MD5 hash.
- none - Indicates no authentication mechanism. Disables cryptographic authentication.

Examples

Enable Cryptographic Authentication (RFC 2747) by setting the authentication type to md5 and configuring an active password.
```
(config-mpls-rsvp)# authentication type md5
```
Configure authentication secrets with an index. One of the indices should be chosen as the actively used password:
```
(config-mpls-rsvp)# authentication index 1 password s3cr3t
(config-mpls-rsvp)# authentication index 1 active
```
Use the active password to authenticate outgoing messages. All configured passwords are accepted for authentication of incoming packets, which allows smooth key rollover.

Password encoding is available:

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

The size of the sequence number reorder window can be changed to accommodate a larger number of 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.
```
(config-mpls-rsvp)# authentication sequence-number window 5
```
The default value is 5. A value of 1 effectively turns off support for packet reordering.

cspf delay

RSVP-TE uses CSPF to compute the FRR backup path. Throttle CSPF to avoid frequent path changes when frequent network events occur. Use the cspf delay command to specify how frequently CSPF runs after a network event by specifying the initial wait interval, back-off interval, and maximum wait interval for CSPF. The no form and the default form of the command remove the CSPF delay.

Command Mode

Router traffic engineering mode

Command Syntax

cspf delay [initial n back-off n] max n

no cspf delay [initial n back-off n] max n

default cspf delay [initial n back-off n] max n

Parameters

initial Specify initial wait interval for CSPF.
- n - Specify the time in milliseconds. 1-300000.
  - back-off - Specify the back-off interval for CSPF.
    - n - Specify the time in milliseconds. 1-300000.
max - Specify the maximum wait interval for CSPF.
- n - Specify the time in milliseconds. 1-300000.

entropy-label

The entropy-label command enables the MPLS LDP Entropy Label.

The no entropy-label command removes the MPLS LDP Entropy Label configurations from the running-config.

Command Mode

MPLS LDP Configuration Mode

Command Syntax

entropy-label

no entropy-label

Example

This command enables the MPLS LDP Entropy Label.

switch(config)# mpls ldp
switch(config-mpls-ldp)# entropy-label
switch(config-mpls-ldp)# exit

fast-reroute

Use the fast-reroute command to support Fast Reroute (FRR) link protection/NHOP (RFC 4090). You can enable FRR protection by setting the Fast Reroute mode to link-protection.

Command Mode

MPLS RSVP sub-mode (mpls-rsvp)

Command Syntax

fast-reroute [mode [ link-protection | node-protection | none]|[reversion [global | local]]

Parameters

mode Fast reroute mode.
- link-protection - Protects against failure of the next link.
- node-protection - Protects against failure of the next node.
- none - Disables fast reroute.
reversion Select reversion behavior.
- global Global revertive repair (default).
- local Local revertive repair.

Examples

Enable support for Fast ReRoute (FRR) link protection/NHOP (RFC 4090) by setting the Fast Reroute mode to link-protection.
```
(config-mpls-rsvp)# fast-reroute mode link-protection
```
To turn off FRR, change the mode to the default setting none.
```
(config-mpls-rsvp)# fast-reroute mode none
```
You can change the revertive behavior of the FRR from the global revertive mode to the local revertive mode. In the global revertive mode, an LSR re-routed over a bypass tunnel because the downstream link keeps uses the bypass tunnel even after the link has recovered. This expects the headend router to set up a new LSP upon notification that a link became unavailable. In the local revertive mode, the LSR switches back to using the primary link after recovery.
```
(config-mpls-rsvp)# fast-reroute reversion local
```

The default for reversion is global.

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

fast-reroute reversion

You can change the revertive behavior of the FRR from the global revertive mode to the local revertive mode. In the global revertive mode, an LSR re-routed over a bypass tunnel because the downstream link became unavailable but keeps using the bypass tunnel after the link recovers. This expects the headend router to set up a new LSP upon notification that a link became unavailable. In the local revertive mode, the LSR switches back to using the primary link after recovery.

The default for reversion is global.

Command Mode

Configuration sub-mode for RSVP

Command syntax

fast-reroute reversion [global | local]

Parameters

global Global revertive repair.
local Local revertive repair.

Examples

Set the fast-reroute reversion to local:

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

The default for reversion is global.

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

graceful-restart

The graceful-restart command configures Graceful Restart for RSVP which preserves data plane traffic when RSVP agents restart.

The no and default versions of the command disables the feature and removes it from the running-config.

Command Mode

MPLS RSVP Configuration Mode

Command Syntax

graceful-restart [role [helper | speaker]] [timer [recovery | restart]] [maximum timer_value]

Parameters

role - Specify the Graceful Restart role.
- helper - Assists with RSVP neighbors restarts.
- speaker - Allows the local node to restart.
timer - Specify the RSVP Graceful Restart time.
- recovery - Specify the recover timer.
- restart - Specify the restart timer.
maximum -
timer_value - Specify the maximum timer value as a number between 1 and 320 seconds.

Example

Use the following commands to configure a Helper role with a maximum recovery timer of 160 seconds:

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

hello interval

Command Mode

Configuration sub-mode for RSVP.

Command Syntax

hello interval [interval [sec]] [multiplier [num]]

no hello interval [interval [sec]][multiplier [num]]

default hello interval [interval [sec]][multiplier [num]]

Parameters

interval sec The interval in units of seconds.
- multiplier num The number of missed hellos after which the neighbor is expired.

Examples

In this example, EOS sends hello messages to all known neighbors every 10 seconds. If the switch does not receive hello responses from a neighbor for 4*10=40 seconds, the switch loses communication and the neighbor resets.
```
(config-mpls-rsvp)# hello interval 10 multiplier 4
```
In this example, the default of 10 seconds with multiplier 4 resets.
```
(config-mpls-rsvp)# default hello interval
```
in this example, explicitly disable the Hello messages.
```
(config-mpls-rsvp)# no hello interval
```

mpls ldp graceful-restart

The ldp graceful-restart command enables MPLS LDP (Label Distribution Protocol) Graceful Restart (GR) functionality. LDP Graceful Restart mechanism allows an LDP router to signal to LDP neighbors about an impending restart due to a software upgrade, hardware failure, or planned reboot, but wants to maintain the MPLS forwarding state and adjacencies.

During a graceful restart, the restarting LDP router attempts to preserve the MPLS forwarding entries (FEC-to-label mappings) and LDP adjacencies with neighbors. This prevents a disruption in MPLS data plane forwarding while the control plane (LDP) restarts and reconverges. Neighbors, after receiving a graceful restart notification, continue to forward traffic using the old labels for a predefined "helper" period, allowing the restarting router to re-establish LDP sessions and refresh label mappings without blackholing traffic.

The no graceful-restart command disables the feature.

Command Mode

MPLS LDP Configuration

Graceful Restart Speaker Configuration

Graceful Restart Helper Configuration

Command Syntax

graceful-restart role [[helper [ timer [ neighbor-liveness seconds] [ recovery seconds] pseudowire]] [[speaker timer [reconnect seconds ] [state-holding seconds]]

Parameters

graceful-restart - Configure LDP Graceful Restart.
role - Specify an LDP Graceful Restart Role.
- helper - Specify an LDP Graceful Restart Helper.
  - pseudowire - Configure LDP Graceful Restart support for Pseudowire.
  - timer - Configure LDP Graceful Restart Timer.
    - neighbor-liveness - Configure the maximum time to preserve the session forwarding-state before session re-establishes. Specify a time in seconds with 90 seconds as the default.
    - recovery - Configure the maximum time to preserve the session forwarding-state after session re-establishes. Specify a time in seconds with 90 seconds as the default.
- speaker - Specify an LDP Graceful Restart Helper.
  - timer - Configure LDP Graceful Restart Timer.
    - reconnect - Specify the time for the peer to preserve the forwarding-state after restart.
    - state-holding - Specify the time for the peer to preserve the forwarding-state after restart.

Examples

Use the following commands to configure an LDP Graceful Restart Helper with a neighbor-liveness time of 500:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart role helper
switch(config-mpls-ldp-gr-helper)# timer neighbor-liveness 500

Use the following commands to configure an LDP Graceful Restart Start Speaker with a reconnect time of 500:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart role speaker
switch(config-mpls-ldp-gr-helper)# timer reconnect 500

Use the following commands to configure an LDP pseudowire:

switch(config)# mpls ldp
switch(config-mpls-ldp)# graceful-restart role helper
switch(config-mpls-ldp-gr-helper)# pseudowire

mpls icmp source-interface

The mpls icmp source-interface command permits the designation of a source interface as an IPv4 address or IPv6 address. Using the no parameter disables the designated interface.

Command Mode

Global Configuration

Command Syntax

mpls icmp [fragmentation-needed | ip | ipv6 ttl-exceeded]

no mpls icmp [fragmentation-needed | ip | ipv6 ttl-exceeded]

Parameters

fragmentation-needed tunneling - Specify fragmentation for larger packets and enable MPLS tunneling.
ip source-interface - Specify the source interface from the list of available interfaces:
- Ethernet
- Loopback
- Management
- Port-Channel
- Tunnel
- Vlan
ipv6 source-interface
- Ethernet
- Loopback
- Management
- Port-Channel
- Tunnel
- Vlan
ttl-exceeded tunneling - Time-to-live exceeded in transit and enable MPLS tunneling on the switch.

Example

Use the following command to enable a source interface, Loopback0, for IPv4:

switch(config)#mpls icmp ip source-interface Loopback0

mpls ip

The mpls ip command enables MPLS routing. Multiprotocol Label Switching (MPLS) provides a networking process that avoids complex lookups in a routing table by replacing complete network addresses with short path labels for directing data packets to network nodes. MPLS data paths are serviced through a tunnel encapsulation data structure that adds four-byte label headers to packets.

The no mpls ip and default mpls ip commands disable MPLS routing by removing the mpls ip command from running-config. When MPLS routing is disabled, routed MPLS packets are dropped and all MPLS routes and adjacencies are removed. MPLS routing is disabled by default.

Command Mode

Global Configuration

Command Syntax

mpls ip

no mpls ip

default mpls ip

Examples

This command enables MPLS routing. Previous commands enabled IP routing and configured MPLS static routes.

switch(config)# mpls ip
switch(config)# show running-config

! Command: show running-config

!
ip routing
!
mpls ip
!
mpls static top-label 3400 10.14.4.4 pop payload-type ipv4
mpls static top-label 4400 10.15.46.45 pop payload-type ipv4
!

!
end
switch(config)#

This command disables MPLS routing.

switch(config)# no mpls ip
switch(config)# show running-config


! Command: show running-config
                 <-------OUTPUT OMITTED FROM EXAMPLE-------->
!
ip routing
!
mpls static top-label 3400 10.14.4.4 pop payload-type ipv4
mpls static top-label 4400 10.15.46.45 pop payload-type ipv4
!

!
end
switch(config)#

mpls parsing speculative

Use the mpls parsing speculative command to configure parsing additional header types used by the load-balancing hash algorithm.

Command Mode

Global Configuration

Command Syntax

mpls parsing speculative [control-word | ethernet | ipv4 | ipv6]

Parameters

parsing - Configure parsing of MPLS packets.
speculative - Configure speculative parsing of different types of MPLS encapsulated packets for all data plane features.
control-word - Enable parsing of MPLS pseudowire packets with a control word.
ethernet - Enable parsing of MPLS encapsulated Ethernet packets.
ipv4 - Enable parsing of MPLS encapsulated IPv4 packets.
ipv6 - Enable parsing of MPLS encapsulated IPv6 packets.

Example

To enable MPLS speculative parsing on Ethernet packets, use the following command:

switch(config)#mpls parsing speculative ethernet

mpls shared index

The mpls shared index command configures an Ethernet-Segment (ES) shared-index to allocate an ESI label value based on the shared-index configuration.

The no mpls shared index command removes mpls shared index configuration from the running-config.

Command Mode

EVPN Ethernet-Segment Mode

Command Syntax

mpls shared index index-value

no mpls shared index index-value

Parameter

index-value Label index value. Value ranges from 1 to 1024.

Example

These commands place the switch on Ethernet-Segment (ES) configuration mode and configure an MPLS shared index value of 100.

switch(config)# interface Ethernet4
switch(config-if-Et1)# switchport access vlan 1000
switch(config-if-Et1)# evpn ethernet-segment
switch(config-evpn-es)# identifier 0022:2222:2222:2222:2222
switch(config-evpn-es)# mpls shared index 100
switch(config-evpn-es)# route-target import 00:02:00:02:00:02

mpls static

The mpls static command creates an MPLS rule that specifies the method of handling of inbound MPLS traffic. Multiprotocol Label Switching (MPLS) is a networking process that replaces complete network addresses with short path labels for directing data packets to network nodes.

Static rules specify these parameters:

MPLS filter: The top-label parameter specifies the 20-bit value that the MPLS packet’s top header label must match to be handled by the rule.
Nexthop location: Specifies the destination nexthop address (IPv4 or IPv6) and the interface through which the switch forwards the packet.
MPLS action: Specifies the MPLS label stack management action performed on the packet:
- pop-payload: removes the top label from stack; this terminates an LSP (label-switched path).
- swap-label: replaces top label with a specified new label; this passes a packet along an LSP.
Rule priority: Specifies the rule to be used when an MPLS packet matches multiple rules.

The no mpls tunnel static and default mpls tunnel static commands delete the specified MPLS rule from running-config.

Commands that include only a top label tag remove all MPLS rules with the matching top label.
Commands with no PRIORITY parameter remove all matching routes of every metric value.

Command Mode

Global Configuration

Command Syntax

mpls tunnel static top-label top_tag[ bgp peer [peer IP]] [DEST_INTF] NEXTHOP_ADDR ACTION [PRIORITY]

no mpls tunnel static top-label top_tag

no mpls tunnel static top-label top_tag [DEST_INTF] NEXTHOP_ADDR ACTION [PRIORITY]

default mpls tunnel static top-label top_tag

default mpls tunnel static top-label top_tag [DEST_INTF] NEXTHOP_ADDR ACTION [PRIORITY]

Parameters

top_tag Top header’s label field contents. Value ranges from 0 to 1048575 (20 bits).
BGP peer peer IP The BGP peer identifier.
DEST_INTF Specifies interface through which NEXTHOP_ADDR is accessed. Options include:
- no parameter Any interface.
- ethernet e_num Ethernet interface specified by e_num.
- loopback l_num Loopback interface specified by l_num.
- management m_num Management interface specified by m_num.
- port-channel p_num Port-channel interface specified by p_num.
- vlan v_num VLAN interface specified by v_num.
- VXLAN vx_num VXLAN interface specified by vx_num.
NEXTHOP_ADDR Nexthop address for MPLS for filtered MPLS packets. Options include:
- ipv4_addr IPv4 address.
- ipv6_addr IPv6 address.
ACTION MPLS header stack management action performed on packet. Options include:
- pop payload-type ipv4 Removes top layer from stack. Payload is handled as IPv4 packet.
- pop payload-type ipv6 Removes top layer from stack. Payload is handled as IPv6 packet.
- swap-label 0 to 1048575 Replaces header label with specified label value (20 bits).
PRIORITY Specifies rule priority when multiple rules match a packet. Options include:
- no parameter Assigns a metric value of 100 to the rule.
- metric 1 to 255 Lower values denote higher priority. Value ranges from 1 to 255.

The mpls tunnel static command does not support push label actions.

Examples

These commands create an MPLS rule that matches packets with a top label value of 3400 and causes the removal of the top label from the header stack. The nexthop destination of the IPv4 payload is IP address 10.14.4.4 through Ethernet interface 3/3/3. This rule has a metric value of 100.
```
switch(config)# mpls tunnel static top-label 3400 ethernet 3/3/3 10.14.4.4 pop payload-type ipv4
switch(config)# show running-config

!
mpls tunnel static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
!

end
switch(config)#
```

These commands create a backup rule that forwards the packet through Ethernet interface 4/3. This rule’s metric value of 150 assigns it backup status prior to the first rule.

switch(config)# mpls tunnel static top-label 3400 ethernet 4/3 10.14.4.4 pop payload-type ipv4 metric 150
switch(config)# show running-config

!
mpls tunnel static top-label 3400 Ethernet4/3 10.14.4.4 pop payload-type ipv4 metric 150
mpls tunnel static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
!

                    <-------OUTPUT OMITTED FROM EXAMPLE-------->
end
switch(config)#

These commands create an MPLS rule that forwards the packet to the nexthop address through any interface.

switch(config)# mpls tunnel static top-label 4400 10.15.46.45 pop payload-type ipv4
switch(config)# show running-config

                     <-------OUTPUT OMITTED FROM EXAMPLE-------->

!
mpls tunnel static top-label 3400 Ethernet4/3 10.14.4.4 pop payload-type ipv4 metric 150
mpls tunnel static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
mpls tunnel static top-label 4400 10.15.46.45 pop payload-type ipv4
!

end
switch(config)#

This command uses the BGP peer option to designate the nexthop..

switch(config)#mpls tunnel static top-label 1001 100.1.1.1 bgp peer pop payload-type ipv4

When the peer IP is not specified, the next-hop is considered as the peer.

switch(config)# mpls tunnel static top-label 1002 100.1.1.2 bgp peer 100.1.1.1 pop payload-type ipv4
switch(config)# mpls tunnel static top-label 1002 100.1.1.3 bgp peer 100.1.1.1 pop payload-type ipv4

Multiple nexthops can be associated with the same BGP peer by explicitly specifying the BGP peer IP. This is useful in the case of third-party nexthops.
```
switch(config)# mpls tunnel static top-label 1000 nexthop-group mygroup bgp peer 100.1.1.1 pop payload-type ipv4
```

mpls static vrf-label

Use the mpls static vrf-label command to configure a static VRF label route. The no and default versions of the command removes the configuration.

Command Mode

Global configuration mode

Command Syntax

mpls static vrf-label mpls-label [vrf vrf-name]

no mpls static vrf-label mpls-label [vrf vrf-name]

default mpls static vrf-label mpls-label [vrf vrf-name]

Parameters

mpls-labelValue of the MPLS label.
vrf vrf-nameVRF instance name.

Example

switch(config)# mpls static vrf-label 100 vrf default
switch(config)# mpls static vrf-label 200 vrf v1

mpls tunnel termination

Command Mode

Global configuration mode

Command Syntax

mpls tunnel termination [ model [php model][ttl [[pipe | uniform] dscp]| pipe | uniform]

no mpls tunnel termination [model [php model][ttl [[pipe | uniform] dscp]| pipe | uniform]

default mpls tunnel termination [model [php model][ttl [[pipe | uniform] dscp]| pipe | uniform]

Parameters

modelTunnel termination TTL and DSCP model.
phpPenultimate hop popping configuration.
ttlModel for TTL.
pipePreserve the inner value.
uniformPropagate value from outer header.
dscpmode for DSCP.

Example

switch(config)# mpls tunnel termination model ttl uniform dscp pipe

mpls tunnel termination (vrf qos map)

The mpls tunnel termination (vrf qos map) command changes configuration mode to allow the attachment of DSCP-to-traffic-class maps to specific VRFs. This is a group change command, so no changes are made to the running config until the exit command is issued.

MPLS tunnel termination mode has one subcommand, vrf. vrf is also a group change command, with the subcommand qos map dscp to traffic-class.

Command Mode

Global Configuration

Command Syntax

mpls tunnel termination

Subcommand

vrf

Example

These commands enter MPLS Tunnel Termination Configuration mode and attach the DSCP-to-traffic-class map map1 to the VRFs newVRF1 and newVRF2.

switch(config)# mpls tunnel termination
switch(config-mpls-tunnel-termination)# vrf newVRF1
switch(config-mpls-tunnel-termination-vrf-newVRF1)# qos map dscp to traffic-class map1
switch(config-mpls-tunnel-termination-vrf-newVRF1)# exit
switch(config-mpls-tunnel-termination)# vrf newVRF2
switch(config-mpls-tunnel-termination-vrf-newVRF2)# qos map dscp to traffic-class map1
switch(config-mpls-tunnel-termination-vrf-newVRF2)# exit
switch(config-mpls-tunnel-termination)# exit
switch(config)# exit

mpls tunnel static

The mpls tunnel static command in the Global Configuration Mode prevents installing a backup path for Destination-based Remote Triggered Black Hole used to prevent DoS attacks on a target network by dropping traffic destined for the target. The route points to a null tunnel and drops the traffic.

The [no | default] versions of the command remove the configuration from the running-config.

Command Mode

Global Configuration

Command Syntax

mpls tunnel static tunnel-name tunnel-endpoint Null0

[no | default] mpls tunnel static tunnel-name tunnel-endpoint Null0

Parameters

tunnel-name - Specify a name for the static tunnel.
tunnel-endpoint - Specify an IP address
Null0 - Specify the interface that drops all traffic.

Example

Use the following command to configure a static tunnel, tun-rtbh1, and IP address, 192.0.1.2, as the destination for DoS traffic:

switch(config)# mpls tunnel static tun-rtbh1 192.0.1.2 Null0

neighbor

The neighbor ip_address command in the MPLS LDP Configuration Mode configures an IP address for an LDP neighbor for authentication or as a targeted peer.

The no version of the command disables the feature on the switch.

Command Mode

MPLS LDP Configuration

Command Syntax

neighbor ip_address [authentication index password_index active] [targeted]

no neighbor ip_address

Parameters

neighbor ip_address - Specify an IPv4 address for the LDP neighbor.
authentication index password_index active - Specify an authentication index value from 1 to 4294967295 and activate it.
targeted - Configure the LDP neighbor as a targeted peer.

Example

Use the following commands to configure the LDP neighbor, 192.168.168.25, as a targeted peer:

switch(config)# mpls ldp
switch(config-mpls-ldp)# neighbor 192.168.168.25 targeted
switch(config-mpls-ldp)#

neighbor end-of-lib

The neighbor end-of-lib command in the MPLS LDP Configuration Mode allows an LDP speaker to notify a neighbor after completion of advertising all labels from the Label Information Base (LIB). This allows the completion of these advertisements as soon as possible and return the network to an optimal state.

The no | default version of the command disables the feature.

Command Mode

MPLS LDP Configuration

Command Syntax

neighbor end-of-lib

no neighbor end-of-lib

default neighbor end-of-lib

Parameters

neighbor - Specify configuring an LDP neighbor.
end-of-lib - Specify to send a signal after label advertisement completion.

Example

Use the following commands to enable sending a signal after label advertisement completion:

switch(config)# mpls ldp
        switch(config-mpls-ldp)# neighbor end-of-lib

neighbor hello-redundancy

The neighbor hello-redundancy command in the MPLS LDP Configuration Mode configures an LDP neighbor to send LDP Hellos on a primary interface. This allows the LDP session to stay active in the event of a link failure.

The no or none version of the command disables the feature on the switch.

Command Mode

MPLS LDP Configuration

Command Syntax

neighbor hello-redundancy [duration [infinite | seconds] none]

no neighbor hello-redundancy

neighbor hello-redundancy none

Parameters

duration [infinite | seconds - Specify to retain redundant targeted adjacencies indefinitely or set the duration in seconds from 0 to 4294967295.
none - Specify to disable hello redundancy for LDP.

Example

Use the following commands to set the hello redundancy to infinite:

switch(config)# mpls ldp
switch(config-mpls-ldp)# neighbor hello-redundancy duration infinite
switch(config-mpls-ldp)#

ping mpls rsvp session

LSP Ping allows the user to check if the remote endpoint of an RSVP session is reachable through the LSP. Running ping on an RSVP LSP creates an LSP Ping Request packet with the label programmed by RSVP and that packet will follow the MPLS path until it reaches the end of the tunnel. If the node that receives this Request is the intended destination, it replies with an RSVP Ping Reply through normal IP routing. When the source receives the Reply it indicates that there are no apparent data plane failures and that the endpoint of that LSP is reachable.

Command Mode

Configuration sub-mode for RSVP

Command Syntax

Parameters

id Specifies the session by ID
- num RSVP session ID.
  - lsp Specifies LSP
  - pad-reply Indicates that the reply should copy the pad TLV.
  - repeat Specifies repeat count.
  - source Specifies source address.
  - standard Sets the standard to comply with.
  - tos Specifies ToS value.
  - tos Specifies MPLS traffic class field.
name Specifies session by name.
- word RSVP session name.
  - lsp Specifies LSP
  - pad-reply Indicates that the reply should copy the pad TLV.
  - repeat Specifies repeat count.
  - source Specifies source address.
  - standard Sets the standard to comply with.
  - tos Specifies ToS value.
  - traffic-class Specifies MPLS traffic class field.

Examples

A user can invoke the ping utility for a specific LSP by using the session and LSP IDs displayed in the CLI show commands.

switch# ping mpls rsvp session id 1 lsp 1 repeat 3
LSP ping to RSVP session #1 LSP #1
   timeout is 5000ms, interval is 1000ms
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=1, time=53.294ms, success: egress ok
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=2, time=75.329ms, success: egress ok
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=3, time=85.574ms, success: egress ok

--- RSVP target fec 0.4.4.4 : lspping statistics ---
Via 10.0.12.2, Ethernet1, label 100000
   3 packets transmitted, 3 received, 0% packet loss, time 2272ms
   3 received from 10.0.34.4, rtt min/max/avg 53.294/85.574/71.399 ms

For the ping mpls rsvp session command, the argument lsp is optional. If unspecified, the utility pings all LSPs within that session.

switch# ping mpls rsvp session id 1 repeat 2
LSP ping to RSVP session #1
   timeout is 5000ms, interval is 1000ms
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=1, time=60.28ms, success: egress ok
LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   Reply from 10.0.34.4: seq=1, time=81.701ms, success: egress ok
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=2, time=52.807ms, success: egress ok
LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   Reply from 10.0.34.4: seq=2, time=62.814ms, success: egress ok

--- RSVP target fec 0.4.4.4 : lspping statistics ---
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   2 packets transmitted, 2 received, 0% packet loss, time 1262ms
   2 received from 10.0.34.4, rtt min/max/avg 52.807/60.280/56.544 ms

LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   2 packets transmitted, 2 received, 0% packet loss, time 1262ms
   2 received from 10.0.34.4, rtt min/max/avg 62.814/81.701/72.257 ms

Similarly, the session can be specified by name and the utility pings all the LSPs within that session.

switch# ping mpls rsvp session name Session1to4 repeat 2
LSP ping to session Session1to4
   timeout is 5000ms, interval is 1000ms
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=1, time=63.314ms, success: egress ok
LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   Reply from 10.0.34.4: seq=1, time=75.639ms, success: egress ok
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   Reply from 10.0.34.4: seq=2, time=60.875ms, success: egress ok
LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   Reply from 10.0.34.4: seq=2, time=77.135ms, success: egress ok

--- RSVP target fec 0.4.4.4 : lspping statistics ---
LSP 1
Via 10.0.12.2, Ethernet1, label 100000
   2 packets transmitted, 2 received, 0% packet loss, time 1262ms
   2 received from 10.0.34.4, rtt min/max/avg 60.875/63.314/62.094 ms

LSP 2
Via 10.0.12.2, Ethernet1, label 100002
   2 packets transmitted, 2 received, 0% packet loss, time 1262ms
   2 received from 10.0.34.4, rtt min/max/avg 75.639/77.135/76.387 ms

preemption method

The preemption method command enables deferred failure of RSVP-TE LSPs on link oversubscription. Use a preemption timer value to configure a delay on a transit router to support LSPs signaled with soft preemption enabled by the headend (RFC 5712).

The default preemption method is soft preemption with a timer value of 30 seconds.

Command Mode

Configuration sub-mode for RSVP

Command Syntax

preemption method [hard | soft ] timer t

no preemption method [hard | soft ] timer t

default preemption method [hard | soft ] timer t

Parameters

hard Hard preemption.
soft Soft preemption.
- timer Time limit for LSP teardown.
  - t 1-65535 Timer value in units of seconds.

Examples

In this example, the preemption method is soft preemption with a timer value of 10 seconds.
```
(config-mpls-rsvp)# preemption method soft timer 10
```
Setting the preemption method to hard preemption results in a timer value of 0 seconds and disables the feature.
```
(config-mpls-rsvp)# preemption method hard
```

refresh method

Using the refresh method command with the bundled keyword enables the Refresh Overhead Reduction that supports the sending of message IDs and refreshing state with refresh messages.

Command Mode

Configuration sub-mode for RSVP

Command Syntax

refresh method [bundled | explicit ]

Parameters

bundled Refresh states using message identifiers lists. This is the default setting.
explicit Send each message individually.

Examples

Use the bundled keyword to enable the Refresh Overhead Reduction.
```
(config-mpls-rsvp)# refresh method bundled
```
To turn off refresh overhead reduction, use the explicit keyword.
```
(config-mpls-rsvp)# refresh method explicit
```

show mpls parsing speculative

The show mpls parsing speculative command displays information about the MPLS Speculative Parsing configuration.

Command Mode

Global Configuration

Command Syntax

show mpls parsing speculative

Parameters

parsing - Configure parsing of MPLS packets.
speculative - Configure speculative parsing of different types of MPLS encapsulated packets for all data plane features.
control-word - Enable parsing MPLS pseudowire packets with a control word.
ethernet - Enable parsing MPLS encapsulated Ethernet packets.
ipv4 - Enable parsing MPLS encapsulated IPv4 packets.
ipv6 - Enable parsing MPLS encapsulated IPv6 packets.

Example

Use the following command to display information about the MPLS configuration:

switch#show mpls parsing speculative
Packet Type        Status  
------------------ --------
Control Word       disabled
Ethernet           disabled
IPv4               enabled
IPv6               enabled

show mpls route summary

The show mpls route summary command displays statistics about the configuration and implementation of MPLS rules.

Command Mode

EXEC

Command Syntax

show mpls route summary

Example

This command displays a summary of MPLS rule implementation.

switch> show mpls route summary
Number of Labels: 1 (1 unprogrammed)
Number of adjacencies in hardware: 0
Number of backup adjacencies: 2
switch>

show mpls route

The show mpls config route command displays the switch’s MPLS static rule configuration for the specified routes and rules.

Command Mode

EXEC

Command Syntax

show mpls [INFO_LEVEL] route [header_label]

Parameters

INFO_LEVEL Specifies the filters that are used to select the routes to display. Options include:
- no parameter Displays routes published by the forwarding agent.
- config Displays all configured routes.
- lfib Displays routes stored to the Label Forwarding Information Base (LFIB).
header_label Filters routes by MPLS top header label. Options include:
- no parameter Displays routes for all header values.
0 to 1048575 Specifies header for which command displays information.

Examples

This command displays the MPLS rule configuration.

switch# show mpls config route
Codes: S - Static MPLS Route, IA - IS-IS SR Adjacency Segment,
       IP - IS-IS SR Prefix Segment, L - LDP,
       I>L - IS-IS SR Segment to LDP, L>I - LDP to IS-IS SR Segment, R - RSVP

In-Label Out-Label Metric Payload NextHop   Egress-ACL Status Monitored     
-------- --------- ------ ------- --------- ---------- ------ --------------
1000     pop       100    ipv4    100.0.0.1 apply      up                   
1001     pop       100    ipv4    20.0.0.2  apply      down                 
1002     pop       100    ipv4    100.0.0.2 apply      down   100.0.0.2(Bgp)
1003     pop       100    ipv4    20.0.0.2  apply      down   100.0.0.2(Bgp)
1004     pop       100    ipv4    20.0.0.2  apply      up     20.0.0.2(Bgp) 
1005     pop       100    ipv4    30.0.0.3  apply      up     200.0.0.3(Bgp)

The status could be down if either of the following is true

Nexthop is not resolved (show ip route nexthop - shows no route).
The monitored BGP session is down (show ip bgp summary - shows the peer is not in established state).

The following example shows that the first route is down because the BGP peer session is down.

switch# show mpls config route 
Codes: S - Static MPLS Route, IA - IS-IS SR Adjacency Segment,
       IP - IS-IS SR Prefix Segment, L - LDP,
       I>L - IS-IS SR Segment to LDP, L>I - LDP to IS-IS SR Segment, R - RSVP

In-Label Out-Label Metric Payload NextHop  Egress-ACL Status Monitored    
-------- --------- ------ ------- -------- ---------- ------ -------------
88886    pop       100    ipv4    14.0.0.4 apply      down   14.0.0.4(BGP)
88887    pop       100    ipv4    15.0.0.5 apply      down

The following example shows the status of label 88886 is down because the BGP peer session to 14.0.0.4 is down, but route exists for 14.0.0.4.

switch# show ip bgp summary 
BGP summary information for VRF default
Router identifier 3.0.1.3, local AS number 3000
Neighbor Status Codes: m - Under maintenance
  Neighbor V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  14.0.0.4 4 4000              16        18    0    0 01:04:42 Active

switch# show ip route 14.0.0.4

VRF: default
Codes: C - connected, S - static, K - kernel, 
 O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B - Other BGP Routes,
       B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
       I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate,
       A O - OSPF Summary, NG - Nexthop Group Static Route,
       V - VXLAN Control Service, M - Martian,
       DH - DHCP client installed default route,
       DP - Dynamic Policy Route, L - VRF Leaked,
       G  - gRIBI, RC - Route Cache Route

 S        14.0.0.4/32 [1/0] via 2.0.1.4, Ethernet2

show mpls tunnel termination qos maps

The show mpls tunnel termination qos maps command shows the DSCP to TC map associated with each VRF, or with a specified VRF.

Command Mode

Privileged EXEC mode

Command Syntax

show mpls tunnel termination qos maps [ vrf vrf_name ]

Parameter

vrf_name The VRF whose DSCP to TC map association is to be shown. If this parameter is omitted, all DSCP to TC maps associated with a VRF are shown.

Examples

This command shows the DSCP to TC maps associated with VRFs.

switch# show mpls tunnel termination qos maps
VRF newVRF1 DSCP to TC map: map1
VRF newVRF2 DSCP to TC map: map1
switch#

This command shows the DSCP to TC map associated with VRF newVRF2.

switch# show mpls tunnel termination qos maps vrf newVRF2
VRF newVRF2 DSCP to TC map: map1
switch#

show platform fap

The show platform fap command displays information about the Egress Encapsulation Database (EEDB), a hardware resource used to store encapsulation information for various networking features. The output displays the number of in-use, free, and maximum entries for MPLS tunnels, grouped by label count.

The following platforms support this command:

DCS-7020R4
DCS-7280R3, DCS-7280R4
DCS-7500R3
DCS-7800R3, DCS-7800R4

Command Mode

EXEC

Command Syntax

show platform fap fap-name eedb capacity mpls

Parameters

Labels - Displays the range of MPLS label counts for this group of tunnel entries. For example, a range of 1 to 21 to 2 indicates the row applies to all tunnels with a label stack size of either 1 or 2.
In Use - Displays the number of entries currently programmed in hardware for this label range.
Free - Displays the number of entries available for new tunnel programming in this label range.
Max - Displays the maximum number of entries supported by hardware for this label range.

Example

Use the following command to display EEDB information for Fap0:

switch# show platform fap Fap0 eedb capacity mpls
Labels   In Use   Free    Max
-------- ------ ------ ------
1 to 2       24  32744  32768
3 to 4        6  32762  32768
5 to 6        0  24576  24576
7 to 8        0  20480  20480
9 to 10       0  20480  20480
11 to 12      0  20480  20480

show traffic-engineering cspf path

Use the show traffic-engineering cspf path command to display all the paths counted by CSPF.

Command Mode

EXEC

Command Syntax

show traffic-engineering cspf path [destination-IP]detail]

Parameters

A.B.C.D CSPF path to this destination IP address.
detail Show detailed path information.

Examples

In this example, the CSPF destination path 20.0.0.1 is selected to display.

switch> show traffic-engineering cspf path 20.0.0.1

Destination     Constraint                           Path
20.0.0.1        exclude Ethernet1                    0.1.1.1
                exclude SRLG of Ethernet1            0.1.1.2
                                                     0.2.2.2
                                                     3.3.3.2
                exclude Ethernet2                    0.1.1.1
                                                     0.1.1.2
                                                     0.2.2.2
                                                     3.3.3.2

In this example, the CSPF destination path 20.0.0.1 is selected to display detailed information.

switch> show traffic-engineering cspf path 20.0.0.1 detail

Destination: 20.0.0.1
   Path Constraint: exclude Ethernet1
                    exclude SRLG of Ethernet1: orange-link (500), 
                       green-link (400), 100, red-link (200), 600
   Request Sequence number: 1
   Response Sequence number: 1
   Number of times path updated: 2
   Last updated: 00:01:58
   Reoptimize: Always
   Path:
  	0.1.1.1
  	0.1.1.2
  	0.2.2.2
  	3.3.3.2

   Path Constraint: exclude Ethernet2
   Request Sequence number: 2
   Response Sequence number: 2
   Number of times path updated: 3
   Last updated: 00:00:38
   Reoptimize: Always
   Path:
  	0.1.1.1
  	0.1.1.2
  	0.2.2.2
  	3.3.3.2

show traffic-engineering database

Command Mode

EXEC

Command Syntax

show traffic-engineering database

Special Considerations

Beginning with EOS Release 4.23.1F, the SRLG group details of a neighbor are shown if it is advertised.
Beginning with EOS Release 4.24.2F, information for the OSPFv2 topology is displayed if configured.

Example

switch# show traffic-engineering database

TE Router-ID: 1.0.0.2
  Source: IS-IS Level-1 IPv4 Topology Database
    IS-IS System-ID: 1111.1111.1001
      Number of Links: 2
        Network type: P2P 
          Neighbor: 1111.1111.1002
		 Administrative group (Color): 0x123a
            TE Metric: 30
            IPv4 Interface Addresses:
              20.20.20.1
              192.168.20.1
            IPv4 Neighbor Addresses:
              20.20.20.2
              192.168.20.2
            Maximum link BW: 25.00 Gbps
            Maximum reservable link BW: 10.00 Mbps
            Unreserved BW:
              TE class 0: 9.00 Mbps     TE class 1: 9.00 Mbps
              TE class 2: 8.5.00 Mbps   TE class 3: 8.00 Mbps
              TE class 4: 7.00 Mbps     TE class 5: 7.50 Mbps
              TE class 6: 6.00 Mbps     TE class 7: 6.00 Mbps                                                                                        
        Network Type: LAN  
          Neighbor: 1111.1111.1003.02
            TE Metric: 30    
        	Administrative Group: 0x12     
            IPv4 Local Addresses:
              30.30.30.1                                                                                                      
            Maximum Link BW: 10.00 Gbps                                                                                       
            Maximum Reservable Link BW: 10.50 Gbps                                                                             
            Unreserved BW:                                                                                                     
              TE-Class 0: 8.50 Gbps       TE-Class 1: 8.70 Gbps                                                               
              TE-Class 2: 7.50 Gbps       TE-Class 3: 7.25 Gbps                                                               
              TE-Class 4: 6.50 Gbps       TE-Class 5: 7.30 Gbps                                                               
              TE-Class 6: 3.50 Gbps       TE-Class 7: 7.20 Gbps
  Source: IS-IS Level-2 IPv4 Topology Database  
    IS-IS System-ID: 1111.1111.1003
      Number of Links: 1  
        Network Type: LAN
         Neighbor: 1111.1111.1003.16
           IPv4 Local Addresses:
             40.40.40.1
            Maximum link BW: 10.00 Gbps
            Maximum reservable link BW: 5.00 Gbps
            Unreserved BW:
              TE class 0: 4.00 Gbps     TE class 1: 4.00 Gbps
              TE class 2: 4.00 Gbps     TE class 3: 4.00 Gbps
              TE class 4: 3.00 Gbps     TE class 5: 3.00 Gbps
              TE class 6: 3.00 Gbps     TE class 7: 3.00 Gbps
  Source: OSPFv2 Instance ID 33 Area-ID 0.0.0.0 Topology Database
    OSPFv2 Router-ID: 1.2.3.4
      Number of Links: 2
        Network type: P2P
          Neighbor: 3.4.5.6
            Administrative group (Color): 0x123a
            TE metric: 30
            IPv4 Interface Addresses:
              20.20.20.1
              192.168.20.1
            IPv4 Neighbor Addresses:
              20.20.20.2
              192.168.20.1
            Maximum link BW: 25.00 Gbps
            Maximum reservable link BW: 10.00 Mbps
            Unreserved BW:
              TE class 0: 9.00 Mbps    TE class 1: 9.00 Mbps
              TE class 2: 8.50 Mbps    TE class 3: 8.00 Mbps
              TE class 4: 7.00 Mbps    TE class 5: 7.50 Mbps
              TE class 6: 6.00 Mbps    TE class 7: 6.00 Mbps
        Network type: LAN
          Neighbor: 2.3.4.5
            Administrative group (Color): 0x12
            TE metric: 30
            IPv4 Interface Addresses:
              30.30.30.1
            IPv4 Neighbor Addresses:
              0.0.0.0
            Maximum link BW: 10.00 Gbps
            Maximum reservable link BW: 10.5 Gbps
            Unreserved BW:
              TE class 0: 8.50 Gbps    TE class 1: 8.70 Gbps
              TE class 2: 7.50 Gbps    TE class 3: 7.25 Gbps
              TE class 4: 6.50 Gbps    TE class 5: 7.30 Gbps
              TE class 6: 3.50 Gbps    TE class 7: 7.20 Gbps                                                                                         
TE Router-ID: 1.0.0.3
  Source: IS-IS Level-1 IPv4 Topology Database
    IS-IS System-ID: 1111.1111.1004
      Number of Links: 2
        Network type: P2P
          Neighbor: 1111.1111.1002
          IPv4 Interface Addresses:
              1.0.5.1
            IPv4 Neighbor Addresses:
              1.0.5.2
            Maximum link BW: 50.00 Gbps
            Maximum reservable link BW: 10.00 Gbps
            Unreserved BW:
              TE class 0: 8.00 Gbps     TE class 1: 8.00 Gbps
              TE class 2: 8.00 Gbps     TE class 3: 8.00 Gbps
              TE class 4: 7.00 Gbps     TE class 5: 7.00 Gbps
              TE class 6: 7.00 Gbps     TE class 7: 7.00 Gbps
            Shared Risk Link Group:
              Group: 100
              Group: green-link (150)

shutdown

The shutdown command disables the RSVP-TE protocol instance or the RSVP-related functions for the interface. The RSVP-TE configuration information associated with the interface is retained.

RSVP-TE is enabled globally by issuing no shutdown in the configuration sub-mode. This is the only mandatory setting for RSVP-TE to work. There is no per-interface knob to enable or disable RSVP. However, RSVP is only enabled on interfaces on which MPLS is enabled.

Command Mode

Configuration sub-mode for RSVP

Command Syntax

shutdown

no shutdown

Examples

You can enable RSVP-TE globally by issuing the no shutdown command.
```
(config-mpls-rsvp)# no shutdown
```
Similarly, it is disabled with the shutdown command, which is the default.
```
(config-mpls-rsvp)# shutdown
```

srlg

The srlg command specifies if link SRLGs of a primary LSP are to be considered as constraints while creating a fast-reroute bypass tunnel with either link or node protection. When the srlg command is specified with strict keyword, then when a path for a bypass tunnel excluding SRLGs of next-hop interface of primary LSP can not be found, RSVP does not setup the bypass tunnel. When the srlg command is specified without the strict keyword, then a bypass tunnel is setup with as many links as possible that exclude the SRLGs of next-hop interface of primary LSP and where such links are not available, links that have the least number of SRLGs which are to be excluded are used.

When this CLI is not configured, the behavior remains the same as before, which is to turn off SRLG processing. Therefore, the no and default versions of the command takes you back to the default of SRLG processing being turned off.

Command Mode

Configuration sub-mode for RSVP

Command Syntax

srlg strict

no srlg strict

default srlg strict

Parameters

strict Applies strict SRLG constraints.

Example

The SRLGs of an interface can be configured using the following traffic-engineering CLIs.

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

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

vrf (MPLS tunnel termination)

The vrf (MPLS tunnel termination) command places the switch in MPLS Tunnel Termination VRF Configuration mode. There is one command available in this mode: qos map dscp to traffic-class (MPLS tunnel termination VRF).

Command Mode

MPLS Tunnel Termination Configuration mode

Command Syntax

vrf vrf_name

Parameter

vrf_name The name of the VRF to configure. This does not create a VRF. The VRF must be created with the vrf command in Configuration mode.

Example

These commands place the switch in MPLS Tunnel Termination VRF Configuration mode for VRF newVRF1.

switch(config)# mpls tunnel configuration
switch(config-mpls-tunnel-configuration)# vrf newVRF1
switch(config-mpls-tunnel-configuration-vrf-newVRF1)#

Page 2 of 17

End of Support

LDP Graceful Restart

LDP Graceful Restart Conditions

Configuring an LDP Graceful Restart Speaker

Configuring Graceful Restart Speaker Parameters

Configuring an LDP Graceful Restart Helper

Configuring Graceful Restart Helper Parameters

RSVP-TE Commands

administrative-group

alias endpoint

authentication index

authentication sequence-number window

authentication type

bandwidth

clear mpls rsvp counters

clear mpls rsvp session

color

cspf delay

cspf ecmp tie-break

destination ip

ecmp shrinkage disable

fast-reroute bypass tunnel optimization interval

fast-reroute mode (RSVP tunnel)

fast-reroute mode

fast-reroute reversion

graceful-restart role

hello interval

hardware next-hop fast-failover

hello-redundancy

hitless-restart

hop (dynamic path)

hop (explicit path)

label local-termination

igp shortcut

local-interface

lsp no-path preservation timer

lsp self-ping

metric

mpls rsvp

mtu signaling

neighbor authentication index

neighbor authentication type

optimization interval

p2mp

path (path specification)

path (RSVP tunnel)

ping mpls rsvp session

preemption method

priority

refresh interval

refresh method

refresh rsvp tunnel optimization

router traffic-engineering – not an RSVP command

rsvp

rsvp bypass administrative-group

show mpls rsvp

show mpls rsvp counters

show mpls rsvp neighbor

show mpls rsvp session

show rib system-tunneling-ldp-rib route ip

show traffic-engineering cspf path

show traffic-engineering database

show traffic-engineering rsvp tunnel detail

show traffic-engineering rsvp tunnel history

show traffic-engineering rsvp tunnel lsp

show traffic-engineering rsvp tunnel name

show traffic-engineering rsvp tunnel sub-tunnel summary

show traffic-engineering rsvp tunnel summary

show traffic-engineering rsvp tunnel

show traffic-engineering rsvp

shutdown (MPLS RSVP)

shutdown (tunnel)

split-tunnel

srlg

neighbor <IP> targeted

timer recovery

timer restart

traffic-engineering srlg

tunnel

tunneling ldp