01-12-2012 12:08 PM - edited 03-04-2019 02:53 PM
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
01-12-2012 01:17 PM
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
01-12-2012 07:06 PM
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.
01-12-2012 07:21 PM
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.
01-12-2012 07:29 PM
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!
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:
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 |
---|---|
|
|
01-12-2012 07:38 PM
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
01-12-2012 08:12 PM
Give me an output of 'sh policy-map interface
This should tell you if you're hitting your target shape rate...total drops should be an indicator of that.
-Chris
01-14-2012 04:57 AM
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.
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