I have some puzzles on configuration qos on 7609 with sup720-3B and 6724-SFP line card as below:
transmit queue capability for 6724-SFP: 1P/3Q/8T
as we konw, traffic on PQ will be forwarded before other standard queue, and WRR can allocate different bandwidth to different queue. Does it mean traffic on PQ cannot be limit bandwidth? On ios command, wrr-queue bandwidth ** ** **, we can allocate bandwidth ratio to Q4, that is pq? Is my understand right?
there is ios command: wrr queue-limit ** ** **, allocate 3 queue-limit to 3 standard queue, but i found some document say: wrr queue-limit 20 20 20, that is allocating 20% to q1, 20% to q2, 20% to q3, and left 40% to q4(pq). I cann't understand: since pq will handle strictly before other 3 standard queue, why we need leave some queue size to PQ. (PQ will be forward out of the interface without needing to enter the buffer). Am i right?
for queue-limit ratio, who can give me some recommedation or best practice? For example, if i will allocate 25% to Q1(best effort & bronze), 25% to Q2(Silver), 30% to Q3(Golden), 20% to Q4(PQ for voice), how will i should allocate queue-limit?
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.
Cisco does have some bandwidth percentages recommendations in their later 11 (or is it 12) class QoS model. But bandwidth reservations are really subject to what your traffic mix is and your service requirements.
I do have my own personal generic QoS model. It uses 4 classes like:
priority percent 40
bandwidth remaining percent 81
bandwidth remaining percent 1
bandwidth remaining percent 9
Conceptionally, traffic that has real-time service requirements, e.g. VoIP bearer, is directed to the real-time class. By default (laugh) everything else goes to the default class (where fair-queue proportions bandwidth per flow). If some traffic really needs priority treatment, it's directed to the foreground class. An example might be something like a screen scraping (e.g. Citrix, RDP) app. (Basically traffic that wants RT like treatment, but doesn't require true RT treatment.) Lastly, traffic that isn't in any rush and might want lots of bandwidth (e.g. server backup), is directed to the background class. (Basically such traffic only gets a minimal guarantee, but is allowed to use any and all available bandwidth, i.e. bandwidth not otherwise needed by any more "important" traffic.)
Unfortunately, devices like 6500 LAN cards don't support FQ, so you often need to carefully distinguish what class (6500 queue) traffic should be directed to and if you push more toward the foreground class, such that it risks excessively delaying the default class, you might want to reduce its bandwidth guarantee and increase default's.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...