For delay sensitive traffic, LLQ is the best choice to ensure good performance. It works pretty much like CBWFQ but adds the capability for some queues to be configured as low-latency. These are treated as strict priority queues, meaning LLQ always services packets in them first.
Confusion over terms can arise because even a single policy map with one low latency queue configured is known as LLQ. Also, the older Priority Queuing (PQ, no longer in use) is simliar to LLQ and sometimes a single LLQ may be called a ""priority queue." This is due to the IOS command used to configure a low latency queue- priority.
LLQ queue adds a low latency queue, but prevents queue starvation which was a problem under the older PQ. LLQ will in fact police the low latency queue, making the configured bandwidth both a guaranteed minimum and a policed maximum. So while low latency is guaranteed, some packets might still be dropped to prevent starvation of other queues.
The priority command is the only addition to queuing configuration commands in IOS for LLQ. It's used instead of the bandwidth command during class configuration. The full syntax is-
priority { bandwidth-kbps | percent percentage } [ burst ]
An example LLQ configuration follows, taken from the text. It assumes all traffic is already marked as EF, etc.
policy map queue-on-dscp
class dscp-ef
priority 58
class dscp-af41
bandwidth 22
class dscp-af21
bandwidth 20
random-detect dscp-based
class dscp-af23
bandwidth 8
random-detect dscp-based
class class-default
fair-queue
random-detect dscp-based
interface Serial0/0
bandwidth 128
max-reserved-bandwidth 85
service-policy output queue-on-dscp
More on Defining and Limiting Bandwidth for LLQ
The priority command for LLQ provides you two choices- define bandwidth as a set number or as a percentage of the total interface bandwidth (the latter is because there's no remaining percent option). Unlike the bandwidth command, you can use both choices within a single policy map. Madness, isn't it?
Of course, you've still got an upper limit set by IOS on total bandwidth usage: max reserved bandwidth times interface bandwidth. Both LLQ and non-LLQ classes can't exceed this magic number. Because both options for the priority command can be used in a single policy map, calculating this number can be confusing unless you pay careful attention. As the book states, you could have one LLQ using the priority option for bandwidth #, another LLQ with bandwidth %, and non-LLQ queues using one of the three bandwidth options.
Let's look at an example using a 256 kbps interface and 3 classes. The unreservable bandwidth is 25% of that, or 64 kbps. Let's say class 1 is configured with priority 32, class 2 with priority percent 25, and class 3 has bandwidth remaining percent 75. This means 32 kbps is used for class 1, 64 kbps for class 2, and 72 kbps for class 3.
As I mentioned before, the calculation for the command bandwidth remaining percent changes when priority queuing is in place. Normally, the command calculates bandwidth remaining as interface bandwidth minus reserved bandwidth (default value 25%). With LLQ in place, this calculation becomes interface bandwidth minus reserved bandwidth minus bandwidth allocated thru priority commands.
Also worth mentioning at this point is why you'd configure multiple queues with the priority command. The answer is policing of traffic. Although you may configure multiple LLQ queues, in reality all these packets will be dumped into one prioritized queue, which will then be serviced FIFO. However, the policing of traffic for each LLQ queue will still take place. Typically, this is used to separately police voice and videoconferencing traffic. Sometimes you'll want to rate limit separately like this.
Miscellaneous Notes
You'll want to configure a bandwidth command under the class class-default. Otherwise, IOS will divide any unallocated bandwidth equally among all classes; this can result in the class-default class having a very small amount of bandwidth.
Similarly, if a queue is empty, IOS will dynamically attempt to redistribute that bandwidth to other queues in proportion to their configured bandwidth commands. Finally, IOS will only use queuing when congestion occurs. Since applying a queuing policy causes IOS to shorten the hardware queue automatically (generally to 1 or 2 packets), "congestion" will occur frequently, ensuring that your QoS policy is enforced on almost all traffic!
Also of note is flow based classification. While only briefly referenced in the text (and in a table at that), flow based classification is for achieving finer granularity in applying QoS. Specifically, it's intended for User Based Rate Limiting.
Confusion over terms can arise because even a single policy map with one low latency queue configured is known as LLQ. Also, the older Priority Queuing (PQ, no longer in use) is simliar to LLQ and sometimes a single LLQ may be called a ""priority queue." This is due to the IOS command used to configure a low latency queue- priority.
LLQ queue adds a low latency queue, but prevents queue starvation which was a problem under the older PQ. LLQ will in fact police the low latency queue, making the configured bandwidth both a guaranteed minimum and a policed maximum. So while low latency is guaranteed, some packets might still be dropped to prevent starvation of other queues.
The priority command is the only addition to queuing configuration commands in IOS for LLQ. It's used instead of the bandwidth command during class configuration. The full syntax is-
priority { bandwidth-kbps | percent percentage } [ burst ]
An example LLQ configuration follows, taken from the text. It assumes all traffic is already marked as EF, etc.
policy map queue-on-dscp
class dscp-ef
priority 58
class dscp-af41
bandwidth 22
class dscp-af21
bandwidth 20
random-detect dscp-based
class dscp-af23
bandwidth 8
random-detect dscp-based
class class-default
fair-queue
random-detect dscp-based
interface Serial0/0
bandwidth 128
max-reserved-bandwidth 85
service-policy output queue-on-dscp
More on Defining and Limiting Bandwidth for LLQ
The priority command for LLQ provides you two choices- define bandwidth as a set number or as a percentage of the total interface bandwidth (the latter is because there's no remaining percent option). Unlike the bandwidth command, you can use both choices within a single policy map. Madness, isn't it?
Of course, you've still got an upper limit set by IOS on total bandwidth usage: max reserved bandwidth times interface bandwidth. Both LLQ and non-LLQ classes can't exceed this magic number. Because both options for the priority command can be used in a single policy map, calculating this number can be confusing unless you pay careful attention. As the book states, you could have one LLQ using the priority option for bandwidth #, another LLQ with bandwidth %, and non-LLQ queues using one of the three bandwidth options.
Let's look at an example using a 256 kbps interface and 3 classes. The unreservable bandwidth is 25% of that, or 64 kbps. Let's say class 1 is configured with priority 32, class 2 with priority percent 25, and class 3 has bandwidth remaining percent 75. This means 32 kbps is used for class 1, 64 kbps for class 2, and 72 kbps for class 3.
As I mentioned before, the calculation for the command bandwidth remaining percent changes when priority queuing is in place. Normally, the command calculates bandwidth remaining as interface bandwidth minus reserved bandwidth (default value 25%). With LLQ in place, this calculation becomes interface bandwidth minus reserved bandwidth minus bandwidth allocated thru priority commands.
Also worth mentioning at this point is why you'd configure multiple queues with the priority command. The answer is policing of traffic. Although you may configure multiple LLQ queues, in reality all these packets will be dumped into one prioritized queue, which will then be serviced FIFO. However, the policing of traffic for each LLQ queue will still take place. Typically, this is used to separately police voice and videoconferencing traffic. Sometimes you'll want to rate limit separately like this.
Miscellaneous Notes
You'll want to configure a bandwidth command under the class class-default. Otherwise, IOS will divide any unallocated bandwidth equally among all classes; this can result in the class-default class having a very small amount of bandwidth.
Similarly, if a queue is empty, IOS will dynamically attempt to redistribute that bandwidth to other queues in proportion to their configured bandwidth commands. Finally, IOS will only use queuing when congestion occurs. Since applying a queuing policy causes IOS to shorten the hardware queue automatically (generally to 1 or 2 packets), "congestion" will occur frequently, ensuring that your QoS policy is enforced on almost all traffic!
Also of note is flow based classification. While only briefly referenced in the text (and in a table at that), flow based classification is for achieving finer granularity in applying QoS. Specifically, it's intended for User Based Rate Limiting.
