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.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
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.
This table describes 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 |
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. Therefore, 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, Cisco recommends that you configure 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. For additional details, refer to FRF.12 Support on Additional Platforms.
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 more information, refer to What Quality of Service (QoS) features are available for the 12000 Series Internet Router?
Use the first two steps to configure DTS on VIP-based Frame Relay interfaces (7500 Series):
Use this command in order to enable dCEF:
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
Create a traffic class. (Required)
Configure a DTS traffic policy. (Required)
Attach the traffic policy and enable DTS. (Required)
Monitor and maintain DTS. (Optional)
Note: Use the Command Lookup Tool (registered customers only) for more information on the commands used in this document.
The first step to enabling any feature using the Modular QoS CLI is to create a traffic class.
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, refer to Modular Quality of Service Command-Line Interface Overview.
You must configure a traffic policy in order to enable DTS. 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 class and shape configuration commands in order to configure the traffic class name and traffic shaping.
Router(config)#policy-map policy-name — Specifies the name of the traffic policy to be created.
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.
Router(config-pmap-c)#shape {average | peak} cir [bc] [be]—Specifies the average or peak rate 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.
Use this command in interface (or map-class) configuration mode in order to attach a traffic policy to the interface, subinterface, or map-class and in order to enable DTS on the interface:
Router(config-if)#service-policy output policy-name —Enables DTS and attaches the specified traffic policy to the interface or map-class.
Note: Applications of dLLQ and FRF.12 are strongly recommended to have the service policy applied to the frame-relay map class.
Refer to Frame Relay Traffic Shaping with Distributed QoS on the Cisco 7500 Series for more information about fragmentation.
Use these commands in EXEC mode in order to monitor and maintain the DTS feature:
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.
For more information about QoS monitoring commands, refer to Understanding Packet Counters in show policy-map interface Output.
DTS on Main Interface
In this 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 this example, two classes are created, and the match criteria is defined based on the access list number. Traffic that goes out on interface fd4/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.
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
Note: The IP addresses in this configuration are examples only.
For additional configuration examples, refer to Configuring Distributed Traffic Shaping.
There is currently no verification procedure available for this configuration.
A VIP interface configured with Frame Relay encapsulation might crash with a bus error if it applies a service-policy while the interface passes 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, refer to Cisco Support Tools & Resources or the Bug Toolkit (registered customers only) .
Revision | Publish Date | Comments |
---|---|---|
1.0 |
01-Jun-2005 |
Initial Release |