Traffic shaping in Cisco IOS
From CT3
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.
Contents |
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:
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 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:
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 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.


BlogMarks
del.icio.us
digg
Facebook
LinkedIn
Newsvine
reddit
Slashdot