CE-PE Shaping and Policing Best Practice?

Unanswered Question
Oct 11th, 2009


We have a requirement to shape a 1Gbit CE-PE interface to 150Mbit in order to conform to a provider's CIR.

Would it be advisable to adjust the normal and extended burst values and engage congestion avoidance techniques such as WRED? Does anyone know where I can find the best practice for this type of configuration or would the following be sufficient?

policy-map SHAPE

class class-default

shape average 150000000

interface GigabitEthernet0/0

service-policy output SHAPE



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Giuseppe Larosa Sun, 10/11/2009 - 03:13

Hello Paul,

your configuration should be enough if you don't need specific differentiated treatment for traffic classes.

If you want to provide for example a LLQ for voice traffic, and you have some premium data classes you should use hierarchical QoS (if supported in your device)

in addition to shape the SHAPE policy-map should invoke a CBWFQ scheduler that becomes the child policy.


policy-map SHAPE

class class-default

shape average 150000000

service child_llq

class-map voice

match ip address voice_traffic

class-map critical_data

match ip address critical_data_traffic

police-map child_llq

class voice

priority 4000

class critical_data

bandwidth 20000

class class-default



Further tuning is possible for example for WRED thresholds.




Hope to help


Joseph W. Doherty Sun, 10/11/2009 - 04:14

Ideally you would want to adjust your shaping parameters to match those of your provider. If these are unknown, using a 10 ms Tc with no excess burst often works well in most cases.

However, one thing to note, shaper's often don't account for L2 Etherenet overhead yet the provider "bandwidth" normally does. What this means is you often need to shape slower than the "nominal" bandwidth (generally 5 to 15% - reason for range, L2 overhad varies based on frame size).

WRED can be complex to get "right". What you might try, beyond basic FIFO, is to just insure fair-queue is active. Most IOS shaper's implement WFQ although the later 12.4T versions only provide pure FQ and they also default to FIFO. To insure one of the FQ variants is active, just add "fair-queue" to your class-default class.

tievens Wed, 12/02/2009 - 12:52


You need to find out what settings the SP is using.  Shaping is different on different platforms (3750 metro as example) and shaping is not the same as police.  

The rule of thumb is that you should be at the same Bc/Tc or under value that is used by the SP.   Previously with ATM and Frame, the shape Tc was normally set to 1 second (Bc=CIR) in order to avoid SP drops.  With Ethernet, it seems that providers are trying to implement lower Tc values again.

Be aware that if the carrier is using SIP-400/600's or 3750Metros you could be at risk of not being able to meet the Tc of the provider.  In other words, your 4ms Tc will still allow a microburst that the carrier can/will drop. 

I've attached a presentation that I wrote regarding the topic of shaping in the carrier cloud and how that can be a problem with microbursts of connectionless traffic, such as RTP/video, WLAN/LWAPP, GRE tunneling, IPSec, ...




This Discussion