Cisco Press
For further details about Cisco MPLS TE, see the book Traffic Engineering with MPLS (Cisco Press) or consult the software documentation available at Cisco.com.
Basic Operation of MPLS TE
The following sections review the configuration and operation of the most important aspects of Cisco MPLS TE. The section “Enabling MPLS TE” introduces the basic node and interface configuration that enables MPLS TE on a Cisco router. Then, the section “Defining a TE Tunnel Interface” discusses how you configure a TE LSP on the headend node. The sections “Link Information Distribution,” “Signaling of TE LSPs,” and “Traffic Selection” explain how to configure the MPLS TE functionality that equivalent sections in Chapter 2 introduced.
Enabling MPLS TE
Cisco MPLS TE requires configuration at the node and interface (link) levels. The configuration involves mainly the definition of MPLS TE and Resource Reservation Protocol (RSVP) behavior. In addition, you may want to enable the TE extensions for your IGP to perform constraint-based routing. Cisco IOS uses mpls traffic-eng as a command prefix for MPLS TE-related configuration. Similarly, ip rsvp is the command prefix for entering RSVP-related configuration. Cisco IOS XR uses a slightly different approach that groups each of those configuration tasks in separate configuration modes that the mpls traffic-eng and rsvp commands define respectively. The individual command syntax shares significant similarity between Cisco IOS and Cisco IOS XR.
Enabling MPLS TE on a Node
You enable MPLS TE on a node using the mpls traffic-eng tunnels command in Cisco IOS. You must configure this global command before you can implement MPLS TE. There are additional global commands. They share the mpls traffic-eng prefix. Those commands are all optional with the exception of the mpls traffic-eng tunnels command. They configure different aspects of the global behavior of MPLS TE for a node, including timers, automation, and logging. Enabling MPLS TE on a global basis does not result in an operational configuration.
Example 4-1 shows an MPLS TE node configuration in Cisco IOS. In this case, the commands enable MPLS on the node, logging of setup and teardown of TE LSPs, and path reoptimization when a physical interface becomes operational. The sections “Path Computation” and “DiffServ-Aware Traffic Engineering” cover some global commands in more detail. See Appendix A, “Command Reference for Cisco MPLS Traffic Engineering and RSVP,” for a list of MPLS TE node commands in Cisco IOS. The Cisco IOS documentation contains additional command details.
Example 4-1 MPLS TE Node Configuration in Cisco IOS
mpls traffic-eng tunnels mpls traffic-eng logging lsp setups mpls traffic-eng logging lsp teardowns mpls traffic-eng reoptimize events link-up !
You enable MPLS TE on a node using the mpls traffic-eng command in Cisco IOS XR. This command defines a separate configuration mode that groups the MPLS TE configuration, with the exception of the TE extensions for the IGP. As the next section describes, you even enable under this configuration mode the physical interfaces that will participate in the MPLS TE network. Most of the global MPLS TE commands in Cisco IOS have an equivalent in Cisco IOS XR. Example 4-2 shows an MPLS TE node configuration under Cisco IOS XR. This configuration enables MPLS TE on two interfaces, defines the maximum number of configurable TE LSPs on the node, and disables penultimate hop popping (PHP) on the upstream neighbor when the node acts as ultimate hop.
Example 4-2 MPLS TE Node Configuration in Cisco IOS XR
mpls traffic-eng interface POS0/3/0/0 ! interface POS0/3/0/1 ! maximum tunnels 500 signalling advertise explicit-null !
Tip – You will find the man command useful to obtain online help on a command if you are using the EXEC interface to configure a node. The command is available only in Cisco IOS XR.
Enabling MPLS TE on an Interface
You use the mpls traffic-eng tunnels command to enable MPLS TE on an interface in Cisco IOS. This command enables MPLS TE on the interface, including the processing of RSVP signaling to set up and tear down TE LSPs. This command, in combination with its global peer, gives the minimal operational configuration. You can configure additional MPLS TE commands under an interface. They share the mpls traffic-eng prefix. Those interface commands enable you to specify link attributes, define link flooding thresholds, and control some aspects of FRR behavior. Example 4-3 illustrates interfaces POS0/1/0 and POS1/0/0 configured for MPLS TE. The sections “Link Information Distribution” and “Link and Node Protection” elaborate on the most relevant interface commands.
Example 4-3 MPLS TE Interface Configuration in Cisco IOS
interface POS0/1/0 ip address 172.16.0.0 255.255.255.254 mpls traffic-eng tunnels mpls traffic-eng administrative-weight 100 ! interface POS1/0/0 ip address 172.16.0.2 255.255.255.254 mpls traffic-eng tunnels mpls traffic-eng srlg 10 !
The interface command enables MPLS TE on an interface in Cisco IOS XR. This command resides under the mpls traffic-eng configuration mode. You do not configure any MPLS TE command under the main interface configuration. The interface command under the mpls traffic-eng mode defines a submode where the interface-specific configuration for MPLS TE resides. Example 4-4 illustrates interfaces POS0/3/0/0 and POS0/3/0/1 with their MPLS TE-specific configuration. As described previously, the sections “Link Information Distribution” and “Link and Node Protection” elaborate on the most relevant interface commands. Contrary to Cisco IOS, enabling MPLS TE on an interface does not enable the processing of RSVP signaling.
Example 4-4 MPLS TE Interface Configuration in Cisco IOS XR
mpls traffic-eng interface POS0/3/0/0 admin-weight 5 attribute-flags 0x8 ! interface POS0/3/0/1 attribute-flags 0xf ! !
Note – This approach of enabling interfaces under protocols or technologies is common in Cisco IOS XR. Cisco IOS follows a different approach of enabling protocols or technologies under interfaces.
You can use a rich collection of show, clear, and debug commands to implement and operate an MPLS network. All show commands begin with the show mpls traffic-eng prefix, clear commands with clear mpls traffic-eng, and all debug commands with debug mpls traffic-eng. Appendix A includes a list of these commands. Cisco IOS and Cisco IOS XR use similar command syntax. The upcoming sections in this chapter cover the complete syntax and output of some of the verification commands that you will probably use most frequently.
Defining a TE Tunnel Interface
Nodes in an MPLS TE network use tunnel interfaces to define a new TE LSP. The tunnel interface specifies the characteristics of the TE LSP, including destination, bandwidth, path, protection requirements, and forwarding parameters, among others. At a minimum, you need to specify the destination and path of the TE LSP. You perform the tunnel configuration on the TE LSP headend. The tailend does not require special configuration because TE LSPs are generally unidirectional. In most cases, you want to have TE LSPs in both directions. In that case, you need to configure a second tunnel at the tailend toward the headend. For all purposes, those will be two separate TE LSPs that happen to have opposite headends and tailends.
Cisco IOS identifies tunnel interfaces with the tunnel keyword. These interfaces have multiple uses in Cisco IOS. They can use Layer 2 Tunnel Protocol (L2TP), generic routing encapsulation (GRE), MPLS, and other protocols as a tunneling mechanism. Therefore, you need to specify the tunnel as an MPLS TE tunnel using the tunnel mode mpls traffic-eng command. MPLS TE tunnels also use the existing tunnel destination command to define their destination. In general, you configure the behavior that is specific to a TE LSP under the tunnel interface. Those commands use the tunnel mpls traffic-eng prefix. Example 4-5 shows how a tunnel configuration looks in Cisco IOS. You will find further details about the most common tunnel commands throughout this chapter.
Example 4-5 Definition of a TE LSP Headend in Cisco IOS
interface Tunnel1 ip unnumbered Loopback0 tunnel destination 172.16.255.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 dynamic !
Note – Notice that MPLS TE commands that you configure under a tunnel interface have a tunnel prefix. MPLS TE commands that you configure under physical interfaces are different and do not have that prefix.
Cisco IOS XR identifies MPLS TE tunnel interfaces with the tunnel-te keyword. As the name suggests, you use this type of interface exclusively for MPLS TE tunnels. The tunnel configuration commands available in Cisco IOS XR have an equivalent in Cisco IOS, and their syntaxes resemble each other. However, the Cisco IOS XR syntax is shorter because the tunnel-te already provides an MPLS TE context to the configuration. Example 4-6 illustrates how a tunnel configuration looks in Cisco IOS XR. You will find further details about the most common tunnel commands throughout this chapter.
Example 4-6 Definition of a TE LSP Headend in Cisco IOS XR
interface tunnel-te0 ipv4 unnumbered Loopback0 destination 172.16.255.5 path-option 10 dynamic !
Link Information Distribution
You can use either IS-IS or OSPF for link information distribution. Both Cisco IOS and Cisco IOS XR support both protocols. The upcoming sections describe how to configure the distribution of link information, how to control the amount of flooding, and how to verify that a node has properly disseminated and received the information.
Using IS-IS for Link Information Distribution
You can use IS-IS to distribute link information relative to MPLS TE in Cisco IOS. You enable the MPLS TE extensions using the mpls traffic-eng command under the router isis configuration mode. The command must specify the proper IS-IS level (one or two). You also need to enable the wide metric format with the metric-style wide command and define an MPLS TE router identifier with the mpls traffic-eng router-id command. Example 4-7 shows a sample IS-IS configuration in Cisco IOS that uses the TE extensions of this protocol.
Example 4-7 MPLS TE Extensions for IS-IS in Cisco IOS
router isis net 49.0001.1720.1625.5001.00 is-type level-2-only metric-style wide mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 passive-interface Loopback0 !
Cisco IOS XR also supports the distribution of this link information using IS-IS. The commands it uses are nearly identical to those in Cisco IOS. In both cases, the commands that relate to MPLS TE have the mpls traffic-eng prefix. In Cisco IOS XR, you need to enable these TE commands under the ipv4 unicast address family in the IS-IS configuration. You can also define the MPLS TE router identifier using the global router-id command that applies to all protocols. Example 4-8 shows an IS-IS configuration in Cisco IOS XR using the TE extensions.
Example 4-8 MPLS TE Extensions for IS-IS in Cisco IOS XR
router isis DEFAULT
is-type level-2-only
net 49.0001.1720.1625.5129.00
address-family ipv4 unicast
metric-style wide
mpls traffic-eng level 2
mpls traffic-eng router-id Loopback0
!
interface Loopback0
passive
address-family ipv4 unicast
!
!
interface POS0/3/0/0
address-family ipv4 unicast
!
!
!
Using OSPF for Link Information Distribution
Cisco IOS and Cisco IOS XR also support MPLS TE extensions for OSPF. You must use the mpls traffic-eng area command to specify the OSPF area where you are enabling MPLS TE. You specify the MPLS TE router identifier with the mpls traffic-eng router-id command. These two commands use the same syntax in both operating systems. All the OSPF commands that relate to MPLS TE have the mpls traffic-eng prefix.
Examples 4-9 and 4-10 show OSPF configurations with MPLS TE extensions for Cisco IOS and Cisco IOS XR, respectively.
Example 4-9 MPLS TE Extensions for OSPF in Cisco IOS
router ospf 100 log-adjacency-changes mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 passive-interface Loopback0 network 172.16.0.0 0.0.255.255 area 0 !
Example 4-10 MPLS TE Extensions for OSPF in Cisco IOS XR
router ospf DEFAULT area 0 interface Loopback0 passive ! interface POS0/3/0/0 ! mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 !
Controlling Flooding
Cisco MPLS TE offers granular control on the flooding of link information. You can have changes in available bandwidth trigger flooding of link updates. A node will also send periodic link updates. You tune periodic updates per node using the link management timers and the bandwidth utilization thresholds per interface using the interface flooding threshold. Figure 4-1 shows the default bandwidth utilization thresholds that influence link flooding in both operating systems. In addition, you can manually force the flooding on a node in Cisco IOS XR using the exec mpls traffic-eng link-management flood command.
Note – “Just because I can” is not a good reason to tune any timer. The timer defaults provide good results for most deployments. Before attempting to modify any timers, make sure you understand what you are trying to achieve and the impact that the change will have on the network.
Figure 4-1 shows the default bandwidth utilization thresholds that influence link flooding in both operating systems. The figure highlights with a circle the changes in bandwidth reservation that trigger the flooding of the link state. Initially, the link has all its bandwidth available. Two TE LSPs reserve 5 percent of the link bandwidth each. Those reservations do not trigger any flooding. The next five reservations cross one of the default thresholds and cause the advertising of the updated link information. At this point, seven reservations have consumed 88 percent of the link bandwidth. After reaching this maximum, five TE LSPs are torn down. All but the fourth TE LSP introduce a change in bandwidth reservation that forces flooding. The link remains with two TE LSPs that hold 10 percent of the link bandwidth.
Configuring Link Attributes
A node will advertise MPLS TE attributes for a link when you configure the IGP with the respective extensions. As described in Chapter 2, those link characteristics include the TE administrative weight, attribute flags, and bandwidth. All links in your MPLS TE network have these three parameters regardless of your IGP choice (IS-IS or OSPF) and regardless of whether you configure them explicitly. This behavior includes all nodes whether they act as TE LSP headends, midpoints, or tailends.
Not all links on a node have to be part of your MPLS TE network. You need to configure at least one link connecting to another MPLS TE node. If you do not configure the link parameters explicitly, a link will use default values as soon as you enable MPLS TE and RSVP on the respective interface.
Bandwidth Utilization Thresholds for Flooding Link Updates
Note – When you configure the link characteristics under an interface, you are configuring one end of the link. The node at the other end of the link is responsible for the configuration in the other direction. The configuration on both sides does not necessarily have to match.
Cisco IOS relies on MPLS TE and RSVP interface commands to set the link characteristics. You use the mpls traffic-eng administrative-weight, mpls traffic-eng attribute-flags, and ip rsvp bandwidth commands. As a prerequisite, you must enable MPLS TE on the interface using the mpls traffic-eng tunnels command. Unless configured explicitly, the administrative weight defaults to a value of the IGP metric, the attribute flags defaults to 0, and the RSVP bandwidth defaults to 75 percent of the interface bandwidth. If you do not configure the ip rsvp bandwidth command, the RVSP bandwidth defaults to 0. You can still signal TE LSPs through that link if those TE LSPs do not try to reserve any bandwidth. You can configure the RSVP bandwidth above or below the actual link capacity. The section “Signaling of TE LSPs” elaborates on the RSVP commands.
Cisco IOS XR uses the interface submodes under the mpls traffic-eng and rsvp configuration modes to define the link characteristics. You use the admin-weight and attribute-flags commands within the mpls traffic-eng configuration mode. In addition, you configure the bandwidth commands within the rsvp mode. All three link characteristics have the same defaults as in Cisco IOS.
Example 4-11 shows the configuration of link characteristics in Cisco IOS. The example includes two interfaces enabled for MPLS TE. Interface POS0/1/0 contains explicit configuration for the attribute flags, administrative weight, and RSVP bandwidth. Interface POS1/0/0 has an explicit administrative weight and implicit attribute flags and RSVP bandwidth.
Example 4-11 Definition of Link Characteristics for MPLS TE in Cisco IOS
interface POS0/1/0 ip address 172.16.0.0 255.255.255.254 mpls traffic-eng tunnels mpls traffic-eng attribute-flags 0xF mpls traffic-eng administrative-weight 20 ip rsvp bandwidth 100000 ! interface POS1/0/0 ip address 172.16.0.2 255.255.255.254 mpls traffic-eng tunnels mpls traffic-eng administrative-weight 30 ip rsvp bandwidth !
Example 4-12 shows the configuration of link attributes for two interfaces in Cisco IOS XR. Notice that the interface configuration resides under the rsvp and mpls traffic-eng configuration modes. Interface POS0/3/0/0 uses an explicit bandwidth, administrative weight, and attribute flags. Interface POS0/3/0/1 only defines the RSVP bandwidth and the attribute flags explicitly.
Example 4-12 Definition of Link Characteristics for MPLS TE in Cisco IOS XR
rsvp interface POS0/3/0/0 bandwidth 100000 ! interface POS0/3/0/1 bandwidth 155000 ! ! mpls traffic-eng interface POS0/3/0/0 admin-weight 5 attribute-flags 0x8 ! interface POS0/3/0/1 attribute-flags 0xf ! !
Verifying Link Information Distribution
You can examine the link information that a node advertises by using the show mpls traffic-eng link-management advertisements command. The output provides details on all the MPLS TE link attributes and the IGP configuration. The same command syntax is available in Cisco IOS and Cisco IOS XR.
Example 4-13 shows the command output in Cisco IOS. The output corresponds to the configuration of interface POS0/1/0 in Example 4-11. Example 4-14 contains the equivalent command output in Cisco IOS XR. The command output corresponds to interface POS0/3/0/0 in Example 4-6. Both Cisco IOS and Cisco IOS XR provide almost identical information with slightly different formats. Both examples highlight the flooding protocol, the MPLS TE router ID, TE metric, the reservable (global) bandwidth, the amount of available bandwidth at each of the eight priority levels, and the link attribute flags.
Example 4-13 Examining MPLS TE Link Advertisements in Cisco IOS
Router#show mpls traffic-eng link-management advertisements
Flooding Status: ready
Configured Areas: 1
IGP Area[1] ID:: isis level-2
System Information::
Flooding Protocol: ISIS
Header Information::
IGP System ID: 1720.1625.5001.00
MPLS TE Router ID: 172.16.255.1
Flooded Links: 1
Link ID:: 0
Link Subnet Type: Point-to-Point
Link IP Address: 172.16.0.0
IGP Neighbor: ID 1720.1625.5129.00, IP 172.16.0.1
TE metric: 20
IGP metric: 10
SRLGs: None
Physical Bandwidth: 155000 kbits/sec
Res. Global BW: 100000 kbits/sec
Res. Sub BW: 0 kbits/sec
Downstream::
Global Pool Sub Pool
----------- ----------
Reservable Bandwidth[0]: 100000 0 kbits/sec
Reservable Bandwidth[1]: 100000 0 kbits/sec
Reservable Bandwidth[2]: 100000 0 kbits/sec
Reservable Bandwidth[3]: 100000 0 kbits/sec
Reservable Bandwidth[4]: 100000 0 kbits/sec
Reservable Bandwidth[5]: 100000 0 kbits/sec
Reservable Bandwidth[6]: 100000 0 kbits/sec
Reservable Bandwidth[7]: 100000 0 kbits/sec
Attribute Flags: 0x0000000F
! Output omitted for brevity
Example 4-14 Examining MPLS TE Link Advertisements in Cisco IOS XR
RP/0/4/CPU0:Router[P]#show mpls traffic-eng link-management advertisements
Flooding Status : ready
Last Flooding : 904 seconds ago
Last Flooding Trigger : Link BW changed
Next Periodic Flooding In : 132 seconds
Diff-Serv TE Mode : Not enabled
Configured Areas : 1
IGP Area[1]:: isis DEFAULT level-2
Flooding Protocol : ISIS
IGP System ID : 1720.1625.5129.00
MPLS TE Router ID : 172.16.255.129
Flooded Links : 2
Link ID:: 0 (POS0/3/0/0)
Link IP Address : 172.16.0.1
O/G Intf ID : 1
Neighbor : ID 1720.1625.5001.00, IP 172.16.0.0
SRLGs :
TE Metric : 5
IGP Metric : 10
Physical BW : 155520 kbits/sec
BCID : RDM
Max Reservable BW : 100000 kbits/sec
Res Global BW : 100000 kbits/sec
Res Sub BW : 0 kbits/sec
Downstream::
Global Pool Sub Pool
----------- -----------
Reservable BW[0]: 100000 0 kbits/sec
Reservable BW[1]: 100000 0 kbits/sec
Reservable BW[2]: 100000 0 kbits/sec
Reservable BW[3]: 100000 0 kbits/sec
Reservable BW[4]: 100000 0 kbits/sec
Reservable BW[5]: 100000 0 kbits/sec
Reservable BW[6]: 100000 0 kbits/sec
Reservable BW[7]: 100000 0 kbits/sec
Attribute Flags: 0x00000008
! Output omitted for brevity
Examining the MPLS TE topology database is an indispensable task to troubleshoot a vast number of problems. The show mpls traffic-eng topology command displays the entire MPLS TE topology database. The output can be rather lengthy, so make sure you get familiar with the command options. They enable you to narrow down the amount of information to display. The topology database includes information about all the links in the MPLS TE network according to the local configuration and the IGP advertisements from other nodes in the same area or level.
Examples 4-15 and 4-16 show an output fragment of this command in Cisco IOS and Cisco IOS XR, respectively. The output highlights the MPLS TE router ID, the TE metric, the attribute flags, the maximum (global) reservable bandwidth, and the amount of available bandwidth at each of the eight priority levels. In both examples, RSVP has not allocated any link bandwidth.
Example 4-15 Examining the MPLS TE Topology Database in Cisco IOS
Router#show mpls traffic-eng topology
My_System_id: 172.16.255.1 (ospf 100 area 0)
Signalling error holddown: 10 sec Global Link Generation 51
IGP Id: 172.16.255.129, MPLS TE Id:172.16.255.129 Router Node (ospf 100 area 0)
link[0]: Point-to-Point, Nbr IGP Id: 172.16.255.1, nbr_node_id:10, gen:51
frag_id 0, Intf Address:172.16.0.1, Nbr Intf Address:172.16.0.0
TE metric:1, IGP metric:1, attribute_flags:0x0
SRLGs: None
physical_bw: 155520 (kbps), max_reservable_bw_global: 155000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 155000 0
bw[1]: 0 155000 0
bw[2]: 0 155000 0
bw[3]: 0 155000 0
bw[4]: 0 155000 0
bw[5]: 0 155000 0
bw[6]: 0 155000 0
bw[7]: 0 155000 0
! Output omitted for brevity
Example 4-16 Examining the MPLS TE Topology Database in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng topology
My_System_id: 172.16.255.129 (ospf area 0)
Signalling error holddown: 10 sec Global Link Generation 173
IGP Id: 172.16.255.129, MPLS TE Id: 172.16.255.129 Router Node (ospf area 0)
Link[0]:Point-to-Point, Nbr IGP Id:172.16.255.1, Nbr Node Id:36, gen:173
Frag Id:0, Intf Address:172.16.0.1, Intf Id:0
Nbr Intf Address:172.16.0.0, Nbr Intf Id:0
TE Metric:1, IGP Metric:1, Attribute Flags:0x0
Switching Capability:, Encoding:
Physical BW:155520 (kbps), Max Reservable BW Global:155000 (kbps)
Max Reservable BW Sub:0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 155000 0
bw[1]: 0 155000 0
bw[2]: 0 155000 0
bw[3]: 0 155000 0
bw[4]: 0 155000 0
bw[5]: 0 155000 0
bw[6]: 0 155000 0
bw[7]: 0 155000 0
! Output omitted for brevity
Tip – The use of command-line interface (CLI) output filtering can be of great help to easily extract important information from the topology database. You filter the command output using the pipe operand (|) and the begin, exclude, or include keywords followed by a regular expression. You can save your most useful filters using the alias configuration command. As an example, the following filter enable you to quickly identify those links that have an IGP or TE metric of 10 on Cisco IOS or Cisco IOS XR nodes:
show mpls traffic-eng topology | include [Ff]rag | [Mm]etric:10,
Consult the Cisco IOS and Cisco IOS XR configuration guides for further detail about filtering CLI output.
Path Computation
A headend performs path computation for a TE LSP. The MPLS TE tunnel interface defines a destination for the TE LSP and a list of path options to reach that destination. These path options may reference an explicit path or request the computation of a dynamic path to the destination. Even if you configure a tunnel with an explicit path, the node verifies the path using the MPLS TE topology database unless you disable this check explicity.
Configuring the TE LSP Path
You can specify multiple path options for a TE LSP. These options can define a complete or partial (loose) explicit path. In addition, you can configure the node with an option to compute dynamically the complete path to the destination. As the section “Defining a TE Tunnel Interface” described, you configure the TE LSP destination with its own command independent of the path configuration. In Cisco IOS, you configure the TE LSP destination with the tunnel destination command and specify a path option with the tunnel mpls traffic-eng path-option command. Cisco IOS XR uses the destination command and the path-option command. You can configure multiple path options for a tunnel. Each one has a sequence number, and the node evaluates them in increasing order.
You actually define explicit paths outside the scope of the tunnel interface. Both Cisco IOS and Cisco IOS XR use a separate configuration mode to define explicit paths. Cisco IOS uses the ip explicit-path command, and Cisco IOS XR uses the explicit-path command. Within this configuration mode, you specify the list of hops (in the form of IP addresses) that you want to include or exclude from the path.
Configuring the TE LSP Constraints
The tunnel configuration determines the constraints that the node uses when executing the constraint-based shortest-path first algorithm to signal the TE LSP. The TE LSP bandwidth, affinity (matching attribute flags), priorities, and metric type influence the computation and validation of a path. In Cisco IOS, you can specify these tunnel parameters with the following tunnel commands, respectively:
tunnel mpls traffic-eng bandwidth
tunnel mpls traffic-eng affinity
tunnel mpls traffic-eng priority
tunnel mpls traffic-eng path-selection metric
If you do not configure these parameters explicitly, the bandwidth defaults to 0 kbps, the affinity to links with attribute flags of 0, the priority to 7 (lowest priority), and the use of the TE metric for path selection. You can specify the default path-selection metric using the mpls traffic-eng path-selection metric global command.
Cisco IOS also enables you to associate the TE LSP constraints with a path option instead of associating them with the tunnel. You define the tunnel constraints as a template using the mpls traffic-eng lsp attributes global command. This command defines a configuration mode where you can use the bandwidth, affinity, and priority commands (among others) to define the behavior you want for a TE LSP. This feature enables you to define multiple path options with progressively less-strict constraints and increase the probability of successfully signaling the tunnel.
Example 4-17 shows a tunnel configuration in Cisco IOS with multiple path options. The tunnel has explicit configuration for setup and hold priority 5, bandwidth reservation of 10,000 kbps, and four different path options. The first three path options are explicit paths with names:
PATH1 defines a single loose hop.
PATH2 specifies a particular address that the path computation must exclude.
PATH3 defines a complete, hop-by-hop path to the destination.
The path computation considers the three paths in that order. If they do not meet all constraints to the tunnel destination, a fourth path option invokes path computation to the destination using LSP attributes LSP-ATTRIB1 to reduce the required bandwidth to 5000 kbps, but limiting the path to links with attribute flags of 0.
Example 4-17 Path and Tunnel Configuration in Cisco IOS
mpls traffic-eng lsp attributes LSP-ATTRIB1 affinity 0x0 mask 0xFFFFFFFF bandwidth 5000 ! interface Tunnel1 description FROM-ROUTER-TO-DST1 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 172.16.255.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 5 5 tunnel mpls traffic-eng bandwidth 10000 tunnel mpls traffic-eng path-option 5 explicit name PATH1 tunnel mpls traffic-eng path-option 10 explicit name PATH2 tunnel mpls traffic-eng path-option 15 explicit name PATH3 tunnel mpls traffic-eng path-option 20 dynamic attributes LSP-ATTRIB1 ! ip explicit-path name PATH1 enable next-address loose 172.16.255.5 ! ip explicit-path name PATH2 enable exclude-address 172.16.8.2 ! ip explicit-path name PATH3 enable next-address 172.16.0.1 next-address 172.16.8.0 !
Cisco IOS XR uses the signalled-bandwidth, affinity, priority, and path-selection metric tunnel commands to influence the path computation. These parameters have the same defaults as Cisco IOS if you do not specify them explicitly.
Example 4-18 shows a tunnel configuration in Cisco IOS XR with multiple path options. The tunnel has the following explicit constraints: 100,000 kbps of bandwidth, three path options, and an affinity value of F in hexadecimal notation. The first two paths are explicit paths with names:
PATH1 defines a complete hop-by-hop path to the tunnel destination.
PATH2 defines two addresses to exclude from the path computation.
The tunnel considers those two paths in that order. If the path computation cannot satisfy all constraints with those paths, it relies on the third and last path option that enable a dynamic path.
Example 4-18 Path and Tunnel Configuration in Cisco IOS XR
explicit-path name PATH1 index 1 next-address ipv4 unicast 172.16.0.4 index 2 next-address ipv4 unicast 172.16.0.7 index 3 next-address ipv4 unicast 172.16.4.2 ! explicit-path name PATH2 index 1 exclude-address ipv4 unicast 172.16.255.131 index 2 exclude-address ipv4 unicast 172.16.255.130 ! interface tunnel-te1 description FROM-ROUTER-TO-DST1 ipv4 unnumbered Loopback0 signalled-bandwidth 100000 destination 172.16.255.2 path-option 10 explicit name PATH1 path-option 20 explicit name PATH2 path-option 30 dynamic affinity f mask f !
Note – A headend always checks the accuracy of a path against the MPLS TE topology database before signaling the TE LSP. This behavior holds true even if you define a hop-by-hop explicit path to the destination. You can omit that path check by using the verbatim keyword on the path option.
Path Reoptimization
A headend can reoptimize automatically existing TE LSPs in search of a better path. You can tune a reoptimization timer using the mpls traffic-eng reoptimize timers frequency command in Cisco IOS. Cisco IOS XR uses the reoptimize command under the mpls traffic-eng configuration mode. In both cases, the reoptimization timer defaults to one hour. In addition to the timer-based mechanism, you can have an event-based reoptimization trigger in Cisco IOS using the mpls traffic-eng reoptimize events link-up global command. This command forces the reoptimization of TE LSPs when a physical interface in the MPLS TE network becomes operational.
You can also begin the reoptimization process manually. The mpls traffic-eng reoptimize EXEC command in Cisco IOS and Cisco IOS XR enables you to request TE LSP reoptimization. The command reoptimizes all eligible TE LSPs by default. Alternatively, you can specify the particular tunnel you want to reoptimize.
A headend will not attempt to reoptimize those TE LSP with a locked down path. You use the lockdown keyword as part of the path option or LSP attributes to indicate that the headend must not reoptimize the tunnel after it has established the TE LSP.
Verifying Path Computation
The show mpls traffic-eng tunnels command enables you to verify the path selection for a tunnel. Example 4-19 shows the command output in Cisco IOS for the tunnel configuration in Example 4-15. The output begins with the tunnel destination and then specifies the operational status of the path that indicates that there is a valid path. Subsequently, you can see the list of path options. The tunnel is using path option (dynamic) 20 to reach the destination. The path has a weight (or cost) of 3. Further down, you find the tunnel constraints (bandwidth, priorities, and affinity) and then details about the active path option (20 in this case). Finally, you can find details on the signaled path in the RSVP signaling component. In this case, path option 20 resulted in path 172.16.0.1, 172.16.192.1, 172.16.8.2, and 172.16.255.3. This command provides a wealth of information about TE LSPs. You will find the description of additional output fields throughout the chapter.
Example 4-19 Examining TE LSP Status in Cisco IOS
Router#show mpls traffic-eng tunnels
Name: FROM-ROUTER-TO-DST1 (Tunnel1) Destination: 172.16.255.3
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 20, type dynamic (Basis for Setup, path weight 3)
path option 5, type explicit PATH1
path option 10, type explicit PATH2
path option 15, type explicit PATH3
Config Parameters:
Bandwidth: 5000 kbps (Global) Priority: 5 5 Affinity: 0x0/0xFFFFFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 5000 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 20 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : POS0/1/0, 120
RSVP Signalling Info:
Src 172.16.255.1, Dst 172.16.255.3, Tun_Id 1, Tun_Instance 1
RSVP Path Info:
My Address: 172.16.0.0
Explicit Route: 172.16.0.1 172.16.192.1 172.16.8.2 172.16.255.3
Record Route: NONE
Tspec: ave rate=5000 kbits, burst=1000 bytes, peak rate=5000 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=5000 kbits, burst=1000 bytes, peak rate=5000 kbits
History:
Tunnel:
Time since created: 2 minutes, 58 seconds
Time since path change: 2 minutes, 58 seconds
Number of LSP IDs (Tun_Instances) used: 1
Current LSP:
Uptime: 2 minutes, 58 seconds
Router#
Example 4-20 shows the verification of the path computation result in Cisco IOS XR. As with Cisco IOS, you use the show mpls traffic-eng tunnels command for this purpose. This example shows the output for the tunnel configuration in Example 4-18. The tunnel details begin with the tunnel destination. Then, this example shows that the path computation could not find a valid path to the destination with the information available in the MPLS TE topology database. The lack of a path results in a down operational status. The output lists all path options and tunnel constraints plus details regarding the path computation failure in the history component. Using the failure details, you can review the MPLS TE topology database to narrow down the cause of the problem. Examples 4-13 and 4-14 illustrated how to examine the topology database.
Example 4-20 Examining TE LSP Status in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng tunnels
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 3403 seconds
Periodic FRR Promotion: every 300 seconds, next in 105 seconds
Periodic auto-bw collection: disabled
Name: tunnel-te1 Destination: 172.16.255.2
Status:
Admin: up Oper: down Path: not valid Signalling: Down
path option 10, type explicit PATH1
path option 20, type explicit PATH2
path option 30, type dynamic
G-PID: 0x0800 (internally specified)
Config Parameters:
Bandwidth: 100000 kbps (Global) Priority: 7 7 Affinity: 0xf/0xf
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 100000 bw-based
Auto-bw: disabled(0/0) 0 Bandwidth Requested: 100000
Direction: unidirectional
Endpoint switching capability unkown, encoding type: unassigned
Transit switching capability unkown, encoding type: unassigned
History:
Prior LSP:
ID: path option 10 [3]
Removal Trigger: path verification failed
Last Error:
PCALC:: Can't reach 172.16.0.4 on 172.16.255.4, from node
172.16.255.129
Displayed 1 (of 1) heads, 0 (of 0) tails
Displayed 0 up, 1 down, 0 recovering, 0 recovered heads
RP/0/4/CPU0:Router#
You can manually begin the path computation process from the EXEC prompt. Both Cisco IOS and Cisco IOS XR provide the show mpls traffic-eng topology path command for this purpose. You can request the computation of a path for a particular tunnel or you can request a path to a destination with a particular set of constraints (bandwidth, priority, and affinity). The manual execution of path computation might show a path different from the current path. This situation does not trigger the reoptimization of the tunnel.
Example 4-21 and Example 4-22 show the output of the show mpls traffic-eng topology path command in Cisco IOS and Cisco IOS XR, respectively. Example 4-21 begins the path computation for Tunnel1 as Example 4-17 defined it. Example 4-22 illustrates the use of the command with an arbitrary choice of constraints. The command output displays the exact constraints that the path computation process used and the hop-by-hop path to the destination if the node found a valid path.
Example 4-21 Manual Execution of Path Computation in Cisco IOS
Router#show mpls traffic-eng topology path tunnel 1 Query Parameters: Destination: 172.16.255.3 Bandwidth: 10000 Priorities: 5 (setup), 5 (hold) Affinity: 0x0 (value), 0xFFFF (mask) Query Results: Min Bandwidth Along Path: 145000 (kbps) Max Bandwidth Along Path: 145000 (kbps) Hop 0: 172.16.0.0 : affinity 00000000, bandwidth 145000 (kbps) Hop 1: 172.16.8.1 : affinity 00000000, bandwidth 145000 (kbps) Hop 2: 172.16.255.3 Router#
Example 4-22 Manual Execution of Path Computation in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng topology path destination 172.16.255.2 bandwidth 1000 Path Setup to 172.16.255.2: bw 1000 (CT0), min_bw 155000, metric: 2 setup_pri 7, hold_pri 7 affinity_bits 0x0, affinity_mask 0xffffffff Hop0:172.16.192.3 Hop1:172.16.4.2 Hop2:172.16.255.2 RP/0/4/CPU0:Router#
Signaling of TE LSPs
You can use node- and interface-level RSVP configuration to influence the signaling of TE LSPs. Cisco IOS XR requires explicit RSVP configuration to enable the signaling of TE LSPs. Cisco IOS enables it when you configured MPLS TE on the interface. In either case, most implementations configure explicitly different aspects of the protocol. At a minimum, you might want to configure the reservable bandwidth on a interface that RSVP will use for admission control. The next two sections discuss how to configure and verify the proper operation of RSVP for the signaling of TE LSPs.
Configuring RSVP
This section examines node configuration commands for RSVP control authentication, graceful restart, refresh behavior, and hello messages. In Cisco IOS, all RSVP node commands start with the ip rsvp prefix, and you enter them in global configuration. In Cisco IOS XR, you specify the RSVP node configuration under the rsvp configuration mode. All commands are optional in Cisco IOS. In Cisco IOS XR, the interface command is mandatory because it enables RSVP processing on individual interfaces. In addition, Cisco IOS XR uses refresh reduction and reliable messages by default, but the behavior is tunable per interface.
RSVP interface commands are optional in Cisco IOS and Cisco IOS XR. In Cisco IOS, all RSVP interface commands have the ip rsvp prefix and reside under the physical interface. In Cisco IOS XR, all interface commands reside under the submode that the interface command enables under the rsvp configuration mode. The nature of the interface commands differs depending on the operating systems. Cisco IOS XR enables you to tune message rate limiting, refresh reduction, and reliable messages per interface. In Cisco IOS, those features are part of the node configuration. In both operating systems, the MPLS TE tunnel does not require any RSVP configuration. The headend automatically signals the TE LSP when it finds a valid path.
Example 4-23 shows an RSVP configuration in Cisco IOS. In this example, the configuration enables the processing of RSVP signaling on interfaces POS0/1/0 and POS1/0/0 with a maximum reservable bandwidth of 155,000 kbps. As part of the global configuration, this node will use the RSVP reliable messaging and refresh reduction extensions. In addition, the node will act as a helper node for neighbors performing RSVP graceful restarts.
Example 4-23 RSVP TE Configuration in Cisco IOS
interface POS0/1/0 ip address 172.16.0.0 255.255.255.254 mpls traffic-eng tunnels ip rsvp bandwidth 155000 ! interface POS1/0/0 ip address 172.16.0.2 255.255.255.254 mpls traffic-eng tunnels ip rsvp bandwidth 155000 ! ip rsvp signalling refresh reduction ip rsvp signalling hello graceful-restart mode help-neighbor !
Example 4-24 illustrates an RSVP configuration in Cisco IOS XR. The configuration enables RSVP on interfaces POS0/3/0/0 and POS0/3/0/1 with a bandwidth allocation of 155,000 kbps. The message retransmission timer for reliable message deliver will be 5000 ms on interface POS0/3/0/0. Finally, the configuration enables RSVP graceful restart with a refresh interval of 10,000 ms.
Example 4-24 RSVP TE Configuration in Cisco IOS XR
rsvp interface POS0/3/0/0 bandwidth 155000 signalling refresh reduction reliable retransmit-time 5000 ! interface POS0/3/0/1 bandwidth 155000 ! signalling graceful-restart signalling hello graceful-restart refresh interval 10000 !
Verifying RSVP
Many show, clear, and debug commands are available for RSVP in Cisco IOS and Cisco IOS XR. These commands begin with the show ip rsvp, clear ip rsvp, and debug ip rsvp prefixes, respectively. From that group, you can use the show ip rsvp interface command in Cisco IOS and the show rsvp interface command in Cisco IOS XR to examine the RSVP status on a particular interface. In addition, the show ip rsvp counters command in Cisco IOS and the show rsvp counters command in Cisco IOS XR will show you detailed counters on RSVP activity. The next section illustrates some additional verification commands for RSVP. The Cisco IOS and Cisco IOS XR documentation completely describes all commands.
Example 4-25 shows the output of the show ip rsvp interface command in Cisco IOS. The command shows the detailed status for interface POS0/1/0 with the configuration in Example 4-23. In this case, the interface configuration enabled RSVP. The protocol has allocated 10 Mbps out of the total RSVP bandwidth of 155 Mbps. The interface is not using RSVP authentication or generating RSVP hello messages.
Example 4-25 Examine RSVP TE Interface Status in Cisco IOS
Router#show ip rsvp interface detail pos0/1/0 PO0/1/0: RSVP: Enabled Interface State: Up Bandwidth: Curr allocated: 10M bits/sec Max. allowed (total): 155M bits/sec Max. allowed (per flow): 155M bits/sec Max. allowed for LSP tunnels using sub-pools (pool 1): 0 bits/sec Set aside by policy (total): 0 bits/sec Traffic Control: RSVP Data Packet Classification is ON Signalling: DSCP value used in RSVP msgs: 0x3F Number of refresh intervals to enforce blockade state: 4 Authentication: disabled Key chain:Type: md5 Window size: 1 Challenge: disabled Hello Extension: State: Disabled Router#
Example 4-26 illustrates the information that the show rsvp interface command provides in Cisco IOS XR. The command provides the detailed output for the interface POS0/3/0/0 with the configuration that Example 4-24 described. In this case, RSVP has not allocated any bandwidth out of the total RSVP bandwidth of 155 Mbps. The interface is using RSVP refresh reduction (supporting both summary refresh and bundle messages). RSVP has one neighbor on this interface, with IP address 172.16.0.0, which is using refresh reduction.
Example 4-26 Examine RSVP TE Interface Status in Cisco IOS XR
RP/0/4/CPU0:Router#show rsvp interface pos0/3/0/0 detail
INTERFACE: POS0/3/0/0 (ifh=0x4000300).
VRF ID: 0x60000000 (Default).
BW (bits/sec): Max=155M. MaxFlow=155M.
Allocated=0 (0%). MaxSub=0.
Signalling: No DSCP marking. No rate limiting.
States in: 1. Max missed msgs: 4.
Expiry timer: Running (every 30s). Refresh interval: 45s.
Normal Refresh timer: Not running. Summary refresh timer: Running.
Refresh reduction local: Enabled. Summary Refresh: Enabled (4096 bytes max).
Reliable summary refresh: Disabled. Bundling: Enabled. (4096 bytes max).
Ack hold: 400 ms, Ack max size: 4096 bytes. Retransmit: 5000ms.
Neighbor information:
Neighbor-IP Nbor-MsgIds States-out Refresh-Reduction Expiry(min::sec)
-------------- -------------- ---------- ------------------ ----------------
172.16.0.0 1 1 Enabled 14::50
RP/0/4/CPU0:Router#
Example 4-27 illustrates the output of the show ip rsvp counters command in Cisco IOS. The command shows aggregate and per-interface counters for each RSVP message type. In this case, a filter reduces the output to the aggregate counter information. You can verify the number of RSVP messages the node has sent and received. In addition, you find information about disconnect reasons for RSVP sessions.
Example 4-27 Examining RSVP Counters in Cisco IOS
Router#show ip rsvp counters | begin All
All Interfaces Recv Xmit Recv Xmit
Path 0 2 Resv 2 0
PathError 0 0 ResvError 0 0
PathTear 0 2 ResvTear 0 0
ResvConf 0 0 RTearConf 0 0
Ack 343 3 Srefresh 298 340
Hello 1112 1111 IntegrityChalle 0 0
IntegrityRespon 0 0 DSBM_WILLING 0 0
I_AM_DSBM 0 0 Errors 0 0
Error Distribution Recv Xmit
Authentication 0 0
Other 0 0
Recv Msg Queues Current Max
RSVP 0 1
Hello (per-I/F) 0 0
Awaiting Authentication 0 0
States
Reason for Teardown State torn down
Path Resv-In Resv-Out
PathTear arrival 0 0 0
ResvTear arrival 0 0 0
Local application requested tear 2 1 0
Output or Input I/F went down 0 0 0
Missed refreshes 0 0 0
Preemption 0 0 0
Backup tunnel failed for FRR Active LSP 0 0 0
Reroutabilty changed for FRR Active LSP 0 0 0
Hello RR Client (HST) requested tear 0 0 0
Graceful Restart (GR) requested tear 0 0 0
Downstream neighbor SSO-restarting 0 0 0
Resource unavailable 0 0 0
Policy rejection 0 0 0
Policy server sync failed 0 0 0
Traffic control error 0 0 0
Error in received message 0 0 0
Unsupported change in Resv 0 0 0
Unsupported change in Resv (Label) 0 0 0
Label programming failed 0 0 0
Non RSVP HOP upstream, TE LSP 0 0 0
Other 0 0 0
Router#
Example 4-28 shows how to examine the different RSVP counters in Cisco IOS XR using the show rsvp counters command. The information is almost identical to the Cisco IOS output, with the exception that this command currently obviates the counters for the disconnect reasons of RSVP sessions.
Example 4-28 Examining RSVP Counters in Cisco IOS XR
RP/0/4/CPU0:Router#show rsvp counters messages | begin All All RSVP Interfaces Recv Xmit Recv Xmit Path 8 647 Resv 717 0 PathError 0 0 ResvError 0 0 PathTear 9 8 ResvTear 0 0 ResvConfirm 0 0 Hello 1190 1595 Ack 9 362 SRefresh 355 314 Retransmit 0 Rate Limited 0 OutOfOrder 0 Bundle 0 8 AckSubmsg 0 7 PathSubmsg 0 0 ResvSubmsg 0 8 PathTearSubmsg 0 0 ResvTearSubmsg 0 0 PathErrorSubmsg 0 0 ResvErrorSubmsg 0 0 RP/0/4/CPU0:Router#
Verifying Signaling of TE LSPs
Example 4-29 shows the signaling status of a TE LSP using the show mpls traffic-eng tunnels command in Cisco IOS. The successful establishment of a TE LSP results in a signaling status of connected (rather than down). In that case, you will see the output interface and label information for the TE LSP, along with an RSVP section showing the most important Path and Resv details. In this example, you can see that the TE LSP is connected. It uses output interface POS0/1/0 and output label 31. The TE LSP does not show an input label, which evidences that the headend executed the command. The RSVP session has reserved 10 Mbps and signals addresses 172.16.0.1, 172.16.8.0, and 172.16.255.3 in the RSVP explicit route object (ERO).
Example 4-29 Examining TE LSP Signaling Status in Cisco IOS
Router#show mpls traffic-eng tunnels
Name: FROM-ROUTER-TO-DST1 (Tunnel1) Destination: 172.16.255.3
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type dynamic (Basis for Setup, path weight 2)
Config Parameters:
Bandwidth: 10000 kbps (Global) Priority: 5 5 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 10000 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : POS0/1/0, 31
RSVP Signalling Info:
Src 172.16.255.1, Dst 172.16.255.3, Tun_Id 1, Tun_Instance 9277
RSVP Path Info:
My Address: 172.16.255.1
Explicit Route: 172.16.0.1 172.16.8.0 172.16.255.3
Record Route: NONE
Tspec: ave rate=10000 kbits, burst=1000 bytes, peak rate=10000 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=10000 kbits, burst=1000 bytes, peak rate=10000 kbits
History:
Tunnel:
Time since created: 4 days, 1 hours, 20 minutes
Time since path change: 7 seconds
Number of LSP IDs (Tun_Instances) used: 9277
Current LSP:
Uptime: 7 seconds
Prior LSP:
ID: path option 10 [9274]
Removal Trigger: tunnel shutdown
Router#
Example 4-30 shows the signaling status of a TE LSP using the show mpls traffic-eng tunnels command in Cisco IOS XR. The output format differs slightly when you compare it with Cisco IOS. However, you follow the same approach of verifying the signaling status as connected and then consulting the signaling component of the output.
Example 4-30 Examining TE LSP Signaling Status in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng tunnels detail
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 229 seconds
Periodic FRR Promotion: every 300 seconds, next in 205 seconds
Periodic auto-bw collection: disabled
Name: tunnel-te1 Destination: 172.16.255.2
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit PATH1 (Basis for Setup, path weight 3)
G-PID: 0x0800 (derived from egress interface properties)
Config Parameters:
Bandwidth: 100000 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 100000 bw-based
Auto-bw: disabled(0/0) 0 Bandwidth Requested: 100000
Direction: unidirectional
Endpoint switching capability: unknown, encoding type: unassigned
Transit switching capability: unknown, encoding type: unassigned
History:
Tunnel has been up for: 05:04:07
Current LSP:
Uptime: 05:04:07
Prior LSP:
ID: path option 10 [1]
Removal Trigger: tunnel shutdown
Current LSP Info:
Instance: 2, Signaling Area: ospf DEFAULT area 0
Uptime: 00:04:07
Incoming Label: -
Outgoing Interface: POS0/3/0/3, Outgoing Label: 35
Path Info:
Explicit Route:
Strict, 172.16.0.4
Strict, 172.16.0.7
Strict, 172.16.4.2
Strict, 172.16.255.2
Record Route: None
Tspec: avg rate=100000 kbits, burst=1000 bytes, peak rate=100000 kbits
Resv Info:
Record Route: None
Fspec: avg rate=100000 kbits, burst=1000 bytes, peak rate=100000 kbits
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
RP/0/4/CPU0:Router#
Strict, 172.16.255.2
Record Route: None
Tspec: avg rate=100000 kbits, burst=1000 bytes, peak rate=100000 kbits
Resv Info: Record Route: None
Fspec: avg rate=100000 kbits, burst=1000 bytes, peak rate=100000 kbits
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
RP/0/4/CPU0:Router#
You can query the session state to review the details of the signaling information that RSVP used to establish a TE LSP. Cisco IOS uses the show ip rsvp sender detail and show ip rsvp reservation detail commands to generate a complete output of the Path and Resv state information. Cisco IOS XR uses the show ip rsvp sender detail and show ip rsvp reservation detail commands for the same purpose. Examples 4-31 and 4-32 illustrate the command output in Cisco IOS and Cisco IOS XR, respectively.
Example 4-31 Examining RSVP Session State in Cisco IOS
Router#show ip rsvp sender detail PATH: Tun Dest: 172.16.255.3 Tun ID: 1 Ext Tun ID: 172.16.255.1 Tun Sender: 172.16.255.1 LSP ID: 17 Path refreshes: sent: to NHOP 172.16.0.1 on POS0/1/0 Session Attr: Setup Prio: 5, Holding Prio: 5 Flags: (0x4) SE Style Session Name: FROM-ROUTER-TO-DST1 ERO: (incoming) 172.16.255.1 (Strict IPv4 Prefix, 8 bytes, /32) 172.16.0.1 (Strict IPv4 Prefix, 8 bytes, /32) 172.16.8.0 (Strict IPv4 Prefix, 8 bytes, /32) 172.16.255.3 (Strict IPv4 Prefix, 8 bytes, /32) ERO: (outgoing) 172.16.0.1 (Strict IPv4 Prefix, 8 bytes, /32) 172.16.8.0 (Strict IPv4 Prefix, 8 bytes, /32) 172.16.255.3 (Strict IPv4 Prefix, 8 bytes, /32) Traffic params - Rate: 10M bits/sec, Max. burst: 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes Fast-Reroute Backup info: Inbound FRR: Not active Outbound FRR: No backup tunnel selected Path ID handle: 03000404. Incoming policy: Accepted. Policy source(s): MPLS/TE Status: Proxied Output on POS0/1/0. Policy status: Forwarding. Handle: 2E000407 Policy source(s): MPLS/TE Router# Router#show ip rsvp reservation detail Reservation: Tun Dest: 172.16.255.3 Tun ID: 1 Ext Tun ID: 172.16.255.1 Tun Sender: 172.16.255.1 LSP ID: 17 Next Hop: 172.16.0.1 on POS0/1/0 Label: 140 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Resv ID handle: 03000406. Created: 22:11:18 UTC Mon Jul 7 2003 Average Bitrate is 10M bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes Status: Policy: Accepted. Policy source(s): MPLS/TE Router#
Example 4-32 Examining RSVP Session State in Cisco IOS XR
RP/0/4/CPU0:Router#show rsvp sender detail PATH: IPv4-LSP Session addr: 172.16.255.2. TunID: 1. LSPId: 33. Source addr: 172.16.255.129. ExtID: 172.16.255.129. Prot: Off. Backup tunnel: None. Setup Priority: 7, Reservation Priority: 0 Rate: 100M bits/sec. Burst: 1K bytes. Peak: 100M bits/sec. Min unit: 40 bytes, Max unit: 500 bytes Flags: Local Sender. State expires in 0.000 sec. Policy: Accepted. Policy source(s): Default. Header info: RSVP TTL=255. IP TTL=255. Flags: 0x0. TOS=0xff. Input interface: None. Previous hop: 0.0.0.0 (lih: 0x0). Output on PO0/3/0/3. Policy: Forwarding. Class-Type: None. Explicit Route (Incoming): Strict, 172.16.0.4/32 Strict, 172.16.0.7/32 Strict, 172.16.4.2/32 Strict, 172.16.255.2/32 Explicit Route (Outgoing): Strict, 172.16.0.4/32 Strict, 172.16.0.7/32 Strict, 172.16.4.2/32 Strict, 172.16.255.2/32 RP/0/4/CPU0:Router# RP/0/4/CPU0:Router#show rsvp reservation detail RESV: IPv4-LSP Session addr: 172.16.255.2. TunID: 1. LSPId: 33. Source addr: 172.16.255.129. ExtID: 172.16.255.129. Input adjusted interface: PO0/3/0/3. Input physical interface: PO0/3/0/3. Next hop: 172.16.0.4 (lih: 0x59300004). Style: Shared-Explicit. Service: Controlled-Load. Rate: 100M bits/sec. Burst: 1K bytes. Peak: 100M bits/sec. MTU min: 0, max: 0 bytes. Flags: None. State expires in 231.030 sec. Policy: Accepted. Policy source(s): Default. Header info: RSVP TTL=255. IP TTL=255. Flags: 0x0. TOS=0xc0. Resource: Labels: Outgoing downstream: 34. RP/0/4/CPU0:Router#
Traffic Selection
You can use several mechanisms to select what traffic a tunnel carries. These mechanisms are independent of the establishment of the TE LSP. Traffic selection takes place at the tunnel headend. Any other node along the path of a TE LSP cannot inject traffic into that TE LSP. Cisco IOS and Cisco IOS XR offer multiple alternatives to perform traffic selection. The next two sections provide an overview of these mechanisms.
Traffic-Selection Alternatives
You can use static methods to inject IP traffic into a tunnel. The two static mechanisms available are static routes and policy-based routing. In both cases, you need to specify the tunnel as the output interface for the routing decision. These two mechanisms can be simple, but their static nature can affect their applicability in many MPLS TE implementations.
Autoroute and forwarding adjacencies enable you to route IP traffic dynamically into a tunnel. The autoroute functionality instructs the IGP to use MPLS TE tunnels as the next-hop interface to reach tailends and downstream destinations. The IGP does not need to build adjacencies through the tunnels. You enable this behavior with the tunnel mpls traffic-eng autoroute command in Cisco IOS. Cisco IOS XR uses the autoroute command. By default, prefixes pointing to tunnel interfaces will have the metric of the shortest physical path. The same commands enable you to tune those metrics. In contrast with autoroute, you can configure a forwarding adjacency between the headend and tailend to instruct the IGP to build a routing adjacency and include the tunnel as another link in their IGP advertisements. In some scenarios, this behavior is desirable. In most cases, autoroute suffices and provides a more scalable solution.
Pseudowire tunnel selection are two additional mechanisms available to inject traffic into a tunnel. The next section covers CBTS, given the importance to use MPLS TE to improve the quality of service of an MPLS network.
Class-Based Tunnel Selection
You can also use MPLS EXP values as tunnel-selection criteria (that is, CBTS). You can use CBTS to discriminate as to which MPLS EXP values a node forwards through specific tunnels. The node must have selected a group of tunnels with the same tailend to reach a particular destination. The selection of the tunnels could be the result of static routes or autoroute configuration. You use the tunnel mpls traffic-eng exp command in Cisco IOS to configure CBTS under the tunnel interface. You should configure at least one of the tunnels as a default, or explicitly configure all possible MPLS EXP values among the tunnels that reach the destination.
Figure 4-2 shows node A that uses CBTS to reach two other nodes D and H. Node A has Tunnel1 and Tunnel2 to reach node D. It also has Tunnel3 and Tunnel4 to reach node H. Using CBTS, node A sends packets with destination D down Tunnel1 if they have an MPLS EXP value of 5. It sends all other packets to destination D through Tunnel2. Similarly, node A sends all packets to destination H through Tunnel3 if they have MPLS EXP values 3 or 4. All other packets to destination H follow Tunnel4.
CBTS
Example 4-33 shows the configuration in node A. Two static routes define Tunnel1 and Tunnel2 as output interfaces for prefix 192.168.0.0/24. Tunnel3 and Tunnel4 select traffic using the autoroute mechanism. Without CBTS, node A would load balance traffic to each destination using the two respective tunnels.
Example 4-33 CBTS in Cisco IOS Using Autoroute and Static Routes
interface Tunnel1 description A2D-EF ip unnumbered Loopback0 tunnel destination 172.16.255.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 5 5 tunnel mpls traffic-eng bandwidth 10000 tunnel mpls traffic-eng path-option 10 dynamic tunnel mpls traffic-eng exp 5 ! interface Tunnel2 description A2D-DEFAULT ip unnumbered Loopback0 tunnel destination 172.16.255.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 75000 tunnel mpls traffic-eng path-option 10 explicit name PATH1 tunnel mpls traffic-eng exp default ! interface Tunnel3 description A2H-3-4 ip unnumbered Loopback0 tunnel destination 172.16.255.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng autoroute metric relative -2 tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 50000 tunnel mpls traffic-eng path-option 10 dynamic tunnel mpls traffic-eng exp 3 4 ! interface Tunnel4 description A2H-DEFAULT ip unnumbered Loopback0 tunnel destination 172.16.255.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng autoroute metric relative -2 tunnel mpls traffic-eng path-option 10 dynamic tunnel mpls traffic-eng path-selection metric igp tunnel mpls traffic-eng exp default ! ip route 192.168.0.0 255.255.255.0 Tunnel1 ip route 192.168.0.0 255.255.255.0 Tunnel2 !
Tip – Using CBTS, you can send some MPLS EXP values through engineered paths and some other values through the IGP shortest path for a specific destination. To use the IGP shortest path, you need to define a tunnel without any constraints and enable autoroute on that tunnel. The path selection should use the IGP metric if you have configured TE metrics explicitly. That is exactly the purpose of Tunnel4 in Example 4-27.
DiffServ-Aware Traffic Engineering (DS-TE)
Cisco IOS and Cisco IOS XR provide support for the DS-TE protocol extensions. You can use either IS-IS or OSPF as your IGP. Both operating systems support the Russian dolls model (RDM) and maximum allocation model (MAM) for bandwidth constraints. The configuration and verification commands for DS-TE are generally extensions to the original MPLS TE commands. The following section, “Prestandard DS-TE,” briefly describes the early DS-TE implementation. The subsequent sections focus on the standard DS-TE implementation.
Prestandard DS-TE
Cisco IOS and Cisco IOS XR support a prestandard and a standard implementation of DS-TE. During the standardization process, the specifications of the protocol extensions evolved since the time that Cisco IOS and Cisco IOS XR introduced support for DS-TE. These implementations are not interoperable because they use different protocol extensions. Moving forward, you can expect this early implementation to support only a subset of the functionality available in the standard implementation. Table 4-1 illustrates the differences between prestandard and standard DS-TE in Cisco IOS and Cisco IOS XR. The following sections focus on the standard DS-TE functionality.
Table 4-1 Differences Between Prestandard and Standard DS-TE
Prestandard DS-TE | Standard DS-TE |
Enabled by default | Explicitly configured using the mpls traffic-eng ds-te mode ietf command in Cisco IOS and the ds-te mode ietf command in Cisco IOS XR |
Supports RDM | Supports RDM and MAM |
No RSVP extensions; subpool signaled as guaranteed service; global pool signaled as controlled-load service. | Uses RSVP extensions (CLASSTYPE object) |
Modifies IGP link advertisements to include 2 pools at 8 priority levels each (16 entries per link total) | No modifications to IGP link advertisements (unreserved bandwidth at 8 priority levels), but new semantics |
Bandwidth constraints and bandwidth constraint model information not included in IGP link advertisement | Bandwidth constraints and bandwidth constraint model information included in IGP link advertisement |
Note – Cisco IOS also supports a migration mode for DS-TE deployments that used the initial DS-TE implementation. In this migration mode, a node uses prestandard link flooding and TE LSP signaling but can process prestandard and standard link flooding and TE LSP signaling. You can enable this migration mode with the mpls traffic-eng ds-te mode migration command.
Class-Types and TE-Class
A DS-TE deployment requires the definition of TE-Classes, Class-Types for MPLS TE tunnels, and bandwidth constraints that links will enforce. DS-TE reuses the MPLS TE mechanisms and commands. In Cisco IOS, you enable DS-TE on a node using the mpls traffic-eng ds-te mode ietf command and enter the configuration mode where you define any TE-Class with the mpls traffic-eng ds-te te-classes command. Cisco IOS XR uses the ds-te mode ietf command to enable DS-TE and the ds-te te-classes command to enter the configuration mode for TE-Class definition. These two commands reside under the mpls traffic-eng configuration mode. The te-class command allows you to define individual classes under the TE-Class configuration. Table 4-2 shows the default TE-Class definitions in both operating systems.
Table 4-2 Default TE-Class Definition in Cisco IOS and Cisco IOS XR
TE-Class | Class-Type | Priority |
0 | 0 | 7 |
1 | 1 | 7 |
2 | Unused | Unused |
3 | Unused | Unused |
4 | 0 | 0 |
5 | 1 | 0 |
6 | Unused | Unused |
7 | Unused | Unused |
Examples 4-34 and 4-35 show a TE-Class configuration in Cisco IOS and Cisco IOS XR, respectively.
In Example 4-34, a CT1 TE LSP can preempt a CT0 TE LSP but not vice versa. A CT0 TE LSP with a better priority (for instance, those corresponding to TE-Class 4) could still preempt a CT0 TE LSP with worse priority (TE-Class 5 through 7).
Example 4-34 TE-Class Definition in Cisco IOS
mpls traffic-eng tunnels mpls traffic-eng ds-te te-classes te-class 0 class-type 1 priority 0 te-class 1 class-type 1 priority 1 te-class 2 class-type 1 priority 2 te-class 3 class-type 1 priority 3 te-class 4 class-type 0 priority 4 te-class 5 class-type 0 priority 5 te-class 6 class-type 0 priority 6 te-class 7 class-type 0 priority 7 mpls traffic-eng ds-te mode ietf !
Example 4-35 shows a different TE-Class definition using Cisco IOS XR. In this case, a CT1 TE LSP can preempt some CT0 TE LSPs and vice versa. However, Other TE LSPs cannot preempt CT1 TE LSPs corresponding to TE-Class 0. This configuration defines only a subset of the eight maximum TE-Classes you can specify.
Example 4-35 TE-Class Definition in Cisco IOS XR
mpls traffic-eng interface POS0/3/0/0 ! interface POS0/3/0/1 ! ds-te mode ietf ds-te te-classes te-class 0 class-type 1 priority 0 te-class 1 class-type 0 priority 1 te-class 2 class-type 1 priority 2 te-class 3 class-type 0 priority 3 te-class 4 unused te-class 5 unused te-class 6 unused te-class 7 unused ! !
Defining a DS-TE Tunnel Interface
Example 4-36 shows the configuration of two DS-TE tunnels in Cisco IOS. Tunnel1 signals CT1 with setup priority 0. The class-type keyword in the tunnel mpls traffic-eng bandwidth command instructs the node to use CT1. Tunnel2 signals Class-Type 0 with priority 7. These two tunnels correspond to TE-Class 0 and 7 in Example 4-34, respectively. The tunnel mpls traffic-eng bandwidth command defines CT0 TE LSPs by default if you do not specify the class-type (or sub-pool) keyword. The class type and priority that you configure for a tunnel must be consistent with your TE-Class definitions, and those definitions must be consistent throughout your DS-TE network.
Example 4-36 MPLS TE Tunnels Using DS-TE in Cisco IOS
interface Tunnel1 description FROM-ROUTER-TO-DST1-CT1 ip unnumbered Loopback0 tunnel destination 172.16.255.131 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 0 0 tunnel mpls traffic-eng bandwidth class-type 1 5000 tunnel mpls traffic-eng path-option 20 dynamic ! interface Tunnel2 description FROM-ROUTER-TO-DST1-CT0 ip unnumbered Loopback0 tunnel destination 172.16.255.131 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 100000 tunnel mpls traffic-eng path-option 20 dynamic !
Example 4-37 shows the configuration of two DS-TE tunnels in Cisco IOS XR. The class-type keyword in the signalled-bandwidth command specifies the Class-Type to 1. If you do not use the sub-pool keyword, the node signals CT0 for the TE LSP. In this case, tunnel-te1 uses CT1 with priority 2, and tunnel-te2 uses CT0 with priority 3. Those combinations correspond to TE-Class 2 and 3 in Example 4-35, respectively. Again, the Class-Type and priorities that you configure for a tunnel must match a valid TE-Class, and your TE-Class definitions must be consistent throughout your DS-TE network.
Example 4-37 MPLS TE Tunnels Using DS-TE in Cisco IOS XR
interface tunnel-te1 description FROM-ROUTER-TO-DST1-CT1 ipv4 unnumbered Loopback0 priority 2 2 signalled-bandwidth class-type 1 5000 destination 172.16.255.130 path-option 30 dynamic ! interface tunnel-te2 description FROM-ROUTER-TO-DST1-CT0 ipv4 unnumbered Loopback0 priority 3 3 signalled-bandwidth 50000 destination 172.16.255.130 path-option 30 dynamic !
Configuring Bandwidth Constraints
You need to define the per-link bandwidth constraints throughout your DS-TE network. Cisco IOS supports the RDM and MAM. RDM is the default bandwidth constraints mode. You use the mpls traffic-eng ds-te bc-model mam command to enable MAM. The ip rsvp bandwidth interface command specifies the bandwidth constraints for a link. The command uses the rdm and mam keywords to associate the constraints to a particular model. For RDM, the first bandwidth amount in the command specifies BC0. A second bandwidth amount following the sub-pool keyword specifies BC1. For MAM, you use the max-reservable-bw keyword to define the maximum reservable bandwidth. The bc0 and bc1 keywords enable you to specify BC0 and BC1, respectively. You can also specify BC1 with the sub-pool keyword.
Example 4-38 shows the configuration of the RDM bandwidth constraints that two interfaces will enforce. In this case, interface POS0/1/0 has a BC0 of 100,000 kbps and a BC1 of 0. Interface POS1/0/0 has a BC0 of 155,000 kbps and a BC1 of 55,000 kbps.
Example 4-38 Interfaces Using DS-TE with RDM in Cisco IOS
interface POS0/1/0 ip address 172.16.0.0 255.255.255.254 mpls traffic-eng tunnels ip rsvp bandwidth rdm bc0 100000 ! interface POS1/0/0 ip address 172.16.0.2 255.255.255.254 mpls traffic-eng tunnels ip rsvp bandwidth rdm bc0 155000 bc1 55000 !
Example 4-39 illustrates the configuration of MAM in Cisco IOS. In this case, both interfaces POS0/1/0 and POS1/0/0 have a maximum reservable bandwidth of 155,000 kbps. Interface POS0/1/0 divides the maximum reservable bandwidth in 100,000 kbps for BC0 and 55,000 for BC1. Interface POS1/0/0 uses a different approach where both BC0 and BC1 are 90,000 kbps and their sum exceeds the maximum reservable bandwidth. These constraints facilitate bandwidth sharing between CT0 and CT1 on this interface.
Example 4-39 Interfaces Using DS-TE with MAM in Cisco IOS
mpls traffic-eng ds-te bc-model mam ! interface POS0/1/0 ip address 172.16.0.0 255.255.255.254 mpls traffic-eng tunnels ip rsvp bandwidth mam max-reservable-bw 155000 bc0 100000 bc1 55000 ! interface POS1/0/0 ip address 172.16.0.2 255.255.255.254 mpls traffic-eng tunnels ip rsvp bandwidth mam max-reservable-bw 155000 bc0 90000 bc1 90000 !
Cisco IOS XR also supports both RDM and MAM. You select the bandwidth constraint model using the ds-te bc-model command, with RDM being the default model. You specify BC0 with the bc0 keyword in the bandwidth interface command under the rsvp configuration mode. The bc1 keyword defines BC1. The same bandwidth command specifies the model the bandwidth constraints apply to with the rdm and mam keywords. The model you configure on the node must match the model you configure with the bandwidth command. When you define MAM constraints, the max-reservable-bw keyword defines the maximum reservable bandwidth on the interface.
Note – Consult the software documentation for the most updated information on the number of bandwidth constraints that a particular device can support.
Example 4-40 shows the configuration of RDM in Cisco IOS XR. In this case, interface POS0/3/0/0 has a BC0 of 155,000 kbps and a BC1 value of 55,000 kbps. Interface POS0/3/0/1 has a slightly different configuration with a BC0 of 100,000 kbps and a BC1 of 55,000 kbps.
Example 4-40 Interfaces Using DS-TE with RDM in Cisco IOS XR
rsvp interface POS0/3/0/0 bandwidth rdm bc0 155000 bc1 55000 ! interface POS0/3/0/1 bandwidth rdm bc0 100000 bc1 55000 ! !
Example 4-41 illustrates the configuration of MAM in Cisco IOS XR. Interface POS0/3/0/0 has a maximum reservable bandwidth of 155,000 kbps, a BC0 of 100,000 kbps, and a BC1 of 100,000 kbps. Interface POS0/3/0/1 has a maximum reservable bandwidth of 155,000 kbps, a BC0 of 100,000 kbps, and a BC1 of 55,000 kbps. Notice that for interface POS0/3/0/0, the sum of the two bandwidth constraints is higher than the maximum reservable bandwidth to improve bandwidth sharing acess CTs with this model.
Example 4-41 Interfaces Using DS-TE with MAM in Cisco IOS XR
rsvp interface POS0/3/0/0 bandwidth mam max-reservable-bw 155000 bc0 100000 bc1 100000 ! interface POS0/3/0/1 bandwidth mam max-reservable-bw 155000 bc0 100000 bc1 55000 ! ! mpls traffic-eng interface POS0/3/0/0 ! interface POS0/3/0/1 ! ds-te mode ietf ds-te bc-model mam !
Verifying DS-TE Link Information Distribution
DS-TE slightly modifies existing verification and debug commands instead of introducing new ones. Therefore, you continue to use the troubleshooting commands that previous verification sections discussed, primarily show mpls traffic-eng link-management advertisements, show mpls traffic-eng topology, and show mpls traffic-eng tunnels.
Example 4-42 illustrates the modification that DS-TE introduces to the output of the show mpls traffic-eng topology command in Cisco IOS. Similarly, Example 4-43 illustrates the output of the show mpls traffic-eng topology command in Cisco IOS XR when you enable DS-TE. Notice that both outputs highlight the bandwidth constraint model, the bandwidth constraint values, and the bandwidth available for each of the TE-Classes for each link.
Example 4-42 Examining the MPLS TE Topology Database with DS-TE Enabled in Cisco IOS
Router#show mpls traffic-eng topology 172.16.255.1
IGP Id: 172.16.255.1, MPLS TE Id:172.16.255.1 Router Node (ospf 100 area 0) id 1
link[0]: Point-to-Point, Nbr IGP Id: 172.16.255.131, nbr_node_id:2, gen:121
frag_id 0, Intf Address:172.16.0.2, Nbr Intf Address:172.16.0.3
TE metric:1, IGP metric:1, attribute flags:0x0
SRLGs: None
physical_bw: 155000 (kbps),
BC Model Id: RDM
BC0 (max_reservable): 155000 (kbps)
BC0 (max_reservable_bw_global): 155000 (kbps)
BC1 (max_reservable_bw_sub): 55000 (kbps)
Total Allocated Reservable
BW (kbps) BW (kbps)
--------------- -----------
TE-Class[0]: 5000 50000
TE-Class[1]: 5000 50000
TE-Class[2]: 5000 50000
TE-Class[3]: 5000 50000
TE-Class[4]: 5000 150000
TE-Class[5]: 5000 150000
TE-Class[6]: 5000 150000
TE-Class[7]: 105000 50000
! Output omitted for brevity
Example 4-43 Examining the MPLS TE Topology Database with DS-TE Enabled in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng topology 172.16.255.129
My_System_id: 172.16.255.129 (ospf DEFAULT area 0)
My_BC_Model_Type: RDM
Signalling error holddown: 10 sec Global Link Generation 481
IGP Id: 172.16.255.129, MPLS TE Id: 172.16.255.129 Router Node (ospf DEFAULT area 0)
Link[0]:Point-to-Point, Nbr IGP Id:172.16.255.130, Nbr Node Id:28, gen:481
Frag Id:0, Intf Address:172.16.192.0, Intf Id:0
Nbr Intf Address:172.16.192.1, Nbr Intf Id:0
TE Metric:1, IGP Metric:1, Attribute Flags:0x0
Switching Capability:, Encoding:
BC Model ID:RDM
Physical BW:155520 (kbps), Max Reservable BW:100000 (kbps)
BC0:100000 (kbps) BC1:55000 (kbps)
Total Allocated Reservable
BW (kbps) BW (kbps)
--------------- -----------
TE-class[0]: 0 55000
TE-class[1]: 0 100000
TE-class[2]: 5000 50000
TE-class[3]: 55000 45000
TE-class[4]: 0 0
TE-class[5]: 0 0
TE-class[6]: 0 0
TE-class[7]: 0 0
! Output omitted for brevity
Verifying Signaling of DS-TE LSPs
DS-TE does not define new commands to verify the signaling of TE LSPs. As described in section “Verifying Signaling of TE LSPs,” the show mpls traffic-eng tunnels, show ip rsvp sender detail, and show ip rsvp reservation detail commands provide all the signaling details for a TE LSP in Cisco IOS. Cisco IOS XR provides the equivalent show mpls traffic-eng tunnels, show rsvp sender detail, and show rsvp reservation detail commands. When you use DS-TE, those commands provide similar output and specify the CT that the TE LSP uses.
Fast Reroute (FRR)
Cisco IOS and Cisco IOS XR provide FRR for link and node protection. Both operating systems use the facility technique because of its superior scalability. You can use FRR with regular TE LSPs or DS-TE LSPs. In addition, you can configure your network to provide connectivity protection or bandwidth protection to make sure that backup tunnels have sufficient capacity before the point of local repair (PLR) selects them to protect a primary TE LSP. To deploy FRR, you must configure the headend of the primary tunnel to request protection-and you must configure at least one midpoint with a backup tunnel to reroute the primary TE LSPs. The backup tunnel must be a next hop (NHOP) or next-next hop (NNHOP) tunnel that bypasses the failure and intersects the primary TE LSP.
You need to configure which TE LSPs require protection with FRR. Cisco IOS uses the tunnel mpls traffic-eng fast-reroute command that you need to apply on the MPLS TE tunnel interface at the headend. The node-protect and bw-protect keywords are optional and set the corresponding node protection desired and bandwidth protection desired flags in the signaling of the primary TE LSP. Cisco PLRs attempt to provide the best protection possible to a primary TE LSP even if you do not set these flags. Cisco IOS XR uses the fast-reroute command on the MPLS TE tunnel to signal that the TE LSP desires protection. Examples 4-44 and 4-45 show MPLS TE tunnels in Cisco IOS and Cisco IOS XR that request FRR protection.
Example 4-44 Tunnel Requesting FRR with Node and Bandwidth Protection in Cisco IOS
interface Tunnel1 description FROM-ROUTER-TO-DST1-FRR-NODEP-BWP ip unnumbered Loopback0 tunnel destination 172.16.255.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 20000 tunnel mpls traffic-eng path-option 10 explicit name PATH2 tunnel mpls traffic-eng fast-reroute bw-protect node-protect !
Example 4-45 Tunnel Requesting FRR Protection in Cisco IOS XR
interface tunnel-te1 description FROM-ROUTER-TO-DST1-FRR ipv4 unnumbered Loopback0 priority 3 3 signalled-bandwidth 30000 class-type 1 destination 172.16.255.2 fast-reroute path-option 10 explicit name PATH1 !
Link and Node Protection
You need to pre-establish a backup TE LSP to implement link and node protection. You can configure this backup with an MPLS TE tunnel interface using the same commands that you use to configure the primary tunnel. The headend of the backup tunnel will always reside on the PLR. Conversely, the tailend will always be the merge point (MP). The backup tunnel can rely on a dynamically computed path or an explicit path. The only obvious restriction is that the path options for the backup tunnel must not use the facility (link, node, or shared-risk link group [SRLG]) whose failure you are trying to protect against. Backup tunnels commonly do not use an explicit bandwidth reservation. Remember that backup tunnels remain unused most of the time, and an explicit reservation limits your ability to share bandwidth.
The tunnel destination determines the type of protection a backup tunnel provides. An NHOP (adjacent neighbor) destination defines a backup tunnel that can protect against the failure of the link that connects to that neighbor. An NNHOP (a neighbor’s neighbor) destination protects against the adjacent neighbor failure for those TE LSPs also traversing that second neighbor. Depending on your topology, you may need multiple backup tunnels to fully protect against the failure of an adjacent neighbor. A PLR may also have multiple backup tunnels to the same destination and protect against the same failure. This allows you to provide redundancy in case a backup tunnel fails and to distribute the primary TE LSPs across several backup tunnels.
You need to associate the backup tunnel with a physical interface that will detect the failure. Cisco IOS uses the mpls traffic-eng backup-path interface command for that purpose. Cisco IOS XR uses the backup-path command under a particular interface in the mpls traffic-eng configuration mode. You use the same command regardless of the type of protection you are trying to implement. To accelerate the detection of some node failures, you might need to enable RSVP hello messages or Bidirectional Forwarding Detection (BFD) between the PLR and the adjacent neighbor. In many cases, the PLR will detect the node failure as a link failure.
Examples 4-39 and 4-40 illustrate the configuration of backup tunnels in Cisco IOS and Cisco IOS XR, respectively. In both examples, one of the tunnels provides link protection; the other tunnel provides node protection. All tunnels use dynamic path computation that excludes the appropriate node or link. Figure 4-3 shows the details of the network topology and the tunnel paths.
In Example 4-46, node A has an NHOP tunnel, Tunnel1, and NNHOP tunnel, Tunnel2. Tunnel1 provides link protection, with interface POS0/1/1 acting as the failure-detection point. Tunnel2 provides node protection, with interface POS1/0/0 as failure-detection point. Similarly, Example 4-47 shows an NHOP tunnel, tunnel-te1, and an NNHOP tunnel, tunnel-te2, on node B. In this example, tunnel-te1 provides link protection and uses interface POS0/3/0/1 as the failure-detection point. Similarly, tunnel-te2 provides node protection and uses interface POS0/3/0/2 for the same purpose.
Sample Network Topology with Link and Node Protection
Example 4-46 Backup Tunnels for Link and Node Protection in Cisco IOS
interface Tunnel1 description NHOP-BACKUP ip unnumbered Loopback0 tunnel destination 172.16.255.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name PATH1 ! interface Tunnel2 description NNHOP-BACKUP ip unnumbered Loopback0 tunnel destination 172.16.255.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 10 explicit name PATH2 ! interface POS0/1/1 ip address 172.16.4.3 255.255.255.254 mpls traffic-eng tunnels mpls traffic-eng backup-path Tunnel1 ip rsvp bandwidth 155000 ! interface POS1/0/0 ip address 172.16.192.5 255.255.255.254 mpls traffic-eng tunnels mpls traffic-eng backup-path Tunnel2 ip rsvp bandwidth 155000 ! ip explicit-path name PATH1 enable exclude-address 172.16.4.2 ! ip explicit-path name PATH2 enable exclude-address 172.16.255.130 !
Example 4-47 Backup Tunnels for Link and Node Protection in Cisco IOS XR
explicit-path name PATH1 index 1 exclude-address ipv4 unicast 172.16.192.1 ! explicit-path name PATH2 index 1 exclude-address ipv4 unicast 172.16.255.131 ! interface tunnel-te1 description NHOP-BACKUP ipv4 unnumbered Loopback0 destination 172.16.255.130 path-option 10 explicit name PATH1 ! interface tunnel-te2 description NNHOP-BACKUP ipv4 unnumbered Loopback0 destination 172.16.255.130 path-option 10 explicit name PATH2 ! mpls traffic-eng interface POS0/3/0/1 backup-path tunnel-te 1 ! interface POS0/3/0/2 backup-path tunnel-te 2 ! !
Note – Cisco IOS provides the automatic creation of backup TE LSPs. You enable this behavior with the mpls traffic-eng auto-tunnel backup command. A detailed discussion of this functionality is beyond the scope of this book. Consult the Cisco IOS documentation for further details.
Bandwidth Protection
The PLR can manage the capacity of backup tunnels to provide bandwidth protection. You can use the tunnel mpls traffic-eng backup-bw command and the backup-bw command to explicitly configure the backup tunnel capacity in Cisco IOS and Cisco IOS XR, respectively. They provide local knowledge of the capacity of the backup tunnels and do not instruct the PLR to signal a bandwidth reservation. With proper design, a PLR can provide bandwidth protection even if the backup tunnel does not reserve bandwidth. A PLR provides bandwidth protection for any primary TE LSP that requests protection if possible. However, it gives precedence to TE LSPs with nonzero bandwidth that request bandwidth protection.
You configure the capacity of a backup tunnel in terms of a bandwidth amount and the Class-Types they can protect. With respect to the bandwidth amount, you can configure the backup with an explicit (limited) bandwidth amount or as a backup with unlimited bandwidth. With respect to Class-Types, you can configure a backup tunnel to protect TE LSPs using the global pool (CT0), the subpool (CT1), or any bandwidth pool (CT0 or CT1). Bandwidth protection enables you to define multiple backup tunnels with different capacity configuration to protect against the same failure. When the PLR detects a TE LSP that requires protection, it evaluates which backup tunnel can provide the best level of bandwidth protection.
Table 4-3 shows the criteria that the PLR uses to select from among multiple backup tunnels to protect a primary TE LSP. In general, the PLR prefers NNHOP over NHOP tunnels because they can protect against both a node and a link failure. It prefers backup tunnels with an explicit (limited) bandwidth amount. Finally, it prefers an exact Class-Type match over backup tunnels that protect any Class-Type. The most preferable backup tunnel will be an NNHOP tunnel with a limited bandwidth amount and an exact class match. In contrast, the least desirable backup tunnel will be an NHOP tunnel with unlimited bandwidth for any Class-Type. This tunnel provides the lowest certain of bandwidth guarantee.
Table 4-3 Priorities for Backup Tunnel Selection in Cisco IOS and Cisco IOS XR
Preference | Backup Tunnel Destination | Bandwidth Amount | Bandwidth Pool |
0 (best) | NNHOP | Limited | Exact match |
1 | NNHOP | Limited | Any |
2 | NNHOP | Unlimited | Exact match |
3 | NNHOP | Unlimited | Any |
4 | NHOP | Limited | Exact match |
5 | NHOP | Limited | Any |
6 | NHOP | Unlimited | Exact match |
7 (worst) | NHOP | Unlimited | Any |
Example 4-48 shows the bandwidth protection configuration on a PLR in Cisco IOS and Cisco IOS XR, respectively. Examine Figure 4-4.
Sample Network Topology with Cisco IOS PLR Providing Bandwidth Protection
In Example 4-48, interface POS1/0/0 can trigger three backup tunnels:
Tunnel1 is an NNHOP backup tunnel protecting 40,000 kbps for CT TE LSPs.
Tunnel2 is an NNHOP tunnel that can protect 90,000 kbps for CT0 LSPs.
Tunnel3 is an NHOP tunnel that can protect 90,000 kbps for TE LSPs of any CT.
Example 4-48 Backup Tunnels for Bandwidth Protection in Cisco IOS
interface Tunnel1 description NNHOP-BACKUP-40M-CT1 ip unnumbered Loopback0 tunnel destination 172.16.255.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng backup-bw 40000 class-type 1 tunnel mpls traffic-eng path-option 10 explicit name PATH1 ! interface Tunnel2 description NNHOP-BACKUP-90M-CT0 ip unnumbered Loopback0 tunnel destination 172.16.255.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng backup-bw 90000 class-type 0 tunnel mpls traffic-eng path-option 10 explicit name PATH2 ! interface Tunnel3 description NHOP-BACKUP-90M-ANY-CT ip unnumbered Loopback0 tunnel destination 172.16.255.130 tunnel mode mpls traffic-eng tunnel mpls traffic-eng backup-bw 90000 tunnel mpls traffic-eng path-option 10 explicit name PATH3 ! interface POS1/0/0 ip address 172.16.192.5 255.255.255.254 mpls traffic-eng tunnels mpls traffic-eng backup-path Tunnel1 mpls traffic-eng backup-path Tunnel2 mpls traffic-eng backup-path Tunnel3 ip rsvp bandwidth rdm 155000 sub-pool 55000 ! ip explicit-path name PATH1 enable exclude-address 172.16.255.130 ! ip explicit-path name PATH3 enable next-address 172.16.192.2 next-address 172.16.192.1 ! ip explicit-path name PATH2 enable next-address 172.16.4.2 !
Examine Figure 4-5.
Example 4-49 shows three backup tunnels that could re-reroute traffic in case of a failure on interface POS0/3/0/1:
tunnel-te1 is an NHOP tunnel protecting 55,000 kbps for CT0 TE LSPs.
tunnel-te2 is an NNHOP tunnel that supports a protection capacity of 20,000 for CT0 TE LSPs.
tunnel-te3 is an NHOP tunnel that protects 25,000 kbps for CT1 TE LSPs.
Sample Network Topology with Cisco IOS XR PLR Providing Bandwidth Protection
Example 4-49 Bandwidth Protection in Cisco IOS XR
interface tunnel-te1 description NHOP-BACKUP-55M-CTO ipv4 unnumbered Loopback0 backup-bw 55000 class-type 0 destination 172.16.255.130 path-option 10 explicit name PATH1 ! interface tunnel-te2 description NNHOP-BACKUP-20M-CTO ipv4 unnumbered Loopback0 backup-bw 20000 class-type 0 destination 172.16.255.2 path-option 10 explicit name PATH2 ! interface tunnel-te3 description NHOP-BACKUP-25M-ANY-CT ipv4 unnumbered Loopback0 backup-bw 25000 class-type 1 destination 172.16.255.130 path-option 10 explicit name PATH1 ! mpls traffic-eng interface POS0/3/0/1 backup-path tunnel-te 1 backup-path tunnel-te 2 backup-path tunnel-te 3 ! !
Verifying FRR on the Headend
In Cisco IOS, you can verify the operation of FRR on a headend by examining the Path and Resv state of the primary TE LSP. The show ip rsvp sender detail command provides the most detail about the Path state of a TE LSP. This command enables you to verify whether the node is signaling the TE LSP with any of the FRR flags (local protection desired, node protection desired, or bandwidth protection desired). Similarly, the show ip rsvp reservation detail command provides the details of the Resv state. This command displays the hop-by-hop route information that the signaling packets collected. In Example 4-50, you see that the first node in the path is providing bandwidth protection for an LSP with an NNHOP backup tunnel.
Example 4-50 Examining Primary TE LSP Protection at the Headend in Cisco IOS
Router#show ip rsvp reservation detail Reservation: Tun Dest: 172.16.255.2 Tun ID: 1 Ext Tun ID: 172.16.255.1 Tun Sender: 172.16.255.1 LSP ID: 6 Next Hop: 172.16.0.3 on POS1/0/0 Label: 30 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Resv ID handle: 06000410. Created: 16:25:39 UTC Tue Jul 29 2003 Average Bitrate is 20M bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes RRO: 172.16.255.131/32, Flags:0x2D (Local Prot Avail/Has BW/to NNHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 30 172.16.255.130/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 33 172.16.255.2/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 0 Status: Policy: Accepted. Policy source(s): MPLS/TE Router#
Example 4-51 shows how to verify the operation of FRR on a headend in Cisco IOS XR. In this case, the show mpls traffic-eng tunnels command provides enough detail about the RSVP state of the TE LSP. In particular, the decoded route record object (RRO) will show you, for every hop in the path, whether the TE LSP has local protection, whether protection is active (the node is rerouting the TE LSP through a backup), and whether bandwidth or node protection is available. The flags in the IPv4/IPv6 subobject contain that information. In this example, the first hop (node ID 172.16.255.131) provides local protection with node and bandwidth protection (flags 0x2d).
Example 4-51 Examining Primary TE LSP Protection at the Headend in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng tunnels role head detail
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 1244 seconds
Periodic FRR Promotion: every 300 seconds, next in 173 seconds
Periodic auto-bw collection: disabled
Name: tunnel-te1 Destination: 172.16.255.2
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit PATH1 (Basis for Setup, path weight 3)
G-PID: 0x0800 (derived from egress interface properties)
Config Parameters:
Bandwidth: 30000 kbps (CT1) Priority: 3 3 Affinity: 0x0/0xffff
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 30000 bw-based
Auto-bw: disabled(0/0) 0 Bandwidth Requested: 30000
Direction: unidirectional
Endpoint switching capability: unknown, encoding type: unassigned
Transit switching capability: unknown, encoding type: unassigned
History:
Tunnel has been up for: 02:01:00
Current LSP:
Uptime: 02:01:00
Current LSP Info:
Instance: 9, Signaling Area: ospf DEFAULT area 0
Uptime: 02:01:00
Incoming Label: explicit-null
Outgoing Interface: POS0/3/0/2, Outgoing Label: 33
Path Info:
Explicit Route:
Strict, 172.16.192.3
Strict, 172.16.192.4
Strict, 172.16.4.0
Strict, 172.16.255.2
Record Route: None
Tspec: avg rate=30000 kbits, burst=1000 bytes, peak rate=30000 kbits
Resv Info:
Record Route:
IPv4 172.16.255.131, flags 0x2d
Label 33, flags 0x1
IPv4 172.16.255.130, flags 0x20
Label 32, flags 0x1
IPv4 172.16.255.2, flags 0x20
Label 0, flags 0x1
Fspec: avg rate=30000 kbits, burst=1000 bytes, peak rate=30000 kbits
Displayed 1 (of 1) heads, 0 (of 1) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
RP/0/4/CPU0:Router#
Examine the information in Table 4-4.
Table 4-4 Flags in the RRO IPv4/IPv6 Subobject
Value (Hexadecimal) | Flag | Description |
0x01 | Local protection available | Node can protect TE LSP. |
0x02 | Local protection in use | Node is rerouting the TE LSP through the backup tunnel. |
0x04 | Bandwidth protection | Node can provide bandwidth protection for the TE LSP. |
0x08 | Node protection | Node can provide protection against downstream node failure. |
0x10 | Preemption pending | TE LSP preemption pending. Headend should reroute the TE LSP. |
0x20 | Node ID | Address represents node ID rather than a link address. |
Verifying FRR on the PLR
A PLR will provide the details of the primary TE LSPs it is protecting and what backup tunnel it uses for that purpose.
Example 4-52 shows the output of the show mpls traffic-eng fast-reroute database command in Cisco IOS. If the PLR has selected a backup for a primary TE LSP, the command displays the TE LSP, the input label, the output interface, the output label, the output backup tunnel, and the backup label. The protection status can be ready when a failure has not occurred or active when the node is rerouting the primary TE LSP through the backup.
Example 4-52 Examining the FRR Database on the PLR in Cisco IOS
Router#show mpls traffic-eng fast-reroute database Headend frr information: Protected tunnel In-label Out intf/label FRR intf/label Status LSP midpoint frr information: LSP identifier In-label Out intf/label FRR intf/label Status 172.16.255.1 1 [6] 30 PO1/0/0:33 Tu2:implicit-nul ready 172.16.255.129 1 [9] 33 PO1/0/0:32 Tu1:implicit-nul ready Router# *Nov 10 16:32:52.852: %LINK-3-UPDOWN: Interface POS1/0/0, changed state to down *Nov 10 16:32:52.856: %OSPF-5-ADJCHG: Process 100, Nbr 172.16.255.130 on POS1/0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Nov 10 16:32:53.852: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0/0, changed state to down Router# Router#show mpls traffic-eng fast-reroute database Headend frr information: Protected tunnel In-label Out intf/label FRR intf/label Status LSP midpoint frr information: LSP identifier In-label Out intf/label FRR intf/label Status 172.16.255.1 1 [6] 30 PO1/0/0:33 Tu2:implicit-nul active 172.16.255.129 1 [9] 33 PO1/0/0:32 Tu1:implicit-nul active Router#
Cisco IOS XR supports the same command with equivalent information. Example 4-53 shows the command output in Cisco IOS XR. Both examples show the command output before and while the node reroutes the TE LSPs.
Example 4-53 Examining the FRR Database on the PLR in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng fast-reroute database
LSP midpoint FRR information:
LSP Identifier Local Out Intf/ FRR Intf/ Status
Label Label Label
----------------------------- ------ ---------------- ---------------- -------
172.16.255.1 1 [677] 83 PO0/3/0/1:31 tt2:ExpNull4 Ready
RP/0/4/CPU0:Router#
RP/0/4/CPU0:Router#LC/0/3/CPU0:May 2 01:23:29.614 : ifmgr[154]: %PKT_INFRA-LINK-3-
UPDOWN : Interface POS0/3/0/1, changed state to Down
LC/0/3/CPU0:May 2 01:23:29.615 : ifmgr[154]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface POS0/3/0/1, changed state to Down
RP/0/4/CPU0:May 2 01:23:29.643 : ospf[269]: %ROUTING-OSPF-5-ADJCHG : Process
DEFAULT, Nbr 172.16.255.130 on POS0/3/0/1 from FULL to DOWN, Neighbor Down:
interface down or detached
RP/0/4/CPU0:Router#
RP/0/4/CPU0:Router#show mpls traffic-eng fast-reroute database
LSP midpoint FRR information:
LSP Identifier Local Out Intf/ FRR Intf/ Status
Label Label Label
----------------------------- ------ ---------------- ---------------- -------
172.16.255.1 1 [677] 83 tt2:ExpNull4 Active
RP/0/4/CPU0:Router#
You can use the show mpls traffic-eng tunnels protection command to examine the details of a protected TE LSP on a PLR. You can use the command in Cisco IOS and Cisco IOS XR. Example 4-54 shows a protected TE LSP traversing interface POS1/0/0. The backup selection process has chosen Tunnel2 to protect this TE LSP. See Example 4-41 for the backup tunnel configuration. Example 4-55 shows the equivalent command output in Cisco IOS XR. In that example, the PLR has selected tunnel-te2 to reroute the protected TE LSP. See Example 4-42 for the backup tunnel configuration
Example 4-54 Examining Protected TE LSPs on the PLR in Cisco IOS
Router#show mpls traffic-eng tunnels protection
NNHOP-BACKUP-40M-CT1
LSP Head, Tunnel1, Admin: up, Oper: up
Src 172.16.255.131, Dest 172.16.255.2, Instance 4
Fast Reroute Protection: None
Path Protection: None
NNHOP-BACKUP-90M-CT0
LSP Head, Tunnel2, Admin: up, Oper: up
Src 172.16.255.131, Dest 172.16.255.2, Instance 1
Fast Reroute Protection: None
Path Protection: None
NHOP-BACKUP-90M-ANY-CT
LSP Head, Tunnel3, Admin: up, Oper: up
Src 172.16.255.131, Dest 172.16.255.130, Instance 1
Fast Reroute Protection: None
Path Protection: None
LSP Tunnel FROM-ROUTER-TO-DST1-FRR-NODEP-BWP is signalled, connection is up
InLabel : POS2/0/0, 30
OutLabel : POS1/0/0, 33
FRR OutLabel : Tunnel2, explicit-null
RSVP Signalling Info:
Src 172.16.255.1, Dst 172.16.255.2, Tun_Id 1, Tun_Instance 6
RSVP Path Info:
My Address: 172.16.192.5
Explicit Route: 172.16.192.4 172.16.4.0 172.16.255.2
Record Route: NONE
Tspec: ave rate=20000 kbits, burst=1000 bytes, peak rate=20000 kbits
RSVP Resv Info:
Record Route: 172.16.255.130(33) 172.16.255.2(0)
Fspec: ave rate=20000 kbits, burst=1000 bytes, peak rate=20000 kbits
LSP Tunnel FROM-ROUTER-TO-DST1-FRR is signalled, connection is up
InLabel : POS0/0/0, 33
OutLabel : POS1/0/0, 32
FRR OutLabel : Tunnel1, explicit-null
RSVP Signalling Info:
Src 172.16.255.129, Dst 172.16.255.2, Tun_Id 1, Tun_Instance 9
RSVP Path Info:
My Address: 172.16.192.5
Explicit Route: 172.16.192.4 172.16.4.0 172.16.255.2
Record Route: NONE
Tspec: ave rate=30000 kbits, burst=1000 bytes, peak rate=30000 kbits
RSVP Resv Info:
Record Route: 172.16.255.130(32) 172.16.255.2(0)
Fspec: ave rate=30000 kbits, burst=1000 bytes, peak rate=30000 kbits
Router#
Example 4-55 Examining Protected TE LSPs on the PLR in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng tunnels protection
NHOP-BACKUP-90M-ANY-CT
LSP Midpoint, signaled, connection up
Src: 172.16.255.131, Dest: 172.16.255.130, Instance: 1
Fast Reroute Protection: None
NHOP-BACKUP-55M-CT0
LSP Head, Admin: up, Oper: up
Src: 172.16.255.129, Dest: 172.16.255.130, Instance: 1
Fast Reroute Protection: None
NNHOP-BACKUP-20M-CT0
LSP Head, Admin: up, Oper: up
Src: 172.16.255.129, Dest: 172.16.255.2, Instance: 1
Fast Reroute Protection: None
NHOP-BACKUP-25M-ANY-CT
LSP Head, Admin: up, Oper: up
Src: 172.16.255.129, Dest: 172.16.255.130, Instance: 1
Fast Reroute Protection: None
FROM-ROUTER-TO-DST1-FRR-NODEP-BWP
LSP Midpoint, signaled, connection up
Src: 172.16.255.1, Dest: 172.16.255.2, Instance: 677
Fast Reroute Protection: Requested
Inbound: FRR Inactive
LSP signalling info:
Original: in i/f: POS0_3_0_0, label: 83, phop: 172.16.0.0
Outbound: FRR Ready
Backup tunnel-te2 to LSP nnhop
tunnel-te2: out i/f: POS0/3/0/2
LSP signalling info:
Original: out i/f: POS0/3/0/1, label: 31, nhop: 172.16.192.1
With FRR: out i/f: tunnel-te2, label: 0
LSP bw: 20000 kbps, Backup level: CT0 limited, type: CT0
RP/0/4/CPU0:Router#
The show mpls traffic-eng tunnels backup command enables you to obtain details about the backup tunnels on the PLR. The output shows you how many TE LSPs the backup tunnel is protecting. It also shows you the current allocation of backup bandwidth. Example 4-56 illustrates the command output in Cisco IOS. In this case, Tunnel2 is protecting one TE LSP and has allocated 10,000 kbps of the total 90,000 kbps of backup bandwidth. Example 4-57 shows the equivalent command output in Cisco IOS XR. In that example, te-tunnel2 is protecting one TE LSP and has allocated all its backup bandwidth (20,000 kbps).
Example 4-56 Examining Backup Tunnels on the PLR in Cisco IOS
Router#show mpls traffic-eng tunnels backup NNHOP-BACKUP-40M-CT1 LSP Head, Tunnel1, Admin: up, Oper: up Src 172.16.255.131, Dest 172.16.255.2, Instance 4 Fast Reroute Backup Provided: Protected i/fs: PO1/0/0 Protected lsps: 1 Backup BW: sub-pool; limit: 40000 kbps, inuse: 30000 kbps (BWP inuse: 0 kbps) NNHOP-BACKUP-90M-CT0 LSP Head, Tunnel2, Admin: up, Oper: up Src 172.16.255.131, Dest 172.16.255.2, Instance 1 Fast Reroute Backup Provided: Protected i/fs: PO1/0/0 Protected lsps: 1 Backup BW: global pool; limit 90000 kbps, inuse: 20000 kbps (BWP inuse: 20000 kbps) NHOP-BACKUP-90M-ANY-CT LSP Head, Tunnel3, Admin: up, Oper: up Src 172.16.255.131, Dest 172.16.255.130, Instance 1 Fast Reroute Backup Provided: Protected i/fs: PO1/0/0 Protected lsps: 0 Backup BW: any pool; limit: 90000 kbps, inuse: 0 kbps (BWP inuse: 0 kbps) Router#
Example 4-57 Examining Backup Tunnels on the PLR in Cisco IOS XR
RP/0/4/CPU0:Router#show mpls traffic-eng tunnels backup tunnel-te1 Admin: up, Oper: up Src: 172.16.255.129, Dest: 172.16.255.130, Instance: 1 Fast Reroute Backup Provided: Protected LSPs: 0 Backup BW: CT0; limit: 55000 kbps, Inuse: 0 kbps Protected i/fs: POS0/3/0/1 tunnel-te2 Admin: up, Oper: up Src: 172.16.255.129, Dest: 172.16.255.2, Instance: 1 Fast Reroute Backup Provided: Protected LSPs: 1 Backup BW: CT0; limit: 20000 kbps, Inuse: 20000 kbps Protected i/fs: POS0/3/0/1 tunnel-te3 Admin: up, Oper: up Src: 172.16.255.129, Dest: 172.16.255.130, Instance: 1 Fast Reroute Backup Provided: Protected LSPs: 0 Backup BW: any-class; limit: 25000 kbps, Inuse: 0 kbps Protected i/fs: POS0/3/0/1 RP/0/4/CPU0:Router#
Summary
Cisco IOS and Cisco IOS XR provide a comprehensive implementation of MPLS TE. They use tunnel interfaces as an abstraction of TE LSPs. You can perform constraint-based routing using IS-IS or OSPF. RSVP performs the signaling of TE LSPs. You can configure different aspects of the protocol (for instance, graceful restart, reliable messages, authentication) that can influence the scalability and reliability of an MPLS TE implementation. You can use multiple traffic-selection mechanisms to inject traffic into a TE LSP. CBTS enables you to use the MPLS EXP value for this purpose.
DS-TE and FRR extend the basic functionality in Cisco MPLS TE. You can implement DS-TE using the RDM or MAM models. Cisco FRR TE supports link, node, SRLG, bandwidth, and path protection.
References
Osborne, E., and A. Simha. Traffic Engineering with MPLS. Cisco Press; 2003.
Cisco Software Center https://www.cisco.com/go/software
Cisco Software Advisor https://tools.cisco.com/Support/Fusion/FusionHome.do
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4 https://www.cisco.com/en/US/products/ps6350/products_configuration_guide_book09186a0080435d50.html
Cisco IOS Software Releases 12.2 S Feature Guides https://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guides_list.htmlCisco IOS XR Software Configuration Guides https://www.cisco.com/en/US/partner/products/ps5845/products_installation_and_configuration_guides_list.html
Copyright © 2007 Pearson Education. All rights reserved.
