Giuseppe,

We are moving this particular site to an MPLS service, and the provider said that we need to shape the connection. It sounds like to me I would want to police it.

We want to back down a 20mb connection to 3mb, how would I do this the most efficient way?

Thanks,

John

If the platform supports it, I would normally recommend shaping over policing. Shaping buffers overspeed bursts, policing drops overspeed bursts. Shaping behaves more like interfaces that have queues to buffer bursts, policing behaves more like interfaces with no queues.

As to an efficient way, depends on the platform, which you've haven't described. If the platform supports CBWFQ, CBWFQ can do either.

e.g. (NB: syntax might be incorrect)

policy-map yourName

class class-default

shape average 3000000

*or*

policy-map yourName

class class-default

police 3000000

interface ?

service-policy output yourName

Hi John,

Just to add some info to the previous posts:

Your choice may be influenced by the applications you run over the provider.

As Giuseppe and Joseph say, shaping stores and delays traffic, so sometimes it is not the most suitable for delay and jitter sensitive applications (like VoIP), because shaping may simply disrupt voice quality.

As the traffic fluctuates, more or less packets are in the shaping queue, so it changes the delay of packets of any single application, which is actually the jitter.

Cheers:

Istvan

Istvan is correct that shaping may delay traffic (just as interface queuing may), however if the platform supports it, a hiearchy policy (mentioned in Giuseppe's first post) allows you to determine how various traffic is delayed.

e.g. (NB: syntax might be incorrect)

policy-map ChildPolicy

class VoIP

priority percent 33

class MissionCritical

bandwidth percent remaining 74

class Scavenger

bandwidth percent remaining 1

class class-default

bandwidth percent remaining 25

policy-map ParentPolicy

class class-default

shape average 3000000

service-policy ChildPolicy

interface ?

service-policy output ParentPolicy

Giuseppe is correct about shaping below nomimal rate might be necessary, especially if you need to account for L2 overhead (common for Ethenet WAN handoffs). Hopefully this is some information your provider might be able to provide (also Tc or Bc values they use).

Mohamed's point about shaping using more CPU than policing can be true, although the benefit, I've found, seems to be worth the extra effort and the delta between the two is usually not enough to overtax the router. If it is, you likely need a more powerful router to process the traffic level.

PS:

One other difference between shaping and policing, policing works much as a single FIFO queue (again perhaps with little depth - can be adjust with Bc and Be) but shapers seem, by default, to implement FQ or perhaps WFQ.

Hello John,

in this case you should shape a little under the contracted rate:

the service provider will police your traffic probably by marking down or by implementing a three levels policer.

This is the sense of their advice: if you send traffic that conforms to the contract you will see your traffic carried to other site.

If you don't shape they will police the traffic and they don't know what is important for your network.

The same scenario happened on FR or ATM WAN service: it is better to set DE or CLP before the provider measures the traffic.

For example you may want to implement a LLQ with a policer so that this type of traffic is always in contract and have the provider to carry it untouched.

Hope to help

Giuseppe