Enterasys Networks Security Router X-PeditionTM - Manual (Page 291)

Mechanisms Providing QoS
XSR User’s Guide 12-9
XSR(config-pmap-c<d32>)#exit
XSR(config-pmap<cbts>)#class foo
XSR(config-pmap-c<foo>)#shape 38400 15440
XSR(config-pmap-c<foo>)#bandwidth per 30
XSR(config-pmap-c<foo>)#exit
XSR(config-pmap<cbts>)#class class-default
XSR(config-pmap-c<class-default>)#set ip dscp 33
Differences Between Traffic Policing and Traffic Shaping
Traffic shaping and traffic policing may appear identical at first glance, but are marked by the
following differences:
• Traffic policing marks or drops packets, it does not buffer them and has no associated queue
management algorithm.
• The police command configures independent input and output rate-limit rules on the same
interface while traffic shaping applies to output only.
• Traffic policing can be used to implement CAR (Committed Access Rate). You can specify
both conform-action and exceed-action. If the exceed-action is drop, then the rate limit is
essentially a CAR rate. Traffic-shaping has no such parameters as all in-profile traffic will be
forwarded or queued and out-of-profile traffic queued and shaped.
• Traffic shaping and policing differ in how they refill the token bucket. Shaping add tokens in
the bucket at regular intervals of 10 milliseconds and calculates token added using this
formula: tokens equal 10 millisecond rate.
The Policer adds tokens to the bucket on every packet, calculating the interval between the
current and previous packet to determine the number of tokens it must add using this
formula: tokens equal (interval between packets) multiplied by rate divided by 8bits
Traffic Shaping and Queue Limit
Traffic shaping delays packets in the queue if there are too few tokens in the bucket. How many
packets are delayed (queued) depends on the shaper values, refill interval of the token bucket (10
milliseconds) and incoming traffic. If too many packets are delayed, the queue may overflow and
incoming packets get dropped, so the queue size must be correct to avoid unwanted dropped
packets.
The queue may also overflow because incoming traffic is significantly beyond expected
parameters. The XSR has no control over incoming traffic and if it misbehaves, no shaping
configuration will prevent packet drops.
Another cause for the queue overflowing is its size may not be big enough to sustain the
configured average rate. Since every 10 milliseconds QoS fills the bucket, the queue should be
configured with enough capacity to hold a 10msec burst. This is the minimum queue size required
to sustain the average rate. Use the following formula to calculate the queue size:
Shape burst equals (rate multiplied by (10msec/1000) divided by (minimum packet size
multiplied 8 bits)
If incoming traffic is expected to be bursty and the expected burst is bigger than the queue size,
packets will be dropped. You can hike the queue size to accommodate incoming bursts as follows:
Expected burst equals burst (in bytes) divided by (minimum packet size)
The XSR automatically calculates shaper burst and you configure expected burst using the queue-
limit command. When both queue-limit and shaper are configured on a queue, QoS uses the