Three Ways to Implement Traffic Shapping
There are three ways to implement traffic shaping.
- Generic Traffic Shapping (GTS)
- Frame Relay Traffic Shapping (FRTS)
- Class-based Traffic Shapping (MQC-S)
Generic Traffic Shaping (GTS) was the first feature to limit the outbound traffic rate of an interface introduced into IOS. With GTS all traffic leaving an interface/subinterface can be shaped, or a subset of traffic can be classified using an access-list. The syntax is as follows.
traffic-shape rate <CIR> <Bc> <Be> <QueueLimit>
traffic-shape group <ACL> <CIR> <Bc> <Be> <QueueLimit>
access-list 101 permit tcp any any eq www
!
interface fa0/0
traffic-shap group 101 10000000
FRTS supports four types of adaptive shaping, 1) BECN adapt, 2) FECN reflection, 3) queue depth monitoring, and 4) a proprietary method called ForeSight.
map-class frame-relay TO->R1
frame-relay cir 512000
frame-relay mincir 256000
frame-relay bc 5120
frame-relay be 0
frame-relay adaptive-shaping becn
frame-relay adaptive-shaping interface-congestion 10
!interface s0/0
frame-relay traffic-shapping //Switch on FRTS
frame-relay class TO->R1
MQC based traffic-shaping allows Generic Traffic Shaping to be applied to any traffic class. This makes traffic-shaping’s configuration modular and unified, without special variants for encapsulations like Frame Relay. Class-based GTS is similar to legacy GTS, but allows shaping based on class-maps, as opposed to access-list classification with legacy GTS, thus allowing any MQC classification options, such as NBAR, to define shaped traffic. Additionally MQC based shaping allows the shaping queue to be tuned, while legacy GTS supports just simple WFQ with no option to tune it.
policy-map SHAPE
class class-default
shape average 384000 7680
!
interface fa0/0
service-policy output SHAPE
Discussion Area - Leave a Comment