Cisco 10000 Series Router Quality of Service Configuration Guide
Configuring Quality of Service for MPLS Traffic
Downloads: This chapterpdf (PDF - 609.0KB) The complete bookPDF (PDF - 21.32MB) | Feedback

Configuring Quality of Service for MPLS Traffic

Table Of Contents

Configuring Quality of Service for MPLS Traffic

MPLS QoS

Feature History for MPLS QoS

MPLS QoS Services

MPLS Tunneling Modes

How QoS Works for MPLS Traffic

MPLS QoS and Packet Priority During Congestion

Interfaces Supporting MPLS QoS

MPLS QoS Implementation

Restrictions and Limitations for MPLS QoS

Configuring MPLS QoS on the Ingress Label Switching Router

Classifying IP Packets Using a Class Map

Setting the MPLS EXP Field Using a Policy Map

Attaching an MPLS QoS Service Policy to an Interface

Configuration Examples for MPLS QoS

Configuration Example for Short Pipe Mode

Configuration Example for Pipe Mode

MPLS CoS Multi-VC Mode

Feature History for MPLS CoS Multi-VC Mode

Label Switched Paths

Class of Service Map

QoS for Label-Controlled ATM VCs

Default Bandwidth for LVCs

Allocating LVC Bandwidth Using Policy Maps

MPLS QoS Support in an MPLS Network

Benefits of MPLS CoS Multi-VC Mode

Restrictions for MPLS CoS Multi-VC Mode

Prerequisites for MPLS CoS Multi-VC Mode

Configuring MPLS CoS Multi-VC Mode

Configuring Multi-VC Mode in the Core of an ATM Network

Configuring Queueing Functions on Router Output Interfaces

Monitoring and Maintaining MPLS CoS Multi-VC Mode Configuration

Configuration Examples for MPLS CoS Multi-VC Mode

MPLS Traffic Engineering—DiffServ Aware

Feature History for MPLS TE—DS

Sub-pool Tunnels

Global Pool Tunnels

Prerequisites for DS-TE

Restrictions and Limitations for DS-TE

Configuring DS-TE

Activating Traffic Engineering on the Router

Activating Traffic Engineering on the Interface

Configuring the Tunnel Interface

Configuring Guaranteed Bandwidth Service

Verifying and Monitoring DS-TE Configurations

Configuration Examples for DS-TE

Configuration Examples for Configuring the Tunnel Head Router

Configuration Examples for Configuring DS-TE on the Midpoint Routers

Configuration Examples for Configuring the Tail-End Router

Configuration Examples for Configuring Guaranteed Bandwidth Service

Per VRF AAA

Related Documentation


Configuring Quality of Service for MPLS Traffic


Multiprotocol label switching (MPLS) combines the performance and capabilities of Layer 2 (data link layer) switching with the proven scalability of Layer 3 (network layer) routing. MPLS enables you, as service providers, to meet the challenges of the explosive growth in network utilization while providing the opportunity to differentiate services without sacrificing the existing network infrastructure. You can employ the flexible MPLS architecture in any combination of Layer 2 technologies.

The Cisco 10000 series router offers MPLS support for all Layer 3 protocols.

This chapter describes QoS for MPLS-enabled networks and includes the following topics:

MPLS QoS

MPLS CoS Multi-VC Mode

MPLS Traffic Engineering—DiffServ Aware

Per VRF AAA

Related Documentation

MPLS QoS

Multiprotocol Label Switching (MPLS) quality of service (QoS) allows you, as the service provider, to provide varying levels of QoS services for different types of traffic in an MPLS network. MPLS allows you to "tunnel" the QoS of a packet. You can classify packets according to their type, input interface, and other factors without changing the IP precedence or DSCP field of the packet.

The IP precedence and DSCP fields allow you to specify the QoS for an IP packet. The MPLS experimental (EXP) field, consisting of 3 bits in the IP header, allows you to specify the QoS for an MPLS packet. The EXP field is used to support differentiated services and can carry all of the information encoded in the IP precedence or DSCP field. In some cases, the EXP bits are used exclusively to encode the drop precedence within a traffic class.

The router applies QoS services based on the class of service (CoS) set for a packet. If the IP precedence field specifies the CoS, the router treats the packet based on the IP precedence marking. In an MPLS network, the router copies the IP precedence bits into the MPLS EXP field at the edge of the network. However, based on the service offering, you might need to set the MPLS EXP field to a value that is different from the IP precedence value. In this case, MPLS QoS allows the IP precedence or DSCP setting of a packet to remain unmodified as the packet passes through the provider network. During congestion, packets receive the appropriate priority, based on the MPLS EXP setting.

You can mark the EXP bits independently of the per-hop behavior (PHB). Instead of overwriting the value in the IP precedence field, you can set the MPLS EXP field, choosing from a variety of criteria (including those based on IP PHB) to classify a packet and set the MPLS EXP field. For example, you can classify packets with or without considering the rate of the packets that the PE1 receives. If the rate is a consideration, you can mark in-rate packets differently from out-of-rate packets.

As the packet travels through the MPLS network, the marking value of an IP packet does not change and the IP header remains available for use. In some instances, it is desirable to extend the MPLS PHB to the egress interface between the provider edge (PE) router and customer edge (CE) router. This has the effect of extending the MPLS QoS tunnel, which allows the MPLS network owner to classify scheduling and discarding behavior on that final interface.

Feature History for MPLS QoS

Cisco IOS Release
Description
Required PRE

Release 12.0(19)SL

The MPLS QoS feature was introduced on the PRE1.

PRE1

Release 12.0(22)S

This feature was enhanced to allow classification and marking based on the MPLS experimental (EXP) field.

PRE1

Release 12.2(16)BX

This feature was introduced on the PRE2.

PRE2

Release 12.2(28)SB

This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

PRE2


MPLS QoS Services

The MPLS experimental (EXP) field allow you to specify the QoS for an MPLS packet while the IP precedence and DSCP fields allow you to specify the QoS for an IP packet. By setting the MPLS EXP field, the router does not modify the IP precedence or DSCP field of IP packets as they traverse the network.

MPLS QoS supports the following QoS services:

Policing—Classifies packets according to input or output transmission rates. Allows you to set the MPLS EXP, IP precedence, or DSCP bits (whichever is appropriate). For more information about policing, see Chapter 6 "Policing Traffic."

Weighted Random Early Detection (WRED)—Monitors network traffic to prevent congestion by dropping packets based on the IP precedence value, DSCP value, MPLS EXP value, or the discard class value. For more information about WRED, see Chapter 11 "Managing Packet Queue Congestion."

Class-Based Weighted Fair Queuing (CBWFQ)— An automated scheduling system that uses a queuing algorithm to ensure bandwidth allocation to different classes of network traffic. For more information about CBWFQ, see Chapter 12 "Sharing Bandwidth Fairly During Congestion."

MPLS Tunneling Modes

MPLS QoS provides QoS on MPLS packets using the following tunnel modes:

Uniform—Provides uniformity in per-hop behavior (PHB) throughout the network. In this mode, all customers of your MPLS network use the same precedence settings.

Short Pipe—(Default) Provides for a distinct MPLS PHB layer (on top of the IP PHB layer) across the entire MPLS network. In this mode, your customers implement their own IP PHB marking scheme.

Pipe—Similar to short pipe mode, except that at the egress of the provider edge (PE) router the MPLS PHB layer is used to classify the packet for discard and scheduling behavior at the outbound interface. In this mode, you schedule and discard packets without needing to know your customer setting.

Figure 20-1 shows a service provider MPLS network that connects two sites of a customer's network. To use these features in a network, set the MPLS experimental field value at PE1 (the ingress label switching router) by using the modular QoS CLI. This sets the QoS value in the MPLS packet.

Figure 20-1 MPLS Network Connecting Two Sites of a Customer's IP Network

Short pipe tunnel mode discards the MPLS EXP value on label disposition. To enable MPLS EXP-based classification after label disposition, you can map the EXP values to the qos-group values at the inbound interface and use qos-group to classify packets into different classes at the outbound interface. However, Weighted Random Early Detection (WRED) on the outbound interface is still based on the IP type of service (ToS) value rather than the disposed EXP value.

The Cisco 10000 series router does not support the propagate-cos command to enable uniform mode. The router does not copy the MPLS EXP values on disposition to the packet's IP header, unless you map the EXP value to a qos-group value at the inbound interface and use the qos-group value to set the IP ToS value on the outbound interface.

How QoS Works for MPLS Traffic

The Cisco 10000 series router bypasses the IP header-based classification for MPLS packets—you cannot classify MPLS packets into distinct classes using the embedded IP header of the MPLS packet. The router classifies MPLS packets as belonging to the class-default class, except if you specify qos-group or input-interface match statements for traffic classes.

Normal QoS processing applies to incoming IP packets that the router later tags. Normal QoS processing resumes for outgoing IP packets that arrived tagged.

Precedence-based Weighted Random Early Detection (WRED) uses the MPLS experimental (EXP) value for MPLS packets.

Upon MPLS imposition, by default the router sets the EXP values of all pushed labels to the packet's IP precedence value. Upon label swap, the new label carries the EXP value of the swapped label. A set or police command directive might modify the default EXP setting.

MPLS QoS and Packet Priority During Congestion

The router classifies packets based on the classification and marking criteria you define, such as a source address, destination address, port, protocol identification, or class of service field. The packets' classification in turn determines each packet's priority and how the router treats the packet during periods of congestion (for example, forward or drop the packet).

For example, service level agreements (SLAs), contracted between providers and their customers, specify how much traffic the service provider agrees to deliver. Packets that comply with the agreed-upon rate are considered in-rate and packets that do not comply are considered out-of-rate. During congestion, the router gives preferential treatment to in-rate packets and might aggressively drop out-of-rate packets.

Interfaces Supporting MPLS QoS

The following describes interface support for MPLS QoS:

The router supports the match mpls experimental topmost command on both input and output interfaces on which MPLS is enabled.

The set mpls experimental imposition command and the set mpls experimental command are supported on the provider edge (PE) router input interface connecting to customer edge (CE) router. You can also use these commands on input interfaces on the CE, in pipe mode of MPLS QoS DiffServ tunneling models.


Note The set mpls experimental imposition command replaces the set mpls experimental command, which the router supports only for backward compatibility. We recommend that you use the set mpls experimental imposition command.


The set-mpls-exp-imposition-transmit action of the police command is only supported on the PE input interface that is connected to the CE.

The mpls ip encapsulate explicit-null command is supported on the CE router interface that is connected to the PE. This command is only used in pipe mode of MPLS QoS DiffServ tunneling models.

MPLS QoS Implementation

When precedence-based weighted random early detection (WRED) is configured on an output policy map and outgoing packets are MPLS packets, the router drops the MPLS packets based on the three EXP bits in the MPLS label, instead of using the three bits of the IP precedence field in the underlying IP packets.

When DSCP-based WRED is configured on an output policy map and outgoing packets are MPLS packets, the router drops the MPLS packets based on the three EXP bits in the MPLS label, instead of using the six bits of the DSCP field in the underlying IP packets. The router left shifts the three EXP bits and makes it six bits. For example, if the value of the EXP bits is 5 (binary 101), the router converts them to binary 101000 (makes it looks like six DSCP bits), and drops packets based on this value.

When configuring the set and police commands in a traffic class, regardless of whether it is an input or output policy map, the police command is processed later than the set command. This means that the values implemented by the police command override the values set by the set command. The value can be IP precedence, DSCP, qos-group, MPLS experimental imposition, discard-class, or ATM CLP bit.

Discard-class is a number between 0 and 7; qos-group is a number between 0 and 63.

Restrictions and Limitations for MPLS QoS

The router does not support the set mpls experimental imposition topmost command.

Configuring MPLS QoS on the Ingress Label Switching Router

A label switching router (LSR) is an ingress provider edge (PE) router, a provider (P) router, or a penultimate-hop provider router. Setting the MPLS EXP field is only valid for packets that arrive on a non-MPLS interface of the LSR and leave on an MPLS interface. Therefore, only input service policies can cause the MPLS EXP bits to be set when the packet goes out an MPLS interface. If the packet arrives on an MPLS interface, setting the MPLS EXP field has no affect.

The IP header of an outbound IP packet determines the packet's QoS. For general information, see the Cisco IOS Quality of Service Solutions Configuration Guide.

The MPLS EXP field in the topmost label of an outbound MPLS packet determines the packet's QoS. For general information, see the MPLS Class of Service manual.

To configure MPLS QoS on the ingress LSR, perform the following configuration tasks to configure the ingress label switching router:

Classifying IP Packets Using a Class Map

Setting the MPLS EXP Field Using a Policy Map

Attaching an MPLS QoS Service Policy to an Interface

Classifying IP Packets Using a Class Map

To classify IP packets using a class map, enter the following commands on the ingress LSR beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# class-map class-map-name

Creates or modifies a class map.

class-map-name is the name of the class map.

Step 2 

Router(config-cmap)# match mpls experimental 
topmost value

(Optional) Specifies the MPLS EXP bits value used to classify traffic.

Note You can configure MPLS EXP-based classification on the ingress provider edge (PE), egress PE, provider (P), or penultimate P router. This command is available only on the PRE2.

Step 3 

Router(config-cmap)# match criteria

Defines criteria by which the router matches packets to this traffic class.

criteria is the match type (for example, precedence or DSCP level)

For more information about match types, see the "Defining Match Criteria Using the match Commands" section.

Configuration Example for Classifying IP Packets Using a Class Map

The following example creates a class map named exp4 with MPLS EXP 4 defined as the match criterion. The router classifies all packets whose EXP bits are set to 4 as belonging to the exp4 traffic class.

Router(config)# class-map match-all exp4
Router(config-cmap)# match mpls experimental topmost 4
Router(config-cmap)# end
 
   

The following example creates a class map named IP_prec4 with IP precedence 4 defined as the match criterion. The router classifies all packets that contain IP precedence 4 as belonging to the IP_prec4 traffic class.

Router(config)# class-map match-all IP_prec4
Router(config-cmap)# match ip precedence 4
Router(config-cmap)# end
 
   

The following example creates a class map named http with the access control list (ACL) named http defined as the match criterion. The router classifies all packets that match the http ACL as belonging to the http traffic class.

Router(config)# class-map match-all http
Router(config-cmap)# match access-group name http
Router(config-cmap)# end
 
   

The following example creates a class map named af41 with DSCP AF41 defined as the match criterion. The router classifies all packets that contain the IP DSCP binary value 100010 as belonging to the af41 traffic class.

Router(config)# class-map match-all af41
Router(config-cmap)# match ip dscp af41
Router(config-cmap)# end

Setting the MPLS EXP Field Using a Policy Map

To set the MPLS EXP field of packets belonging to a specific traffic class, enter the following commands beginning in global configuration mode:


Note Even though the commands in Steps 3 through 6 are optional, you must configure one of the commands to set the MPLS EXP field. The router sets the EXP bits when the packet leaves the router using an MPLS interface. If the packet arrives on an MPLS interface, the router does not set the EXP bits. You can only set the EXP bits of packets that arrive on a non-MPLS interface and leave on an MPLS interface.


 
Command
Purpose

Step 1 

Router(config)# policy-map policy-map-name

Creates or modifies a policy map that specifies the QoS actions to take on specific traffic classes.

policy-map-name is the name of the policy map.

Step 2 

Router(config-pmap)# class class-map-name

Assigns a traffic class to a policy map. Enters policy-map class configuration mode.

class-map-name is the name of a previously configured class map.

Step 3 

Router(config-pmap-c)# police [cir] bps 
[bcburst-normal [be] burst-excess 
[conform-action 
set-mpls-exp-imposition-transmit] 
[exceed-action action] [violate-action 
action]

(Optional) Configures traffic policing based on bits per second and sets the MPLS EXP field for all packets that conform to the rate.

For more information, see Chapter 6 "Policing Traffic."

Step 4 

Router(config-pmap-c)# police {cir cir} 
[bcburst-normal [pir pir] [bepeak-burst 
[conform-action 
set-mpls-exp-imposition-transmit] 
[exceed-action action] [violate-action 
action]

(Optional) Configures traffic policing using the committed information rate (CIR) and the peak information rate (PIR) and sets the MPLS EXP field for all packets that conform to the rate.

For more information, see Chapter 6 "Policing Traffic."

Step 5 

police [cir] percent percent [bc] 
normal-burst-in-msec [pir pir] 
[beexcess-burst-in-msec [conform-action 
set-mpls-exp-imposition-transmit] 
[exceed-action action] [violate-action 
action]

(Optional) Configures traffic policing on the basis of a percentage of bandwidth available on an interface and sets the MPLS EXP field for all packets that conform to the rate.

For more information, see Chapter 6 "Policing Traffic."

Step 6 

Router(config-pmap-c)# set mpls 
experimental imposition mpls-exp-value

(Optional) Sets the MPLS EXP bits of the packets belonging to this traffic class.

mpls-exp-value specifies the value used to set the MPLS EXP bits. Valid values are from 0 to 7.

For more information about other QoS actions you can define in the policy map, see the "Types of QoS Actions" section.

Configuration Example for Setting the MPLS EXP Field Using a Policy Map

The following example shows how to set the MPLS EXP field using the set mpls experimental imposition command. The sample configuration creates a policy map named set_experimental_5 and defines the traffic class named IP_prec4. The router sets the MPLS EXP bits to 5 for all of the packets belonging to the IP_prec4 class.

Router(config)# policy-map set_experimental_5
Router(config-pmap)# class IP_prec4
Router(config-pmap-c)# set mpls experimental imposition 5
Router(config-pmap-c)# end

Attaching an MPLS QoS Service Policy to an Interface

An MPLS QoS service policy is a policy map that sets the MPLS EXP field of packets belonging to a specific traffic class.

To attach an MPLS QoS service policy to an interface, enter the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface type number

Creates or modifies an interface. Enters interface configuration mode.

type is the type of interface (for example, serial).

number is the number of the interface (for example, 1/0/0).

Step 2 

Router(config-if)# service-policy input 
policy-map-name

Attaches the specified policy map to the input interface.

policy-map-name is the name of the policy map you want to attach to the interface.

Configuration Example for Attaching an MPLS QoS Service Policy to an Interface

The following example applies the MPLS QoS service policy named set_experimental_5 to the Gigabit Ethernet interface 1/0/0 for inbound packets.

Router(config)# interface GigabitEthernet1/0/0 
Router(config-if)# service-policy input set_experimental_5 
Router(config-if)# end

Configuration Examples for MPLS QoS

This section provides example configurations for the following:

Configuration Example for Short Pipe Mode

Configuration Example for Pipe Mode

Configuration Example for Short Pipe Mode

The following example shows how to configure short pipe mode on the ingress PE router for the following sample topology. In this topology, esr5 is the CE router, esr6 is the PE router, esr4 is the P router.

Customer router/switch---(gig4/0/0) esr5 (gig3/0/0.2)---(gig3/0/0.2) esr6 (pos4/0/0)---
---(pos4/0/0) esr4 (gig5/0/0)---PE router

Esr6 (ingress PE router):

policy-map set-exp
 class http
  police 200000000 10000000 10000000 conform-action set-mpls-exp-imposition-transmit 1 
exceed-action set-mpls-exp-imposition-transmit 0 violate-action drop
 class telnet
  set mpls experimental imposition 5
  set ip precedence 2
 class rtp
  set mpls experimental 3
  set dscp cs4
 class tftp
  set mpls experimental 2
 class dscp32
  set mpls experimental imposition 5
 class prec6
  set mpls experimental imposition 6
!
policy-map wred
 class exp0
  bandwidth percent 10
  bandwidth remaining percent 12
  random-detect precedence-based
  random-detect precedence 0 500 1500 1
  shape 120000
 class exp1
  bandwidth percent 10
  bandwidth remaining percent 12
  random-detect precedence-based
  random-detect precedence 1 500 1500 1
  random-detect precedence 2 800 1300 5
  random-detect precedence 3 1000 1800 15
  random-detect precedence 4 1500 2000 20
  shape 550000
 class exp2
  bandwidth percent 10
  random-detect dscp-based
  random-detect dscp 16 800 1200 5
  shape 120000
 class exp3
  bandwidth remaining percent 12
  random-detect precedence-based
  random-detect precedence 1 500 1000 1
  random-detect precedence 2 800 1300 5
  random-detect precedence 3 500 1500 1
  random-detect precedence 4 1500 2000 20
  shape 120000
 class exp4
  bandwidth remaining percent 12
  random-detect precedence-based
  random-detect precedence 1 500 1000 1
  random-detect precedence 2 800 1300 5
  random-detect precedence 3 1000 1800 15
  random-detect precedence 4 500 1500 1
  shape 120000
 class exp5
  bandwidth percent 10
  bandwidth remaining percent 12
  random-detect precedence-based
  random-detect precedence 5 500 1500 1
  shape 120000
 class exp6
  bandwidth percent 10
  bandwidth remaining percent 12
  random-detect precedence-based
  random-detect precedence 6 500 1500 1
  shape 120000
 class exp7
  bandwidth percent 10vbandwidth remaining percent 12
  random-detect precedence-based
  random-detect precedence 7 500 1500 1
  shape 120000
 class class-default
! 
interface GigabitEthernet3/0/0.2
 encapsulation dot1Q 2
 ip vrf on forwarding vrf_2
 ip address 220.220.56.6 255.255.255.0
 service-policy input set-exp
!
!
interface POS4/0/0
 ip address 220.220.46.6 255.255.255.0
 load-interval 30
tag-switching ip
 crc 32
 clock source internal
service-policy output wred

Configuration Example for Pipe Mode

The following example shows how to configure pipe mode on the CE and PE routers in the following sample topology. In this topology, esr5 is the CE router, esr6 is the PE router, esr4 is the P router.

Customer router/switch---(gig4/0/0) esr5 (gig3/0/0.2)---(gig3/0/0.2) esr6 (pos4/0/0)---
---(pos4/0/0) esr4 (gig5/0/0)---PE router

Configuration for esr5 (CE router):

class-map match-all prec0
 match ip precedence 0 
class-map match-all prec1
 match ip precedence 1 
class-map match-all prec2
 match ip precedence 2 
class-map match-all prec3
 match ip precedence 3
class-map match-all prec4
 match ip precedence 4 
class-map match-all prec5
 match ip precedence 5 
class-map match-all prec6
 match ip precedence 6 
class-map match-all prec7
 match ip precedence 7
!
policy-map prec2exp
 class prec0
  set mpls experimental imposition 1
 class prec1
  set mpls experimental imposition 2
 class prec2
  set mpls experimental imposition 3
 class prec3
  set mpls experimental imposition 4
 class prec4
  set mpls experimental imposition 5
 class prec5
  set mpls experimental imposition 6
 class prec6
  set mpls experimental imposition 7
 class prec7
  set mpls experimental imposition 0
!
!
interface GigabitEthernet4/0/0
 ip address 220.5.1.1 255.255.255.0
 service-policy input prec2exp
 load-interval 30
 no negotiation auto
 no keepalive
!
interface GigabitEthernet3/0/0.2
 encapsulation dot1Q 2
 ip address 220.220.56.5 255.255.255.0
 mpls ip encapsulate explicit-null
 
   

Configuration for esr6 (ingress PE router):

class-map match-all exp4
 match mpls experimental topmost 4 
class-map match-all exp5
 match mpls experimental topmost 5 
class-map match-all exp7
 match mpls experimental topmost 7 
class-map match-all exp6
 match mpls experimental topmost 6 
class-map match-all exp1
 match mpls experimental topmost 1 
class-map match-all exp0
 match mpls experimental topmost 0 
class-map match-all exp3
 match mpls experimental topmost 3 
class-map match-all exp2
 match mpls experimental topmost 2
!
policy-map exp2exp
 class exp0
  set mpls experimental imposition 1
 class exp1
  set mpls experimental imposition 2
 class exp2
  set mpls experimental imposition 3
 class exp3
  set mpls experimental imposition 4
 class exp4
  set mpls experimental imposition 5
 class exp5
  set mpls experimental imposition 6
 class exp6
  set mpls experimental imposition 7
class exp7
  set mpls experimental imposition 0
!
interface GigabitEthernet3/0/0.2
 encapsulation dot1Q 2
 ip vrf forwarding vrf_2
 ip address 220.220.56.6 255.255.255.0
 service-policy input exp2exp
 tag-switching ip

MPLS CoS Multi-VC Mode

The Multiprotocol Label Switching Class of Service (MPLS CoS) Multi-Virtual Circuit (VC) Mode feature on the Cisco 10000 router provides multi-VC support on the performance routing engine (part number PRE1) and extends QoS functionality to Label-Controlled Asynchronous Transfer Mode (LC-ATM) and multi-VC subinterfaces in a service provider MPLS-enabled network. Such a network incorporates ATM interfaces on the edge of the network, as well as ATM interfaces within the core of the network.

The MPLS CoS Multi-VC Mode feature enables you to map the experimental (EXP) field values of an MPLS label to an ATM VC to create sets of labeled virtual circuits (LVCs). Each set, called an LVC Service Group, consists of multiple LVCs and each LVC is treated as a member of the set. All members of a set are associated with a label-switched path (LSP) that is set up between a pair of ATM-connected routers in the user's networking environment. Each member of the set may have a different quality of service from other members of the set.

By using multi-VC sets, you can provide differentiated services to users of MPLS-enabled service provider networks. To provide this service differentiation, the provider edge (PE) router in the service provider network sets an appropriate value in the EXP field in the header of each incoming packet as it is received. A standard IP access list (ACL) together with a class of service (CoS) map and a prefix map are used to specify the number of classes (and LVCs) per IP destination. For information on a CoS map, see the"Class of Service Map" section.

Each MPLS-enabled ATM interface in the service provider network, including each ATM edge interface and each ATM router or switch interface within the core of the network, provides QoS support in a manner similar to that provided for IP packet interfaces. IP packets transiting the service provider's MPLS-enabled network are treated with the same priorities as afforded ATM traffic. Accordingly, MPLS CoS multi-VC functionality is virtually indistinguishable from the QoS support provided for IP packet interfaces.

For more information, see the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(2)T feature module.

Feature History for MPLS CoS Multi-VC Mode

Cisco IOS Release
Description
Required PRE

Release 12.0(27)S

This feature was introduced on the router.

PRE1

Release 12.2(16)BX

This feature was introduced on the PRE2.

PRE2

Release 12.2(28)SB

This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

PRE2


Label Switched Paths

IP packets travel through the core of an MPLS-enabled service provider network by means of multiple, label-switched paths (LSPs). In ATM networks, label virtual circuits (LVCs) are automatically established for each IP destination prefix. A standard IP access list (ACL) together with a class of service (CoS) map and a prefix map are used to specify the number of classes (and LVCs) per IP destination. For information on a CoS map, see the "Class of Service Map" section.

If there are multiple equal-cost paths through an ATM network from a P router within the core of the network to a destination, it is possible that each LVC relating to the same destination could take a different path through the network, since each LVC could be set up along an alternate equal-cost path. For example, if four equal-cost paths exist through the network, the first LVC would be set up along the first path, the second LVC would be set up along the second path, and so on. There is no guarantee, however, that each LVC would be set up along a parallel path in the network, nor is there any requirement that each LVC be set up in such a manner.

If there are multiple equal-cost paths through an ATM network from a PE router on the edge of the network to a destination, LVCs are established for all configured classes of service for each of the equal-cost paths. The configured load-balancing mechanism determines path selection for data forwarding.

Class of Service Map

A class of service (CoS) map is a template that maps EXP values to a VC number within an LVC service group. The Cisco IOS software uses the CoS map to create a binding table that maps EXP values to the actual VCs. Each LVC has a CoS map and a separate binding table.

You can specify a maximum of four LVCs for each service group. Table 1 shows the default CoS map. Based on this map, the binding table will have four VCs named available, standard, premium, and control. The two least significant bits of the EXP field determine the LVC to which the IP packets will be directed.

Table 1 Default CoS Map

EXP Values
VC Number
VC Name

0, 4

0

Available

1, 5

1

Standard

2, 6

2

Premium

3, 7

3

Control


You can configure a CoS map to limit the number of LVCs created and to redefine the mapping of the EXP bits. Table 2 shows a configured CoS map. Based on this map, the binding table will have two VCs named available and premium.

Table 2 Configured CoS Map

EXP Values
VC Number
VC Name

0, 4

0

Available

1, 5

0

Available

2, 6

2

Premium

3, 7

2

Premium


QoS for Label-Controlled ATM VCs

The router dynamically creates label-controlled ATM virtual circuits (LC-ATM VCs), also referred to as LVCs. In Cisco IOS Release 12.0(28)S and later releases, the implementation of LC-ATM interfaces is expanded to provide QoS capability for LVCs.

The router treats LVCs like unspecified bit rate (UBR) permanent virtual circuits (PVCs). By default, the LVCs share the bandwidth on an ATM interface with UBR PVCs. You can configure the bandwidth on the LC-ATM subinterface using a nested policy map. For more information, see the "Allocating LVC Bandwidth Using Policy Maps" section.

Default Bandwidth for LVCs

The default bandwidth is the bandwidth an LC-ATM interface will have when it first becomes active. LVCs and UBR PVCs share all available bandwidth.

Allocating LVC Bandwidth Using Policy Maps

The router allows you to configure bandwidth for an LC-ATM subinterface. Because the router does not support a default bandwidth for LVCs, you must use a nested policy map to configure the bandwidth. The router does not allow non-nested policy maps to be attached to an LC-ATM subinterface.

The nested policy map provides the bandwidth. The router treats the configured bandwidth like the SCR of the VBR PVCs, in that all LVCs on a specific LC-ATM subinterface use the aggregate bandwidth specified in the nested policy map. The available bandwidth for UBR PVCs is then reduced by the configured bandwidth amount.

MPLS QoS Support in an MPLS Network

MPLS QoS provides IOS IP QoS (Layer 3) functionality for MPLS devices, including label edge routers (LERs), label switching routers (LSRs), and Asynchronous Transfer Mode LSRs (ATM-LSRs). You can use MPLS QoS in an MPLS-enabled networking environment in several different ways. The method you choose depends on whether the core of the network contains LSRs or ATM label switching routers (ATM-LSRs). In either case, the same QoS services are provided, such as CAR, weighted random early detection (WRED), class-based weighted fair queueing (CBWFQ).

For information about how you can deploy LSRs and ATM-LSRs to take advantage of QoS functions in an MPLS network, refer to the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(2)T feature module.

Benefits of MPLS CoS Multi-VC Mode

The MPLS CoS Multi-VC Mode feature has the following benefits:

Ensures effective deployment of differentiated service classes in an MPLS-enabled ATM network

Leverages the use of existing ATM infrastructures

Restrictions for MPLS CoS Multi-VC Mode

The MPLS CoS Multi-VC Mode feature has the following restrictions:

A multi-VC service group can have up to four LVCs.

The Cisco 10000 series router supports a maximum of 500 LVC service groups.

The Cisco 10000 series router does not support available bit rate (ABR) for ATM VCs. Therefore, the router also does not support ABR LVCs.

All LVCs and the control-VC share the same QoS policy. Any QoS policy changes are applied to the subinterface. All LVCs will then automatically share the new policy.

Prerequisites for MPLS CoS Multi-VC Mode

The MPLS CoS Multi-VC Mode feature has the following requirements:

The Cisco 10000 series router must be running Cisco IOS Release 12.0(27)S or later releases.

The performance routing engine (PRE), part number PRE1 must be installed in the router's chassis.

To use MPLS QoS to full advantage in your network, the following functionality must be supported:

Multiprotocol Label Switching (MPLS)—The standardized label switching protocol defined by the Internet Engineering Task Force (IETF).

Cisco Express Forwarding (CEF)—An advanced Layer 3 IP switching technology that optimizes performance and scalability in networks that handle large volumes of traffic and exhibit dynamic traffic patterns.

Asynchronous Transfer Mode (ATM)—International standard for cell relay in which multiple service types (such as voice, video, or data) are conveyed in fixed-length cells. ATM signaling is required if you use ATM interfaces in your network.

The following QoS features are required:

MPLS CoS Multi-VC Mode to provide QoS functionality on ATM interfaces in a service provider MPLS-enabled network.

Class-based weighted fair queueing (CBWFQ) to allocate bandwidth fairly to all network traffic.

Weighted random early detection (WRED) to configure different discard priorities or classes of service using the MPLS experimental field in the MPLS packet header.

Configuring MPLS CoS Multi-VC Mode

To configure the MPLS CoS Multi-VC Mode feature on the Cisco 10000 router, perform the following required configuration tasks:

Configuring Multi-VC Mode in the Core of an ATM Network

Configuring Queueing Functions on Router Output Interfaces

Configuring Multi-VC Mode in the Core of an ATM Network

To configure multi-VC mode in the core of an ATM network, perform the following required configuration tasks:

Configuring Multi-VC Mode Using the Default CoS Map

Configuring Multi-VCs Using a Specific CoS Map

Configuring Multi-VC Mode Using the Default CoS Map

To configure multi-VC mode in an MPLS-enabled network using the default CoS map, enter the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface atm number [slot/module/port.subinterface-number] mpls

Configures an ATM MPLS interface or subinterface and enters interface or subinterface configuration mode.

Step 2 

Router(config-if)# ip unnumbered type number

Enables IP processing on the interface without assigning an explicit IP address to the interface.

Step 3 

Router(config-if)# mpls atm multi-vc

Enables ATM multi-VC mode on the interface.

Configures the ATM interface to create one or more label virtual circuits (VCs) over which packets of different classes are sent.

Note This command results in the creation of the default CoS map shown in Table 1.

Step 4 

Router(config-if)# mpls ip

Enables MPLS forwarding of IP version 4 (IPv4) packets along normally routed paths.

Step 5 

Router(config-if)# mpls label protocol {ldp | tdp | both}

Specifies the label distribution protocol to be used on the interface.

Configuring Multi-VCs Using a Specific CoS Map

To configure multi-VCs using a CoS map that you specify, enter the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# mpls cos-map cos-map number

Creates a class of service (CoS) map that specifies how classes map to label virtual circuits (LVCs) when they are combined with a prefix map. Enters cos-map configuration submode.

Step 2 

Router(config-tag-cos-map)# class class [available | standard | premium |control]

Maps traffic classes to LVCs.

class is the precedence of identified traffic to classify traffic.

The default values for assigning traffic classes to the CoS map range from 0 to 3:

Class 0—Available

Class 1—Standard

Class 2—Premium

Class 3—Control

The two least significant bits of the EXP field in the packet header determine the class of a packet.

Step 3 

Router(config-tag-cos-map)# exit

Exits the cos-map configuration submode.

Step 4 

Router(config)# access-list access-list-number permit destination

Creates an access list to control traffic going to the specified destination address.

Step 5 

Router(config)# mpls prefix-map prefix-map access-list access-list cos-map cos-map

Configures the router to use a specified QoS map when an MPLS destination prefix matches the specified access list.

Configuring Queueing Functions on Router Output Interfaces

To configure queuing functions on the router's output interfaces, see Chapter 3 "Configuring QoS Policy Actions and Rules."

Monitoring and Maintaining MPLS CoS Multi-VC Mode Configuration

To monitor and maintain the configuration of MPLS CoS Multi-VC Mode on ATM interfaces, enter any of the following commands in privileged EXEC mode:

Command
Purpose

Router# show mpls interfaces [interface] [detail]

Displays information about one or more interfaces that have been configured for label switching.

If you do not specify an interface, information about all interfaces that have been configured for label switching displays.

detail displays detailed label switching information for the specified interface or for all interfaces if you do not specify an interface.

Router# show mpls cos-map [cos-map]

Displays the quality of service (QoS) map used to assign a quantity of label virtual circuits and the associated class of service (CoS) for those virtual circuits.

cos-map is an optional number that specifies the QoS map to be displayed.

Router# show mpls prefix-map [prefix-map]

Displays the prefix map used to assign a QoS map to network prefixes that match a standard IP access list.

prefix-map is an optional number that specifies the prefix map to be displayed.

Router# debug mpls atm-cos [bind | request]

Displays ATM label VC bind or request activity that is based on the configuration of a QoS map.


Configuration Examples for MPLS CoS Multi-VC Mode

For an example of how to configure MPLS CoS multi-VC mode functionality, see the "Configuration Examples" section in the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(4)T3 feature module.

MPLS Traffic Engineering—DiffServ Aware

The MPLS Traffic Engineering—DiffServ Aware (DS-TE) feature extends MPLS traffic engineering capabilities to provide stricter quality of service (QoS) guarantees. TE tunnels provide differentiated services (DiffServ) to satisfy bandwidth requirements of regular traffic. However, the bandwidth currently advertised for TE tunnels and the tunnel traffic does not correspond to any queue. Instead, the MPLS class of service (CoS) provides DiffServ service, which is adequate for most customer services. Special services such as voice, however, require stricter QoS guarantees. The DS-TE feature addresses this need, providing strict bandwidth guarantees for TE tunnels.

The DS-TE feature introduces awareness of a particular class of traffic referred to as the guaranteed bandwidth traffic. DS-TE enables you, as service providers, to perform separate admission control and separate route computation of the guaranteed bandwidth traffic. Therefore, you can develop QoS services for end customers that rely on signaled QoS rather than provisioned QoS, which enables you to build QoS services with hard commitments and without overprovisioning.

MPLS traffic engineering allows constraint-based routing of IP traffic. One of the constraints satisfied by constraint-based routing is the availability of required bandwidth over a selected path. DS-TE extends MPLS TE so that constraint-based routing and admission control of special TE tunnels (referred to as guaranteed bandwidth TE tunnels) are performed over a more restrictive bandwidth constraint than regular TE tunnels. A more restrictive bandwidth constraint enables you to achieve higher QoS performance (in terms of delay, jitter, or loss) for the guaranteed traffic.

The more restrictive bandwidth is referred to as a sub-pool, while the regular TE tunnel bandwidth is called the global pool. The sub-pool is a portion of the global pool and applies to tunnels that carry traffic requiring strict bandwidth guarantees or delay guarantees. The global pool applies to tunnels that carry traffic requiring only differentiated service.

Having a separate pool for traffic requiring strict guarantees allows you to limit the amount of such traffic admitted on any given link. Often, it is possible to achieve strict QoS guarantees only if the amount of guaranteed traffic is limited to a portion of the total link bandwidth.

Having a separate pool for other traffic (best-effort or DiffServ traffic) allows you to have a separate limit for the amount of such traffic admitted on any given link. This is useful because it allows you to fill up links with best-effort and DiffServ traffic, thereby achieving a greater utilization of those links.

The DS-TE feature also extends the Open Shortest Path First (OSPF) routing protocol so that the available sub-pool bandwidth at each preemption level is advertised in addition to the available global pool bandwidth at each preemption level. The DS-TE feature also modifies constraint-based routing to take this more complex advertised information into account during path computation.

For more information, see the MPLS Traffic Engineering—DiffServ Aware, Release 12.2(14)S feature module.

Feature History for MPLS TE—DS

Cisco IOS Release
Description
Required PRE

Release 12.3(7)XI

The MPLS Traffic Engineering—DiffServ Aware (DS-TE) feature was introduced on the PRE2.

PRE2

Release 12.2(28)SB

This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

PRE2


Sub-pool Tunnels

A sub-pool tunnel carries traffic that requires strict bandwidth guarantees or delay guarantees, such as real-time voice, virtual IP leased line, and bandwidth trading traffic. As traffic enters the sub-pool tunnel, DS-TE marks the traffic with a unique value in the MPLS EXP field. The router places traffic with this unique value in the guaranteed bandwidth queue at the outbound interface of every tunnel hop. The strict guaranteed traffic has exclusive use of the guaranteed bandwidth queue; no other traffic can use this queue.

DS-TE ensures that the guaranteed bandwidth queue is never oversubscribed and limits the amount of traffic that enters the queue to a percentage of the total bandwidth of the corresponding outbound link. Therefore, the amount of traffic sent into the sub-pool is never more than the amount the guaranteed bandwidth queue can handle.

Global Pool Tunnels

A tunnel that uses global pool bandwidth carries the best-effort class of traffic as well as other classes of traffic. To ensure that traffic from each class receives differentiated services (DiffServ), each traffic class has a distinct DiffServ queue and the router marks each class of traffic with a unique value in the MPLS EXP field. The router places traffic in the appropriate queue based on this unique value. The router sets tunnel bandwidth based on the expected aggregate traffic across all classes of service.

Prerequisites for DS-TE

To run DS-TE your network must support the following Cisco IOS features:

Multiprotocol Label Switching (MPLS)

IP Cisco Express Forwarding (CEF)

Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS) routing protocols

Resource Reservation Protocol-Traffic Engineering (RSVP-TE)

QoS


Note IP CEF is enabled by default on the Cisco 10000 series router and it cannot be turned off. If you attempt to disable IP CEF, an error appears.


Restrictions and Limitations for DS-TE

The total number of TE tunnels (regular TE tunnels and DS-TE tunnels) that can originate on a device is limited to 1013 tunnels.

Configuring DS-TE

To configure DS-TE, perform the following required configuration tasks:

Activating Traffic Engineering on the Router

Activating Traffic Engineering on the Interface

Configuring the Tunnel Interface

Configuring Guaranteed Bandwidth Service

Activating Traffic Engineering on the Router

To globally activate traffic engineering on the router, enter the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# mpls traffic-eng tunnels

Enables MPLS traffic engineering tunnel signaling on the router.

Step 2 

Router(config)# router ospf

or

Router(config)# router isis

Invokes the OSPF routing process for IP and enters router configuration mode. Continue with Step 9.

Invokes the IS-IS routing process and enters router configuration mode. Continue with Step 3.

Step 3 

Router(config-router)# network network-entity-title

Specifies the IS-IS network entity title (NET) for the routing process.

network-entity-title specifies the area address and the system ID for an IS-IS routing process. You can specify an address or a name for network-entity-title.

Step 4 

Router(config-router)# metric-style wide [transition] [{level-1 | level-2 | level-1-2}]

Enables the router to generate and accept IS-IS only new-style type, length, and value (TLV) objects.

Step 5 

Router(config-router)# is-type {level-1 | level-1-2 | level-2-only}

Configures the IS-IS level at which the Cisco IOS software operates.

When you specify level-1, the router acts as a station router and learns about destinations inside its area. For interarea routing information, the router depends on the closest level-1-2 (L1L2) router.

When you specify level-1-2, the router acts as both a station router and an area router. The router has one link state database (LSDB) for destinations inside the area (L1 routing) and runs a shortest path first (SPF) calculation to discover the area topology. The router also has another LSDB with link state protocol (LSP) packets of all other backbone (L2) routers and runs another SPF calculation to discover the topology of the backbone, and the existence of all other areas.

When you specify level-2-only, the router acts an area router only. This router is part of the backbone and does not talk to L1-only routers in its own area.

Step 6 

Router(config-router)# mpls traffic-eng {level-1 | level-2}

Configures the router to flood MPLS traffic engineering link information into the IS-IS level you specify. The IS-IS level you specify must be the same level you specified in the preceding step.

Step 7 

Router(config-router)# passive-interface type number

Disables the IS-IS routing protocol from sending routing updates on the interface you specify. IS-IS advertises the IP address of the interface without actually running IS-IS on that interface.

For type number, specify the loopback0 interface.

Note When you enable passive-interface on an interface, IS-IS continues to advertise the subnet to other interfaces and continues to receive and process updates on the interface from other routers.

Step 8 

Router(config-router)# mpls traffic-eng router-id interface-name

Specifies that the traffic engineering router identifier for the node is the IP address associated with a specific interface.

interface-name specifies the IP address associated with the loopback0 interface.

Note For IS-IS configurations, this completes the activation of TE on the router. Do not continue to Step 9.

Step 9 

Router(config-router)# mpls traffic-eng area num

Turns on MPLS traffic engineering for a particular OSPF area.

Note Enter this command for OSPF configurations only. Do not enter this command for IS-IS configurations.

Configuration Example for Activating Traffic Engineering on the Router

Example 20-1 configures the router for TE using the OSPF routing protocol.

Example 20-1 Activating Traffic Engineering on the Router

Router(config)# mpls traffic-eng tunnels
Router(config)# router ospf 100
Router(config-router)# network 10.1.1.0 0.0.0.255 area 0
Router(config-router)# network 10.16.1.1 0.0.0.0 area 0
Router(config-router)# mpls traffic-eng area 0
Router(config-router)# mpls traffic-eng router-id loopback0
Router(config-router)# exit

Activating Traffic Engineering on the Interface

To activate traffic engineering on the physical interface, enter the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface type number

Configures an interface and enters interface configuration mode.

type is the type of interface (for example, serial).

number is the number of the interface (for example, 1/0/0).

Step 2 

Router(config-if)# ip rsvp bandwidth interface-kbps [sub-pool kbps]

Enables Resource Reservation Protocol (RSVP) for IP on an interface.

interface-kbps specifies the amount of bandwidth (in kbps) on an interface to be reserved. Valid values are from 1 to 10,000,000.

(Optional) sub-pool kbps is the amount of bandwidth (in kbps) on an interface to be reserved to a portion of the total. Valid values are from 1 to the value of interface-kbps.

Note The sum of bandwidth used by all tunnels on this interface cannot exceed interface-kbps and the sum of bandwidth used by all sub-pool tunnels cannot exceed sub-pool kbps.

Step 3 

Router(config-if)# mpls traffic-eng tunnels

Enables MPLS traffic engineering tunnel signaling on the interface.

Step 4 

Router(config-if)# ip router isis

Enables the IS-IS routing protocol on the interface.

Note Do not enter this command if you are configuring an OSPF configuration.

Configuration Example for Activating Traffic Engineering on the Interface

Example 20-2 configures TE on a physical interface using the IS-IS routing protocol.

Example 20-2 Activating Traffic Engineering on a Physical Interface with IS-IS

Router(config-if)# ip address 10.1.1.1 255.255.255.255
Router(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000
Router(config-if)# mpls traffic-eng tunnels
Router(config-if)# ip router isis 

Configuring the Tunnel Interface

To configure the attributes for the tunnel on the tunnel interface, enter the following commands beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# interface tunnel number

Creates a virtual tunnel interface and enters interface configuration mode.

number is the number of the tunnel interface that you want to create or configure. The Cisco 10000 series router does not limit the number of tunnel interfaces that you can create.

Step 2 

Router(config-if)# tunnel mode mpls traffic-eng

Sets the mode of a tunnel to MPLS for traffic engineering.

Step 3 

Router(config-if)# tunnel destination {hostname | ip-address}

Specifies the destination for a tunnel interface.

hostname is the name of the host destination.

ip-address is the IP address of the host destination.

Step 4 

Router(config-if)# tunnel mpls traffic-eng bandwidth [sub-pool | global] bandwidth

Configures the bandwidth required for an MPLS traffic engineering tunnel and assigns the tunnel to the sub-pool or global pool.

(Optional) sub-pool indicates a subpool tunnel. If you do not specify sub-pool, the tunnel is global pool.

global indicates a global pool tunnel. By default, all tunnels are global pool.

bandwidth specifies the bandwidth (in kbps) allocated for the MPLS traffic engineering tunnel. Valid values are from 1 to 4,294,967,295.

Step 5 

Router(config-if)# tunnel mpls traffic-eng priority setup-priority [hold-priority]

Configures the setup and reservation priority for an MPLS traffic engineering tunnel.

setup-priority indicates the priority used when signaling a link state protocol (LSP) for this tunnel to determine which existing tunnels can be preempted. Valid values are from 0 to 7, where a lower number indicates a higher priority. Therefore, an LSP with a setup-priority of 0 can preempt any LSP with a non-0 priority.

hold-priority is the priority associated with an LSP for this tunnel to determine if it should be preempted by other LSPs that are being signaled. Valid values are from 0 to 7, where a lower number indicates a higher priority.

Step 6 

Router(config-if)# tunnel mpls traffic-eng path-option [protect] number {dynamic | explicit {name path-name | path-number}} [lockdown]

Configures the path (hops) that you want an MPLS traffic engineering tunnel to use. You can configure many path options for a single tunnel, including both dynamic and explicit path options.

(Optional) protect indicates a backup label-switched path (LSP).

When you configure several path options, use lower numbered options for number.

dynamic indicates that the router dynamically calculates the LSP path.

explicit indicates that the LSP path is an IP explicit path.

name path-name specifies the path name of the IP explicit path. This path name represents the specific IP addresses of the hops.

path-number is the path number of the IP explicit path.

lockdown indicates that the LSP cannot be reoptimized.

Configuration Example for Configuring the Tunnel Interface

Example 20-3 configures DS-TE on the tunnel interface.

Example 20-3 Configuring Traffic Engineering on the Tunnel Interface

Router(config-if)# bandwidth 110000
Router(config-if)# ip unnumbered loopback0
Router(config-if)# tunnel destination 10.16.1.1
Router(config-if)# tunnel mode mpls traffic-eng
Router(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000
Router(config-if)# tunnel mpls traffic-eng priority 0 0
Router(config-if)# tunnel mpls traffic-eng path-option 1 dynamic

Configuring Guaranteed Bandwidth Service

To configure guaranteed bandwidth service, perform the following required configuration tasks:

Providing Strict QoS Guarantees Using DS-TE Sub-pool Tunnels

Providing Differentiated Service Using DS-TE Global Pool Tunnels

Providing Strict Guarantees and Differentiated Service in the Same Network

For guaranteed bandwidth service configuration examples, see the MPLS Traffic Engineering—DiffServ Aware, Release 12.2(14)S feature module.

Providing Strict QoS Guarantees Using DS-TE Sub-pool Tunnels

To provide strict QoS guarantees using DS-TE sub-pool tunnels, do the following:

1. Select a queue (referred to as per-hop behavior (PHB) in DiffServ terminology) to be used exclusively by the strict guarantee traffic. This queue is referred to as the guaranteed bandwidth queue.

If you want to provide delay or jitter guarantees, use the DiffServ expedited forwarding queue (EF PHB). On the Cisco 10000 series router, it is the absolute priority queue.

If you only want to provide bandwidth guarantees, use the DiffServ assured forwarding queue (AF PHB). On the Cisco 10000 series router, use one of the existing class-based weighted fair queuing (CBWFQ) queues.

2. Ensure that the router places the guaranteed traffic from the sub-pool tunnel in the guaranteed bandwidth queue at the outbound interface of every tunnel hop, and that the router does not place any other traffic in this queue. To do this, mark the traffic entering the tunnel with a unique value in the MPLS EXP field. The router sends only the marked traffic into the guaranteed bandwidth queue.

3. Ensure that the router does not oversubscribe the queue and instead sends only the amount of traffic into the sub-pool tunnel that the guaranteed bandwidth queue can handle. To do this, limit the rate of the guaranteed traffic before it enters the sub-pool tunnel. The aggregate rate of all traffic entering the sub-pool tunnel is less than or equal to the bandwidth capacity of the sub-pool tunnel. For delay or jitter guarantees, excess traffic is dropped. For bandwidth guarantees, excess traffic can be marked differently for preferential discard.

4. Ensure that the amount of traffic entering the guaranteed bandwidth queue is limited to an appropriate percentage of the total bandwidth of the corresponding outbound link. The exact percentage to use depends on several factors that can contribute to accumulated delay in your network: your QoS performance objective, the total number of tunnel hops, the number of links folded in along the tunnel path, the burstiness of the input traffic and so on. To do this, set the sub-pool bandwidth of each outbound link to the appropriate percentage of the total link bandwidth by adjusting the sub-pool kbps parameter of the ip rsvp bandwidth command.

Providing Differentiated Service Using DS-TE Global Pool Tunnels

To provide differentiated service using DS-TE global pool tunnels, do the following:

1. Select a separate queue for each traffic class.

2. Mark each class of traffic using a unique value in the MPLS EXP field.

3. Ensure that packets marked for a specific traffic class are placed in the queue for that class. The tunnel bandwidth is set based on the expected aggregate traffic across all classes of service.

To control the amount of DiffServ tunnel traffic you intend to support on a given link, adjust the size of the global pool on that link.

Providing Strict Guarantees and Differentiated Service in the Same Network

Because DS-TE allows simultaneous constraint-based routing of sub-pool and global pool tunnels, you can provide strict guarantees and differentiated services (DiffServ) simultaneously in a given network.

Verifying and Monitoring DS-TE Configurations

To verify and monitor DS-TE configurations, enter any of the following commands in privileged EXEC mode:

Command
Purpose

Router# show running-config

Displays the complete DS-TE configuration.

Router# show interfaces tunnel number [accounting]

Displays tunnel interface information for the tunnel interface you specify.

number is the port line number.

(Optional) accounting displays the number of packets of each protocol type that has been sent through the interface.

Router# show ip ospf [process-id]

Displays general information about all OSPF routing processes or about only the routing process you specify.

(Optional) process-id is the process ID. When specified, information displays for only the specified routing process.

Router# show ip route [address [mask] [longer-prefixes]] | [protocol [process-id]]

Displays the current state of the routing table.

Router# show ip rsvp host {host {receivers | senders} | installed | interface | neighbor | request | reservation | sender}

Displays Resource Reservation Protocol (RSVP) terminal point information for receivers or senders, including RSVP installed reservations, interface information and neighbor information.

request displays RSVP reservations upstream information.

reservation displays RSVP reservation requests from downstream.

sender displays RSVP PATH state information.

Router# show ip rsvp interface [type number]

Displays RSVP-related interface information.

Use this command to show the current allocation budget and the maximum allocatable bandwidth.

(Optional) type number is the type and number of an interface (for example, serial 1/0/0).

Router# show mpls traffic-eng autoroute

Displays tunnels that are announced to Interior Gateway Protocol (IGP), including interface, destination, and bandwidth. This command displays which tunnels are currently being used by the IGP in its enhanced shortest path first (SPF) calculation (tunnels that are up and have autoroute configured).

Router# show mpls traffic-eng fast-reroute database

Displays the contents of the Fast Reroute database.

Router# show mpls traffic-eng fast-reroute log reroutes

Displays the contents of the Fast Reroute event log.

Router# show mpls traffic-eng link-management admission-control [interface name]

Displays the tunnels that have been admitted locally and their parameters such as priority, bandwidth, incoming and outgoing interface, and state.

(Optional) interface name indicates to display only those tunnels that are admitted on the interface specified by name (for example, serial 1/0/0).

Router# show mpls traffic-eng link-management advertisements

Displays local link information currently being flooded by MPLS traffic engineering link management into the global traffic engineering topology.

Router# show mpls traffic-eng link-management bandwidth-allocation [interface name]

Displays current local link information.

(Optional) interface name indicates to display only those tunnels that are admitted on the interface specified by name (for example, serial 1/0/0).

Router# show mpls traffic-eng link-management igp-neighbors [{igp-id {isis isis-address | ospf ospf-id} | ip A.B.C.D}]

Displays Interior Gateway Protocol (IGP) neighbors.

Router# show mpls traffic-eng link-management interfaces [interface]

Displays per-interface resource and configuration information.

(Optional) interface indicates to display information for the specified interface.

Router# show mpls traffic-eng link-management summary [interface name]

Displays summary of link management information.

(Optional) interface name indicates to display information for the specified interface.

Router# show mpls traffic-eng topology [{A.B.C.D | igp-id {isis nsapaddr | ospf A.B.C.D}] [brief]

Displays the MPLS traffic engineering global topology as currently known at this node.

You can specify the node by IP address (router identifier to interface address), IGP router identifier (igp-id), router identification (nsapaddr) if using IS-IS, and router identifier (A.B.C.D) if using OSPF.

(Optional) brief indicates to display a brief form of the output that provides a less detailed version of the topology.

Router# show mpls traffic-eng tunnels

Displays information about tunnels.


For more information about these commands, see the MPLS Traffic Engineering—DiffServ Aware, Release 12.2(14)S feature module.

Configuration Examples for DS-TE

This section provides the following example configurations:

Configuration Examples for Configuring the Tunnel Head Router

Configuration Examples for Configuring DS-TE on the Midpoint Routers

Configuration Examples for Configuring the Tail-End Router

Configuration Examples for Configuring Guaranteed Bandwidth Service

Configuration Examples for Configuring the Tunnel Head Router

This section provides the following examples of how to activate DS-TE on the tunnel head router.

Configuration Example for Configuring DS-TE on the Tunnel Head Router

Configuration Example for Configuring DS-TE on the Tunnel Head Physical Interface

Configuration Example for Configuring DS-TE on the Tunnel Interface

Configuration Example for Configuring DS-TE on the Tunnel Head Router

Example 20-4 activates DS-TE on the router at the head of the tunnel. This DS-TE configuration uses the OSPF routing protocol and configures the loopback0 virtual interface.

Example 20-4 Configuring DS-TE on the Tunnel Head Router

router-1(config)# mpls traffic-eng tunnels
router-1(config)# router ospf 100
router-1(config-router)# redistribute connected
router-1(config-router)# network 10.1.1.0 0.0.09.255 area 0
router-1(config-router)# network 10.20.1.1 0.0.0.0 area 0
router-1(config-router)# mpls traffic-eng area 0
router-1(config-router)# mpls traffic-eng router-id loopback0
router-1(config-router)# exit
router-1(config)# interface loopback0
router-1(config-if)# ip address 10.22.1.1 255.255.255.255
router-1(config-if)# no ip directed-broadcast
router-1(config-if)# exit

Configuration Example for Configuring DS-TE on the Tunnel Head Physical Interface

Example 20-5 activates DS-TE on the egress physical interface POS 2/0/0. This physical interface is configured on the tunnel head router.

Example 20-5 Configuring DS-TE on the Tunnel Head Physical Interface

router-1(config)# interface POS2/0/0
router-1(config-if)# ip address 10.1.1.1 255.255.255.0
router-1(config-if)# mpls traffic-eng tunnels
router-1(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000
router-1(config-if)# exit

Configuration Example for Configuring DS-TE on the Tunnel Interface

Example 20-6 activates DS-TE on the egress Tunnel1 interface. This tunnel interface is configured on the tunnel head router.

Example 20-6 Configuring DS-TE on the Tunnel Interface

router-1(config)# interface Tunnel1
router-1(config-if)# bandwidth 110000
router-1(config-if)# ip unnumbered loopback0
router-1(config-if)# tunnel destination 10.24.1.1
router-1(config-if)# tunnel mode mpls traffic-eng
router-1(config-if)# tunnel mpls traffic-eng priority 0 0
router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 320000
router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic
router-1(config-if)# exit

Configuration Examples for Configuring DS-TE on the Midpoint Routers

This section provides the following examples of how to configure DS-TE on the midpoint routers:

Configuration Example for Configuring DS-TE on the Midpoint Router

Configuration Example for Configuring DS-TE on the Midpoint Network Interfaces


Note Do not configure tunnel interfaces on the midpoint routers.


Configuration Example for Configuring DS-TE on the Midpoint Router

Example 20-7 globally activates DS-TE on the midpoint router. This configuration uses the IS-IS routing protocol and configures the loopback0 virtual interface.

Example 20-7 Configuring DS-TE on the Midpoint Router

router-2(config)# mpls traffic-eng tunnels
router-2(config)# router isis
router-2(config-router)# net 49.0000.1000.0000.0012.00 
router-2(config-router)# metric-style wide 
router-2(config-router)# is-type level-1 
router-2(config-router)# mpls traffic-eng level-1 
router-2(config-router)# passive-interface loopback0 
router-2(config-router)# mpls traffic-eng router-id loopback0
router-2(config-router)# exit
router-2(config)# interface loopback0
router-2(config-if)# ip address 10.25.1.1 255.255.255.255
router-2(config-if)# no ip directed-broadcast
router-2(config-if)# exit

Configuration Example for Configuring DS-TE on the Midpoint Network Interfaces

Example 20-8 activates DS-TE on the physical network interfaces POS 4/0 and POS 4/1 of the midpoint router. The example uses the IS-IS routing protocol.

Example 20-8 Configuring DS-TE on the Midpoint Network Interfaces

router-2(config)# interface POS4/0
router-2(config-if)# ip address 10.11.1.2 255.255.255.0
router-2(config-if)# mpls traffic-eng tunnels
router-2(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000
router-2(config-if)# ip router isis
router-2(config-if)# interface POS4/1
router-2(config-if)# ip address 10.12.1.2 255.255.255.0
router-2(config-if)# mpls traffic-eng tunnels
router-2(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000
router-1(config-if)# ip router isis
router-1(config-if)# exit

Configuration Examples for Configuring the Tail-End Router

This section provides the following examples of how to configure DS-TE on the tail-end router:

Configuration Example for Configuring DS-TE on the Tail-End Router

Configuration Example for Configuring DS-TE on the Tail-End Physical Interfaces


Note Do not configure tunnel interfaces on the tail-end router.


Configuration Example for Configuring DS-TE on the Tail-End Router

Example 20-9 activates DS-TE globally on the tail-end router. This example configures the IS-IS routing protocol and the loopback0 virtual interface.

Example 20-9 Configuring DS-TE on the Tail-End Router

router-3(config)# mpls traffic-eng tunnels
router-3(config)# router isis
router-3(config-router)# net 49.0000.1000.0000.0013.00 
router-3(config-router)# metric-style wide 
router-3(config-router)# is-type level-1 
router-3(config-router)# mpls traffic-eng level-1 
router-3(config-router)# passive-interface loopback0
router-3(config-router)# mpls traffic-eng router-id loopback0
router-3(config-router)# exit
router-3(config)# interface loopback0
router-3(config-if)# ip address 10.24.1.1 255.255.255.255
router-3(config-if)# no ip directed-broadcast
router-3(config-if)# ip router isis
router-3(config-if)# exit

Configuration Example for Configuring DS-TE on the Tail-End Physical Interfaces

Example 20-10 activates DS-TE on the physical interface POS 4/0 of the tail-end router. This example configuration uses the IS-IS routing protocol.

Example 20-10 Configuring DS-TE on the Tail-End Physical Interface

router-1(config)# interface POS4/0
router-1(config-if)# ip address 10.12.1.3 255.255.255.0
router-1(config-if)# mpls traffic-eng tunnels
router-1(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000
router-1(config-if)# ip router isis
router-1(config-if)# exit

Configuration Examples for Configuring Guaranteed Bandwidth Service

For examples of guaranteed bandwidth configuration, see the MPLS Traffic Engineering—DiffServ Aware, Release 12.2(14)S feature module.

Per VRF AAA

The per VRF AAA feature allows the Cisco 10000 series router to communicate directly with the customer RADIUS server without having to go through a RADIUS proxy. Using the per VRF AAA feature, you can partition authentication, authorization, and accounting (AAA) services based on a virtual routing and forwarding (VRF) instance.

The Cisco 10000 series router supports the per VRF AAA feature in the following deployment models:

Managed L2TP Network Server

PPP Terminated Aggregation (PTA) to VRF

Remote Access (RA) to MPLS VPN

To support the per VRF AAA feature, AAA must be VRF aware. Define operational parameters for each VRF and secure them to the VRF partitions, using a virtual template interface. For more information about setting AAA parameters, see the "Configuring RADIUS Attribute Accept or Reject Lists" section on page 6-36.

For more information about the Per VRF AAA feature, see the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.

Related Documentation

This section provides hyperlinks to additional Cisco documentation for the features discussed in this chapter. To display the documentation, click the document title or a section of the document highlighted in blue. When appropriate, paths to applicable sections are listed below the documentation title.

Feature
Related Documentation

Class maps

Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2

Part 8: Modular Quality of Service Command Line Interface > Configuring the Modular Quality of Service Command Line Interface > Modular QoS CLI Configuration Task List > Creating a Traffic Class

DiffServ-Traffic Engineering (DS-TE)

MPLS Traffic Engineering—DiffServ Aware, Release 12.2(14)S feature module

MPLS

Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS Configuration Guide

Configuring Remote Access to MPLS VPN

Multiprotocol Label Switching on Cisco Routers, Release 12.1(3)T feature module

MPLS Class of Service manual

MPLS CoS Multi-VC Mode

MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(2)T feature module

MPLS Label Distribution Protocol, Release 12.1(8a)E feature module

Multiprotocol Label Switching on Cisco Routers, Release 12.1(3)T feature module

MPLS Class of Service Enhancements, Release 12.1(5)T feature module

MPLS Virtual Private Networks (VPNs), Release 12.0(22)S feature module

Quality of Service Solutions Configuration Guide, Release 12.2

Policy maps

Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2

Part 8: Modular Quality of Service Command Line Interface > Configuring the Modular Quality of Service Command Line Interface > Modular QoS CLI Configuration Task List > Creating a Traffic Policy