FlexWAN and Enhanced FlexWAN Modules Installation and Configuration Guide

Configuring QoS on the FlexWAN and Enhanced FlexWAN Modules

This chapter describes how to configure Quality of Service (QoS) on the Cisco 7600 FlexWAN and Enhanced FlexWAN modules.

Note Cisco IOS Release 12.2SRA and later releases do not support the FlexWAN module or Supervisor Engine 2. These releases support the Enhanced FlexWAN module and the Sup720 and Sup32. In addition, note that Cisco IOS Release 12.2SRB introduced support for the Route Switch Processor 720 (RSP720).

This chapter contains the following sections:

•Understanding QoS on FlexWAN and Enhanced FlexWAN

•IPv6 Hop-by-Hop Rate Limiter

•Classification

•Policing

•Configuring Priority Percent on a Policy- Map

•Congestion Management

•Congestion Avoidance

•Traffic Shaping

•Layer 2 QoS Applications

•Configuring QoS on Bridged Interfaces

•Understanding MPLS QoS

•Understanding MPLS QoS

•Using MPLS QoS with FlexWAN and Enhanced FlexWAN Modules

•Configuring MPLS QoS

•Configuring MPLS VPN QoS

•Configuring QoS with Any Transport over MPLS

•DE/CLP and EXP Mapping on Frame Relay and ATM over MPLS VC

•HQoS for Ethernet over MPLS Virtual Circuits

Understanding QoS on FlexWAN and Enhanced FlexWAN

Each FlexWAN and Enhanced FlexWAN module has both ingress and egress QoS capability.

Ingress QoS Capability

Because the FlexWAN and Enhanced FlexWAN modules provide for both policing and marking in the FlexWAN module itself, packets that are received through a FlexWAN port bypass the QoS functionality of the policy feature card (PFC). As a result, the QoS functionality of the PFC is not required. Policing and marking on the FlexWAN is configured by means of the Modular QoS command-line interface.

QoS features are performed by the CPUs on the FlexWAN and Enhanced FlexWAN modules; enabling more complex QoS features may affect port adapter performance.

The FlexWAN and Enhanced FlexWAN modules support the following QoS implementations on ingress ports:

•Classification

•Policing

•Marking

•CBWFQ

•Low latency queuing (LLQ)

•WRED

•Traffic shaping

•Percentage-based policing

Egress QoS Capability

The outbound QoS capabilities of the FlexWAN module include policing, marking, Class-Based Weighted Fair Queuing (CBWFQ), Weighted Random Early Detection (WRED), and traffic shaping. All features are configured using the Modular QoS command-line interface. As the features are implemented in Cisco IOS software, there are few limits on the complexity of the QoS configuration. However, as the complexity increases, the probability of a noticeable performance impact also increases.

The FlexWAN and Enhanced FlexWAN modules support the following QoS implementations on egress ports:

•Classification

•Policing

•Marking

•CBWFQ

•Low latency queuing (LLQ)

•WRED

•Traffic shaping

•Link fragmentation and interleaving (LFI)

Note Distributed Class-Based Weighted Fair Queueing (CBWFQ), Low Latency Queueing (LLQ), and Distributed Weighted Random Early Detection (dWRED) are also supported when present in a child policy that has shaping in the parent.

Note You configure FlexWAN and Enhanced FlexWAN QoS using a subset of the Modular QoS command-line interface (MQC). For information on MQC, refer to the Modular Quality of Service Command-Line Interface Overview at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5/mqc/ mcli.htm

IPv6 Hop-by-Hop Rate Limiter

The IPv6 Hop-by-Hop (HBH) extension header is part of the original specification of the IPv6 protocol (RFC 2460). It is identified by the next header field being 0, and when present, this extension header must always be the first extension header (EH) to follow the main header. Because a node must process any received packet that has an HBH extension header, forwarding of packets containing the HBH header can represent or be used as a security threat.

The IPv6 Hop- by- Hop (IPv6 HBH) Rate Limiter feature provides protection from denial of service (DoS) attacks by allowing you to rate limit IPv6 HBH packets.

To connect to a specific line card to execute the test platform police ipv6 set command, test platform police ipv6 get command or test platform police ipv6 disable command, use the attach command in privileged EXEC mode. You can then set the IPv6 internal police rate by using the test platform police set command in privileged EXEC mode from the line card console.

Restrictions and Usage Guidelines

When rate limiting IPv6 HBH packets on the FlexWAN card, follow these restrictions and usage guidelines:

•Supported on the following supervisor engines:

–Route Switching Processor 720-1GE

–Route Switching Processor 720-10GE

–Supervisor Engine 32

–Supervisor Engine 720

•Setting the police rate to 0 drops all the IPv6 HBH packets.

•After setting the police rate, the setting remains on the line card even if the line card is moved to another chassis running Cisco IOS Release 12.2(33)SRD3 or later.

•IPv6 packets with HBH and EH bypasses other QoS packets configured on the FlexWAN Card.

•You can set a separate police rate for each bay of the enhanced FlexWAN module.

SUMMARY STEPS

1. attach module-number bay-number

2. enable

3. test platform police ipv6 get

4. test platform police ipv6 set rate <rate in pps>

5. test platform police ipv6 disable

DETAILED STEPS

FlexWAN-ENH-9/0# enable

Example

The following sample configuration shows how to set the IPv6 internal police rate.

FLEXWAN-ENH-2/0#test platform ?

atom PLATFORM specific atom test commands

debugger Debugger utilities

fwd-idx Test the Forwarding Index Mangager

hardware Test hardware platform information

police IPv6 Aggregate Policer

software Test platform software information

FLEXWAN-ENH-2/0#test platform pol

FLEXWAN-ENH-2/0#test platform police ?

ipv6 IPv6 packet with HBH header

FLEXWAN-ENH-2/0#test platform police ip

FLEXWAN-ENH-2/0#test platform police ipv6 ?

get Get IPv6 policer rate

set Set IPv6 Policer rate

disable Disable IPv6 Policer 

<cr>

FLEXWAN-ENH-2/0#test platform police ipv6

IPv6 HBH packet policer rate = 2000 pps, Rate in rommon = 2000 pps

FLEXWAN-ENH-2/0#test platform police ipv6 get

IPv6 HBH packet policer rate = 2000 pps, Rate in rommon = 2000 pps

FLEXWAN-ENH-2/0#test platform police ipv6 set

% Incomplete command.

FLEXWAN-ENH-2/0#test platform police ipv6 set ?

<0-25600> IPv6 HBH policer rate in pps

FLEXWAN-ENH-2/0#test platform police ipv6 set 0

Dropping off the IPv6 HBH Packets

IPv6 HBH packet policer rate = 0 pps

FLEXWAN-ENH-2/0#test platform police ipv6 set 1000

IPv6 HBH packet policer rate = 1000 pps

FLEXWAN-ENH-2/0#test platform police ipv6 get

IPv6 HBH packet policer rate = 1000 pps, Rate in rommon = 1000 pps

FLEXWAN-ENH-2/0#test platform police ipv6 set

FLEXWAN-ENH-2/0#test platform police ipv6 set ?

<0-25600> IPv6 HBH policer rate in pps

FLEXWAN-ENH-2/0#test platform police ipv6 set 25600

IPv6 HBH packet policer rate = 25600 pps

FLEXWAN-ENH-2/0#test platform police ipv6 set 25601

^

% Invalid input detected at '^' marker.

FLEXWAN-ENH-2/0#test platform police ipv6 set 1000

IPv6 HBH packet policer rate = 1000 pps

FLEXWAN-ENH-2/0#

FLEXWAN-ENH-2/0#test platform police ipv6 get

IPv6 HBH packet policer rate = 1000 pps, Rate in rommon = 1000 pps

FLEXWAN-ENH-2/0#sho

FLEXWAN-ENH-2/0#show pl

FLEXWAN-ENH-2/0#show platform so

FLEXWAN-ENH-2/0#show platform software ip

FLEXWAN-ENH-2/0#show platform software ipv6-policer

IPv6 HBH packet policer rate = 1000 pps

Rate in rommon = 1000 pps

Packets dropped = 2196472, Packets punted to RP = 525811

To disable the IPv6 internal policer:

FLEXWAN-ENH-2/0# test platform police ipv6 disable

FLEXWAN-ENH-2/0# test platform police ipv6 get 

IPv6 with HBH header is not policed.

FLEXWAN-ENH-2/0#

FLEXWAN-ENH-2/0#

Terminate IPC console session? [confirm]

Left#

Left#hw-module module 2 reset

Proceed with reload of module?[confirm]

% reset issued for module 2

Left#

Left#att 2

Entering CONSOLE for slot 2

Type "^C^C^C" to end this session

FLEXWAN-ENH-2/0>

FLEXWAN-ENH-2/0>

FLEXWAN-ENH-2/0>en

FLEXWAN-ENH-2/0#sh platform software ipv6-policer

IPv6 HBH packet policer rate = 1000 pps

Rate in rommon = 1000 pps

Packets dropped = 297850, Packets punted to RP = 37424

FLEXWAN-ENH-2/0#

On fresh bootup default policer is stored in Rommon too.

SIP-200-6#show platform software ipv6-policer

IPv6 HBH packet policer rate = 1000 pps

Rate in rommon = 1000 pps

Packets dropped = 0, Packets punted to RP = 0

Use the show platform software ipv6-policer command to display the IPv6 packet policer and rommon rates in packets per second.

FlexWAN-ENH-3/0#show platform software ipv6-policer

IPv6 HBH packet policer rate = 1 pps

Rate in rommon = 1 pps

Packets dropped = 0, Packets punted to RP = 12

FlexWAN-ENH-3/0#

Classification

Classification entails using a traffic descriptor to categorize a packet within a specific group to define that packet and make it accessible for QoS handling on the network. Using packet classification, you can partition network traffic into multiple priority levels or classes of service.

Configuring Classification

This section contains information for configuring classification for the FlexWAN and Enhanced FlexWAN QoS features.

The FlexWAN and Enhanced FlexWAN modules can classify traffic based on the following criteria:

•Differentiated Services Code Point (DSCP) (6-bits, defined in TOS byte—up to 64 values can be specified)

•IP Precedence (3-bits defined in the TOS byte in the IP header—up to 8 different precedence values can be specified)

Note Use the match precedence command for IPv6 classification.

•VLAN ID (Ethernet packets with specific VLAN IDs or VLAN IDs in a range)

•VLAN ID inner (VLAN ID in the 802.1Q header of bridged Ethernet packets)

•FR DLCI (Frame Relay DLCI value, which is 10 bits)

•ATM CLP bit (Cell Loss Priority bit in one or more of the ATM cells)

•Protocol (various protocols supported by the NBAR feature)

•MAC-layer address

•Frame Relay DE bit

•CoS bits (3-bit class of service field in the 802.1Q header)

•CoS bits inner (CoS bits in the 802.1Q header of bridged Ethernet packets)

•BGP index

•Packet length (match packets of a given size within a range)

•Access control list (ACL)

•EXP (3-bits used for classification in MPLS environment)

Use the class-map commands in global configuration mode to specify the name of the class map and define the class matching criteria.

Restrictions and Usage Guidelines

The classification restrictions and usage guidelines are as follows:

•Traffic types —The classification information in this section is for IP traffic. For information about configuring classification for MPLS, EoMPLS, and AToM traffic, refer to the "Configuring Multiprotocol Label Switching on FlexWAN and Enhanced FlexWAN Modules" section.

•Traffic classes —You can configure up to 255 discrete traffic classes in a single policy map, one class for each IP DSCP value. In addition to the traffic classes you specify, the class-default class is predefined when you create the policy map. It is the class to which traffic is directed if that traffic does not satisfy the match criteria of other classes defined in the policy map.

Configuration Tasks

To configure classification, perform the following steps in global configuration mode on the MSFC:

This example shows how to configure a class map named ipp5, and enter a match statement for IP precedence 5:

Router(config)# class-map ipp5

Router(config-cmap)# match ip precedence 5

Router(config-cmap)# 

This example shows how to display class-map information for a specific class map using the show class-map command:

Router# show class-map ipp5

Class Map match-all ipp5 (id 1)

Match ip precedence 5

Policing

Policing rate limits a particular flow or group of flows using a token bucket policer. Packets not conforming to the user-specified rate and burst parameters are considered to be out-of-profile and are subject to either being dropped or marked down.

For more information, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt4/qcfpolsh.htm

The FlexWAN and Enhanced FlexWAN modules support percentage-based policing and priority percent on a policy map.

Additionally, you can mark packets by setting the following:

•ATM Cell Loss Priority (CLP) bit

•Frame Relay Discard Eligibility (DE) bit

•IP precedence value

•IP differentiated services code point (DSCP) value

•MPLS experimental (EXP) value

•CoS bits (3-bit class of service field in the 802.1Q header)

Configuring Policing

Use the police command to enable policing on a class of traffic. The police command imposes a maximum rate on a particular class of traffic and provides the following actions if the rate is exceeded:

•Drop

•Transmit

•Transmit with re-marking

Note The PFC normally implements policing between ports in the router, however with FlexWAN and Enhanced FlexWAN modules, this feature is disabled for WAN ports. The FlexWAN and Enhanced FlexWAN modules handle policing because WAN packets generally have smaller headers than LAN packets, and the use of the PFC for policing in this manner would result in policing inaccuracies.

Restrictions and Usage Guidelines

The classification restrictions and usage guidelines are as follows:

•There are two forms of policers: single rate and dual rate. Single rate uses the committed information rate (CIR) to police traffic, while dual-rate uses a combination of CIR and peak information rate (PIR) to police traffic.

•With both forms of policers, there are three associated states of traffic: conform, exceed, and violate.

–Traffic falls into the conform state if the bits-per-second rate has not been exceeded.

–Traffic falls into the exceed state when the bits-per-second rate has been exceeded.

–Traffic falls into the violate state when the bits-per-second rate is greater than the maximum-burst-bytes rate.

For each of the above states, policing is accomplished through one of these actions: drop and transmit with re-marking or drop and transmit without re-marking.

For additional information, see Traffic Policing at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtpoli.htm

Configuration Tasks

To configure policing, perform the following steps in global configuration mode on the MSFC:

This example shows a traffic policing configuration with the average rate at 8000 bits per second, the normal burst size at 2000 bytes, and the excess burst size at 4000 bytes:

Router(config)# class-map acgroup2

Router(config-cmap)# match access-group 2

Router(config-cmap)# exit

Router(config)# policy-map police

Router(config-pmap)# class acgroup2

Router(config-pmap-c)# police 8000 2000 4000 conform-action transmit exceed-action 
set-qos-transmit 4 violate-action drop

Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)# interface fastethernet 0/0

Router(config-if)# service-policy input police

Use the following commands to verify policing:

This example shows how to display policing statistics using the show policy-map interface command in the EXEC mode.

Router# show policy-map interface

POS6/1/0

service-policy output: x

class-map: a (match-all)

0 packets, 0 bytes

5 minute rate 0 bps

match: ip precedence 0

police:

1000000 bps, 10000 limit, 10000 extended limit

conformed 0 packets, 0 bytes; action: transmit

exceeded 0 packets, 0 bytes; action: drop

        conformed 0 bps, exceed 0 bps, violate 0 bps

Configuring Priority Percent on a Policy- Map

To configure priority percent on a policy map, follow these commands:

Note Priority percent command is supported for both dLFIoFR and dLFIoATM on FlexWan and Enhanced FlexWan Modules.

The following example shows a sample configuration of the priority percent on a policy-map:

class-map voip

match ip precedence 3

policy-map llq

class voip

priority percent <1-100>

Marking

Associating a packet with an IP Precedence or IP DSCP marking allows users to classify traffic based on IP Precedence and IP DSCP value, depending on which value is marked. These markings can be used to identify traffic within the network, and other interfaces can match traffic based on the IP Precedence or DSCP markings.

Configuring Marking

Marking sets various attributes of packets belonging to a particular class. You can mark IP and MPLS packets with the FlexWAN and Enhanced FlexWAN modules.

In Cisco IOS Release 12.2SR and later releases, you can also mark bridged Ethernet packets with the Enhanced FlexWAN module. See "Configuring QoS on Bridged Interfaces" section for more information.

Note The FlexWAN and Enhanced FlexWAN modules always trust ToS. To change the ingress ToS, use marking.

Restrictions and Usage Guidelines

The marking restrictions and usage guidelines are as follows:

•You typically perform marking with the set command. The FlexWAN and Enhanced FlexWAN modules support the following forms of the set command:

–Differentiated Services Code Point (DSCP) (6-bits, defined in the TOS byte—up to 64 values can be specified)

–IP Precedence (3-bits defined in the TOS byte in the IP header—up to 8 different precedence values can be specified)

–CoS bits (3-bit class of service field in the 802.1Q header)

Note The Enhanced FlexWAN module (beginning in Cisco IOS Release 12.2SR) also supports the marking of inner COS bits (for bridged Ethernet packets).

–EXP (3-bits used for classification in MPLS environment)

Configuration Tasks

To configure marking, perform the following steps in global configuration mode on the MSFC:

This examples shows the creation of a service policy called policy1. This service policy is associated to a previously defined classification policy through the use of the class command. This example assumes that a classification policy called class1 was previously configured.

Router(config)# policy-map policy1

Router(config-pmap)# class class1

Router(config-pmap-c)# set ip precedence 1 

Use the following commands to verify marking:

Congestion Management

Congestion management features allow you to control congestion by determining the order in which packets are sent out an interface based on priorities assigned to those packets. Congestion management entails the creation of queues, assignment of packets to those queues based on the classification of the packets, and scheduling of the packets in a queue for transmission. The congestion management QoS feature offers four types of queueing protocols, each of which allows you to specify creation of a different number of queues, affording greater or lesser degrees of differentiation of traffic, and to specify the order in which that traffic is sent.

For more information, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at:

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/fqos_c.html

The following sections describe congestion management on the FlexWAN and Enhanced FlexWAN modules:

•Configuring Class-Based Weighted Fair Queuing

•Configuring CBWFQ for MLPPP Links

•Flow-Based Weighted Fair Queuing (WFQ)

•Configuring Low Latency Queuing

•Configurable LLQ Burst Size

•Configuring LLQ for MLPPP Links

•Distribution of Remaining Bandwidth

Configuring Class-Based Weighted Fair Queuing

This section contains information for configuring Class-Based Weighted Fair Queueing (CBWFQ). CBWFQ provides guaranteed bandwidth rate to a non-priority class. Under congestion conditions, the class receives the guaranteed bandwidth. To configure CBWFQ, use one of the three forms of the bandwidth command:

•bandwidth <x kbps>—Minimum bandwidth guarantee of x kbps

•bandwidth percent <x%>—Minimum bandwidth guarantee of x% of link bandwidth

•bandwidth remaining percent <x%>—Minimum bandwidth guarantee of x% of remaining bandwidth in the link or the percentage bandwidth sharing of unused bandwidth among classes with bandwidth and bandwidth remaining configured

Note Low Latency Queueing (LLQ) provides guaranteed bandwidth for the priority classes. The sum of all bandwidth on a link guaranteed by CBWFQ for non-priority classes and LLQ for priority classes cannot exceed 99% of the total available link bandwidth. For more information on LLQ, see the "Configuring Low Latency Queuing" section.

The FlexWAN and Enhanced FlexWAN modules also support distributed CBWFQ. For more information, see Distributed Class-Based Weighted Fair Queueing and Distributed Weighted Random Early Detection at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtcbwred.htm

Restrictions and Usage Guidelines

•FlexWAN and Enhanced FlexWAN modules support—Supports all forms of the bandwidth command except the bandwidth remaining ratio form.

•Physical interface—Configuring CBWFQ on a physical interface is only possible if the interface is in the default queuing mode. Serial interfaces at E1 (2.048 Mbps) and below use WFQ by default; other interfaces use FIFO by default. Enabling CBWFQ on a physical interface overrides the default interface queuing method. Enabling CBWFQ on an ATM PVC does not override the default queuing method.

•If you configure a class in a policy map to use WRED for packet drop instead of tail drop, you must ensure that WRED is not configured on the interface to which you intend to attach that service policy.

•Traffic shaping and policing are not currently supported with CBWFQ.

•CBWFQ is supported on variable bit rate (VBR) and available bit rate (ABR) ATM connections. It is not supported on unspecified bit rate (UBR) connections.

•Minimum bandwidth rate—On the FlexWAN and Enhanced FlexWAN modules, the minimum CBWFQ rate is the greater of (a) 1 Kbps or (b) 1% of the link rate or the hierarchical shape rate.

•Bandwidth allocation—When a link is not experiencing congested conditions, the unused (or excess) bandwidth is shared among all classes. The excess bandwidth available to a class is in proportion to its guaranteed bandwidth specified by the priority or bandwidth commands. For example, if one class is guaranteed 20% of the link and a second class is guaranteed 10% of the link, then the first class receives twice as much excess bandwidth as the second class.

•Using class-default—The default queuing for class-default class is weighted fair queuing; at least 1% of the link bandwidth is always reserved for the default queuing. More bandwidth can be reserved using the bandwidth command.

Configuring a Service Policy in the Policy Map

To configure CBWFQ, use the Modular QoS command-line interface. Define the class of traffic with the class-map command, create a policy map that contains the bandwidth command, and apply the policy to the appropriate interface with the service-policy command.

To configure the class of traffic, see the "Configuring Classification" section. To configure a policy with CBWFQ and to assign the policy to an interface, perform the following tasks in global configuration mode:

Router(config)# policy-map policy-map

Router(config-pmap)# class class-name

This example shows a service policy called policy1 that specifies the amount of bandwidth to allocate for traffic classes 1 and 2:

Router(config)# class-map class1 
Router(config-cmap)# match ip dscp 30

Router(config-cmap)# exit

Router(config)# class-map class2 
Router(config-cmap)# match ip dscp 10

Router(config-cmap)# exit

Router(config)# policy-map policy1

Router(config-pmap)# class class1

Router(config-pmap-c)# bandwidth 30000 

Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)# class class2

Router(config-pmap-c)# bandwidth 20000 

Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)#

Router(config)# interface pos 2/0/0 
Router(config-if)# service-policy output policy1 

Router(config-if)# exit

Use the following commands to verify CBWFQ:

Note The counters displayed after issuing the show policy-map interface command are updated only if congestion is present on the interface.

This example shows the information displayed when you enter the show policy-map interface command:

Router1-PE# show policy-map interface

POS6/2/0

service-policy output: 

queue stats for all priority classes:

queue size 0, queue limit 32655

packets output 0, packet drops 0

tail/random drops 0, no buffer drops 0, other drops 0

class-map:dscp0 (match-all)

0 packets, 0 bytes

30 second offered rate 0 bps, drop rate 0 bps

match:ip dscp 0

queue size 0, queue limit 610

packets output 0, packet drops 0

tail/random drops 0, no buffer drops 0, other drops 0

shape:cir 2440000,  Bc 9760,  Be 9760

(shape parameter is rounded to 2439000 due to granularity)

output bytes 0, shape rate 0 bps

    class-map:dscp1 (match-any)

      0 packets, 0 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      match:ip dscp 1

        0 packets, 0 bytes

        30 second rate 0 bps

      queue size 0, queue limit 100000

      packets output 0, packet drops 0

      tail/random drops 0, no buffer drops 0, other drops 0

      bandwidth:kbps 400000, weight 64

      (bandwidth parameter is rounded to 397592 kbps due to granularity)

    class-map:dscp2 (match-all)

      0 packets, 0 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      match:ip dscp 2

      Priority:21% (130620 kbps), burst bytes 3265500, b/w exceed drops:0

      (Priority parameter is rounded to 129278 kbps due to granularity)

    class-map:class-default (match-any)

      0 packets, 0 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      match:any

        0 packets, 0 bytes

        30 second rate 0 bps

      queue size 0, queue limit 11422

      packets output 0, packet drops 0

      tail/random drops 0, no buffer drops 0, other drops 0

Configuring CBWFQ for MLPPP Links

Multilink Point-to-Point Protocol (MLPPP) allows multiple T1/E1 links to be bundled together to offer bandwidth greater than multiple T1s/E1s but less than a T3/E3. MLPPP with QoS supports CBWFQ, enabling MLPPP to carry voice and data on the same MLPPP bundle.

For information on configuring CBWFQ on MLPPP links, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/index.htm

Note The ppp multilink interleave and ppp multilink fragment-delay commands are required on a multilink interface only when Link Fragmentation and Interleaving (LFI) is also required.

Flow-Based Weighted Fair Queuing (WFQ)

Flow-based weighted fair queuing (WFQ) tries to ensure that reserved flows receive enough bandwidth and bounds latency to meet their minimum needs in the event of congestion. With standard WFQ, packets are queued by flow. Packets with the same source IP address, destination IP address, source Transmission Control Protocol (TCP) or UDP port, destination TCP or UDP port belong to the same flow.

For configuration information, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfwfq_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Configuring Low Latency Queuing

LLQ lets you specify low-latency behavior for a traffic class. LLQ allows delay-sensitive data to be given preferential treatment. You can give one or more classes priority status. You configure LLQ with the priority command.

The priority command configures guaranteed bandwidth to a priority class under worst-case congestion scenarios. It does not limit the bandwidth to the configured rate if the priority class is over subscribed. Typically, you would use the priority command in conjunction with an admission control mechanism that controls the amount of load offered to the priority class to avoid starvation of other classes.

Note CBWFQ and LLQ both provide guaranteed bandwidth for their respective classes. The sum of all bandwidth on a link guaranteed by CBWFQ for non-priority classes and LLQ for priority classes cannot exceed 99% of the total available link bandwidth. For more information on CBWFQ, see the "Configuring Class-Based Weighted Fair Queuing" section.

Restrictions and Usage Guidelines

The LLQ restrictions and usage guidelines are as follows:

•FlexWAN and Enhanced FlexWAN modules priority command support—All forms of the priority command are supported.

•Bandwidth granularity—On the FlexWAN and Enhanced FlexWAN modules, there is no restriction on the granularity of the priority rate.

•Minimum priority rate—The priority command has a minimum rate of 1 Kbps or 1% of the bandwidth.

•Voice over IP (VoIP)—LLQ supports Voice over IP (VoIP) on serial links and ATM permanent virtual circuits (PVCs). It does not support VoIP over Frame Relay links.

•Priority matching—If you use access control lists to configure matching port numbers, this feature provides priority matching for all port numbers, both odd and even numbers. Because voice typically exists on even port numbers, and control packets are generated on odd port numbers, control packets are also given priority when using this feature.

On very slow links, giving priority to both voice and control packets may produce degraded voice quality. Therefore, if you are only assigning priority based on port numbers, you should use the ip rtp priority command instead of the priority command. (The ip rtp priority command provides priority only for even port numbers.)

Note Effective with Cisco IOS Release 15.0(1)S, the ip rtp priority command will not be available on Cisco IOS Software. Use the MQC equivalent ip rtp priority command in the Legacy QoS Command Deprecation feature document at: http://www.cisco.com/en/US/docs/ios/ios_xe/qos/configuration/guide/legacy_qos_cli_deprecation_xe.html

•Priority command restrictions—The random-detect command, queue-limit command, and bandwidth policy-map class configuration command cannot be used while the priority command is configured.

The priority command can be configured in multiple classes, but it should only be used for voice-like, constant bit rate (CBR) traffic.

•Bandwidth allocation—When a link is not under congested conditions, the unused (or excess) bandwidth is shared among all classes. The excess bandwidth available to a class is in proportion to its guaranteed bandwidth specified by the priority or bandwidth commands. For example, if one class is guaranteed 20% of the link and a second class is guaranteed 10% of the link, then the first class receives twice as much excess bandwidth as the second class.

•Bandwidth command restriction—You cannot configure the bandwidth command for a priority class.

Configuration Tasks

To configure LLQ, use the Modular QoS command-line interface. Define the class of traffic with the class-map command, create a policy map that contains the priority command, and apply the policy to the appropriate interface with the service-policy command.

To configure the class of traffic, see the "Configuring Classification" section. To configure a policy with LLQ and to assign the policy to an interface, perform the following tasks in global configuration mode:

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

Router(config-pmap-c)# priority bandwidth-kbps | 
percent % of available bandwidth 

This example shows how to configure a priority queue reserved for traffic with an IP DSCP value of 40:

Router(config)# class-map gold-data

Router(config-cmap)# match-any ip dscp 40

Router(config-cmap)# exit

Router(config)# class-map match bar

Router(config-cmap)# match-any ip dscp 8

Router(config-cmap)# exit

Router(config)#

In the example, a priority queue for the class gold-data is reserved with a guaranteed allowed bandwidth of 50 Mbps, and a bandwidth of 20 Mbps is configured for the class bar. The service-policy command attaches the policy map to interface pos 4/1.

Router(config)# policy-map policy1

Router(config-pmap)# class gold-data

Router(config-pmap-c)# priority 50000

Router(config-pmap)# class bar

Router(config-pmap-c)# bandwidth 20000

Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)# interface pos 4/1/1

Router(config-if)# service-policy output policy1

Router(config-if)# exit

Use the following command to verify LLQ:

Configurable LLQ Burst Size

Configurable LLQ Burst Size extends the functionality available with LLQ. This feature allows customers to specify the Committed Burst (Bc) size in LLQ and, therefore, configure the network to accommodate temporary bursts of traffic.

For information on configuring LLQ burst size, see the Configuring Burst Size in Low Latency Queueing at:

https://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/dtcfgbst.html

Configuring LLQ for MLPPP Links

MLPPP allows multiple T1/E1 links to be bundled together to offer bandwidth greater than multiple T1s/E1s but less than a T3/E3. MLPPP with QoS supports LLQ, enabling MLPPP to carry voice and data on the same MLPPP bundle.

For information on configuring LLQ on MLPPP links, see Configuring Distributed Low Latency Queueing and Other QoS Features in a Traffic Policy.

Note The ppp multilink interleave and ppp multilink fragment-delay commands are required on a multilink interface only when LFI is also required.

Distribution of Remaining Bandwidth

You can use MQC to specify how the remaining bandwidth is distributed among the output queues on a Cisco 7600 router interface or subinterface. Remaining bandwidth is the available bandwidth left on an interface or subinterface after all guaranteed traffic is accounted for. The amount of remaining bandwidth available for use is determined by the excess information rate (EIR) configured for the queue.

In MQC, the bandwidth remaining percent command allows you to configure the remaining bandwidth for output queues.

The following example shows how to use the bandwidth remaining percent command to distribute percentages of remaining bandwidth to various traffic classes in a policy map.

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# policy-map myPolicy

Router(config-pmap)# class class-default

Router(config-pmap-c)# bandwidth remaining percent 20

Router(config-pmap-c)# class prec1

Router(config-pmap-c)# bandwidth remaining percent 30

Router(config-pmap-c)# class prec2

Router(config-pmap-c)# bandwidth remaining percent 10

Router(config-pmap-c)# bandwidth percent 50

Router(config-pmap-c)# ^Z

Router#

20:44:36: %SYS-5-CONFIG_I: Configured from console by console 

Router# show policy-map myPolicy

  Policy Map myPolicy

    Class prec1

         bandwidth remaining percent 30

    Class prec2

         bandwidth percent 50

         bandwidth remaining percent 10

    Class class-default

         bandwidth remaining percent 20

Command Reference

To specify how the remaining bandwidth is distributed among the output queues on a Cisco 7600 series router interface or subinterface, use the MQC bandwidth remaining percent command in policy-map class configuration mode. To remove the percentage of remaining bandwidth specified for a traffic class, use the no form of this command.

•bandwidth remaining percent percentage

•no bandwidth remaining percent percentage

Syntax Description

Defaults

This command has no default behavior or values.

Command Modes

Modular QoS policy-map class configuration

Command History

Usage Guidelines

Use the MQC bandwidth remaining percent command to specify how the remaining bandwidth is distributed among the output queues on a Cisco 7600 series router interface or subinterface. Remaining bandwidth is the available bandwidth left on an interface or subinterface after all guaranteed traffic is accounted for.

The bandwidth remaining percent command allows you to configure the remaining bandwidth for output queues. The percentage parameter specified with the bandwidth remaining percent command is translated into an internal excess information rate (EIR) value between 0 and 255. The aggregate of all user-configured EIR bandwidth percentages cannot exceed 100 percent.

If the aggregate of all remaining bandwidth is less than 100 percent, the remainder is evenly split among user queues (including the default queue) that do not have a remaining bandwidth percentage configured. The minimum EIR value of each output queue is 1.

The EIR parameter for the network control queue is fixed at 128 and is not configurable.

If you have not configured a committed information rate (CIR) value for the default queue and it is the only user queue, the default queue receives half of the remaining bandwidth percentage of the network control queue.

Congestion Avoidance

Congestion avoidance techniques monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottlenecks. Congestion avoidance is achieved through packet dropping. Among the more commonly used congestion avoidance mechanisms is Random Early Detection (RED), which is optimum for high-speed transit networks. Cisco IOS QoS includes an implementation of RED that, when configured, controls when the router drops packets. If you do not configure Weighted Random Early Detection (WRED), the router uses the cruder default packet drop mechanism called tail drop.

For more information, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt3/qcfconav.htm

The following sections describe congestion avoidance on the FlexWAN and Enhanced FlexWAN modules:

•Configuring Weighted Random Early Detection

•Distributed WRED

•DiffServ-Compliant WRED

Configuring Weighted Random Early Detection

Weighted Random Early Detection (WRED) is a congestion avoidance mechanism that takes advantage of the congestion control mechanism of TCP. By selectively dropping packets based on IP precedence prior to periods of high congestion, WRED tells the packet source to decrease its transmission rate. Edge routers assign IP Precedence to packets as they enter the network. WRED is useful on any output interface where you expect to have congestion. However, WRED is usually used in the core routers of a network rather than at the edge. WRED uses these precedences to determine how it treats different types of traffic.

When a packet arrives, the average queue size is calculated and one of the following events occurs:

•If the average queue size is less than the minimum queue threshold, the arriving packet is queued.

•If the average queue size is between the minimum queue threshold for that type of traffic and the maximum threshold for the interface, the packet is either dropped or queued, depending on the packet drop probability for that type of traffic.

•If the average queue size is greater than the maximum threshold, the packet is dropped.

Restrictions and Usage Guidelines

The WRED restrictions and usage guidelines are as follows:

•The random-detect command is used to enable WRED on a class of traffic. The FlexWAN and Enhanced FlexWAN modules support all three forms of the command:

–random-detect precedence-based—Dropping based on IP Precedence bits

–random-detect dscp-based—Dropping based on DSCP bits

•The parameters that can be tuned on a per-precedence, DSCP, or discard class basis include minimum and maximum thresholds, mark probability, and weight. When the average queue size is between the minimum and maximum thresholds, the packets are subjected to random discard. The mark probability controls the probability of dropping the packet when the queue size reaches the maximum threshold, and the weight determines the time constant needed to compute the average queue size.

For more details on the queue calculations and how WRED works, refer to the section "About WRED" in the chapter "Congestion Avoidance Overview" in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at the following URL:

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/fqos_c.html

Configuration Tasks

To configure WRED, use the Modular QoS command-line interface.

1. Define the class of traffic with the class-map command.

2. Create a policy map that contains the random-detect command.

3. Apply the policy to the appropriate interface with the service-policy command.

To configure the class of traffic, see the "Configuring Classification" section.

To configure a policy with WRED and to assign the policy to an interface, perform the following steps in global configuration mode:

Configuration Example

This example shows how to configure WRED:

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# policy-map wred_test

Router(config-pmap)# class class-default

Router(config-pmap-c)# random-detect

Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)# interface pos 7/1/0

Router(config-if)# service-policy output wred_test

Router(config-if)# end

This example shows how to verify the configuration:

Router# show policy-map interface pos 7/1/0

 POS7/1/0 

  Service-policy output: wred_test

    Class-map: class-default (match-any)

      16634097 packets, 8217243918 bytes

      30 second offered rate 482198000 bps, drop rate 0 bps

      Match: any 

      queue size 0, queue limit 128

      packets output 16634097, packet drops 0

      tail/random drops 0, no buffer drops 0, other drops 0

      Random-detect:

        Exp-weight-constant: 3 (1/8)

        Mean queue depth: 0

        Class Random       Tail   Minimum   Maximum     Mark       Output

                drop       drop threshold threshold  probability  packets

        0     104806          0        32        64     1/10      3026812

        1     104569          0        36        64     1/10      3027050

        2     104732          0        40        64     1/10      3026884

        3     104169          0        44        64     1/10      3027449

        4     103047          0        48        64     1/10      3028569

        5     103156          0        52        64     1/10      3028460

        6          0          0        56        64     1/10            0

        7          0          0        60        64     1/10            0

Distributed WRED

Distributed WRED (dWRED) is useful on any output interface where you expect to have congestion. However, dWRED is usually used in the core routers of a network, rather than the edge. Edge routers assign IP precedences to packets as they enter the network. WRED uses these precedences to determine how to treat different types of traffic. For more information, see Distributed Class-Based Weighted Fair Queueing and Distributed Weighted Random Early Detection at:

http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/dtcbwred.html

DiffServ-Compliant WRED

DiffServ Compliant WRED extends the functionality of WRED to enable support for DiffServ and Assured Forwarding (AF) Per Hop Behavior (PHB). This feature enables customers to implement AF PHB by coloring packets according to DSCP values and then assigning preferential drop probabilities to those packets.

This feature can be used with IP packets only. It is not intended for use with Multiprotocol Label Switching (MPLS)-encapsulated packets. For configuration information, see Configuring Weighted Random Early Detection at:

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfwred_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Traffic Shaping

A shaper typically delays excess traffic using a buffer, or queueing mechanism, to hold packets and shape the flow when the data rate of the source is higher than expected.

For more information, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 at:

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/fqos_c.html

The following sections describe shaping on the FlexWAN and Enhanced FlexWAN modules:

•Configuring Traffic Shaping

•Configuring Hierarchical Traffic Shaping

•Configuring Queue Limit

Configuring Traffic Shaping

Traffic shaping allows us to impose a maximum rate for a particular class of traffic. The rationale for shaping is to smooth out bursty traffic into the network. It is accomplished by buffering. You perform traffic shaping with the shape command. These are the basic forms of the command:

•shape average—Bursty traffic is shaped on average to the maximum specified rate.

•shape peak—Bursty traffic is shaped to the maximum specified rate.

Restrictions and Usage Guidelines

The traffic shaping restrictions and usage guidelines are as follows:

•The minimum shaping rate is fixed by the command-line interface as 8,000 bps and is not dependent on the link rate.

•There is no minimum granularity on a shaper. The command-line interface allows a granularity up to 1 bps.

•A shaper value greater than link rate is allowed.

Configuration Tasks

Use MQC to configure traffic shaping. Create a class-map using the class-map command and a policy map using the policy-map command. Attach the class to the policy using the class command and then use the shape command to configure shaping for that class.

This example shows traffic shaping on a main interface; traffic leaving interface pos1/0/0 is shaped at the rate of 10 Mbps:

Router(config)# class-map class-interface-all

Router(config-cmap)# match any

Router(config-cmap)# exit

Router(config)# policy-map dts-interface-all-action

Router(config-pmap)# class class-interface-all

Router(config-pmap-c)# shape average 10000000

Router(config-pmap-c)# exit

Router(config)# interface pos1/0/0

Router(config-if)# service-policy output dts-interface-all-action

Use the following commands to verify traffic shaping:

Configuring Hierarchical Traffic Shaping

Hierarchical traffic shaping allows multiple classes of traffic to be shaped at a single rate. A hierarchical traffic shaping policy consists of a child policy that identifies one or more classes of traffic, and a parent policy that shapes the output of the traffic classes into a single shape rate. You can apply a nested policy to an interface or subinterface.

Restrictions and Usage Guidelines

The hierarchical traffic shaping restrictions and usage guidelines are as follows:

•Hierarchical traffic shaping is supported on both input and output policies.

•Hierarchical traffic shaping is supported on the interfaces, subinterfaces, and PVCs for the FlexWAN and Enhanced FlexWAN modules.

Configuration Tasks

To configure hierarchical traffic shaping, use the Modular QoS command-line interface to define the parent and child policies. For the child policy, define the classes of traffic with the class-map command and create a policy with the policy-map command. For the parent policy, create a policy with the policy-map command, apply the child policy to the default class with the service-policy command, and apply the parent policy to the appropriate interface with the service-policy command.

To configure the classes of traffic, see the "Configuring Classification" section. To configure a child and parent policies for hierarchical traffic shaping, perform the following tasks in global configuration mode:

Router(config-pmap)# class class-name

This example shows a nested traffic policy configuration where traffic matching the class called "voice" will be guaranteed 3,200 Kbps, or 10% of the parent_policy's shape average:

Router(config)# class-map match-all voice

Router(config-cmap)# match ip dscp 5

Router(config-cmap)# exit

Router(config)# policy-map child_policy

Router(config-pmap)# class voice

Router(config-pmap-c)# priority percent 10

Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)# policy-map parent_policy

Router(config-pmap)# class class-default

Router(config-pmap-c)# shape average 32000000 

Router(config-pmap-c)# service-policy child_policy

Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)# interface Serial6/1:1.1 point-to-point

Router(config-subif)# service-policy output parent_policy

Configuring Queue Limit

For the class-based traffic shaping and CBWFQ features, you can specify or modify the maximum number of packets the queue can hold for a class policy configured in a policy map using the queue-limit command from policy-map class configuration mode.

Restrictions and Usage Guidelines

The queue limit restrictions and usage guidelines are as follows:

•FlexWAN and Enhanced FlexWAN queue limit values—The default queue limit value is calculated as a function of line card type, buffers available, and the allocated CIR for that class. It is not chosen based on the bandwidth assigned to the traffic class or the amount of buffer memory. You can change the default queue limit to any value.

Configuration Tasks

To configure the queue limit, use the Modular QoS command-line interface. Define the class of traffic with the class-map command, create a policy-map that contains the queue-limit command, and apply the policy to the appropriate interface with the service-policy command.

To configure the class of traffic, see the "Configuring Classification" section. To configure a policy with the queue-limit command and assign the policy to an interface, perform the following tasks in global configuration mode:

Router(config-pmap)# class class-name

Router(config-if)# queue-limit number-of-packets

Layer 2 QoS Applications

This section describes the QoS features for Layer 2 operations. It contains the following sections:

•Configuring QoS for ATM VC Access Trunk Emulation

•Configuring ATM Cell Loss Priority Setting

For information about how to configure QoS for interfaces that support bridging, see the "Configuring QoS on Bridged Interfaces" section.

Configuring QoS for ATM VC Access Trunk Emulation

Ingress and Egress QoS

The ingress QoS features are as follows:

•Aggregated ingress policy based on the bridged VLAN

•Ingress policy per dot1q VLAN per VC

•Ingress policy based on CoS value of the dot1q header

Note ATM VC access trunk emulation works in Trust CoS mode. CoS values of the dot1q header are set as the CoS values for the bridged VLAN.

Egress QoS features based on dot1q ID or CoS value of the dot1q header:

•Hierarchical traffic shaping

•Priority queuing

•Bandwidth commands

Configuration of QoS is shown in the following example:

Router(config)# interface atm3/0/0.100 point-to-point

Router(config-if)# pvc 1/21

Router(config-if-atm-vc)# bridge-domain 200 dot1q 100

Router(config-if-atm-vc)# bridge-domain 300 dot1q 101

Router(config-if-atm-vc)# service-policy in atm-policy-in

Router(config-if-atm-vc)# service-policy out atm-policy-out

As a result of this configuration of the VC, the match vlan or match cos parameters shown in the following example are the values from the dot1q header for 100 and 101.

Router(config)# class-map match-all match-cos-2

Router(config-cmap)# match cos inner 2

Router(config)# class-map match-all match-cos-3

Router(config-cmap)# match cos inner 3

Router(config)# class-map match-all match-vlan-101

Router(config-cmap)# match vlan inner 101

Router(config)# class-map match-all match-vlan-100

Router(config-cmap)# match vlan inner 100

!

Router(config)# policy-map atm-policy-out

Router(config-pmap)# class match-vlan-100

Router(config-pmap)# shape average 64000 256 256

Router(config-pmap)# class match-cos-2

Router(config-pmap)# priority percent 70

!

Router(config)# policy-map atm-policy-in

Router(config-pmap)# class match-cos-3

Router(config-pmap)# police 128000 4000 4000 conform-action transmit exceed-action drop

!

Verifying the Configuration

Use the following show commands to verify the configurations or counters:

Router# show class map

 Class Map match-any class-default (id 0)

   Match any

 Class Map match-all match-cos-2 (id 1)

   Match cos inner 2

 Class Map match-all match-cos-3 (id 2)

   Match cos inner 3

 Class Map match-all match-vlan-101 (id 4)

   Match vlan inner 101

 Class Map match-all match-vlan-100 (id 5)

   Match vlan inner 100

Router# show policy-map

 Policy Map atm-policy-out

   Class match-vlan-100

     shape average 64000 256 256

   Class match-cos-2

     priority percent 70

   Class class-default

   Policy Map atm-policy-in

     Class match-cos-3

        police 128000 4000 conform-action transmit exceed-action drop

Router# show policy-map interface

 ATM3/0/0.100: VC 1/21

  Service-policy input: atm-policy-in

    Class-map: match-cos-3 (match-all)

      0 packets, 0 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: cos inner 3

      Queueing

      queue size 0, queue limit 5

      packets input 0, packet drops 0

      tail/random drops 0, no buffer drops 0, other drops 0, flow drops 0

      police:

        128000 bps, 4470 limit

        conformed 0 packets, o bytes; action: transmit

        exceeded 0 packets, 0 bytes; action: drop

        conformed 0 bps, exceed 0 bps

    Class-map: class-default (match-any)

      51 packets, 6408 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: any

      queue size 0, queue limit 1772

      packets input, packet drops 0

      tail/random drops 0, no buffer drops 0, other drops 0, flow drops 0

  Service-policy output: atm-policy-out

    queue stats for all priority classes:

      queue limit 8272 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 0/0

    Class-=map match-vlan-100 (match-all)

      921 packets, 77748 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: vlan inner 100

      Queueing

      queue limit 5 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 921/77748 shape (average) cir 64000 bc 256 be 256

      target shape rate 64000

    Class-map: match-cos-2 (match-all)

      0 packets, 0 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: cos inner 2

      Priority: 70 (%) (104832 kbps), burst 2620800 (bytes)

    Class-map: class-default (match-any)

      870 packets, 71340 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: any

      queue limit 1772 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 870/71340

Configuring ATM Cell Loss Priority Setting

The ATM Cell Loss Priority (CLP) Setting feature allows users to control the CLP bit setting on routers with the PA-A3 and PA-A6 port adapters.

When creating a class map, the following commands are supported:

•match ip precedence

•match ip dscp

•match protocol

•match any

Configure the CLP setting feature as described at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s7/atmclp.htm

Configuring QoS on Bridged Interfaces

This section describes the QoS features available for interfaces that support bridging and provides information about how to configure QoS on bridged interfaces. It contains the following sections:

•QoS Over Bridging

•Restrictions and Usage Guidelines

•Configuring QoS on Bridged Interfaces

QoS Over Bridging

In Cisco IOS Release 12.2SR and later releases, the Enhanced FlexWAN module supports the QoS over bridging feature, which provides QoS services to bridged packets carrying Ethernet frames. The QoS over bridging feature is available on interfaces that are configured for one of the following encapsulation types:

•ATM RFC 1483 (point-to-point bridging, multipoint bridging, and multi-VLAN in single VC)

•Frame Relay RFC 1490 (point-to-point bridging and multipoint bridging)

•PPP/BCP (trunk and single-VLAN mode)

•BRE (bridged routing encapsulation) over ATM PVCs

•RBE (routed bridged encapsulation) over ATM PVCs

•Half-bridging over ATM PVCs

The QoS over bridging feature allows you to classify bridged Ethernet packets into different traffic classes and perform QoS based on packet classification. This way you can apply different QoS features to different classes of traffic.

QoS over Bridging Features

You can apply the following QoS features to bridged Ethernet packets:

•Classification (ingress)

–match VLAN ID (vlan-inner)

–match L2 802.1q CoS bits (cos-inner)

–match FR DLCI

–match FR DE

–match ATM CLP

–match IP DSCP

–match IP precedence

•Classification (egress)

–match VLAN ID (vlan-inner)

–match L2 802.1q CoS bits (cos-inner)

–match FR DLCI

–match IP DSCP

–match IP precedence

•Marking (ingress)

–set L2 802.1q CoS bits (cos-inner)

•Marking (egress)

–set FR DE

–set ATM CLP

–set L2 802.1q CoS bits (cos-inner)

•LLQ, CBWFQ, and WRED (egress)

•Shaping

•Policing (ingress and egress)

•Hierarchical QoS (HQoS)

Note The terms vlan-inner and cos-inner refer to the VLAN ID and CoS bits in the Ethernet header of a bridged packet. The terms do not refer to the inner dot1q (802.1q) tag of an 802.1q Q-in-Q packet.

For a list of QoS over bridging classification and marking statements, see Table 5-1 and Table 5-2.

Restrictions and Usage Guidelines

The QoS over bridging feature has the following restrictions and usage guidelines:

•Supported on the Enhanced FlexWAN module, in Cisco IOS Release 12.2SR and later releases.

•Supported on the Supervisor Engine 720, Supervisor Engine 32 (in Release 12.2(18)SXF and later), and Route Switch Processor 720 (in Release 12.2SRB and later).

•The system performs a single (fast-classification table) lookup on vlan inner, cos inner, IP DSCP, and IP precedence values. This fast-classification lookup does not support overlapping values for these keywords. This means that you cannot use the same value for a particular keyword in more than one match statement in a single class map. If overlapping values are used, the system reverts to the standard matching algorithm, in which each match statement in the class map is examined sequentially, one-at-a-time, until a match is found.

•Tagged and untagged packets are supported. Note however, that untagged packets in the ingress direction do not support the match cos inner option. This is because an untagged packet does not contain an 802.1q header with the CoS bits. In the egress direction, match cos inner is supported on untagged packets as long as the class map does not contain overlapping values.

•All QoS restrictions and usage guidelines apply (see the "Understanding QoS on FlexWAN and Enhanced FlexWAN" section for details).

•For ATM (RFC 1483) and Frame Relay (RFC 1490) interfaces configured for multipoint bridging, MPB restrictions and usage guidelines apply (see the "Configuring Multipoint Bridging" section for details).

•Due to restrictions with the TCAM, the following match statements cannot be used in a policy map that contains IPv4 or IPv6 match ACL statements:

•match input vlan

•match vlan

•match cos

•match vlan inner

•match cos inner

•Only ATM PVCs (and not SVCs) support the QoS over bridging feature.

•Weighted random early detection (WRED) is not supported on bridged ATM VCs.

•Marking either the IP DSCP or IP precedence field in bridged frames is not supported. (CSCsd55169 has been opened for IP precedence marking.)

Configuring QoS on Bridged Interfaces

To configure a policy map that provides QoS features for bridged packets carrying Ethernet frames, follow these steps. See the "QoS over Bridging Configuration Examples" section for configuration examples.

Note These instructions highlight the matching and marking options available for QoS on bridged packets. Standard QoS options can also be used in policy maps for bridged packets.

Router(config-pmap-c)# police cir cir-bps 
[bc conform-burst-size-bytes] [pir pir-bps] 
[be peak-burst-size-bytes] [conform-action action] 
[exceed-action action] [violate-action action] 

QoS over Bridging Class-Map and Policy-Map Statements

Table 5-1 and Table 5-2 list the class-map and policy-map statements for QoS over bridging features. The tables list the types of interfaces that support each statement; the terms ingress and egress refer to whether the statement applies to incoming (ingress) or outgoing (egress) packets on the interface. See the "QoS over Bridging Configuration Examples" section for configuration examples.

match vlan inner vlan-value 

match cos inner cos-value 

match ip dscp dscp-value 

match ip precedence prec-value 

match fr-de 

match fr-dlci dlci-value 

match atm clp 

Table 5-2 lists the marking statements available for QoS on bridged packets.

set cos-inner cos-value 

set-cos-inner-transmit cos-value 

set fr-de 

set atm clp 

Table 5-3 lists the other QoS features that are available for bridged packets. Examples of most of these features are provided in the "QoS over Bridging Configuration Examples" section.

Sample Interface Configurations

Following are several sample configurations for the types of interfaces that support the QoS over bridging feature:

ATM (RFC 1483) Interface:

interface atm3/0/0

pvc 10/100

bridge-domain 100 dot1q

Routing Bridged Encapsulation (RBE) Interface:

interface atm3/0/0.2 point

ip address 20.0.0.2 255.255.0.0

atm route-bridge ip

pvc 10/100

Bridged Routing Encapsulation (BRE) Interface:

interface atm3/0/0.1 point-to-point

pvc 0/40 

bre-connect 40

Half-bridging Interface:

interface atm3/0/0.2 point

ip address 20.0.0.2 255.255.0.0

pvc 10/100

encapsulation aal5snap bridge

Frame Relay (RFC 1490) Interface:

interface POS1/0/0

encapsulation frame-relay ietf 

frame-relay interface-dlci 100

bridge-domain 100 

BCP/PPP (RFC 3518) Interface (Single-VLAN Mode):

interface POS1/0/0

encapsulation ppp 

bridge-domain 200 dot1q

BCP/PPP (RFC 3518) Interface (Trunk Mode):

interface POS5/0/0

switchport

switchport trunk allowed vlan all 

switchport mode trunk 

switchport nonegotiate 

no ip address

encapsulation ppp

clock source internal

BCP/PPP (RFC 3518) Interface (Tunnel Mode):

interface POS5/0/0

no ip address

encapsulation ppp

bridge-domain 100 dot1q-tunnel 

clock source internal

QoS over Bridging Configuration Examples

The following sections provide several examples of how to configure QoS on interfaces that support bridging. The following types of configuration examples are included:

•Traffic Classification—Examples of how to map traffic into different traffic classes based on characteristics of the traffic. Different QoS features can then be applied to different traffic classes.

•Shaping Traffic—Examples of how to control the flow of traffic on an interface.

•Marking Traffic—Examples of how to set the precedence of packets based on their conformance to QoS policies. Also included is an example of a policy for traffic policing.

•Hierarchical QoS—An example of how to create a policy map that contains other policy maps.

Traffic Classification

The following several examples show how to filter (classify) traffic based on the VLAN ID or CoS bits in the Ethernet header, the Frame Relay DLCI (FR-DLCI) or discard eligibility (FR-DE) bit, and IP precedence or IP DSCP value.

The following class maps classify traffic based on the VLAN ID in the Ethernet (inner) header:

Router(config)# class-map match-all vlan100 

Router(config-cmap)# match vlan inner 100 

Router(config-cmap)# exit  
Router(config)# class-map match-all vlan101 

Router(config-cmap)# match vlan inner 101 

Router(config-cmap)# exit 

The following class map creates a traffic class that matches all packets whose CoS bits are equal to 7:

Router(config)# class-map match-all cos7 

Router(config-cmap)# match cos inner 7 

Router(config-cmap)# exit  

The following class maps match Frame Relay traffic with a DLCI of 100 or 101:

Router(config)# class-map match-all dlci100 

Router(config-cmap)# match fr-dlci 100 

Router(config-cmap)# exit  
Router(config)# class-map match-all dlci101 

Router(config-cmap)# match fr-dlci 101 

Router(config-cmap)# exit  

The following class maps classify traffic based on the IP precedence or IP DSCP value:

Router(config)# class-map match-any prec2 

Router(config-cmap)# match ip prec 2 

Router(config-cmap)# exit 

Router(config)# class-map match-any dscp10 

Router(config-cmap)# match ip dscp 10 

Router(config-cmap)# exit 

The following class maps classify traffic based on whether the packets are marked for discard during congestion. The first example matches Frame Relay packets whose discard eligibility (FR-DE) bit is set, and the second matches ATM packets whose cell loss priority (ATM-CLP) bit is set:

Router(config)# class-map match-all FRdiscard 

Router(config-cmap)# match fr-de 

Router(config-cmap)# exit 

Router(config)# class-map match-all ATMdiscard 

Router(config-cmap)# match atm clp 

Router(config-cmap)# exit 

Shaping Traffic

The next two examples show how to classify and shape traffic based on VLAN ID and Frame Relay DLCI.

This example creates class maps to filter VLAN 100 and VLAN 101 traffic into separate traffic classes and a policy map that shapes the traffic on the VLANs. The policy map is then attached to an ATM PVC.

Router(config)# class-map match-all vlan100 

Router(config-cmap)# match vlan inner 100 

Router(config-cmap)# exit  
Router(config)# class-map match-all vlan101 

Router(config-cmap)# match vlan inner 101 

Router(config-cmap)# exit  

Router(config)# policy-map match-vlan 

Router(config-pmap)# class vlan100 

Router(config-pmap-c)# shape average 1000000 8000 8000 

Router(config-pmap)# class vlan101 

Router(config-pmap-c)# shape average 1000000 8000 8000 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

Router(config)# interface ATM3/0/0 

Router(config-if)# pvc 10/100 

Router(config-if)# bridge-domain 100 dot1q 

Router(config-if)# service-policy output match-vlan 

Router(config-if)# service-policy input match-vlan 

Router(config-if)# exit 

The following commands create class maps and a policy map to classify and shape Frame Relay traffic on POS interface 1/0/0. This example is similar to the one above.

Router(config)# class-map match-all DLCI00 

Router(config-cmap)# match fr-dlci 100 

Router(config-cmap)# exit  

Router(config)# policy-map DLCI 

Router(config-pmap)# class DLCI100 

Router(config-pmap-c)# shape average 1000000 8000 8000 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

Router(config)# interface POS1/0/0 

Router(config-if)# encapsulation frame-relay ietf 

Router(config-if)# frame-relay interface-dlci 100 

Router(config-if)# bridge-domain 100 

Router(config-if)# service policy output DLCI 

Router(config-if)# exit 

Marking Traffic

The following example matches Frame Relay traffic with a DLCI of 100 and sets the discard eligibility bit (FR-DE) of those packets:

Router(config)# class-map match-all DLCI100 

Router(config-cmap)# match fr-dlci 100 

Router(config-cmap)# exit  
Router(config)# policy-map FR-DE 

Router(config-pmap)# class-map DLCI100 

Router(config-pmap-c)# set fr-de 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

The following examples set the ATM CLP bit of packets that have a CoS or IP precedence value of 2. The class maps match traffic based on the value of the CoS or IP precedence bits in the Ethernet header within the packet.

Router(config)# class-map match-all COS2 

Router(config-cmap)# match cos inner 2 

Router(config-cmap)# exit  
Router(config)# policy-map ATM-CLP-COS 

Router(config-pmap)# class-map COS2 

Router(config-pmap-c)# set atm-clp 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

Router(config)# class-map match-all IP-PREC2 

Router(config-cmap)# match ip prec 2 

Router(config)# policy-map ATM-CLP-IP 

Router(config-pmap)# class-map IP-PREC2 

Router(config-pmap-c)# set atm-clp 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

The following commands filter traffic from VLANs 100 and 101 and set the CoS bits of those packets. VLAN 100 traffic is assigned a CoS value of 3 and VLAN 101 traffic is assigned a CoS value of 7 (highest priority):

Router(config)# class-map match-all vlan100 

Router(config-cmap)# match vlan inner 100 

Router(config-cmap)# exit  
Router(config)# class-map match-all vlan101 

Router(config-cmap)# match vlan inner 101 

Router(config-cmap)# exit  

Router(config)# policy-map set-cos 

Router(config-pmap)# class vlan100 

Router(config-pmap-c)# set cos-inner 3 

Router(config-pmap)# class vlan101 

Router(config-pmap-c)# set cos-inner 7 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

The following commands perform policing on traffic in VLAN 101. The police command (two-rate) sets the traffic rate for VLAN 101 traffic as follows: the committed information rate is 1 Mbps and the peak information rate is 2 Mbps. In addition, the command sets the CoS bits to 6 for traffic that conforms to the specified rate. In this example, the policy is attached to a PVC on ATM interface 3/0/0, but it could be applied to other types of interfaces.

Router(config)# class-map match-all vlan101 

Router(config-cmap)# match vlan inner 101 

Router(config-cmap)# exit 

Router(config)# policy-map police101 

Router(config-pmap)# class vlan101 

Router(config-pmap-c)# police cir 1000000 bc 31250 pir 2000000 be 31250  
  conform-action set-cos-inner-transmit 6 exceed-action drop 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

Router(config)# interface atm3/0/0 

Router(config-if)# pvc 10/100 

Router(config-if)# bridge-domain 101 dot1q 

Router(config-if)# service-policy input police101 

Router(config-if)# service-policy output police101 

Hierarchical QoS

The following configuration example shows a hierarchical QoS policy that filters traffic from different VLANs (100, 200, 300) into different traffic classes and then allocates bandwidth to the traffic based on CoS values. This example uses child policies within a parent policy (hierarchical QoS).

The following commands create three class maps, which map traffic in VLANs 100, 200, and 300 into separate traffic classes:

Router(config)# class-map match-all vlan100 

Router(config-cmap)# match vlan inner 100 

Router(config-cmap)# exit  
Router(config)# class-map match-all vlan200 

Router(config-cmap)# match vlan inner 200 

Router(config-cmap)# exit  
Router(config)# class-map match-all vlan300 

Router(config-cmap)# match vlan inner 300 

Router(config-cmap)# exit  

The following commands create several class maps to classify traffic based on CoS values:

Router(config)# class-map match-all cos0 

Router(config-cmap)# match cos inner 0 

Router(config-cmap)# exit  
Router(config)# class-map match-all cos2 

Router(config-cmap)# match cos inner 2 

Router(config-cmap)# exit  
Router(config)# class-map match-all cos4 

Router(config-cmap)# match cos inner 4 

Router(config-cmap)# exit  
Router(config)# class-map match-all cos7 

Router(config-cmap)# match cos inner 7 

Router(config-cmap)# exit  

The following commands create two policy maps to allocate bandwidth for VLAN 100 and VLAN 200 traffic. Each policy map uses CBWFQ and LLQ to allocate bandwidth based on CoS values.

Router(config)# policy-map vlan100 

Router(config-pmap)# class cos2 

Router(config-pmap-c)# bandwidth percent 10 

Router(config-pmap)# class cos4 

Router(config-pmap-c)# bandwidth percent 20 

Router(config-pmap)# class cos7 

Router(config-pmap-c)# priority percent 30 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

Router(config)# policy-map vlan200 

Router(config-pmap)# class cos2 

Router(config-pmap-c)# bandwidth percent 10 

Router(config-pmap)# class cos4 

Router(config-pmap-c)# bandwidth percent 20 

Router(config-pmap)# class cos7 

Router(config-pmap-c)# priority percent 30 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

The following commands create a hierarchical policy map (a policy within a policy). The parent policy map (egress_mpb) assigns a percentage of the link's bandwidth to traffic on VLANs 100 and 200. Two child policy maps (vlan100 and vlan200) further allocate each VLAN's bandwidth to different traffic classes in the VLAN based on CoS values.

Router(config)# policy-map egress_mpb 

Router(config-pmap)# class vlan100 

Router(config-pmap-c)# bandwidth percent 30 

Router(config-pmap-c)# service-policy vlan100 

Router(config-pmap-c)# exit 

Router(config-pmap)# class vlan200 

Router(config-pmap-c)# bandwidth percent 40 

Router(config-pmap-c)# service-policy vlan200 

Router(config-pmap-c)# exit 

The following commands create a policy map that assign a CoS value of 5 to VLAN 100 traffic and a CoS value of 3 to VLAN 200 traffic:

Router(config)# policy-map ingress_mpb 

Router(config-pmap)# class vlan100 

Router(config-pmap-c)# set cos-inner 5 

Router(config-pmap-c)# exit 

Router(config-pmap)# class vlan200 

Router(config-pmap-c)# set cos-inner 3 

Router(config-pmap-c)# exit 

Router(config-pmap)# exit 

The following commands create a policy map that sets the ATM CLP (cell loss priority) bit for traffic with a CoS value of 2:

Router(config)# policy-map atm-clp 

Router(config-pmap)# class cos2 

Router(config-pmap-c)# set atm-clp 

Router(config-pmap-c)# exit 

The following commands assign the policy maps egress_mpb and ingress_mpb to a POS interface that has been configured for bridging (BCP trunk mode). Note that the BCP trunk on the interface is configured to carry traffic from VLANs 100, 200, and 300.

Router(config)# interface POS3/0/0 

Router(config-if)# switchport 

Router(config-if)# switchport trunk allowed vlan 100,200,300 

Router(config-if)# service-policy output egress_mpb 

Router(config-if)# service-policy input ingress_mpb 

Router(config-if)# encapsulation ppp 

Router(config-if)# shutdown 

Router(config-if)# no shutdown 

Router(config-if)# exit 

Next, we assign the policy map atm-clp to an ATM interface that VLAN 100 traffic has been mapped to:

Router(config)# interface ATM4/1/0 

Router(config-if)# pvc 15/100 

Router(config-if)# bridge-domain 100 dot1q 

Router(config-if)# service-policy output atm-clp 

Router(config-if)# exit 

Router(config)# exit 

Understanding MPLS QoS

MPLS QoS allows a network administrator to provide differentiated levels of service across an MPLS network. Network administrators can satisfy a wide range of networking requirements by specifying the class of service applicable to each transmitted frame or packet. Different classes of service can be established for frames and packets by setting EXP bits in the attached MPLS label.

Note All of the MPLS QoS features available for the FlexWAN or Enhanced FlexWAN modules are managed from the modular QoS command-line interface (CLI). The modular QoS CLI (MQC) is a command-line interface that allows you to define traffic classes, create and configure traffic policies (policy maps), and then attach those traffic policies to interfaces.

The following paragraphs provide a summary of MPLS QoS features for the FlexWAN and Enhanced FlexWAN modules.

Trust

Trust is a port assignment instructing the port whether to trust (leave) existing priorities as is on incoming frames or to rewrite the priority back to zero. Ports on the FlexWAN or Enhanced FlexWAN modules have a default trust state of IP precedence that cannot be changed. The FlexWAN or Enhanced FlexWAN module defaults to accepting the IP precedence or DSCP value contained in the received packets. If you want to mark these values, you can configure a distributed class-based packet marking policy that is applied to ingress traffic while the traffic is still on the FlexWAN or Enhanced FlexWAN module.

Note The FlexWAN or Enhanced FlexWAN module preserves ToS by default.

Classification

Classification is the process of generating a distinct path for a packet by associating it with a QoS label. For received MPLS packets, the FlexWAN or Enhanced FlexWAN modules match on the EXP in the received topmost label using the match mpls experimental command. The QoS label that is generated identifies all future QoS actions to be performed on this packet.

Note The FlexWAN or Enhanced FlexWAN modules support all match criteria except qos-group, match input-interface, discard-class, FR-DE, ATM CLP, COS, source address, and destination address.

Marking and Policing

Policing decides whether a packet is in or out of profile by comparing the rate of the inbound traffic to the configured policer. The policer limits the bandwidth consumed by a flow of traffic. The result is passed to the marker.

Marking evaluates the policer configuration information for the action to take when a packet is out of profile. Marking actions are to pass through a packet without modification, to mark down the QoS label in the packet, or to drop the packet.

The FlexWAN or Enhanced FlexWAN modules perform MPLS marking and policing; interfaces are trusted by default.

Note The FlexWAN and Enhanced FlexWAN modules support all forms of the set command except qos_group, ATM CLP bit, set cos, FR-DE, and discard-class.

Preserving IP ToS

The FlexWAN or Enhanced FlexWAN module automatically preserves the IP ToS during all MPLS operations including imposition, swapping, and disposition. You do not need to configure a command to do this.

Using MPLS QoS with FlexWAN and Enhanced FlexWAN Modules

This section describes how to use FlexWAN and Enhanced FlexWAN MPLS QoS for the following:

•IP to MPLS Edge (Ingress Interface) QoS Features

•MPLS to IP Edge (Egress Interface) QoS Features

•MPLS Core QoS Features

Note For Information on Ethernet to MPLS (EoMPLS) QoS with the FlexWAN and Enhanced FlexWAN modules, see the "Ethernet over MPLS and EXP Bits" section.

IP to MPLS Edge (Ingress Interface) QoS Features

This section describes the MPLS QoS features supported at the ingress to the MPLS network.

Note By default, the IP DSCP is preserved throughout the LSP.

Ingress Port Features

Classification based on the packet length is only supported for IPv4 and IPv6 packets.

EXP Marking Support

With the Cisco Supervisor Engine 2 (Sup2), EXP marking is supported for basic MPLS and MPLS/VPN. For MPLS VPN, there is EXP, IP Precedence, and DSCP marking based on IP information (IP Precedence, DSCP, ACL) for imposed (pushed) label only.

With the Sup720, Sup32, or RSP720, for MPLS and MPLS VPN, EXP marking is supported based on IP information (IP Precedence, DSCP, ACL) for imposed (pushed) label only.

Note The set mpls experimental command is not supported as an input policy at the IP to MPLS edge.

Egress Port Features

The FlexWAN and Enhanced FlexWAN module port features classify using the match mpls experimental command. The match mpls experimental command does not match on the EXP in the topmost label.

The Supervisor Engine 2 supports EXP marking at the output QoS policy based on the EXP value for all labels in the label stacks.

The Sup720, Sup32, and RSP720 support EXP marking at the output QoS policy based on EXP value for all labels in the label stacks.

MPLS to IP Edge (Egress Interface) QoS Features

This section describes the MPLS QoS features are supported at the egress interface to the MPLS network.

Ingress Port Features

The FlexWAN and Enhanced FlexWAN module port features classify using the match mpls experimental command. The match mpls experimental command matches on the EXP in the received topmost label.

EXP matching is supported.

Egress Port Features

The FlexWAN and Enhanced FlexWAN module port features classify on information in the transmitted IP header.

EXP matching is supported.

MPLS Core QoS Features

This section describes the MPLS QoS features are supported at the MPLS to MPLS core.

Ingress Port Features

The FlexWAN and Enhanced FlexWAN module port features classify using the match mpls experimental command. The match mpls experimental command matches on the EXP in the received topmost label.

EXP marking is supported at the input QoS policy based on EXP bits.

Egress Port Features

The FlexWAN and Enhanced FlexWAN module port features classify using the match mpls experimental command.

EXP marking is supported.

Configuring MPLS QoS

Note See the "Using MPLS QoS with FlexWAN and Enhanced FlexWAN Modules" section for information about ingress and egress port features at the edges and core of an MPLS VPN network.

QoS is configured through the Modular QoS command-line interface (class maps and policy maps). QoS functionality is distributed and performed on the FlexWAN and Enhanced FlexWAN modules.

These sections provide configuration information for MPLS QoS:

•FlexWAN MPLS QoS

•FlexWAN MPLS QoS with Supervisor Engine 2

•Supported FlexWAN MPLS QoS Features

•Understanding the MPLS Experimental Field

•Setting the MPLS Experimental Field

•Configuring Class-Based Marking for MPLS

FlexWAN MPLS QoS

Cisco 7600 Supervisor Engines and the Route Switch Processor 720 provide MPLS QoS capabilities; however, the FlexWAN and Enhanced FlexWAN modules do not use them. All MPLS QoS features are distributed by the FlexWAN and Enhanced FlexWAN modules. In this respect, FlexWAN QoS behavior is similar to that of the Cisco 7500 VIP QoS. The FlexWAN and Enhanced FlexWAN modules perform all input and output QoS while the Supervisor Engine or RSP720 performs MPLS switching.

Note The Cisco 7500 VIP makes extensive use of qos-group and discard-class for MPLS DiffServ tunnelling modes. However, these functions are not supported by the Cisco 7600 FlexWAN or Enhanced FlexWAN.

The FlexWAN and Enhanced FlexWAN modules provide the following:

•Ability to map IP ToS / DSCP / EXP to the output COS bits

•Output queuing for MPLS packets based on the output CoS bits. The Policy Feature Card copies the topmost outgoing EXP bits to the output CoS value. The FlexWAN and Enhanced Flexwan modules use the match mpls experimental command to match on the output CoS bits.

•Configuration commands follow the MQC guidelines

FlexWAN MPLS QoS with Supervisor Engine 2

With the Supervisor Engine 2, the FlexWAN and Enhanced FlexWAN modules perform the label lookup and label operations. With the Supervisor Engine 2, the FlexWAN and Enhanced FlexWAN modules provide the following:

•Ability to map IP ToS / DSCP to the MPLS EXP bits

•Output queuing based on the EXP bits in the label

•Configuration commands follow the MQC guidelines

Supported FlexWAN MPLS QoS Features

The FlexWAN and Enhanced FlexWAN modules support the following MPLS QoS features:

•QoS features using MPLS EXP classification

•MPLS EXP policing and marking

The following additional QoS features are supported in MPLS QoS in the same manner as in IP QoS:

•Weighted Fair Queuing (WFQ)

•Class Based Weighted Fair Queuing (CBWFQ)

•Low Latency Queuing (LLQ)

•Weighted Random Early Detection (WRED)

•Traffic Shaping

•Policing

Understanding the MPLS Experimental Field

Setting the MPLS experimental field value satisfies the requirement of service providers that do not want the value of the IP precedence field modified within IP packets transported through their networks.

By choosing different values for the MPLS experimental field, you can mark packets so that packets have the priority that they require during periods of congestion.

By default, the IP precedence value is copied into the MPLS experimental field during imposition.You can mark the MPLS EXP bits with a policy.

Figure 5-1 shows a service provider MPLS network connecting two sites of a customer network.

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

Setting the MPLS Experimental Field

Use the set mpls experimental command on the input interface to set the pushed label entry's value during label imposition.

By default, the label edge router copies the IP Precedence of the IP packet to the MPLS EXP field in all pushed label entries.

You can optionally map the IP Precedence or DSCP field to the MPLS EXP field in the MPLS header by using the set mpls experimental command.

Configuring Class-Based Marking for MPLS

To configure Class-based Marking for MPLS, perform the tasks described in the following sections:

•Configuring a Class Map to Classify MPLS Packets

•Configuring a Policy Map to Set the MPLS Experimental Field

•Attaching the Service Policy

•Verifying QoS Operation

Note Class-based marking for MPLS (with Supervisor Engine 2) is supported only on the P-facing interface of the ingress PE.

Configuring a Class Map to Classify MPLS Packets

To configure a class map, perform this task beginning in global configuration mode:

Router(config)# class-map class-name

Router(config-cmap)# match mpls experimental value

Router(config-cmap)# exit

This example shows that all packets that contain MPLS experimental value 3 match any with the class name exp-class:

Router(config)# class-map match-any exp-class 
Router(config-cmap)# match mpls experimental 3 
Router(config-cmap)# exit

Configuring a Policy Map to Set the MPLS Experimental Field

To configure a policy map, perform this task beginning in global configuration mode:

Router(config)# policy-map policy-name

Router(config-pmap)# class class-name

Router(config-pmap-c)# set mpls experimental value1 

Router(config-pmap-c)# exit

This example shows that the value in the MPLS experimental field of each packet that is matched by the policy-map MARKING is set to 5:

Router(config)# policy-map MARKING 
Router(config-pmap)# class exp-class 
Router(config-pmap-c)# set mpls experimental 5 
Router(config-pmap-c)# exit

Router(config-pmap)# exit

Attaching the Service Policy

To attach the service policy to an interface, perform the following steps from global configuration mode:

Router(config)# interface name

Router(config-if)# service-policy {input | output} 
policy-name

Router(config-if)# exit

This example shows that the service policy set_experimental_5 is applied to outgoing traffic on the POS interface POS6/0/0:

Router(config)# policy-map MARKING 
Router(config-pmap)# class exp-class 
Router(config-pmap-c)# set mpls experimental 5 
Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)# interface POS6/0/0 
Router(config-if)# service-policy output set_experimental_5 
Router(config-if)# exit

Verifying QoS Operation

To verify the operation of MPLS QoS, perform this task:

Configuration Examples

Sample configurations provided in this section can be applied to FlexWAN and Enhanced FlexWAN modules supported on the Cisco 7600 series routers.

Ingress PE Router Configuration

In the following example, IP packets with IP precedence 1 entering an MPLS network are shaped to 2,000,000 bits per second and set to MPLS experimental field 3.

Step 1 Define the traffic class:

Router(config)# class-map exp1

Router(config-cmap)# match mpls experimental 1

Router(config-cmap)# exit

Note Traffic classes should be defined to match on MPLS experimental values instead of IP precedence.

Step 2 Define a policy to take actions on traffic classes:

Router(config)# policy-map gold1

Router(config-pmap)# class exp 1

Router(config-pmap-c)# shape average 2000000

Router(config-pmap-c)# set mpls experimental 3

Router(config-pmap-c)# exit

Step 3 Apply the policy to the output interface of a PE router:

Router(config)# interface POS6/1/0

Router(config-if)# ip address 153.61.0.2 255.255.0.0

Router(config-if)# tag-switching ip

Router(config-if)# service-policy output gold1

Router(config-if)# exit

Core Router Ingress and Egress Interface Configuration

The following example provides ingress and egress interface configurations at the P router:

Step 1 Configure the ingress interface:

Router(config)# interface pos 5/0/0

Router(config-if)# ip address 153.61.0.1 255.255.0.0

Router(config-if)# tag-switching ip

Router(config-if)# service-policy input gold1

Step 2 Configure the egress interface:

Router(config)# interface pos 5/0/3

Router(config-if)# ip address 153.62.0.1 255.255.0.0

Router(config-if)# tag-switching ip

Router(config-if)# service-policy input gold1

Configuring MPLS VPN QoS

Note See the "Using MPLS QoS with FlexWAN and Enhanced FlexWAN Modules" section for information about ingress and egress port features at the edges and core of an MPLS VPN network.

The FlexWAN and Enhanced FlexWAN modules support the following MPLS VPN QoS features:

•FlexWAN QoS features using MPLS EXP classification.

•The Supervisor Engine 2 supports MPLS EXP marking done by the FlexWAN and Enhanced FlexWAN modules. See the "Configuring Class-Based Marking for MPLS" section.

•All other Supervisor Engines and the RSP720 support MPLS EXP policing and marking done by the FlexWAN and Enhanced FlexWAN modules.

In addition to these features, with a Supervisor Engine 2, MPLS VPN also supports the set ip precedence command on the input WAN interfaces on the FlexWAN and Enhanced FlexWAN modules.

The following restrictions apply to the support for MPLS VPN QoS on the FlexWAN and Enhanced FlexWAN modules:

•PFC2 QoS features are not supported with MPLS VPN.

•MPLS VPN QoS is supported on the VPN interfaces only.

•Match IP precedence and Set IP precedence and MPLS Experimental values are supported on the input interface only.

Configuration Example

The following example shows how to configure QoS on an MPLS VPN:

Router# configure terminal

Router(config)# class-map match-any vpn-class

Router(config-cmap)# match ip precedence 3

Router(config-cmap)# exit

Router(config)# policy-map VPN-MARKING

Router(config-pmap)# class vpn-class

Router(config-pmap-c)# set ip precedence 5

Router(config-pmap-c)# set mpls exp 5

Router(config-pmap-c)# ^Z

Router# configure terminal

Router(config)# interface POS 6/0/0

Router(config-if)# service-policy output VPN-MARKING

Router(config-if)# ^Z

Router# show running-config interface p6/0/0

Building configuration...

Current configuration: 175 bytes

!

interface POS 6/0/0

 ip vrf forwarding TEST

 ip address 194.3.1.3 255.255.255.0

 negotiation auto

 service-policy input VPN-MARKING

 mls qos trust dscp

end

Router#

Configuring QoS with Any Transport over MPLS

The following QoS features are supported on Any Transport over MPLS:

•Marking on the CE-facing card—(imposition packets) with match criteria, match-dlci, match-any, or class-default.

Note For Marking on the CE-facing card, match-dcli applies to the FlexWAN module only.

•Shaping on the core-facing card, with match exp, and match-any.

•Shaping on the CE-facing card (disposition packets) with match-any.

•WRED on the core-facing card with match criteria, match-exp, or match-any

This section explains how to configure QoS with AToM and includes the following procedures:

•How to Set Experimental Bits with AToM

•Enabling Traffic Shaping

Note PFC QoS features do not apply to ATM over MPLS and Frame Relay over MPLS packets.

How to Set Experimental Bits with AToM

For configuration steps and examples, see the "How to Set Experimental Bits with AToM" section.

MPLS AToM uses the three experimental bits in a label to determine the queue of packets. You statically set the experimental bits in both the VC label and the LSP tunnel label, because the LSP tunnel label might be removed at the penultimate router. The following sections explain the transport-specific implementations of the EXP bits.

Ethernet over MPLS and EXP Bits

Note The information in this section is for FlexWAN-based EoMPLS only. For more information on PFC QoS, see the following URL. http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/software/122sx/swcg/qos.htm

FlexWAN-based EoMPLS supports the following QoS implementations:

•VLAN interface policies

•Core-facing interface policy

You apply a VLAN interface policy to an individual VLAN. You may configure a unique policy for each individual VLAN. Within a policy, you can classify on 802.1q P bits to set the MPLS experimental bits. You can also implement a single traffic shaper that applies to all traffic within the VLAN.

You apply a core-facing interface policy to the EoMPLS uplink interface. This policy applies to traffic from all VLANs. It does not distinguish between different VLANs. Within a policy, you can classify on MPLS experimental bits and configure the following features:

•Class-based traffic shaping

•Class-based weighted fair queuing (CBWFQ)

•Low latency queuing (LLQ)

•Weighted random early detection (WRED)

Note You cannot use both VLAN interface policies and core-facing interface policies at the same time. If you configure QoS for FlexWAN-based EoMPLS, you must select either VLAN interface policies or a core-facing interface policy.

For more information on the commands used to enable Quality of Service, see the following documents:

•Modular Quality of Service Command-Line Interface

•Cisco IOS Quality of Service Solutions Command Reference, Release 12.2

Setting the Priority of Packets with the Experimental Bits

Ethernet over MPLS provides Quality of Service (QoS) using the three experimental bits in a label to determine the priority of packets. To support QoS between LERs, set the experimental bits in both the VC and tunnel labels. If you do not assign values to the experimental bits, the priority bits in the 802.1q header's "tag control information" field and are written into the experimental bit fields.

Perform the following steps to set the experimental bits:

Router(config)# class-map class-name 

Router(config-cmap)# match cos 0-7

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

Router(config-pmap)# class class-name 

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

Router(config)# interface vlan vlan-number 

Router(config-if)# service-policy [input | output] 
policy-name 

Note You can enable traffic shaping and set experimental bits in the same policy-map.

Note You can configure the service-policy for either the input or the output direction. However, the policy is always implemented on the core-facing FlexWAN module port and is applied only to the traffic leaving the core-facing FlexWAN module port.

Enabling Traffic Shaping

Traffic shaping limits the rate of transmission of data. Average rate shaping limits the transmission rate to the committed information rate (CIR). To add traffic shaping, issue the following commands:

Router(config)# class-map class-name 

Router(config-cmap)# match any

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

Router(config-pmap)# class class-name 

Router (config-pmap-c)# shape average cir 1  

Router(config)# interface vlan vlan-number 

Router(config-if)# service-policy [input | output] 
policy-name 

The shape average rate is rounded to the nearest multiple of the link rate divided by 255. If the shape value is lower than the link rate divided by 255, it is rounded up to link rate divided by 255.

This example shows how the shape value is rounded:

Router# show pol p2

 Policy Map p2

  class  any-pkt

   shape average 2000000 8000 8000

Router# show pol int

 Vlan101

  service-policy input:p2

    class-map:any-pkt (match-all)

      2018169 packets, 4575195376 bytes

      30 second offered rate 295768000 bps, drop rate 0 bps

      match:any

      queue size 0, queue limit 0

      packets input 40492, packet drops 1977677

      tail/random drops 0, no buffer drops 0, other drops 1977677

      shape:cir 2000000,  Bc 8000,  Be 8000

      input bytes 40847436, shape rate 1874000 bps

    class-map:class-default (match-any)

      0 packets, 0 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      match:any

        0 packets, 0 bytes

        30 second rate 0 bps

Displaying the Traffic Policy Assigned to an Interface

To display the traffic policy attached to an interface, issue the following command:

Router# show policy-map vlan50

service-policy input: badger

    class-map: blue (match-all)

      0 packets, 0 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      match: any 

      queue size 0, queue limit 2

      packets input 0, packet drops 0

      tail/random drops 0, no buffer drops 0, other drops 0

      shape: cir 2000000,  Bc 8000,  Be 8000

        output bytes 0, shape rate 0 bps

    class-map: class-default (match-any)

      0 packets, 0 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      match: any 

        0 packets, 0 bytes

30 second rate 0 bps

ATM AAL5 over MPLS and EXP Bits

•ATM AAL5 over MPLS allows you to statically set the experimental bits.

•If you do not assign values to the experimental bits, the priority bits in the header's "tag control information" field are set to zero.

ATM Cell Relay over MPLS and EXP Bits

•ATM Cell Relay over MPLS allows you to statically set the experimental bits in VC mode.

•If you do not assign values to the experimental bits, the priority bits in the header's tag control information field are set to zero.

Frame Relay over MPLS and EXP Bits

Frame Relay over MPLS provides QoS using the three experimental bits in a label to determine the priority of PDUs. If you do not assign values to the experimental bits, the priority bits in the header's tag control information field are set to zero. For Frame Relay over MPLS, you must set the experimental bits on a per-DLCI basis.

Setting the Priority of Packets with EXP Bits

Set the experimental bits in both the VC label and the LSP tunnel label. You set the experimental bits in the VC label, because the LSP tunnel label might be removed at the penultimate router.

Perform the following steps to set the experimental bits.

Router# enable

Router(config)# configure terminal

Router(config)# class-map class-name 

Router(config-cmap)# match any

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

Router(config-pmap)# class class-name 

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

Router(config)# interface slot/port 

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

Enabling Traffic Shaping

Traffic shaping limits the rate of transmission of data. Average rate shaping limits the transmission rate to the committed information rate (CIR). To add traffic shaping, issue the following commands: