QoS - combine LLQ policer with shapers in one policy-map?

[hgans]

Hello,

I have to ask this, because I've never seen this configuration in any design/config guide....

Usually I use the bandwidth (bandwidth remaining percent) configuration, especially when LLQ is needed.

The requirement in this special case is to have one priority queue policed to a fixed rate for real time traffic.

All other classes should be shaped to a fixed amount of bandwidth, the total bandwidth of the interface (GigabitE) is much higher, than the sum of all configured shapers...

The policy is applied outgoing to a Gigabit interface.

My developed configuration looks like this:

policy-map L1
class L1_RT
    priority 10000
   police rate 10000000 bps burst 50000 bytes
     conform-action set-dscp-transmit ef
     exceed-action set-dscp-transmit ef
     violate-action drop
class L1_SI
    shape average 60000000
   set dscp af41
class L1_BC
    shape average 50000000
   set dscp af23
     random-detect dscp-based
class L1_NM
    shape average 1000000
   set dscp cs6
class L1_BS
    shape average 60000000
   set dscp cs1
class class-default
    shape average 2000000
     random-detect
   set dscp default

I don't see a problem in this config, but I am not sure how queueing works here for the different classes and I am very thankful for all inputs regarding this...

Regards

[milan.kulik]

Hi,

a) I'm missing match commands in your Class configurations,

b) wouldn't there be more effective to configure a hierarchical policy which  would shape the whole outgoing traffic while reserving bandwidth for particular (non-priority) classes with the bandwidth ... commands?

When shaping particular classes, you might be not using a bandwidth not-used by other classes at the moment.

HTH,

Milan

[hgans]

Hi Milan,

ad a)

I do the matching over the class itself, it's pointing to an access-list, so this is ok.

ad b)

Yes, that's right. But in this case the requirement says: Do not allow a certain class to oversubscribe the defined bandwidth per class.

More background of this config: My config on the CPE and on the backbone they use incoming policers per class.

The targets on CPEs are to mark traffic according to customer needs and to guarantie that a class can only obtain a certain amount of bandwidth - so that in an ideal world the policers on providers side are not going into dropping thresholds...

br,

Herwig

[Lei Tian · Accepted solution]

Hi Herwig,

With your config, class L1_RT will never exceed the configured rate, other classes will be shaped down to the configured rate. When the GE interface is congested, class L1_RT will be served first among all other traffic, and no bandwidth guarantee for any other class.

One thing I noticed is you might need to configure a exceed burst to use double buckets policer.

HTH,

Lei Tian

[milan.kulik]

Hi Lei,

if I understand the config correctly, the GE interface will never get congested, as all classes are shaped or policed (total sum of bandwidth consumed should be shaped to 174 Mbps if I'm calculating correctly).

So the priority queueing will not work properly, I'm afraid.

That's another reason for creating a hierarchical policy shaping ALL traffic to 174 Mbps (or similar value), isn't it?

HTH,

Milan

[hgans]

Milan,

Yes, I also think the LLQ itself will have no affect in that way to serve this packets before all other classes, because there will never be congestion on the physical link.

The policer for RT is just used that this class is also regulated to a certain amount of bandwidth.

So practically I could also create a standard queue instead of the priority queue for my realtime traffic in my case i guess.

Regards

Herwig

[milan.kulik]

Hi Herwig,

as you are using 1 Gbps line to your provider which is never loaded more then 20% and each traffic class is policed separately by the provider,

it seems you really "could also create a standard queue instead of the priority queue for the realtime traffic" in this unusual case.

BR,

Milan

[Lei Tian · Accepted solution]

Hi Milan,

You are absolutely correct. The GE interface will not get congested. If the interface is a sub-rate of GE from PE, hqos is needed. Otherwise, no queueing is required, all traffic will  pass the tx-ring with FIFO fashion.

HTH,

Lei Tian

[hgans]

Thanks Lei,

Right,I think this answers my question.

Using bandwidth to give guaranties in case of interface congestion is the usual approach.

Since I also shape the default-class, the interface will never get congested.

I will check the policer with exceed rate - maybe in my case it's using a self calculated value... I'm not sure.

Regards,

Herwig