nested qos, which takes priority

[Mike Schooley]

I have a policy that first shapes the traffic to the correct bandwidth, then applies LLQ, then of course the cos_out has ef, af41, etc with different bandwidths.  So my question is I'm seeing a lot of buffer drops, are these packets being dropped before LLQ is applied as when the link gets congested, my voice quality goes to heck.  what I think is happening is the traffic is shaped, therefore buffered if busy, becuase of this there are a lot of buffer drops, then the llq is applied as I am seing no exceeded bandwidth drops on my priority queue.  Perhaps I should remove the shaping.

policy-map COS-OUT-SHAPE-1544000

class class-default

   shape average 1446000

service-policy COS_OUT

[lgijssel]

Hey Mike,

You need the shaping when the available (by contract) bandwidth is less than the interface speed.

Ex: 10Mb over a 100Mb interface.

In this case it looks like a T1 and you could give it a try.

regards,

Leo

[Mike Schooley]

that doesnt answer the question, and it the example is just an example, but lets say its a t1 and we burst to 2mb, therefore the router has to buffer a lot of traffic and lets say the buffers get full and there are buffer drops, so the question is does it apply the qos, mainly the priority queue, first and send the ef traffic thru before anything gets buffered, or does it buffer traffic first, there by possibly dropping voip traffic before it even reaches the priority queue, pretty much negating the the priority queue.

[Mike Schooley]

i understand the thought of shaping to match purchased cir, but let say you dont shape and the carrier has the same priority queue as you do, therefore, they will forward all ef traffic first before dropping any traffic and the only traffic that wil be dropped will be lower priority traffic  that exceeds the bandwidth, vs shaping and dropping it before you reach your priority queue because you ran out of memory.  I guess I could look at some buffer tunning also.  To me if I am shaping/buffering so much that I am having buffer drops, I am negating my priority queue.

[cflory]

It would probably help to see your QoS configuration, instead of the example.  The reason for that, is to see if perhaps your class-maps are out of order.  As you can see from the info provided below (taken from http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080160fc1.shtml), it describes how matching terminates at the first matching class.  If your shaping is matching prior to your LLQ, then indeed you could be affecting your voice.  HTH!

Common Classification

Classification is the process of defining traffic classes that sort traffic into categories groups of flows. Classification defines the "match criteria" for each class of traffic that is to be treated by a QoS policy. More specifically, it defines the "traffic filter" that packets are checked against when a service-policy is applied.

Both distributed and non-distributed platforms match packets to a single class in a policy-map. Matching terminates at the first matching class. If two classes within a policy-map match the same IP precedence or IP address range, the packet always belongs to the first matching class. For this reason, class order within a policy-map is very important.

This classification approach is called "common classification" and has these benefits:

• Accurate accounting and the avoidance of double-accounting problems that were seen before "common classification".
• Reduces the impact of access control lists (ACLs) on the CPU since the ACL is checked once per class, rather than once per feature.
• Faster lookup of packet headers because of caching.

Common classification is enabled automatically when you attach an input or output policy-map with the service-policy command.This table illustrates the order of operation with common classification. It is important to understand from the table when classification occurs in the context of QoS features. On the inbound path, a packet is classified before it is switched. On the outbound path, a packet is classified after it is switched.

Inbound	Outbound
QoS Policy Propagation through Border Gateway Protocol (BGP) (QPPB) Input common classification Input ACLs Input marking (class-based marking or Committed Access Rate (CAR)) Input policing (through a class-based policer or CAR) IP Security (IPSec) Cisco Express Forwarding (CEF) or Fast Switching	CEF or Fast Switching Output common classification Output ACLs Output marking Output policing (through a class-based policer or CAR) Queueing (Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ)), and Weighted Random Early Detection (WRED)

[Mike Schooley]

actually I misread my output, I thought they were no buffer drops but its total drops, any idea what the total drops are from?

Class-map: class-default (match-any)

      19776906231 packets, 7826541851222 bytes

      5 minute offered rate 2728000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/24618044/0

      (pkts output/bytes output) 2572419154/7805690425780

      shape (average) cir 30000000, bc 120000, be 120000

      target shape rate 30000000

[cflory]

Give me an output of 'sh policy-map interface | inc rate|Class'

This should tell you if you're hitting your target shape rate...total drops should be an indicator of that.

-Chris

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

actually I misread my output, I thought they were no buffer drops but its total drops, any idea what the total drops are from?
Class-map: class-default (match-any)
      19776906231 packets, 7826541851222 bytes
      5 minute offered rate 2728000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/24618044/0
      (pkts output/bytes output) 2572419154/7805690425780
      shape (average) cir 30000000, bc 120000, be 120000
      target shape rate 30000000

Those drops are queue overflow drops.  I.e. Trying to add a packet to the queue when your queue contains 64 packets.

As to your initial issue about poor VoIP performance, there can be many reasons why your QoS policy isn't performing as expected.  Some include:

Some shapers don't account for L2 overhead (solution shape slower)

Hardware queue is FIFO (solution reduce TX-ring size)

Shaper's Tc might be too large

As Leo asked if this was a real T1, you wouldn't need to shape.  QoS, I've found, performs a better on against a real interface.

In answer to one of your later post questions, CBWFQ only queues when the hardware interface FIFO queue "overflows".  When a shaper is involved, it generally will create flow queues, which seem to be managed WFQ, at least before HQF QoS.  If a shaper has a subordinate/child policy defined, it pushes packets into those queues, although I've haven't seen clear documentation whether is still continues to manage its own queues. I've seen some platforms seem to show it might.