OECG – Chapter 16

478 Words. Plan about 2 minute(s) to read this.

When configuring a Cisco router to perform traffic-shaping, you have flexibility. You can classify packets and apply various traffic-shaping policies to the different classes. (I’ve used this to make sure that people listening to on-demand audio don’t overwhelm my link and to prevent a fat e-mail upload or download from clogging the pipe.)

The IOS “shape [average | peak] mean-rate [[burst-size] [excess-burst-size]]” command is used to implement traffic shaping for packets output from an interface. Note that you don’t have to set burst-size (Bc) or excess burst (Be). Class-based shaping will change its computation for Tc (the time window during which Bc is sent) depending on whether we’re shaping higher or lower than 320Kbps.

  • Bc = 8000 bits if the rate is <= 320Kbps, otherwise shaping rate * Tc
  • Be = Bc always
  • Tc = Bc/shaping rate if the rate is <= 320Kbps, otherwise 25ms

For voice traffic, you’ll want to implement a low-latency queue (“priority”). If you are also running traffic shaping, it’s helpful to understand how the router determines what queue to put a voice packet in.

  • The router must determine if traffic-shaping is active. It is active if the traffic flow has exceeded the contract. In this case, the packet would go into the shaping queue. Once the packet is ready to leave the shaping queue, it will then flow to the software queue.
  • If traffic-shaping is not active, then the packet would flow directly into the appropriate software queue as defined by the class-based policy.

It is possible to define a shaping rate based on percentage of interface bandwidth, as opposed to a bit rate. Keep the following in mind when doing so:

  • “shape percent” looks to the interface or subinterface where it is applied to know what bandwidth to use.
  • Subinterfaces don’t magically have the same bandwidth as their parent interface. So if you don’t use a bandwidth statement to define the bandwidth, then the router is going to default to 1544, which won’t work well on your frame-relay PVC with a feeble 56Kbps you’re trying to shape over.
  • The committed burst (Bc) and excess burst (Be) rates are now in milliseconds instead of bits. The router will calculate the values.
  • Tc (the time interval to send Bc) will match Bc.

The behavior I’ve outlined so far implies that you’re doing a “shape average” command. What are the differences if you use a “shape peak” command instead?

  • Bc, Be and Tc are calculated the same way.
  • Bc AND Be tokens are replenished in the token bucket every time. In this way, the shaper can send both the committed and excess burst every time. The formula ends up looking like shaping rate = configured rate (1+Be/Bc).

And finally, to adjust your shaper so that it will back off when BECNs are received, use the “shape adaptive <rate>” command, where rate is bits per second.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

2 thoughts on “OECG – Chapter 16

  1. Hi there,

    I do not agree with the statement “If traffic-shaping is not active, then the packet would flow directly into the appropriate software queue as defined by the class-based policy”.

    If the shaper is not active then that means there is no congestion and if there is no congestion there are no queues. Queuing subsystem is only activated if the backpressure is applied by the interface to IOS queueing subsystem. This backpressure is only appliled if there is congestion on the interface.


  2. Hi Ethan,

    The OCEG mentions that Tc is always 25ms when using links over 320kbps. Is this correct? From what I have gleaned the Tc should workout to be Tc = BC / CIR unless the shaped rate is <320kbps.

    Otherwise how could you tune a LLQ shaped queue down to a 10ms Tc or other custom value.

    great site btw

Comments are closed.