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
What this means is that per cent you allocate to the bandwidth is a minimum ie. it can use more than that if there is spare capacity to use but if the interface is congested it will get the per cent you allocated to it.
Yes and no. Class will get the percent allocated if all the class percents sum to 100 and all the classes want more than their allocation.
For example:
policy-map sample
class a
bandwidth percent 25
class b
bandwidth percent 25
class c
bandwidth percent 50
If there was no class c traffic, and classes a and b both wanted all the bandwidth, each would get 50%. If there was no class b traffic, and classes a and c both wanted all the bandwidth, class a would get 1/3 and class c would get 2/3.
The key to understanding bandwidth allocations, whether percentage or absolute, it really sets dequeuing scheduling ratios between the classes, so the above would be 1:1:2
As John noted the priority queue is policed but packets that are marked for the priority queue can use excess bandwidth but as far as i know if they use any excess bandwidth the packets are not treated as priority packets.
Correct, because LLQ packets are only policed when they actually queue in the LLQ. When then are not in the LLQ, they are FIFO on the tx-ring (interface hardware queue).
If you apply an outbound policy then yes if you have not marked the packets anywhere else then you would need to mark the packets on an inbound policy on the router. You may be able to mark the packets on a switch which presumably you have. if you do and the switch supports it, it is worth marking the DCSP value as this would not then need to remarked on the router.
Packets don't need to be ToS marked, unless you're examining the markings for some purpose such as for classification.
In John's first post, he's using NBAR classification, and he mentions ACL classification; both will work just fine without any kind of ToS marking.
The advantage of ToS marking, it's less for the device to examine when doing classification.
As to the merits of marking/trusting as close to the source as possible, that's the "book" answer, but in practice, often QoS isn't critical on LAN and can be real pain to manage on a LAN. (You can also run into the need to tune buffers if you don't want QoS activation performance to drop in a 2K or 3K switch.) If you have only a few WAN interfaces, which are likely to congest because of much less bandwidth than the LAN supports, I've found it pretty effective doing an egress policy similar (perhaps with a few more classes) to what John shows in his first posting.
