Distributed Traffic Shaping Configuration Example [Frame Relay]

Document ID: 22600

PDF Downloads

Distributed Traffic Shaping Configuration Example

Introduction

This document discusses Distributed Traffic Shaping (DTS) and consolidates much of the information that is available today.

Traffic shaping (TS) provides a mechanism to control the traffic flow on a particular interface. "Distributed" TS is a feature specific to the higher-end platforms such as the Cisco 7500 or the 12000 Series Internet Router. These platforms have the ability to offload traffic shaping from the main processor (Route Switch Processor - RSP or Gigabit Route Processor - GRP) to the individual interface processors (Versatile Interface Processor - VIP or line card - LC). In networks where Distributed Cisco Express Forwarding (dCEF) is the preferred mode of switching, DTS on the VIP or line card is the logical choice for traffic shaping.

Why Shape Traffic with DTS?

If you are reading this document, then, most likely, you already have an idea of why you want to shape traffic. The distributed piece of the puzzle should be pretty clear, too - you are distributing the duties of the main processor to the individual card processors. With respect to shaping, many customers are simply trying to avoid exceeding the guaranteed rate of the circuit based on the agreement with the provider. This prevents drops in the cloud and, as a result, reduces retransmissions (with TCP/IP) when the provider discards packets. A common scenario where you need to shape traffic is depicted below. In this example, there is no need for the Central Site to forward traffic at T1 rate if the Branch Office only has a 128K circuit:

There are many additional reasons for using DTS. Benefits include an assortment of related Quality of Service (QoS) functionalities, and the drive to use bandwidth as efficiently as possible across varied types of traffic. DTS configures traffic shaping at the interface level, subinterface level, or logical interface level for ATM or Frame Relay permanent virtual circuits (PVCs).

Shaping can achieve an array of network goals, and can key on the following criteria:

All traffic on the physical or logical interface
Traffic classified through simple and extended IP access control lists (ACLs) (IP addresses, TCP/UDP ports, IP Precedence)
Traffic classified by QoS group (an internal packet label applied upstream by Committed Access Rate - CAR, or QoS policy propagation - QPPB)

DTS supports up to 200 shape queues per VIP, supporting up to OC-3 rates when the average packet size is 250 bytes or greater, and when using a VIP2-50 or better with 8M static RAM (SRAM). Unlike regular traffic shaping (GTS), DTS does not require that weighted fair queueing (WFQ) be enabled. Instead, DTS uses fair queuing or distributed first-in, first-out (FIFO) for the shaped queue.

Platform Specifics

The following table shows how to configure TS depending on the platform - mainly illustrating that the feature is significant for high-end platforms:

	12000 Series	7500 Series	7200, 3600, 2600 and Other Non-VIP Platforms
Supported shaping mechanisms	DTS	DTS	GTS or Frame Relay TS
Configuration command	shape command in a policy-map	shape command in a policy-map	traffic-rate or frame-relay traffic-shaping on a main interface, and with FRTS - map-class configuration commands to specify shaping parameters
Requires distributed Cisco Express Forwarding (dCEF)	Default is CEF	Yes (Verify with the show cef linecard command)	No

7500 Series DTS Notes

On the Cisco 7500 Series, the ability to configure Frame Relay Traffic Shaping (FRTS) using the frame-relay traffic-shaping command is now blocked since FRTS executes on the RSP in a non-distributed mode. With dCEF and FRTS, a CEF "punt" adjacency causes all packets to be fast-switched by the RSP, which is sub-optimal for maximum forwarding performance.

As of Cisco IOS^® Software Release 12.1(5)T, QoS policies must run in distributed mode on the VIP; Route/Switch Processor (RSP)-based QoS is no longer supported. Thus, you must use the shape command and other commands of the Modular QoS Command Line Interface (MQC) to implement DTS for interfaces on VIPs on the Cisco 7500 Series.

While Cisco IOS Software Release 12.1(2)T introduced support for Low Latency Queueing (LLQ) on platforms other than the Cisco 7500 Series, distributed LLQ (dLLQ) was introduced in 12.1(5)T on the VIP. The distributed version enhances the performance of this feature. You can configure a unique service-policy per Data-Link Connection Identifier (DLCI). You do not need to use a map-class and can apply the service-policy command directly to the subinterface or DLCI. However, we recommend configuring dLLQ inside a map-class.

When applying distributed FRF.12 (fragmentation) to a Frame Relay interface, you must define a map-class and apply the service-policy under the map-class. FRF.12 was introduced in Cisco IOS software version 12.0(4)T and is extended to the Cisco 805, 1600, 1700, 2500, 4500, and 4700 router platforms as from Cisco IOS software version 12 1(2)T. Additional details are available at FRF.12 Support on Additional Platforms.

Cisco 12000 Series Internet Router DTS Notes

On the 12000 Series, fast switching and process switching are not options. If a destination prefix cannot be resolved to a forwarding entry in the inbound line card's (LC) tables, the packet is dropped. Only packets matching a glean adjacency are punted to the Gigabit Routing Processor (GRP). In addition, on the 12000, the LC CPU won't punt packets to the GRP for features, and the LC sends an Internet Control Message Protocol (ICMP) unreachable (as long as the no ip unreachables command is not configured). On the 12000, the only traffic punted to the GRP are packets destined to an interface on the router or packets sourced from the router. For additional information, see QoS features by Engine Type.

Configuring DTS

Use the first two steps to configure DTS on VIP-based Frame Relay interfaces (7500 Series):

Enable dCEF with the following command:

router(config)#ip cef distributed

Ensure that the Frame Relay interface is enabled for distributed switching.

router(config-if)# interface serial 2/0/0
router(config-if)# ip route-cache distributed

router#show ip interface serial 2/0/0
Serial8/0/0 is up, line protocol is up
  Internet address is 64.0.0.2/24
  Broadcast address is 255.255.255.255
  ICMP redirects are always sent
  ICMP unreachables are always sent
  ICMP mask replies are never sent
  IP fast switching is enabled
  IP fast switching on the same interface is disabled
  IP Flow switching is disabled
  IP CEF switching is enabled
  IP Distributed switching is enabled
  IP Fast switching turbo vector
  IP CEF switching with tag imposition turbo vector
  IP multicast fast switching is enabled
  IP multicast distributed fast switching is disabled
  IP route-cache flags are Fast, Distributed, CEF
  Router Discovery is disabled
  IP output packet accounting is disabled

Creating a Traffic Class (Required)
Configuring a Traffic Policy that Uses DTS (Required)
Attaching the Traffic Policy and Enabling DTS (Required)
Monitoring and Maintaining DTS (Optional)

Creating a Traffic Class

The first step in enabling any feature using the Modular QoS CLI is creating a traffic class.

	Command	Purpose
Step 1	Router(config)# class-map [match-any* \| match-all] class-name*	Specifies the name and whether any or all of the criteria will constitute a match.

For information on the Modular QoS CLI, and the procedure for creating a traffic class, see Modular Quality of Service Command Line Interface Overview.

Configuring a Traffic Policy that Uses DTS

To enable DTS, you must configure a traffic policy. You can configure traffic policies for as many classes as are defined on the router up to the maximum of 256.

To configure a traffic policy, use the policy-map command beginning in global configuration mode to specify the traffic policy name, then use the configuration commands in the table below in policy-map configuration mode to configure the traffic class name and traffic shaping.

Traffic is directed to the traffic policy default class if it does not satisfy the match criteria of any other classes whose policies are defined in the traffic policy.

	Command	Purpose
Step 1	Router(config)# policy-map policy-name	Specifies the name of the traffic policy to be created.
Step 2	Router(config-pmap)# class class-name	Specifies the name of a predefined traffic class included in the traffic policy. The class was defined in the previous step of this process.
Step 3	Router(config-pmap-c)# shape <average \| peak> <meanrate>[<burst size> [<excess burst size>]]	Specifies the target bits per second (bps) rate.

Attaching the Service Policy and Enabling DTS

To attach a traffic policy to the interface, subinterface, or map-class and enable DTS on the interface, use the following command in interface (or map-class) configuration mode. Applications of dLLQ and FRF.12 are strongly recommended to have the service policy applied to the frame-relay map class.

See FRF.12 and DTS for additional specifics for fragmentation.

Command

Purpose

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

* APPLY TO FR MAP-CLASS for llq and fragmentation

Enables DTS and attaches the specified traffic policy to the interface or map-class.

Monitoring and Maintaining DTS

To monitor and maintain the DTS feature, use the following commands in EXEC mode, as needed.

For additional monitoring commands with respect to QoS, see show policy-map interface.

Command	Purpose
Router# show interface [interface-name] shape	Displays detail status of the traffic shaping.
Router# show policy policy-name	Displays the configuration of all classes composing the specified traffic policy.
Router# show policy policy-name class class-name	Displays the configuration of the specified class of the specified traffic policy.

Sample Configurations

DTS on Main Interface
In the following example, traffic that goes out on interface pos1/0/0 is shaped at the rate of 10Mbits/sec.

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

Class-based DTS on Main Interface

In the following example, two classes are created and the match criteria is defined based on the access list number. Traffic that goes out on interface fdi4/0/0 and matches the criteria in access list 10 is shaped to 16Mbps. Traffic that matches the criteria in access list 20 is shaped to 8 Mbps.

Note: The following IP addresses are examples only.

router(config)# access-list 10 permit 171.69.0.0

router(config)# access-list 20 permit 192.168.0.0

router(config)# class-map class1

router(config-cmap)# match access-group 10

router(config-cmap)# exit

router(config)# class-map class2

router(config-cmap)# match access-group 20

router(config-cmap)# exit

router(config)# policy-map DTS-interface-class-action

router(config-pmap)# class class1

router(config-pmap-c)# shape average 16000000

router(config-pmap-c)# exit

router(config-pmap)# class class2

router(config-pmap-c)# shape average 8000000

router(config-pmap-c)# exit

router(config-pmap)# interface fd4/0/0

router(config-if)# service-policy output DTS-interface-class-action

See additional configuration samples.

Tools for Identifying Issues

A VIP interface configured with Frame Relay encapsulation may crash with a bus error if applying a service-policy while the interface is passing traffic. This problem is resolved in various versions of Cisco IOS software (Cisco bug ID CSCdt88568). For more information on this ddts and additional bugs, see Cisco TAC Tools or the Bug Toolkit.

Tools Information

For additional resources, refer to Cisco TAC Tools for Access-Dial Technologies.

Related Information

Additional Documentation

QoS Technical Tips
QoS Top Issues

Updated: Jun 01, 2005

Document ID: 22600

Frame Relay