MPLS shaping per site

Unanswered Question
May 22nd, 2008

I'm trying to get my head round the best way of doing a nested (child/parent) LLQ policy. The setup is a central site with 10mb MPLS circuit (connected via a 100mb interface). And 30 remote sites varying 1-5mb, in all totalling 40mb.

I read a few posts including

and its still not clear to me how this would work.

For example, if I create child policies that match each remote site subnets, shape the traffic and include a sub-child that prioritises voice etc, that makes sense to me. However I have to have an overall shaping limit of 10mb. So it seems I'd end up having a 3 tier nested policy.

But the actual policy attached to the interface, would merely be shaping to 10mb and referencing another policy that split each site out (as per the link I added). So I'd have an extra policy over and above that link.

Now how would this work? If traffic hits the interface but remains under 10mb, I'm assuming the policy attached to the interface would never get congested and therefore never reference the child policies. So would voice still get priority? If it was congested, how would the queueing and prioritisation then work.

I haven't setout the config yet, but thought I'd just bounce the idea first before I end up going down the wrong path.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
royalblues Thu, 05/22/2008 - 02:15

When you create a nested service policy, you generally shape the rate to the actual bandwidth and then define child policies.

Remember QoS comes into picture only when there is congestion. During times of congestion the shaping will cause the router to delay packets and during this time, the packets will be prioritized based on the child policies .

If there is no congestion, there would not be a need for prioritising the traffic



billybjo1 Thu, 05/22/2008 - 06:43

Yes I agree QoS only gets used under congestion, but once the shaping command is added, I though that was used all the time regardless if there was congestion or not. Can you clarify?

The reason I'm trying to have nested shaping also is to attempt to shape the bandwidth down to the same as each remote site. I.e. only send 1mb to 1mb remote sites. But I would still have to ensure overall the limit is 10mb. Thats the bit that confuses me, maybe it isn't possible?

royalblues Thu, 05/22/2008 - 07:08

Shaping becomes active when the packets exceeds the traffic contract.

When traffic exceeds, the shaper needs to queue the packet. Now if you have defined some child policies then the shaper queues the packet as per the configuration rather than using the normal FIFO queue.


Joseph W. Doherty Fri, 05/23/2008 - 04:34

I understand, I think, exactly what you want to accomplish, but don't believe you can accomplish your goals within a single outbound service policy on your hub router.

What you might be able to accomplish, if your MPLS provider supports QoS on their MPLS egress devices (the PEs), configure the hub's outbound policy to queue important traffic as necessary when there's congestion at the hub's outbound 10 Mbps (either via a 10 Mbps shaper or set the physical interface to 10 Mbps) regardless of destination; then rely on the provider's egress QoS to queue as necessary based on traffic ToS markings. Ideally, the provider would implement a QoS on their MPLS egress that would be want you wanted to accomplish within a child policy on your hub, however most MPLS providers aren't that cooperative.

So for instance, if there's hub outbound congestion, VoIP packets go first (i.e. LLQ). Regardless of hub congestion, and assuming VoIP packets are marked, the MPLS provider also sends them first if there's remote site MPLS egress congestion.


If the HQ hub 10 Mbps service limitation applies both to inbound and outbound, change the interface to 10 Mbps. If the limitation is just to HQ outbound, i.e. your remote sites can send their aggregate 40 Mbps to the hub, use a hub outbound shaper. (The reason for the suggestion, physical interfaces "shape" better than the software shapers.)


This Discussion