10-11-2009 02:32 AM - edited 03-04-2019 06:19 AM
Hi,
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
Thanks,
Paul
10-11-2009 03:13 AM
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.
example
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
fair-queue
random-detect
Further tuning is possible for example for WRED thresholds.
see
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/ngwane.html
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html
Hope to help
Giuseppe
10-11-2009 04:14 AM
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.
12-02-2009 12:52 PM
Paul,
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, ...
HTH
--Tim
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide