Traffic shaping in Cisco IOS

From CT3

Jump to: navigation, search

By Ivan Pepelnjak

The traffic shaping Cisco IOS QoS mechanism configured with the shape command within a policy-map class allows you to enforce a traffic contract even when the bandwidth of the outbound interface far exceeds the contractual rate.

Both shaping and policing can be used to in Cisco IOS to enforce the traffic contract. Policing drops or relabels out-of-contract packets without incurring any transmission delay or processing overhead while shaping delays out-of-contract packets, resulting in increased delay and jitter. TCP responds much better to the shaping of excess traffic (increased transmission delay) than policing (which result in packet drops).

This article applies to IOS traffic shaping on non-distributed architecture (for example, the ISR series) running Cisco IOS. High-speed routers (from ASR to GSR) and Catalyst switches supporting traffic shaping use hardware-implemented or hardware-assisted shaping.


Typical usage scenarios

Traffic shaping is commonly used when the traffic has to be prioritized on a link which is too fast to experience output queue congestion, for example on a core site in an MPLS VPN network:

Figure 1: Typical traffic shaping usage

The link between PE-2 and Site routers is the bottleneck in the network shown in Figure 1. If the MPLS VPN service provider does not implement the desired QoS mechanisms on this link, the high-priority traffic sent from the Core site to the Remote site might be delayed due to the output queue congestion on PE-2 on which the customer has no influence.

The issues described in this section are not limited to MPLS VPN networks; similar problems occur in Frame Relay networks or in ATM networks using UBR virtual circuits.

The only alternative to proper outbound queuing on PE-2 is the introduction of an artificial bottleneck (implemented with traffic shaping) on the outbound interface of the Core router. Once the bottleneck is introduced, the packets that exceed the transmission capacity of the remote site link are delayed and stored into the shaping queue (see Traffic shaping mechanisms for more details) where they can be prioritized and reordered.

Cisco IOS configuration

Historically Cisco IOS implemented numerous somewhat incompatible standalone traffic shaping mechanisms, including Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping (FRTS). Recent IOS releases (including IOS releases 12.4, 12.4T and 12.2S) support traffic shaping within the Modular QoS CLI framework, where you can configure shaping of individual traffic classes with the shape configuration command.

The shape command allows you to specify average or peak traffic rate, adaptive Frame Relay traffic shaping and even voice-sensitive Frame Relay traffic shaping. Most variants of the shape command allow you to specify token bucket parameters (Bc and Be) in addition to the desired traffic rate.

All traffic shaping mechanisms use identical technology, they differ in their traffic classification capabilities (GTS uses IP access lists, FRTS uses Frame Relay virtual circuits) and underlying queuing structures (GTS uses WFQ, whereas FRTS uses custom- or priority queuing). MQC offers the most versatile configuration model; it gives you very fine control over traffic classification and queuing mechanisms.

Traffic shaping mechanisms

Cisco IOS shapes outbound traffic using the following steps:

  • If shaping is not yet active (forwarded traffic has not exceeded the traffic contract), the traffic is measured with a token bucket algorithm. If a packet exceeds the token bucket capacity, it’s queued in the shaping queue structures (activating the shaping mechanism).
  • If shaping is active (the shaping queues are not empty), forwarded traffic is not measured but queued directly into the shaping queues.
  • Every Tc, the router removes up to Bc packets from the shaping queues and re-queues them into the interface queue.

The complete algorithm is illustrated in the following diagram:

Figure 2: Traffic shaping in Cisco IOS
The Bc and Be parameters can be specified in the shape command. If you don't specify them, Cisco IOS selects reasonable values. Tc is always computed from the shaping rate and Bc.

Implications of traffic shaping mechanism

The traffic shaping mechanism used by Cisco IOS has the following side effects:

  • The packets in the shaped class are not delayed unless they exceed the traffic contract (more than Bc bytes in Tc period).
  • Once the traffic contract is exceeded, all subsequent traffic in the same class is shaped until the shaping queues are empty.
  • Relatively large amount of data is simultaneously dequeued from the shaping queues every Tc and sent as a single packet burst. These bursts might interfere with the traffic from other QoS classes in the interface output queue.

The secondary queue structure introduced by the traffic shaping mechanism works as follows:

  • Packets delayed by the shaping mechanism are entered into the shaping queue according to its queuing policy.
The shaping queues use per-flow weighted fair queuing unless you change the queuing structure of the shaped traffic with the hierarchical service-policy.
  • The packets dequeued from the shaping queue (or packets transparently passed without being delayed) are queued in the interface output queue according to the bandwidth or fair-queue parameter of the shaped class.
If you expect interface output queue congestion, make sure you assign enough bandwidth to the shaped traffic with the bandwidth command. The bandwidth assigned to the shaped class should be equal to the shaping rate.

Additional Resources  

Personal tools


Main menu