Configuring RSVP-TE

The configuration of RSVP-TE requires the configuration of one or more of the following:

Configuring RSVP-TE LER
Configuring RSVP-TELSR
Configuring RSVP-TE P2MP LER
Configuring RSVP-TE P2MP LSR

Configuring RSVP-TE LER

Enable the dedicated RSVP-TE LER configuration mode by entering the router traffic-engineering – not an RSVP 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 three components for P2P tunnels:

Global configuration: All settings apply to all configured tunnels.
Path specifications: Describes a set of constraints for paths.
Tunnel specifications: Describes which path each tunnel can take.Also includes per-tunnel configuration, fast-reroute, metric, and profiles.

Configuration Example

Enable IP routing.

switch(config)# ip routing
switch(config)#

Before starting RSVP-TE, make sure that MPLS is enabled (add x-ref to MPLS section 19.1) and a local interface is used to derive the source IP address for RSVP-TE tunnels.
Note: This is a mandatory setting.
```
switch(config-te-rsvp)# local-interface Loopback 0
```

ISIS or OSPF needs to be enabled for traffic-engineering. For more information about ISIS, refer to (add x-ref to section 15.4):

switch(config)# router isis 1 
switch(config-router-isis)#traffic-engineering
switch(config-router-isis-te)# no shutdown
switch(config-router-isis-te)# is-type level-2

MPLS interfaces have to be enabled globally for traffic-engineering by issuing no shutdown in the configuration sub-mode.
```
switch(config)# mpls rsvp
switch(config-mpls-rsvp)# no shutdown
```

RSVP-TE is enabled globally by issuing no shutdown in the configuration sub-mode.

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

Note: Additional LER configurations may be configured, since they apply to all tunnels by default, but can then typically be overridden by the tunnel. These include FRR mode, SRLG mode, preemption timers, GR/HR settings, MTU signaling, CSPF ECMP tie-break settings, and lsp self-ping. More information is available in RSVP-TE Commands.

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 either be 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 explicit submode is used to configure explicit paths.

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 before and after keywords allow the insertion of new hops in any 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 thekeyword no nop.

switch(config-te-rsvp-path-expl-MyPath)# no hop 10.0.12.2

Dynamic Path Specifications

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

The dynamic submode is used to configure dynamic paths.

switch(config-te-rsvp)# path MyPath dynamic
switch(config-te-rsvp-path-dyn-MyPath)#

The keyword exclude specifies 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.

Note: Other interfaces on the same node may be used.

switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.56.6 exclude

The keyword include specifies that it must be included in the computed path in a certain order. By default, a hop is strict, meaning that it must appear directly after the previously specified hop. A hop can be loose, allowing other hops to be filled by the CSPF procedure.

switch(config-te-rsvp-path-dyn-MyPath)# hop 10.0.56.6 include

The keyword administrative-group 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 not in any of those in the exclude range. The admin group range starts at 0 and ends at 31.

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

Administrative groups can be specified using a name as an alias mapped to a numerical value. The mapping can be configured in global TE mode. Please refer to IS-IS Traffic-Engineering TOI for details.

These names can be directly used to configure administrative group constraints in addition to the numerical format. The list of administrative groups should be comma-separated without spaces.

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

Tunnel specifications

Tunnel specification has its own submode tunnel .

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

Basic Tunnel Configuration

Each tunnel must have a tunnel destination IP.

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

Adding Path Specifications

A tunnel needs to specify the path on which its LSPs should be established. For this, a path specification is referenced by its name, which configures the primary LSP.

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

A secondary LSP may be specified, providing a fallback in case the primary LSP is not available. 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

Bandwidth Specification

A tunnel can be used to reserve bandwidth along the path with an explicit configuration. Available units are bps, kbps, mbps, and gbps. By default, no bandwidth reservation is signalled.

switch(config-te-rsvp-tunnel-myTunnel)# bandwidth 10 mbps

An alternative to explicit bandwidth configuration is the auto command, which specifies the minimum and maximum bandwidth for the tunnel and adjusts bandwidth with an adjustment period based on the observed traffic. The adjustment period is an optional parameter measured in seconds. The default adjustment period is 0, meaning the algorithm decides when to adjust bandwidth.

switch(config-te-rsvp-tunnel-myTunnel)# bandwidth auto min 1 mbps max 5 mbps adjustment-period 60

Tunnel priorities

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

Note:The hold priority should have a lower value (more preferred) than the setup priority to avoid cycles where 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 in steering traffic into the tunnel.

Note: This color attribute is strictly a local attribute.

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

Enabling the Tunnel

Tunnels are not enabled by default. It must be enabled using the no shutdown command to leave the tunnel sub-mode.

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

Note: None of the per-tunnel settings take effect if a command other than no shutdown is used to leave the tunnel sub-mode. This includes exit. Use abort to cancel all changes and leave the command mode.

To view the active configuration, use the show active command. To view the pending configuration, use the show pending command. To view the differences between the active and the pending configurations, use the show diff command.

Tunnel Participation in IGP Shortcuts and LDP over RSVP

To specify an RSVP tunnel to participate in IGP shortcuts, use the igp shortcut command.

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

Periodic tunnel optimization can be configured globally or individually for a specific tunnel. The optimization interval is configured in config-te-rsvp mode for global periodic tunnel optimization..

switch(config-te-rsvp)# 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, use the following commands.

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

Tunnel Endpoint Aliases

Configuring alias IPv4 and IPv6 endpoints per tunnel 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 the bandwidth for a tunnel between multiple sessions. With this feature enabled, RSVP will automatically create multiple LSPs with smaller bandwidth reservations for a single tunnel.

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

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 is done by configuring the min/max with the split-tunnel configuration. Each sub-tunnel grows and shrinks between these values, as opposed to being of a fixed size in the regular split tunnel case.

Note: Adaptive split-tunnels cannot be configured with explicit fixed bandwidth configuration, and instead, auto-bandwidth must always be used.

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

If the bandwidth has been reduced enough that it can be satisfied by fewer sub-tunnels than what currently exists, sub-tunnels will not be deleted immediately. There is a delay after which these extra sub-tunnels get removed. This reduction-delay is configurable and has a default value of 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

The limit on the number of sub-tunnels is also configurable. Even if the last computed bandwidth requires more sub-tunnels, the number will be capped at that limit. The default limit is 10.

switch(config-te-rsvp-tunnel-myTunnel)# split-tunnel min 1 gbps max 50 gbps sub-tunnels limit 10

Tunnel Metric

The tunnel metric feature is used to configure a per RSVP tunnel metric so that specific tunnels to a TEP can take precedence over other tunnels to the same TEP when forming ECMP. The tunnel metric is published to the tunnel RIB to be considered for BGP cost calculations.

switch(config-te-rsvp-tunnel-myTunnel)# metric 10

A dynamic metric mode that follows the IGP metric is also available.

switch(config-te-rsvp-tunnel-myTunnel)# metric igp

Configuring RSVP-TE LSR

Basic Configuration

The device needs to be in the 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
```
Configure the state refresh interval. This affects how often state refresh messages are sent. The interval parameter is in seconds. The default value is 30 seconds.
```
switch(config-mpls-rsvp)# refresh interval 30
```
Configure the hello interval. 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 for the period of the interval multiplied by the multiplier value (4*10=40 seconds), the configuration loses connectivity and resets the neighbor. Hellos are one way to determine that a neighbor is unreachable, BFD can also be used.
Note: Configuring the hello interval is optional.
```
switch(config-mpls-rsvp)# hello interval 10 multiplier 4
```
Configure the refresh method, which supports sending message IDs and refreshing state with Srefresh messages. This is an optional configuration setting which reduces signaling overhead at high scale. When the Srefresh method is set to bundled, it enables Refresh Overhead Reduction which supports sending message IDs and refreshing state with Srefresh messages.
```
switch(config-mpls-rsvp)# refresh method bundled
```

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.

Configuring Traffic Engineering

For CSPF to compute the FRR backup path to a particular destination, enable traffic engineering on all the IGP-enabled interfaces, and globally enable the traffic engineering extensions. For IS-IS, enable under the Router ISIS configuration mode, for OSPFv2, enable 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 it can find a path to it. CSPF also uses its own router-id as a source for running SPF. So a router-id is required to be configured under router traffic-engineering mode for CSPF to function properly.

Cryptographic Authentication Extension

Enable Cryptographic Authentication by configuring the authentication type to md5 and adding an active password.

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. Authentication of all incoming packets accepts all configured passwords, allowing smooth key rollover.

Configuring Fast Reroute Extension

This setting applies to the Point of Local Repair (PLR) behavior. The router may be a PLR if it is the upstream node relative to a protected link or node for routing an LSP. Merge Point (MP) behavior is not affected by this setting. In addition to affecting PLR behaviour, if the node is the headend for LSPs this also determines which local-protection mode is requested by the LSP.

Enable Fast ReRoute (FRR) link protection by setting the Fast Reroute mode to link-protection.

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

Enable Node Protection using the parameter node-protection Available options include:

link-protection which protects against failure of the next link.
Node-protection protects against failure of the next node.
None disables fast reroute.

You can change the reversion behavior of FRR from global revertive mode to the local revertive mode. An LSR reroutes over a bypass tunnel because the downstream link failed. With global reversion the LSR will keep using the bypass tunnel to reroute traffic for the affected LSPs, even if the link recovers. This expects the headend router to set up a new LSP upon notification that a link is no longer available. With local reversion, the LSR switches back to using the primary link after recovery.

Note: Node protection will always use global reversion on the PLR, even if local reversion is configured

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

Note: The default for reversion is global.

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 bypassing that interface, including link and node protection.

Administrative group constraints can be configured for 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 without spaces.

Administrative group constraints are represented with a single 512-bit value, where each bit represents a single admin group, supporting administrative groups in the range of 0 to 511. Administrative groups can also be directly specified in the command in hexadecimal format, where each bit represents a single admin group:

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

Note: The hexadecimal format is limited to a 32-bit value, and thus can only specify admin groups in the 0-31 range.

Administrative group constraints can be specified using the administrative-group alias ALIAS group VALUE command in the router traffic-engineering mode. These names can be directly used to configure administrative group constraints in addition to the existing numerical format in the range of 0-511:

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 can be considered as constraints when creating a fast-reroute bypass tunnel with either link or node protection. When using srlg with the strict keyword, and if a path for a bypass tunnel excluding SRLGs of the next-hop interface of primary LSP can not be found, RSVP does not setup the bypass tunnel. 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 primary LSP.

switch(config-mpls-rsvp)# srlg

If not configured, the behavior remains the same, SRLG processing is turned off . The no and default versions of the command return to the default of behavior no SRLG processing.

The CSPF path selection process will choose the path where the shared unique Shared Risk Link Groups (SRLGs) have the lowest cost. This is to enable users to quantify the risk of a particular SRLG in their network. This is configured using the cost keyword followed by the desired cost as a number between 1-4294967295. If no cost is specified for an SRLG, it will have the default cost of 100. Without any costs configured, the CSPF path selection process will behave as before and choose the path with the fewest shared SRLGs.

The SRLGs of an interface can be configured using the following commands:

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

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

Note: Although many of SRLGs can be configured on an interface, Constrained Shortest Path First (CSPF) only tconsiders a maximum of 16 SRLGs for finding a path with 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 frequent events occur on the network. Use the Router Traffic Engineering configuration mode 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. Use the following commands to configure CSPF to an initial wait interval of 200 milliseconds, a back-off interval of 400 milliseconds, and a maximum wait interval of 2000 milliseconds:

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

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 MTU Signaling

RSVP can discover the lowest Maximum Transmission Unit (MTU) used along an LSP by evaluating and updating the MTU at each hop on which MTU signaling is enabled. The MTU will still be updated at other nodes in the path that have MTU signaling enabled. Additionally, if MTU signaling is not enabled at the headend then MTU signaling is not done at all for the LSP.

switch(config-mpls-rsvp)# mtu signaling

Configuring a Preemption Method

The preemption method is configured using the preemption method command. Soft preemption enables the deferred failure of RSVP-TE LSPs on a link oversubscription. Configure a preemption timer value to create a delay on a transit router to support LSPs signaled with soft preemption enabled by the headend. The default timer value is 30 seconds. The delay is the waiting period before tearing down the LSP.

The following example uses the preemption method soft timer command to configure the preemption method as soft preemption with a timer value of 10 seconds.

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

The alternative is hard preemption. Setting the preemption method to hard preemption results in a timer value of 0 seconds and disables the soft preemption feature.

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.

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 starts when a Hello Message times out, which marks the end of an RSVP neighbor communication. If a neighbor advertises a non-zero restart time value, a timer starts after detecting a communication loss from that neighbor.

If an RSVP node does not receive a Hello Message from a neighbor before the end of the restart phase, Hello communication loss procedures begin on the network.
If an RSVP node receives a Hello message with the same source instance before the end of the restart phase, the network returns to a normal RSVP state.
If an RSVP node receives a Hello message from a neighbor with a different source instance before the recovery period starts, with a non-zero recovery value in the message, RSVP considers the neighbor as restarted, and a recovery phase begins.

Note: Path and Resv messages are paused during the restart phase.

During the recovery phase, outgoing RSVP reservation messages toward that neighbor pause until a path message for the same LSP is received from that neighbor. At the end of the recovery period, RSVP clears any data plane and control plane states from that neighbor not re-advertised since the restart of the RSVP neighbor.

The following is an example of configuring Helper Mode.

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

Note: Graceful Restart does not support Fast-Reroute events during the restart or recovery phases.

Configuring Speaker Mode

Use the following commands to enable Speaker mode and configure the requested restart and recovery values.

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

Configuring Hitless Restart

Similar to the Graceful Restart feature, but without any communication with RSVP neighbors, Hitless Restart allows the RSVP agents to be restarted without any data plane interruptions. There are no standard procedures for this, and for this reason, if Hello messages are enabled, any restart taking longer than the configured timeout for Hello messages will result in the communication detected as lost by the RSVP neighbors of the local node.

Hitless Restart does not have any restart phase, as this phase is only meaningful for the neighbors of a restarting node. It only has a recovery period, during which it will preserve the existing installed RSVP states, until either those RSVP states are refreshed by its neighbors through usual RSVP mechanisms, or until the recovery period ends, at which points those states will be cleared.

Hitless Restart allows the RSVP agents to be restarted without any data plane interruptions. The neighbors of a restarting node using Hitless Restart do not have any way of telling that the local node has restarted, and the source instance used in Hello messages will stay the same across restarts. 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

Explicit-Null

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

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

Sample 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 1.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

Configuring RSVP-TE P2MP LER

RSVP-TE P2MP LER adds ingress and egress support for Point-to-Multipoint (P2MP) LSPs to be used in Multicast Virtual Private Network (MVPN) as an extension of the LSR support which adds transit support.

There are two major parts to the configuration: BGP and RSVP.

BGP Configuration

To enable MVPN using an RSVP P2MP tunnel, the default encapsulation can be set to mpls protocol rsvp p2mp. An RSVP P2MP tunnel profile can be configured for the VRF, as shown in the following example. It can also be configured for all VRFs under the address-family mvpn-ipv4 config mode within router bgp.

switch# config
switch(config)# router bgp
switch(config-router-bgp)# show active
router bgp 100
   neighbor 4.4.4.4 remote-as 100
   neighbor 4.4.4.4 update-source Loopback0
   neighbor 4.4.4.4 send-community extended
   neighbor 5.5.5.5 remote-as 100
   neighbor 5.5.5.5 update-source Loopback0
   neighbor 5.5.5.5 send-community extended
   !
   address-family mvpn-ipv4
      neighbor 4.4.4.4 activate
      neighbor 5.5.5.5 activate
      neighbor default encapsulation mpls protocol rsvp p2mp
   !
   address-family vpn-ipv4
      neighbor 4.4.4.4 activate
      neighbor 5.5.5.5 activate
   !
   vrf red
      rd 1:1
      route-target import vpn-ipv4 100:1
      route-target export vpn-ipv4 100:1
      network 11.0.0.0/24
      !
         mvpn-ipv4
            rsvp p2mp tunnel profile MyProfile

If the tunnel profile is not configured, then an implicit

default
                    profile

is used, which does not contain any other configuration options, as shown in the following example.

switch# config
switch(config)# router bgp
switch(config-router-bgp)# vrf red
switch(config-router-bgp-vrf-red)# mvpn-ipv4
aip1(config-mvpn-ipv4-vrf-red)# show active
router bgp 1
   vrf red
      mvpn-ipv4
         pmsi-tunnel protocol rsvp p2mp

A VRF specific PMSI tunnel can be configured using the command pmsi-tunnel protocol rsvp p2mp.

Configuring RSVP

Enable RSVP P2MP signaling functionality, which is done by entering the p2mp submode.

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

Enable Fast Re-Route (FRR) in the mpls rsvp configuration mode on LER.

Note: For P2MP, only link protection is supported. Even if node protection is configured, it will mean that for P2P LSPs (LER/LSR), node protection will be requested and used if available and successfully created, but for P2MP LSPs, only link protection is supported.

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

The tunnel profile associated with the VRF above in the BGP configuration must be defined in the rsvp submode of router traffic-engineering as follows.

switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)# show active
router traffic-engineering
   rsvp
      tree ExpTree explicit
                leaf 4.4.4.4
                     hop 2.2.2.2 node
                     hop 4.4.4.4 node
                !
                leaf 5.5.5.5
                     hop 10.0.12.2
                     hop 4.4.4.4 node
                     hop 5.5.5.5 node
                  !
             !
            tunnel profile MyProfile p2mp
               tree ExpTree
switch(config-te-rsvp)#

This profile will serve as a template for all tunnels requested from BGP for VRFs that are configured to use this profile.

Note: Only destinations requested by BGP will actually be signaled as part of the RSVP P2MP tunnel.

Explicit Tree Specification

The configuration example above configures an explicit tree specification called ExpTree. For each leaf, each hop in the path to reach the leaf from the root needs to be explicitly configured. Any leaf that is not present in the explicit tree specification will not be part of the tunnel and will not be signaled.

By default, the configured IP of the hop must be the ingress IP interface of the node. Alternatively, a node hop can be specified using the node keyword, which allows the path to traverse any link to the specified node. IPs specified with the node keyword can be ingress addresses or TE router IDs. Node and non-node hops can be mixed for the same leaf, as in the example.

Dynamic Tree Specification

Alternatively, a Dynamic Tree Specification can be configured. A dynamic tree specification delegates the discovery of the tree to a CSPF run, allowing CSPF to find paths from the root to all leaves. A dynamic tree specification does not need to contain all leaves that are part of the tree. Tree-level constraints can be in the form of administrative group constraints.

The following example directs CSPF to only consider links that do not contain the administrative group associated with name red, and administrative group 10. As with P2P tunnels, administrative group constraints exclude, include all, and include any are supported and can be mixed freely.

switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)# show active
router traffic-engineering
   rsvp
      tree DynTree dynamic
         administrative-group exclude red,10
      !
      tunnel profile MyProfile p2mp
         tree DynTree
switch(config-te-rsvp)#

Default Tree Specification

If a tunnel profile does not specify the name of a tree specification then a default dynamic tree specification is applied. This is equivalent to configuring an empty dynamic tree specification, meaning the specification has no constraints. In this case, CSPF is used to find the paths to all leaves and can use any link because of the lack of constraints.

Interoperability

Routers from other vendors may not support signaling of multiple sub-LSPs per sub-group. A compatibility configuration option is available to limit sub-group size. That setting may need to be set to 1 for interoperability with routers from some other vendors.

Note: Signaling and processing are less efficient with a smaller sub-group size. The default is 20.

switch# config
switch(config)# mpls rsvp
switch(config-mpls-rsvp)# p2mp
switch(config-mpls-rsvp-p2mp)# sub-group limit 1 sub-lsps
switch(config-mpls-rsvp-p2mp)# exit
switch(config-mpls-rsvp)#

Configuring RSVP-TE P2MP LSR

RSVP-TE P2MP LSR adds transit support for Point-to-Multipoint (P2MP) LSPs. Specifically, the feature adds protocol support for the transit role.

RSVP P2MP functionality is enabled by entering the p2mp submode.

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.

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

Note: By default without the disabled command, P2MP is enabled as long as the mode is configured.

Use the same configuration methods and commands as RSVP-TE LSR.Refer to Configuring RSVP-TE LSR for more information.

Class Based Forwarding for MPLS Labeled Packets

Class Based Forwarding (CBF) provides a means for forwarding traffic through selected tunnels based on the traffic class of the incoming packet.CBF supports forwarding MPLS labeled traffic based on the EXP value in the incoming packet or the internal traffic class (TC) resolved from the parameters of the packet (e.g TC derived from EXP bits combined with port trust mode). Here, EXP bits refer to the Experimental bits in the MPLS header.

This feature enables a Label Switched Router, to steer labeled traffic (that has specific EXP values) into colored RSVP-TE tunnels. These colored tunnels are identified as follows:

The EXP value in the payload is mapped to a TC. The TC is mapped to a color via configuration.
Among RSVP tunnels configured with the mapped colors identified above, a suitable tunnel that terminates on the shortest path to the resolved destination is identified.

Traffic to that very label that does not have the EXP bits corresponding to a configured color-tc map is steered through an RSVP-TE tunnel mapped to a default color or an uncolored tunnel. If neither of those are available, the traffic will be steered through any available hop by hop path.

MPLS CBF can be configured on a headend node to allow different flows bound to the same endpoint to be steered into different paths. There are a few conditions required for CBF to use colored RSVP TE tunnels.

The RSVP-TE tunnel must be colored.
The RSVP-TE tunnels must be enabled for tunneling ldp, and must terminate on a node that is on the shortest path to the LDP destination.
Color-TC mapping must be configured for the associated color.
All the RSVP-TE tunnels to be considered for an LSP endpoint must terminate on the same node. Colored tunnels terminating on the nodes other than the node nearest to the destination are filtered out.

Fallback Precedence

Traffic that matches a colored tunnel will be steered through the colored tunnel, but traffic that does not match a configured/Up colored tunnel will be steered through the default tunnel. In case a default colored tunnel or an uncolored tunnel are not available, a colored tunnel can be used as the default FEC by enabling fallback-highest-colored-tunnel knob. In this case, the highest colored tunnel among the tunnels to a given destination is chosen for forwarding traffic that doesn't match any specified TC in the TC->color configuration.

Configuring Class Based Forwarding for MPLS Labeled Packets

This section provides an example for LDP CBF and an example for ISIS-SR CBF.

Configuration example for LDP CBF

Configuring MPLS CBF involves four major steps and one optional configuration.

Configuring colored LDP-over-RSVP-TE tunnels.

switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)# tunnel MyTunnel
switch(config-te-rsvp-tunnel-myTunnel)# color 60
switch(config-te-rsvp-tunnel-myTunnel)# tunneling ldp

Enable MPLS CBF with LDP-over-RSVP-TE colored tunnels.

switch(config)# router traffic-engineering
switch(config-te)# class-based-forwarding
switch(config-te-cbf)# forwarding-plane mpls
switch(config-te-cbf-mpls)# tunneling ldp

Configure EXP to TC mappings.

switch(config)# qos map exp 2 to traffic-class 4

Color/TC mappings.

switch(config)# router traffic-engineering
switch(config-te)# class-based-forwarding
switch(config-te-cbf)# color-tc-mappings
switch(config-te-cbf-color-tc)# color 100 ?
  default        Associate the specified color with any unmapped traffic class values
  traffic-class  Map the specified color to specific traffic class values

Enable knob to choose highest colored tunnel as default FEC.This is an optional config which is useful in cases where a default colored tunnel or an uncolored tunnel are not available. When enabled, the highest colored tunnel can then be chosen for the default FEC.
```
switch(config)# router traffic-engineering
switch(config-te)# class-based-forwarding
switch(config-te-cbf)# forwarding-plane mpls
switch(config-te-cbf-mpls)# color default fallback highest
```

Configuration example for ISIS-SR CBF

Configure tunnels with color and enable IGP-Shortcut over RSVP-TE.

switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)# tunnel MyTunnel
switch(config-te-rsvp-tunnel-myTunnel)# color 60
switch(config-te-rsvp-tunnel-myTunnel)# igp shortcut

Enable MPLS CBF with ISIS-SR over RSVP-TE colored tunnels:

switch(config)# router traffic-engineering
switch(config-te)# class-based-forwarding
switch(config-te-cbf)# forwarding-plane mpls
switch(config-te-cbf-mpls)# tunneling segment-routing