Configuring RSVP-TE
Configuring RSVP-TE LER
switch# config
switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)#
- 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
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.
explicit
submode is used to configure explicit paths.
switch(config-te-rsvp)# path MyPath explicit
switch(config-te-rsvp-path-expl-MyPath)#
switch(config-te-rsvp-path-expl-MyPath)# hop 10.0.12.2
switch(config-te-rsvp-path-expl-MyPath)# 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
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).
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.
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
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.
switch(config-te-rsvp-path-dyn-MyPath)# administrative-group include all blue include any 2-4,red exclude green,7
Tunnel specifications
switch(config-te-rsvp)# tunnel MyTunnel
switch(config-te-rsvp-tunnel-MyTunnel)#
Basic Tunnel Configuration
switch(config-te-rsvp-tunnel-MyTunnel)# destination ip 10.2.2.2
Adding Path Specifications
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.
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
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.
switch(config-te-rsvp-tunnel-myTunnel)# priority setup 5 hold 3
Color Attributes
switch(config-te-rsvp-tunnel-myTunnel)# color 60
Enabling the Tunnel
switch(config-te-rsvp-tunnel-MyTunnel)# no shutdown
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
switch(config-te-rsvp-tunnel-MyTunnel)# igp shortcut
tunneling ldp
command.
switch(config-te-rsvp-tunnel-MyTunnel)# tunneling ldp
tunneling ldp
ucmp
command.
switch(config-te-rsvp-tunnel-MyTunnel)# tunneling ldp ucmp
Tunnel Optimization
config-te-rsvp
mode for global periodic tunnel optimization..
switch(config-te-rsvp)# optimization interval 3600 seconds
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
switch(config-te-rsvp-tunnel-myTunnel)# alias endpoint 5.5.5.5
switch(config-te-rsvp-tunnel-myTunnel)# alias endpoint 2001::10
Split-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.
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
switch(config-te-rsvp-tunnel-myTunnel)# metric 10
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
switch(config-mpls-rsvp)# authentication type md5
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
- 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.
switch(config-mpls-rsvp)# fast-reroute reversion local
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.
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.
switch(config-if-Et1)# rsvp bypass administrative-group exclude 0x280
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.
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
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.
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
- 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.
- 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.
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
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.
switch(config-mpls-rsvp)# hitless-restart
switch(config-mpls-rsvp-hr)# timer recovery 40 seconds
Explicit-Null
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
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
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
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.
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.
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
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.
p2mp
submode.
switch# config
switch(config)# mpls rsvp
switch(config-mpls-rsvp)# no shutdown
switch(config-mpls-rsvp)# p2mp
switch(config-mpls-rsvp-p2mp)#
disabled
command in the p2mp
submode.
switch(config-mpls-rsvp-p2mp)# disabled
switch(config-mpls-rsvp-p2mp)#
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.
- 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.
- 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 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
- 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
Platform Configuration
CBF for MPLS labeled packets requires use of an appropriate TCAM profile. The mpls-pbr-match profile supports this feature. If this profile is not sufficient, please open a case with Arista support for a profile that supports your needs.
Limitations
- CBF is only supported in the default VRF.
- CBF does not support graceful restart.
- PBR takes precedence over CBF.
- The FEC Override Table supports up to 2048 entries per TCAM bank. A maximum of 12*2048= 24576 override entries can be present if all available TCAM banks are used exclusively for CBF. ‘
show hardware capacity
’ can be used to determine the exact maximum scale limitations for different platforms. - ECMP is supported for MPLS CBF, i.e. if there are multiple colored tunnel endpoints for a given default LfibViaSet associated with a particular TC, we only use one of the colored tunnel endpoints. It is also suggested in case we have tunnels with the same color but different endpoints.
- CBF does not apply to MPLS routes with the "
pop
” action such as penultimate hop pop. Any routes with the pop action will follow the default FEC and will not use the colored tunnels. - TC can be only set based on the EXP bits. QOS / traffic-policies that modify TC cannot modify the TC of the packet that was originally derived from the EXP - TC mapping on the device.
- CBF for ISIS-SR is only supported for IPv4 prefixes and not IPv6 prefixes.
- IPv6 Support can get enabled if they share same default fec with IPv4.