Queuing, or congestion management, is used to manage frames before they exit a device. In routers this is known as output queuing because IP forwarding decisions are made prior to the queuing. Congestion avoidance is a term for managing traffic to decide if/when packets will be dropped during congestion periods. The most common congestion avoidance tool is Weighted Random Early Detection (WRED).
The concept of fancy queuing is defined as using congestion avoidance and management techniques. This is as opposed to simple queuing where you use FIFO. Hardware queuing always uses simple queuing (FIFO) and has the following characteristics:
IOS queuing tools maintain software-based queues that feed into the hardware queue, on a per-interface level. Queuing tools can also be used along side traffic shaping, which basically delays packet(s) to ensure that the traffic rate for a class doesn't exceed the defined rate. If you use shaping, it queues packets (by default into a FIFO queue). Also, depending on the shaping tool(s) used, you might be able to manipulate the delayed packets using a queuing tool. However, this won't be discussed until Chapter 14.
The book lists 5 major queuing tools in use with IOS: classification, drop policy, scheduling, maximum number of queues, and maximum queue length. Brief notes on each include:
Classification- checking packet headers to select a queue
Drop Policy- rules for dropping packets during congestion
Scheduling- logic for which packet to dequeue and send next
Max # Classes- how many classes of packets a queuing tool can utilize or is configured to use
Max Queue Length- upper limit of packets contained in a single queue
Queuing Tools: CBWFQ and LLQ
Class Based Weighted Fair Queuing (CBWFQ) reserves bandwidth for each individual queue and provides a way to implement WFQ for the class-default queue. Low Latency Queuing (LLQ) implements a Priority Queue (PQ) in addition to CBWFQ, but unlike the original PQ there can be no starvation of other queues. Both are configured via MQC with its wealth of classification options.
The largest implementation difference is whether you use the bandwidth command (CBWFQ) or the priority command (LLQ). Both support up to 64 queues or classes. Both implement a special queue known as the default (class-default) queue. If a packet fails to match any class-map specifications it is handled by the default queue.
CBWFQ Features and Configuration
CBWFQ implements a scheduler to guarantee a configured percentage of bandwidth to each queue. However, if some queues are empty, bandwidth will be allocated across other classes temporarily. CBWFQ implements that standard classification features. Its drop policy choices include either WRED or tail drop, configurable per queue.
As said, there can be up to 64 queues. Max queue length support varies according to the model of router used. Within each queue, CBWFQ uses FIFO scheduling, except for the class-default, which can use either FIFO or WFQ.
Command Reference
bandwidth { kbps | percent percentage }
Class level subcommand; sets BW %
bandwidth { remaining percent percent }
Class level subcommand; sets aside a % of remaining BW for the class
queue-limit queue-limit
Class level subcommand; sets the maximum length for a queue in packets
fair-queue [ queue-limit queue-value ]
Class level subcommand; enables QWFQ in the class (class-default only)
max-reserved-bandwidth percent
Interface level subcommand; sets % of link BW for all classes except class-default. Defaults to 75%
An example config
This is an example config which would place VOIP traffic into one queue and everything else into class-default.
class-map match-all voip-rtp
match ip rtp 16384 16383
policy-map queue-voip
class voip-rtp
bandwidth 64
class class-default
fair-queue
interface Serial0/0
encapsulation frame-relay
load-interval 30
bandwidth 128
service-policy output queue-voip
Define and Limit CBWFQ Bandwidth Usage
When you apply a service policy to an interface, IOS checks the configured bandwidth (using the bandwidth command) against the bandwidth defined for the policy. The policy defines bandwidth needs using two subcommands- bandwidth and max-reserved-bandwidth. Nonreservable bandwidth is meant for use by overhead traffic.
When defining the bandwidth for CBWFQ, the policy-map uses the product of the bandwidth and max-reserved-bandwidth commands. So if the interface bandwidth is set to 512 kbps and the max reserved value is 75 percent, the policy-map has 384 kbps of bandwidth which can be allocated among the various queues (or bandwidth commands). If the policy-map allocates more total bandwidth than would be available using this calculation, IOS will reject the policy (you can't apply it). Go do some math and try again!
If you're thinking of just changing the max-reserved-bandwidth setting instead to a higher number, be aware that Cisco doesn't recommend you monkey with the defaults unless you know what you're doing. Another way to allocate bandwidth without specifying traffic size in kbps is to use bandwidth percent or bandwidth remaining percent. This makes it unlikely you will oversubscribe. The trade off is you still need to be certain how much bandwidth in kbps is allocated to priority queues such as voice and video.
There's a bit of subtlety to using the latter two commands though. Bandwidth percent sets reserved bandwidth for a class as a percentage of the total interface bandwidth. Again, IOS will check the total value set using these commands within a policy map to ensure it doesn't violate the value set using max-reserved-bandwidth (default 75%).
Bandwidth remaining percent defines bandwidth as a percentage of remaining bandwidth. However, the calculation changes when LLQ is used. Remaining bandwidth is another name for the product of bandwidth and max-reserved-bandwidth. Taking my earlier example of a 512 kbps link, remaining bandwidth would be 384 kbps. If the command bandwidth remaining percent 50 were issued on a router, 192 kbps would be set aside for that particular class.
All total, there are three different bandwidth related commands in place here: explicit, percentage, and remaining percent. IOS will only allow you to use one of the three methods in a single policy map. The following table is taken direct from the book:
Method BW Amt Rsvd Sum BW Values Must Be <=
Explicit BW As per command Interface BW x Max-Rsv-BW
Percent % of interface BW Max Reserved BW setting
Remaining % % of reservable BW 100 %
The concept of fancy queuing is defined as using congestion avoidance and management techniques. This is as opposed to simple queuing where you use FIFO. Hardware queuing always uses simple queuing (FIFO) and has the following characteristics:
- No CPU interrupt is required between packet transmissions from the queue
- It cannot be affected by IOS queuing tools (since this is the last step before transmission on the wire)
- The only controllable function from IOS is queue length
- IOS automatically shrinks hardware queues when other queuing tools are in use
- These shorter hardware queues mean traffic is more likely to end up in configurable software queues
IOS queuing tools maintain software-based queues that feed into the hardware queue, on a per-interface level. Queuing tools can also be used along side traffic shaping, which basically delays packet(s) to ensure that the traffic rate for a class doesn't exceed the defined rate. If you use shaping, it queues packets (by default into a FIFO queue). Also, depending on the shaping tool(s) used, you might be able to manipulate the delayed packets using a queuing tool. However, this won't be discussed until Chapter 14.
The book lists 5 major queuing tools in use with IOS: classification, drop policy, scheduling, maximum number of queues, and maximum queue length. Brief notes on each include:
Classification- checking packet headers to select a queue
Drop Policy- rules for dropping packets during congestion
Scheduling- logic for which packet to dequeue and send next
Max # Classes- how many classes of packets a queuing tool can utilize or is configured to use
Max Queue Length- upper limit of packets contained in a single queue
Queuing Tools: CBWFQ and LLQ
Class Based Weighted Fair Queuing (CBWFQ) reserves bandwidth for each individual queue and provides a way to implement WFQ for the class-default queue. Low Latency Queuing (LLQ) implements a Priority Queue (PQ) in addition to CBWFQ, but unlike the original PQ there can be no starvation of other queues. Both are configured via MQC with its wealth of classification options.
The largest implementation difference is whether you use the bandwidth command (CBWFQ) or the priority command (LLQ). Both support up to 64 queues or classes. Both implement a special queue known as the default (class-default) queue. If a packet fails to match any class-map specifications it is handled by the default queue.
CBWFQ Features and Configuration
CBWFQ implements a scheduler to guarantee a configured percentage of bandwidth to each queue. However, if some queues are empty, bandwidth will be allocated across other classes temporarily. CBWFQ implements that standard classification features. Its drop policy choices include either WRED or tail drop, configurable per queue.
As said, there can be up to 64 queues. Max queue length support varies according to the model of router used. Within each queue, CBWFQ uses FIFO scheduling, except for the class-default, which can use either FIFO or WFQ.
Command Reference
bandwidth { kbps | percent percentage }
Class level subcommand; sets BW %
bandwidth { remaining percent percent }
Class level subcommand; sets aside a % of remaining BW for the class
queue-limit queue-limit
Class level subcommand; sets the maximum length for a queue in packets
fair-queue [ queue-limit queue-value ]
Class level subcommand; enables QWFQ in the class (class-default only)
max-reserved-bandwidth percent
Interface level subcommand; sets % of link BW for all classes except class-default. Defaults to 75%
An example config
This is an example config which would place VOIP traffic into one queue and everything else into class-default.
class-map match-all voip-rtp
match ip rtp 16384 16383
policy-map queue-voip
class voip-rtp
bandwidth 64
class class-default
fair-queue
interface Serial0/0
encapsulation frame-relay
load-interval 30
bandwidth 128
service-policy output queue-voip
Define and Limit CBWFQ Bandwidth Usage
When you apply a service policy to an interface, IOS checks the configured bandwidth (using the bandwidth command) against the bandwidth defined for the policy. The policy defines bandwidth needs using two subcommands- bandwidth and max-reserved-bandwidth. Nonreservable bandwidth is meant for use by overhead traffic.
When defining the bandwidth for CBWFQ, the policy-map uses the product of the bandwidth and max-reserved-bandwidth commands. So if the interface bandwidth is set to 512 kbps and the max reserved value is 75 percent, the policy-map has 384 kbps of bandwidth which can be allocated among the various queues (or bandwidth commands). If the policy-map allocates more total bandwidth than would be available using this calculation, IOS will reject the policy (you can't apply it). Go do some math and try again!
If you're thinking of just changing the max-reserved-bandwidth setting instead to a higher number, be aware that Cisco doesn't recommend you monkey with the defaults unless you know what you're doing. Another way to allocate bandwidth without specifying traffic size in kbps is to use bandwidth percent or bandwidth remaining percent. This makes it unlikely you will oversubscribe. The trade off is you still need to be certain how much bandwidth in kbps is allocated to priority queues such as voice and video.
There's a bit of subtlety to using the latter two commands though. Bandwidth percent sets reserved bandwidth for a class as a percentage of the total interface bandwidth. Again, IOS will check the total value set using these commands within a policy map to ensure it doesn't violate the value set using max-reserved-bandwidth (default 75%).
Bandwidth remaining percent defines bandwidth as a percentage of remaining bandwidth. However, the calculation changes when LLQ is used. Remaining bandwidth is another name for the product of bandwidth and max-reserved-bandwidth. Taking my earlier example of a 512 kbps link, remaining bandwidth would be 384 kbps. If the command bandwidth remaining percent 50 were issued on a router, 192 kbps would be set aside for that particular class.
All total, there are three different bandwidth related commands in place here: explicit, percentage, and remaining percent. IOS will only allow you to use one of the three methods in a single policy map. The following table is taken direct from the book:
Method BW Amt Rsvd Sum BW Values Must Be <=
Explicit BW As per command Interface BW x Max-Rsv-BW
Percent % of interface BW Max Reserved BW setting
Remaining % % of reservable BW 100 %
From that day forwards, Jonek’s success grew from force to force. He developed a new condo for his family and bought a small farm in a Download Online Videos neighbouring discipline. He additionally bought two horses and some cows and even an ox.
ReplyDelete