From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 15

383 Words. Plan about 2 minute(s) to read this.

Class-based WFQ and low-latency queuing (which I’ll blog about in the next post) are best of breed queuing methods that take from PQ, CQ and WFQ, plus add new features of their own.

CBWFQ Key Points

  • Classification – can classify any traffic that MQC commands match
  • Drop policy – tail-drop or WRED (which we’ll talk about later), configurable per queue
  • Number of queues – 64
  • Max queue length – varies by router model and memory
  • Scheduling inside a single queue – FIFO on 63 queues. FIFO or WFQ on the “class-default” queue. Cisco 7500s support WFQ on all 64 queues.
  • Scheduling among all queues – scheduler provides a percentage of guaranteed bandwidth to each queue

CBWFQ Commands

  • bandwidth {kbps | percent <percentage>} – a class subcommand; set literal or a percentage bandwidth for the class
  • bandwidth {remaining percent <percentage>} – a class subcommand; sets a percentage of remaining bandwidth for the class
  • queue-limit <queue-limit> – a class subcommand; sets the maximum length in packets of a CBWFQ queue.
  • fair-queue [queue-limit <value>] – a class subcommand; enables WFQ for the “class-default” only.
  • max-reserved-bandwidth – interface subcommand; the percentage of link-bandwidth that can be reserved for queues other than the class-default queue – defaults to 75%.

Defining and Limiting CBWFQ Bandwidth

  • IOS will check to see that a “service-policy output” command does not allocate too much bandwidth on an interface, and will reject the command if it does. IOS determines this by looking at the “bandwidth” command on the interface and the “max-reserved-bandwidth” statement in the policy map.
  • Let’s say you have an interface with “bandwidth 512”. If you leave the max-reserved-bandwidth at the default of 75%, the most bandwidth you can therefore allocate is 384Kbps.
  • It is possible to change max bandwidth, as mentioned above, but Cisco does not recommend this.
  • You can define bandwidth as a percentage, rather than a specific bit rate.
    • “bandwidth percent <percentage>” reserves bandwidth for a traffic class as a percentage of the interface bandwidth. IOS verifies that all of these together do not exceed max-reserved-bandwidth.
    • “bandwidth remaining percent <percentage>” where remaining in this context means the reservable bandwidth, by default 75%. So…it’s really a percentage of how ever much the max reservable is. The book mentions that this is more useful in LLQ.