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.
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.
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.
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:
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.
QoS Policy Propagation through Border Gateway Protocol (BGP) (QPPB)
Input common classification
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 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)
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.
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.
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
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.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...