Chapter 4: Cisco MPLS Traffic Engineering

Cisco Press

1 2 3 4 5 6 7 8 Page 5
Page 5 of 8
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.

Figure 4.2

Figure 4-2

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
!
Related:
1 2 3 4 5 6 7 8 Page 5
Page 5 of 8
SD-WAN buyers guide: Key questions to ask vendors (and yourself)