Table Of Contents
MPLS Traffic Engineering (TE): Class-based Tunnel Selection
Prerequisites for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
Restrictions for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
Information About MPLS Traffic Engineering (TE): Class-based Tunnel Selection
Incoming Traffic Supported by MPLS TE Class-based Tunnel Selection
CoS Attributes for MPLS TE Class-based Tunnel Selection
Routing Protocols and MPLS TE Class-based Tunnel Selection
Tunnel Selection with MPLS TE Class-based Tunnel Selection
Tunnel Selection for EXP Values
Fast Reroute and MPLS TE Class-based Tunnel Selection
DS-TE Tunnels and MPLS TE Class-based Tunnel Selection
Reoptimization and MPLS TE Class-based Tunnel Selection
Interarea and Inter-AS and MPLS TE Class-based Tunnel Selection
ATM PVCs and MPLS TE Class-based Tunnel Selection
How to Configure MPLS Traffic Engineering (TE): Class-based Tunnel Selection
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel
Making the MPLS TE or DS-TE Tunnels Visible for Routing
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP
Configuration Examples for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend: Example
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel: Example
Making the MPLS TE or DS-TE Tunnels Visible for Routing: Example
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP: Example
Configuring a Master Tunnel: Example
tunnel mpls traffic-eng exp-bundle master
tunnel mpls traffic-eng exp-bundle member
Feature Information for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
MPLS Traffic Engineering (TE): Class-based Tunnel Selection
First Published: November 1, 2003Last Updated: August 8, 2007The MPLS Traffic Engineering (TE): Class-based Tunnel Selection feature enables you to dynamically route and forward traffic with different class of service (CoS) values onto different TE tunnels between the same tunnel headend and the same tailend. The TE tunnels can be regular TE or DiffServ-aware TE (DS-TE) tunnels.
The set of TE (or DS-TE) tunnels from the same headend to the same tailend that you configure to carry different CoS values is referred to as a "tunnel bundle." After configuration, CBTS dynamically routes and forwards each packet into the tunnel that:
•
Is configured to carry the CoS of the packet
•
Has the right headend for the destination of the packet
Because Class-Based Tunnel Selection (CBTS) offers dynamic routing over DS-TE tunnels and requires minimum configuration, it greatly eases deployment of DS-TE in large-scale networks.
CBTS can distribute all CoS values on eight different tunnels.
CBTS also allows the TE tunnels of a tunnel bundle to exit headend routers through different interfaces.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for MPLS Traffic Engineering (TE): Class-based Tunnel Selection" section.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
•
Restrictions for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
•
Information About MPLS Traffic Engineering (TE): Class-based Tunnel Selection
•
How to Configure MPLS Traffic Engineering (TE): Class-based Tunnel Selection
•
Configuration Examples for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
•
Feature Information for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
Prerequisites for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
•
Multiprotocol Label Switching (MPLS) must be enabled on all tunnel interfaces.
•
Cisco Express Forwarding or distributed Cisco Express Forwarding must be enabled in global configuration mode.
Restrictions for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
•
For a given destination, all CoS values are carried in tunnels terminating at the same tailend. Either all CoS values are carried in tunnels or no values are carried in tunnels. In other words, for a given destination, you cannot map some CoS values in a DS-TE tunnel and other CoS values in a Shortest Path First (SPF) Label Distribution Protocol (LDP) or SPF IP path.
•
CBTS does not allow load-balancing of a given experimental (EXP) value in multiple tunnels. If two or more tunnels are configured to carry a given EXP value, CBTS picks one of those tunnels to carry this EXP value.
•
The operation of CBTS is not supported with Any Transport over MPLS (AToM), MPLS TE Automesh, or label-controlled (LC)-ATM.
Information About MPLS Traffic Engineering (TE): Class-based Tunnel Selection
To configure the MPLS Traffic Engineering (TE): Class-based Tunnel Selection feature, you should understand the following concepts:
•
Incoming Traffic Supported by MPLS TE Class-based Tunnel Selection
•
CoS Attributes for MPLS TE Class-based Tunnel Selection
•
Routing Protocols and MPLS TE Class-based Tunnel Selection
•
Tunnel Selection with MPLS TE Class-based Tunnel Selection
•
DS-TE Tunnels and MPLS TE Class-based Tunnel Selection
•
Reoptimization and MPLS TE Class-based Tunnel Selection
•
Interarea and Inter-AS and MPLS TE Class-based Tunnel Selection
•
ATM PVCs and MPLS TE Class-based Tunnel Selection
Incoming Traffic Supported by MPLS TE Class-based Tunnel Selection
The CBTS feature supports the following kinds of incoming packets:
•
At a provider edge (PE) router—Unlabeled packets that enter a Virtual Private Network (VPN) routing and forwarding (VRF) instance interface
•
At a provider core (P) router—Unlabeled and MPLS-labeled packets that enter a non-VRF interface
•
At a PE router in a Carrier Supporting Carrier (CSC) or interautonomous system (Inter-AS)—MPLS-labeled packets that enter a VRF interface
CoS Attributes for MPLS TE Class-based Tunnel Selection
CBTS supports tunnel selection based on the value of the EXP field that the headend router imposes on the packet. Before imposing this value, the router considers the input modular quality of service (QoS) command-line interface (CLI) (MQC). If the input MQC modifies the EXP field value, CBTS uses the modified value for its tunnel selection.
Packets may enter the headend from multiple incoming interfaces. These interfaces can come from different customers that have different DiffServ policies. In such cases, service providers generally use input MQC to apply their own DiffServ policies and mark imposed EXP values accordingly. Thus, CBTS can operate consistently for all customers by considering the EXP values marked by the service provider.
Note
If the output MQC modifies the EXP field, CBTS ignores the change in the EXP value.
CBTS allows up to eight different tunnels on which it can distribute all classes of service.
Routing Protocols and MPLS TE Class-based Tunnel Selection
CBTS routes and forwards packets to MPLS TE tunnels for specified destinations through use of the following routing protocols:
•
Intermediate System-to-Intermediate System (IS-IS) with Autoroute configured
•
Open Shortest Path First (OSPF) with Autoroute configured
•
Static routing
•
Border Gateway Protocol (BGP) with recursion configured on the BGP next hop with packets forwarded on the tunnel through the use of IS-IS, OSPF, or static routing
Tunnel Selection with MPLS TE Class-based Tunnel Selection
This section contains the following topics related to tunnel selection:
•
Tunnel Selection for EXP Values
EXP Mapping Configuration
With CBTS, you can configure each tunnel with any of the following:
•
The same EXP information configured as it was before the CBTS feature was introduced, that is, with no EXP-related information
•
One or more EXP values for the tunnel to carry
•
A property that allows the carrying of all EXP values not currently allocated to any up-tunnel (default)
•
One or more EXP values for the tunnel to carry, and the default property that allows the carrying of all EXP values not currently allocated to any up-tunnel
The default property (the carrying of all EXP values not currently allocated to any up-tunnel) effectively provides a way for the operator to avoid explicitly listing all possible EXP values. Even more important, the default property allows the operator to indicate tunnel preferences onto which to "bump" certain EXP values, should the tunnel carrying those EXP values go down. (See the tunnel mpls traffic-eng exp command for the command syntax.)
The configuration of each tunnel is independent of the configuration of any other tunnel. CBTS does not attempt to perform any consistency check for EXP configuration.
This feature allows configurations where:
•
Not all EXP values are explicitly allocated to tunnels.
•
Multiple tunnels have the default property.
•
Some tunnels have EXP values configured and others do not have any values configured.
•
A given EXP value is configured on multiple tunnels.
Tunnel Selection for EXP Values
This section contains information about the following topics:
•
Multipath with Non-TE Paths and MPLS TE Class-Based Tunnel Selection
•
MPLS TE Class-Based Tunnel Selection and Policy-Based Routing
Tunnel Selection Process
Tunnel selection with this feature is a two-step process:
1.
For a given prefix, routing (autoroute, static routes) occurs exactly as it did without the CBTS feature. The router selects the set of operating tunnels that have the best metrics, regardless of the EXP-related information configured on the tunnel.
2.
CBTS maps all of the EXP values to the selected set of tunnels:
•
If a given EXP value is configured:
–
On only one of the tunnels in the selected set, CBTS maps the EXP value onto that tunnel.
–
On two or more of the tunnels in the selected set, CBTS arbitrarily maps the EXP value onto one of these tunnels. First CBTS selects the tunnel on which the lowest EXP value is explicitly configured. Then CBTS picks the tunnel that has the lowest tunnel ID.
•
If a given EXP value is not configured on any of the tunnels in the selected set:
–
And only one of the tunnels in the selected set is configured as a default, CBTS maps the EXP value onto that tunnel.
–
And two or more of the tunnels in the selected set are configured as defaults, CBTS arbitrarily maps the EXP value onto one of these tunnels.
–
And no tunnel in the selected set of tunnels is configured as a default, CBTS does not map this EXP value onto any specific tunnel. Instead, CBTS performs CoS-unaware load balancing of that EXP information across all tunnels in the selected set.
CBTS relies on autoroute to select the tunnel bundle. Autoroute selects only tunnels that are on the SPF to the destination. Therefore, similar to Autoroute, CBTS does not introduce any risk of routing loops.
Tunnel Selection Examples
The following examples show various tunnel configurations that are set up by an operator and indicate how CBTS maps packets carrying EXP values onto these tunnels. Each example describes a different configuration: a default tunnel configured, more than one tunnel configured with the same EXP value, and so on.
Example 1—Default Tunnel Configured
An operator configures the following parameters on tunnels T1 and T2:
•
T1: exp = 5, autoroute
•
T2: exp = default, autoroute
If T1 and T2 are next-hop interfaces for prefix P, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 5> onto T1
•
Packets with <Dest = P, exp = anything-other-than-5> onto T2
Example 2— EXP Values Configured on Two Tunnels; One Default Tunnel
An operator configures the following parameters on tunnels T1, T2, and T3:
•
T1: exp = 5, autoroute
•
T2: exp = 3 and 4, autoroute
•
T3: exp = default, autoroute
If T1, T2, and T3 are next-hop interfaces for prefix P, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 5> onto T1
•
Packets with <Dest = P, exp = 3 or 4> onto T2
•
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T3
Example 3—More than One Tunnel with the Same EXP
An operator configures the following parameters on tunnels T1, T2, and T3:
•
T1: exp = 5, autoroute
•
T2: exp = 5, autoroute
•
T3: exp = default, autoroute
If T1, T2, and T3 are next-hop interfaces for prefix P, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 5> onto T1 (arbitrary selection)
•
Packets with <Dest = P, exp = anything-other-than-5> onto T3
•
No packets onto T2
Example 4—Static Route Configured
An operator configures the following parameters on tunnels T1 and T2:
•
T1: exp = 5, autoroute
•
T2: exp = 3
•
Static route to P on T2
If prefix P is behind the T1 and T2 tailend router, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = anything> onto T2
•
No packets onto T1
Static routes are preferred over dynamic routes; therefore, the router chooses only T2 as the "selected set" of tunnels.
Example 5—Metrics Configured on Tunnels
An operator configures the following parameters on tunnels T1 and T2:
•
T1: exp = 5, autoroute, relative metric -2
•
T2: exp = 3, autoroute, relative metric -3
CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = anything> onto T2
•
No packets onto T1
The autoroute tunnel selection algorithm selects the tunnel with the best metric. Therefore, the router selects only T2 as the "selected set" of tunnels.
Example 6—No Default or Metric Configuration
An operator configures the following parameters on tunnels T1 and T2:
•
T1: exp = 5, autoroute
•
T2: exp = 3, autoroute
If T1 and T2 are the next-hop interfaces for prefix P, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 5> onto T1
•
Packets with <Dest = P, exp = 3> onto T2
•
Packets with <Dest = P, exp = anything-other-than-3-or-5> onto T2
If a packet arrives with an EXP value that is different from any value configured for a tunnel, the packet goes in to the default tunnel. If no default tunnel is configured, the packet goes in to the tunnel that is configured with the lowest EXP value.
Multipath with Non-TE Paths and MPLS TE Class-Based Tunnel Selection
For a given prefix in the routing process, the router might select a set of paths that includes both TE tunnels and non-TE-tunnel paths (SPF paths). For example, internal Border Gateway Protocol (iBGP) Multipath might be activated and result in multiple BGP next hops for that prefix, where one BGP next hop is reachable through TE tunnels and other BGP next hops are reachable through non-TE-tunnel paths.
An equal cost IGP path might also exist over TE tunnels and over a non-TE tunnel path. For example, a TE tunnel metric might be modified to be equal to the SPF path.
In these situations, CBTS maps traffic in the following manner:
•
If a given EXP value is configured on one or more of the tunnels in the selected set, CBTS maps the EXP value onto that tunnel or one of those tunnels.
•
If a given EXP value is not configured on any of the tunnels in the selected set but one or more of the tunnels is configured as a default in the selected set, then CBTS maps the EXP value onto that tunnel or one of those tunnels.
•
If a given EXP value is not configured on any of the tunnels from the selected set and no tunnel in the selected set is configured as a default, CBTS performs CoS-unaware load-balancing of that EXP value across all the possible paths, including all of the TE tunnels of the selected set and the non-TE paths.
•
If the routing process allocates all EXP values to tunnels or if a default is used, then routing does not use the non-TE paths unless all TE tunnels are down.
MPLS TE Class-Based Tunnel Selection and Policy-Based Routing
If you configure both policy-based routing (PBR) over TE tunnels (in non-VRF environments) and CBTS, the PBR decision overrides the CBTS decision. PBR is an input process that the router performs ahead of regular forwarding.
Tunnel Failure Handling
This section contains the following sections:
•
Behavior When a Tunnel Goes Down
Tunnel Up or Down
For CBTS operation, the important question is whether the tunnel interface is up or down, not whether the current TE label switched path (LSP) is up or down. For example, a TE LSP might go down but is reestablished by the headend because another path option exists. The tunnel interface does not go down during the transient period while the TE LSP is reestablished. Because the tunnel interface does not go down, the corresponding EXP does not get rerouted onto another tunnel during the transient period.
Behavior When a Tunnel Goes Down
When a tunnel used by CBTS for forwarding goes down, the feature adjusts its tunnel selection for the affected EXP values. It reapplies the tunnel selection algorithm to define the behavior of packets for all EXP values, as shown in the examples that follow.
Example 1—Tunnel Other than the Default Tunnel Goes Down
An operator configures the following parameters on tunnels T1, T2, and T3:
•
T1: exp = 5, autoroute
•
T2: exp = 3 and 4, autoroute
•
T3: exp = default, autoroute
If T1, T2, and T3 are next-hop interfaces for prefix P and Tunnel T1 goes down, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 3, 4> onto T2 (as before)
•
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T3 (as before)
•
Packets with <Dest = P, exp = 5> onto T3
Example 2—Default Tunnel Goes Down
An operator configures the following parameters on tunnels T1, T2, and T3:
•
T1: exp = 5, autoroute
•
T2: exp = 3 and 4, autoroute
•
T3: exp = default, autoroute
If T1, T2, and T3 are next-hop interfaces for prefix P and Tunnel T3 goes down, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 5> onto T1 (as before)
•
Packets with <Dest = P, exp = 3, 4> onto T2 (as before)
•
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T1 and T2, following existing CoS-unaware load balancing
Example 3—Two Default Tunnels Are Configured
An operator configures the following parameters on tunnels T1, T2, and T3:
•
T1: exp = 5, autoroute
•
T2: exp = 3, 4, and default, autoroute
•
T3: exp = 0, 1, 2, 6, 7, and default, autoroute
If T1, T2, and T3 are next-hop interfaces for prefix P and Tunnel T3 goes down, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 5> onto T1 (as before)
•
Packets with <Dest = P, exp = 3, 4> onto T2 (as before)
•
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T2
If tunnel T2 goes down, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 5> onto T1 (as before)
•
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T3 (as before)
•
Packets with <Dest = P, exp = 3, or 4> onto T3
If tunnel T1 goes down, CBTS maps the packets onto the tunnels in this way:
•
Packets with <Dest = P, exp = 3, or 4> onto T2 (as before)
•
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T3 (as before)
•
Packets with <Dest = P, exp = 5> onto either T2 or T3, but not both
In Example 3, the operator configures the EXP default option on two tunnels to ensure that nonvoice traffic is never redirected onto the voice tunnel (T1).
Misordering of Packets
In DiffServ, packets from a given flow might get marked with EXP values that are different from each other but belong to the same CoS value because of in-contract and out-of-contract marking of packets. We can refer to these values of EXP bits as EXP-in and EXP-out.
If packets for EXP-in are sent on a different tunnel than packets for EXP-out, then misordering of packets within the same flows could occur. For that reason, CBTS allows operators to ensure that EXP-in and EXP-out never get mapped onto different tunnels.
The CBTS feature allows the operator to configure EXP-in and EXP-out to be transported on the same tunnel when that tunnel is up. This ensures that the feature does not introduce misordering of packets. In case of tunnel failure, the tunnel selection algorithm ensures that if EXP-in and EXP-out were carried on the same tunnel before the failure, they are still carried on a single tunnel after the failure. Thus, CBTS protects against nontransient misordering even in the event of tunnel failure.
Note
CBTS does not attempt to force EXP-in and EXP-out to be carried on the same tunnel. The operator must configure CBTS so that EXP-in and EXP-out are carried on the same tunnel. This is comparable to the regular DiffServ situation, where the operator must ensure that EXP-in and EXP-out are configured to go in the same queue.
Fast Reroute and MPLS TE Class-based Tunnel Selection
CBTS allows Fast Reroute (FRR) protection on tunnels for which you configure CoS-based selection.
CBTS operation with FRR does not change the number of or the way in which FRR backup tunnels might be used. The operation of FFR is the same as when CBTS is not activated. After you configure primary tunnels from a given headend to a given tailend, you can use FRR in the same way whether you activate CoS-based tunnel selection or not. This includes the following possibilities:
•
None of the tunnels use FRR.
•
All of the x tunnels are FRR-protected and share the same backup tunnel, if the traffic goes out the same interface.
•
Some of the x tunnels are not FRR-protected; the remaining tunnels are FRR-protected and share the same backup tunnel, if the traffic goes out the same interface.
•
Some of the x tunnels are not FRR-protected; the remaining tunnels are FRR-protected and are protected by different backup tunnels (for example, if the traffic goes out different interfaces, or if the traffic goes out the same interface). Bandwidth guarantees exist on the backup tunnels.
The important question for CBTS operation is only whether a tunnel interface goes down or stays up. FRR protects a given tunnel in exactly the same way as if CBTS were not configured on the tunnel.
DS-TE Tunnels and MPLS TE Class-based Tunnel Selection
CBTS operates over tunnels using DS-TE. Therefore, the tunnels on which CoS-based selection is performed can each arbitrarily and independently use a bandwidth from the global pool or the subpool.
Reoptimization and MPLS TE Class-based Tunnel Selection
CBTS allows tunnels on which CoS-based selection is performed to be reoptimized. Reoptimization does not affect CBTS operation.
Interarea and Inter-AS and MPLS TE Class-based Tunnel Selection
The CBTS operates over tunnels that are interarea when the interarea tunnels use static routes on destination prefixes or on the BGP next hops.
ATM PVCs and MPLS TE Class-based Tunnel Selection
CBTS operates over ATM permanent virtual circuits (PVCs). This means that TE or DS-TE tunnels handled by CBTS can span links that are ATM PVCs. ATM PVCs might be used on the headend router that is running CBTS and on transit label switch routers (LSRs).
How to Configure MPLS Traffic Engineering (TE): Class-based Tunnel Selection
This section contains the following procedures:
•
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend
•
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel
•
Making the MPLS TE or DS-TE Tunnels Visible for Routing
•
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP
You need to configure the CBTS feature only on the tunnel headend. No CBTS configuration is required on the tailend or transit LSR.
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend
Figure 1 shows an example of two tunnels, Tunnel 65 and Tunnel 66, transporting different classes of traffic between the same headend and the same tailend.
Figure 1 Tunnels Transporting Different Classes of Service Between the Same Headend and Tailend
To create multiple MPLS TE or DS-TE tunnels with the same headend and same tailend, perform the following steps.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface tunnel number
4.
ip unnumbered type number
5.
tunnel destination {hostname | ip-address}
6.
tunnel mode mpls traffic-eng
7.
tunnel mpls traffic-eng bandwidth [sub-pool | global] bandwidth
8.
exit
9.
Repeat steps 3 through 8 on the same headend router to create additional tunnels from this headend to the same tailend.
10.
end
DETAILED STEPS
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel
To configure EXP values to be carried by each MPLS TE or DS-TE tunnel, perform the following steps.
For each tunnel that you create, you must indicate which EXP values the tunnel carries.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type number
4.
tunnel mpls traffic-eng exp [list-of-exp-values] [default]
5.
exit
6.
Repeat steps 3 through 5 for all MPLS TE tunnels that you created in the "Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend" section.
7.
end
DETAILED STEPS
Command or Action PurposeStep 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
interface type number
Example:Router(config)# interface tunnel65
Configures an interface type and enters interface configuration mode.
Step 4
tunnel mpls traffic-eng exp [list-of-exp-values] [default]
Example:Router(config-if)# tunnel mpls traffic-eng exp 5
Specifies the EXP bits that will be forwarded over a member tunnel that is part of the CBTS bundle.
Step 5
exit
Example:Router(config-if)# exit
Returns to global configuration mode.
Step 6
Repeat steps 3 through 5 for all MPLS TE tunnels that you created in the "Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend" section.
—
Step 7
end
Example:Router(config-if)# end
Returns to privileged EXEC mode.
Making the MPLS TE or DS-TE Tunnels Visible for Routing
Perform the following task to make the MPLS TE or DS-TE tunnels visible for routing.
Note
Alternatively, static routing could be used instead of autoroute to make the TE or DS-TE tunnels visible for routing.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type number
4.
tunnel mpls traffic-eng autoroute announce
5.
tunnel mpls traffic-eng autoroute metric {absolute | relative} value
6.
end
DETAILED STEPS
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP
To verify that the MPLS TE or DS-TE tunnels are operating and announced to the IGP, perform the following steps.
SUMMARY STEPS
1.
show mpls traffic-eng topology {A.B.C.D | igp-id {isis nsap-address | ospf A.B.C.D} [brief]
2.
show mpls traffic-eng tunnels number [brief] protect
3.
show ip cef [vrf vrf-name] [unresolved [detail] | [detail | summary]]
4.
show mpls forwarding-table [network {mask | length} | labels label [- label] | interface interface | next-hop address | lsp-tunnel [tunnel-id]] [vrf vrf-name] [detail]
5.
show mpls traffic-eng autoroute
DETAILED STEPS
Step 1
show mpls traffic-eng topology {A.B.C.D | igp-id {isis nsap-address | ospf A.B.C.D} [brief]
Use this command to display the MPLS TE global topology currently known at this node:
Router# show mpls traffic-eng topologyMy_System_id: 0000.0025.0003.00IGP Id: 0000.0024.0004.00, MPLS TE Id:172.16.4.4 Router Nodelink[0 ]:Intf Address: 10.1.1.4Nbr IGP Id: 0000.0024.0004.02,admin_weight:10, affinity_bits:0x0max_link_bw:10000 max_link_reservable: 10000globalpool subpooltotal allocated reservable reservable--------------- ---------- ----------bw[0]: 0 1000 500bw[1]: 10 990 490bw[2]: 600 390 390bw[3]: 0 390 390bw[4]: 0 390 390bw[5]: 0 390 390Step 2
show mpls traffic-eng tunnels number [brief] [protection]
Use this command to display information for a specified tunneling interface:
Router# show mpls traffic-eng tunnels 500 brief protectionRouter#_t500LSP Head, Tunnel500, Admin: up, Oper: upSrc 172.16.0.5, Dest 172.16.0.8, Instance 17Fast Reroute Protection: NonePath Protection: 1 Common Link(s) , 1 Common Node(s)Primary lsp path:192.168.6.6 192.168.7.7192.168.8.8 192.168.0.8Protect lsp path:172.16.7.7 192.168.8.810.0.0.8Path Protect Parameters:Bandwidth: 50 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFFMetric Type: TE (default)InLabel : -OutLabel : Serial5/3, 46RSVP Signalling Info:Src 172.16.0.5, Dst 172.16.0.8, Tun_Id 500, Tun_Instance 18RSVP Path Info:My Address: 172.16.0.5Explicit Route: 192.168.7.7 192.168.8.8Record Route: NONETspec: ave rate=50 kbits, burst=1000 bytes, peak rate=50 kbitsRSVP Resv Info:Record Route: NONEFspec: ave rate=50 kbits, burst=1000 bytes, peak rate=50 kbitsStep 3
show ip cef summary
Use this command to display a summary of the IP CEF table:
Router# show ip cef summaryIP Distributed CEF with switching (Table Version 25), flags=0x021 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 121 leaves, 16 nodes, 19496 bytes, 36 inserts, 15 invalidations0 load sharing elements, 0 bytes, 0 referencesuniversal per-destination load sharing algorithm, id 5163EC153(0) CEF resets, 0 revisions of existing leavesResolution Timer: Exponential (currently 1s, peak 1s)0 in-place/0 aborted modificationsrefcounts: 4377 leaf, 4352 nodeTable epoch: 0 (21 entries at this epoch)Adjacency Table has 9 adjacenciesStep 4
show mpls forwarding-table [network {mask | length} | labels label [- label] | interface interface | next-hop address | lsp-tunnel [tunnel-id]] [vrf vrf-name] [detail]
Use this command to display the contents of the MPLS Label Forwarding Information Base (LFIB):
Router# show mpls forwarding-tableLocal Outgoing Prefix Bytes tag Outgoing Next HopLabel Label or VC or Tunnel Id switched interface26 No Label 10.253.0.0/16 0 Et4/0/0 10.27.32.428 1/33 10.15.0.0/16 0 AT0/0.1 point2point29 Pop Label 10.91.0.0/16 0 Hs5/0 point2point1/36 10.91.0.0/16 0 AT0/0.1 point2point30 32 10.250.0.97/32 0 Et4/0/2 10.92.0.732 10.250.0.97/32 0 Hs5/0 point2point34 26 10.77.0.0/24 0 Et4/0/2 10.92.0.726 10.77.0.0/24 0 Hs5/0 point2point35 No Label[T] 10.100.100.101/32 0 Tu301 point2point36 Pop Label 10.1.0.0/16 0 Hs5/0 point2point1/37 10.1.0.0/16 0 AT0/0.1 point2point[T] Forwarding through a TSP tunnel.View additional tagging info with the 'detail' optionStep 5
show mpls traffic-eng autoroute
Use this command to display tunnels that are announced to the IGP, including interface, destination, and bandwidth:
Router# show mpls traffic-eng autorouteMPLS TE autorouting enableddestination 0002.0002.0002.00 has 2 tunnelsTunnel1021 (traffic share 10000, nexthop 10.2.2.2, absolute metric 11)Tunnel1022 (traffic share 3333, nexthop 10.2.2.2, relative metric -3)destination 0003.0003.0003.00 has 2 tunnelsTunnel1032 (traffic share 10000, nexthop 172.16.3.3)Tunnel1031 (traffic share 10000, nexthop 172.16.3.3, relative metric -1)
Configuring a Master Tunnel
To configure a master tunnel to which other tunnels can be members, perform the following steps.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface tunnel number
4.
ip unnumbered type number
5.
tunnel destination {hostname | ip-address}
6.
tunnel mode mpls traffic-eng
7.
tunnel mpls traffic-eng exp-bundle master
8.
tunnel mpls traffic-eng exp-bundle member tunnel-number
9.
exit
DETAILED STEPS
Configuration Examples for MPLS Traffic Engineering (TE): Class-based Tunnel Selection
This section contains the following configuration examples:
•
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend: Example
•
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel: Example
•
Making the MPLS TE or DS-TE Tunnels Visible for Routing: Example
•
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP: Example
•
Configuring a Master Tunnel: Example
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend: Example
The following example shows how to create multiple MPLS TE or DS-TE tunnels from the same headend to the same tailend:
Router(config)# interface Tunnel 65Router(config-if)# ip numbered loopback0Router(config-if)# tunnel destination 10.1.1.1Router(config-if)# tunnel mode mpls traffic-engRouter(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000Router(config-if)# ^ZRouter(config)# interface Tunnel 66Router(config-if)# ip numbered loopback0Router(config-if)# tunnel destination 10.1.1.1Router(config-if)# tunnel mode mpls traffic-engRouter(config-if)# tunnel mpls traffic-eng bandwidth 50000Router(config-if)# endRouter#Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel: Example
The following example shows how to configure EXP values to be carried by each MPLS TE or DS-TE tunnel that you created:
Router(config)# interface Tunnel 65Router(config-if)# tunnel mpls traffic-eng exp 5Router(config-if)# ^ZRouter(config)#Router(config)# interface Tunnel 66Router(config-if)# tunnel mpls traffic-eng exp 0 1 2 3 4 6 7Router(config-if)# endRouter#Making the MPLS TE or DS-TE Tunnels Visible for Routing: Example
The following example shows how to make the MPLS TE or DS-TE tunnels visible for routing:
Router(config)# interface Tunnel 65Router(config-if)# tunnel mpls traffic-eng autoroute announceRouter(config-if)# tunnel mpls traffic-eng autoroute metric relative -2Router(config-if)# ^ZRouter(config)#Router(config)# interface Tunnel 66Router(config-if)# tunnel mpls traffic-eng autoroute announceRouter(config-if)# tunnel mpls traffic-eng autoroute metric relative -2Router(config-if)# endRouter#Packets destined beyond 10.1.1.1 are sent on:
•
Tunnel 65 if their EXP value after input MQC is 5.
•
Tunnel 66 if their EXP value after input MQC is 0, 1, 2, 3, 4, 6, or 7.
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP: Example
The output for each of the following examples helps verify that the MPLS TE or DS-TE tunnels are operating and visible.
The show mpls traffic-eng topology command output displays the MPLS TE global topology:
Router# show mpls traffic-eng topology 10.0.0.1IGP Id: 10.0.0.1, MPLS TE Id:10.0.0.1 Router Node (ospf 10 area 0) id 1link[0]: Broadcast, DR: 10.0.1.2, nbr_node_id:6, gen:18frag_id 0, Intf Address:10.1.1.1TE metric:1, IGP metric:1, attribute_flags:0x0SRLGs: Nonephysical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps)max_reservable_bw_sub: 0 (kbps)Global Pool Sub PoolTotal Allocated Reservable ReservableBW (kbps) BW (kbps) BW (kbps)--------------- ----------- ----------bw[0]: 0 1000 0bw[1]: 0 1000 0bw[2]: 0 1000 0bw[3]: 0 1000 0bw[4]: 0 1000 0bw[5]: 0 1000 0bw[6]: 0 1000 0bw[7]: 100 900 0link[1]: Broadcast, DR: 10.0.2.2, nbr_node_id:7, gen:19frag_id 1, Intf Address:10.0.2.1TE metric:1, IGP metric:1, attribute_flags:0x0SRLGs: Nonephysical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps)max_reservable_bw_sub: 0 (kbps)Global Pool Sub PoolTotal Allocated Reservable ReservableBW (kbps) BW (kbps) BW (kbps)--------------- ----------- ----------bw[0]: 0 1000 0bw[1]: 0 1000 0bw[2]: 0 1000 0bw[3]: 0 1000 0bw[4]: 0 1000 0bw[5]: 0 1000 0bw[6]: 0 1000 0bw[7]: 300 700 0Router#Router# show mpls traffic-eng topology 10.0.0.9IGP Id: 10.0.0.9, MPLS TE Id:10.0.0.9 Router Node (ospf 1


