CCIE Cert Guidge — QoS notes Part II

Congestion Management and Avoidance

· Software vs Hardware Queues:

o Hardware queues are called, Transmit queue (TX queue) or Transmit ring (TX ring) – depending on the model.

o IOS automatically shrinks the length of the hardware queue to smaller length than the default when a queuing tool is present.

o ONLY function of a hardware queue that can be manipulated is the LENGTH OF THE QUEUE.

o “show controllers serial 0/0”

o tx-ring-limit 1 (set tx ring limit to 1).

· Queuing Tools: CBWFQ and LLQ

o PQ and CQ legacy queuing methods are no longer covered.

o WFQ is covered in context of CBWFQ, not alone

o CBWFQ reserves bandwidth for each queue and provided ability to use WFQ for packets in the class-default queue.

o LLQ adds to CBWFQ the concept of priority queue but unlike PQ, prevents high priority queue from starving other queues.

o configuration for LLQ and CBWFQ is exactly the same EXCEPT whether bandwidth command (CBWFQ) or the priority command (LLQ) is used to configure.

o each class defines a single queue, that’s why sometimes class and queues are used interchangeably.

o both support 64 queues/classes.

o Both have special class, “class-default queue”.

o CBWFQ configuration:

§ guarantees a minimum percentage of a link’s bandwidth to each class/queue. If some queues are empty and do not need their bandwidth for a short period, the bandwidth is proportionally allocated across the other classes.

§ it drops based on “Tail drop” or WRED and can be configured per queue.

§ Commands:

· bandwidth {in kbps or percent}

· bandwidth {remaining percent}

· queue-limit {sets the max length of cbwfq}

· fair-queue [queue-limit]: enabled WFQ on class-default only.

· max-reserved-bandwidth: defines % of link that can be reserved for CBWFQ besides class-default (default: 75%)

· load-interval 30 (how often it’s updated, 30 seconds)

§ Input is not allowed on routers for policy maps that perform queuing.

§ IOS checks CBWFQ policy map to ensure it does not allocate too much bandwidth.

§ IOS performs the check when the “service policy output” command is added.

§ defines bandwidth based on: bandwidth command and max-reserved-bandwidth commands.

§ IOS allows a policy map to allocate bandwidth based on the product of int-btw and max-res. E.g: with default max-res of 75 on an interface with int-bw of 256 (256kbps), the policy map could allocate 192kbps.

§ To avoid problems: bandwidth command must not total more than max-res X int-bw.

§ “bandwidth percent” sets class’s reserved bandwidth as a % of int-bw. Bandwidths <= max-res%. IOS checks all the bandwidth percent commands in a single policy map to ensure that the total does not exceed the max-res setting for that interface. In other words, with default setting for max-res, all the bandwidth percent commands in a single policy cannot exceed more than 75.

§ “bandwidth remaining percent”: remaining bandwidth is the reservable bandwidth. E.g. remaining bandwidth would be 75% x 128 kbps or 96kbps. The command “bandwidth remaining percent 50” would allocate 48kbps for a class.

o LLQ Configuration

§ for delay (latency) sensitive traffic, LLQ is the tool of choice.

§ like CBWFQ but adds the capability for some queues to be configured as LLQ (specific queues as strict priority queues).

§ Sometimes a single LLQ is called “the LLQ” or “the PQ”. But LLQ polices the PQ based on the configured bandwidth.

§ Bandwidth given to the LLQ PQ is both guaranteed minimum and policed maximum.

§ use the “priority {bandwidth kbps | percent percentage} [burst]” command instead of bandwidth command.

§ class subcommand: enables LLQ, reserves bandwidth and enables policing function.

§ Burst size by default is 20% of configured bandwidth.

§ IOS allows both the explicit and percentage version of the priority command inside the same policy map.

§ the actual bandwidth from both LLQ classes (with priority commands) and non-LLQ classes (with bandwidth commands) not allowed to exceed max-res x int-bw.

§ class percent is percentage of Link Bandwdith.

§ LLQ > 1 PQ:

· LLQ places packets from multiple LLQs into a single internal LLQ.

· why use multiple priority queues? for POLICING. By policing traffic in one class at one speed, and traffic in another class at another speed, you get more granularity for the policing function of LLQ.

o IOS will not allow “priority” command in “class-default”.

o When class class-default does not have a “bandwidth” command, IOS internally allocates any unassigned bandwidth among all classes. As a result, class class-default might not get much bandwidth unless the class is configured a minimum amount of bandwidth using the bandwidth command.


o WRED uses the measured “average queue depth” when deciding if a queue has filled enough to begin discarding packets.

o WRED then compares the avg depth to min and max queue threshold, performing different discard actions depending on the outcome.

o if avg depth > max threshold (drop all like tail drop)

o if avg depth < max threshold and > than min threshold, random drop is done.

o “full drop” to distinguish from “tail drop” (all new packets are discarded).

o Mark probability Denominator (MPD), from which the discard percentage used at the max threshold is derived, using 1/MPD.

o WRED method of weighing:

§ uses different traffic profile for packets with different IPP and DSCP values

§ traffic profile based on: min threshold, max threshold and MPD.

§ MPD of 20 is 1/20 = 5% drop. higher MPD means lower discard percentage.

§ DSCP values ending with 1 get better treatment than values of 2 and 3.

o WRED Configuration

§ WRED can only be configured on the following locations:

· physical interface (with FIFO queuing)

· non-LLQ class inside CBWFQ policy map

· for an ATM VC

§ for physical interface, IOS disables all other queuing mechanisms and creates a single FIFO queue.

§ for CBWFQ, WRED is configured in a class inside a policy map.

§ random-detect” command enables WRED IPP based. To enable dscp based, use “random-detect dscp-based

§ to change values use either “random-detect precedence” or “random-detect dscp”

§ exponential-weighting-constant – to affect calculation of rolling average queue depth.

· MDRR (Modified Deficit Round Robin)

o only by Cisco 12000 series routers.

o replaces CBWFQ and LLQ

o allows classifying traffic into seven round-rabin queues (0-6), with one additional priority queue.

o when no packets in the PQ, MDRR services its queues in a round-robin approach, once per cycle.

o with packets in PQ, has 2 algos, Strict Priority mode and Alternate Priority Mode

o Strict Pri Mode: serves PQ whenever traffic is present in that queue. (may lead to starvation)

o Altername Mode: serves PQ in b/w serving each of the other queue. (every other cycle, PQ is serviced)

o Can cause jitter and latency for traffic in PQ.

o MDRR removes packets from a queue until the Quantum Value (QV) for that queue has been removed. QV quantifies a number of bytes and is used much like the byte count is used by the CQ scheduler.

o MDRR deals with the CQ scheduler’s problem by treating any “extra” bytes sent during a cycle as a “deficit”.

o Formula: (QV for Queue X)/(Sum of All QVs)


One thought on “CCIE Cert Guidge — QoS notes Part II

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s