rates and interarrival periods much more
predictable. Class-Based WFQ: Ensuring Network
Bandwidth
CBWFQ is one of Cisco's newest
congestion-management tools for providing greater flexibility.
It will provide a minimum amount of bandwidth to a class as
opposed to providing a maximum amount of bandwidth as with
traffic shaping. CBWFQ allows a network administrator to create
minimum guaranteed bandwidth classes. Instead of providing a
queue for each individual flow, the administrator defines a
class that consists of one or more flows, each class with a
guaranteed minimum amount of bandwidth. CBWFQ prevents
multiple low-priority flows from swamping out a single
high-priority flow. For example, WFQ will provide a video
stream that needs half the bandwidth of T1 if there are two
flows. But, if more flows are added, the video stream gets less
of the bandwidth because WFQ's mechanism creates fairness. If
there are 10 flows, the video stream will get only 1/10th of
the bandwidth, which is not enough. CBWFQ provides the
mechanism needed to provide the half of the bandwidth that
video needs. The network administrator defines a class, places
the video stream in the class, and tells the router to provide
768 kbps (half of a T1) service for the class. Video therefore
gets the bandwidth that it needs. The rest of flows receive a
default class. The default class uses flow-based WFQ schemes
fairly allocating the remainder of the bandwidth (half of the
T1, in this example).
Content 3.2 Implementing
Cisco IOS QoS 3.2.3 Queue Management
(Congestion-Avoidance Tools) Congestion avoidance is a form
of queue management. Congestion-avoidance techniques monitor
network traffic loads in an effort to anticipate and avoid
congestion at common network bottlenecks, as opposed to
congestion-management techniques that operate to control
congestion after it occurs. The primary Cisco IOS congestion
avoidance tool is WRED. The random early detection (RED)
algorithms avoid congestion in internetworks before it becomes
a problem. RED works by monitoring traffic load at points in
the network and randomly discards packets if the congestion
begins to increase. The result of the drop is that the source
detects the dropped traffic and slows its transmission. RED is
primarily designed to work with TCP in IP internetwork
environments. WRED combines the capabilities of the RED
algorithm with IP precedence. This combination provides for
preferential traffic handling for higher-priority packets. It
can selectively discard lower-priority traffic when the
interface starts to get congested and can provide
differentiated performance characteristics for different
classes of service as shown in Figure . WRED is also Resource
Reservation Protocol (RSVP) aware and can provide an integrated
services controlled-load QoS. As you know, each queue can house
a finite number of packets. A full queue causes tail drops.
Tail drops are dropped packets that could not fit into the
queue because the queue was full. This is undesirable because
the dropped packet may have been a high-priority packet and the
router did not have a chance to queue it. If the queue is not
full, the router can look at the priority of all arriving
packets and drop the lower-priority packets, allowing
high-priority packets into the queue. By managing the depth of
the queue (the number of packets in the queue) by dropping
specified packets, the router does its best to make sure that
the queue does not fill and that tail drops do not happen. This
allows the router to make a better decision as to which packets
to drop when the queue depth increases. WRED also helps prevent
overall congestion in an internetwork. WRED uses a minimum
threshold for each IP precedence level to determine when to
drop a packet. (The queue length must exceed the minimum
threshold for WRED to consider a packet as a candidate for
dropping.) Consider this example for two classes of traffic.
The first class has a minimum drop threshold for IP precedence
of 20. The next queue in our example has a drop threshold for
IP precedence of 22. If the queue length is 21, then WRED drops
packets for the first class, but packets from the second class
remain in the queue. If the queue depth deepens and exceeds 22,
then packets with IP precedence = 1 can be dropped as well.
WRED uses an algorithm that raises the probability that the
router can drop a packet as the queue depth rises from the
minimum drop threshold to the maximum drop threshold. Above the
maximum drop threshold, WRED drops all packets.
Content
3.2 Implementing Cisco IOS QoS 3.2.4
Preparing to Implement QoS There are three basic steps
shown in Figure involved in implementing QoS on a network:
Step 1 Identify types of traffic and their
requirements: Study the network to determine the type of
traffic that is running on the network and then determine the
QoS requirements needed for the different types of traffic.
Step 2 Define traffic classes: This activity
groups the traffic with similar QoS requirements into classes.
For example, three classes of traffic might be defined as
voice, mission-critical, and best effort. Step 3
Define QoS policies: QoS policies meet QoS requirements
for each traffic class.
Content 3.2
Implementing Cisco IOS QoS 3.2.5 Step 1:
Identify Types of Traffic and Their Requirements The first
step in implementing QoS is to identify the traffic on the
network and then determine the QoS requirements and the
importance of the various traffic types. This step provides
some high-level guidelines for implementing QoS in networks
that support for multiple applications, including
delay-sensitive and bandwidth-intensive applications. These
applications may enhance business processes, but stretch
network resources. QoS can provide secure, predictable,
measurable, and guaranteed services to these applications by
managing delay, delay variation (jitter), bandwidth, and packet
loss in a network. This step consists of these activities
illustrated in Figure : - Determine the QoS problems
of users. Measure the traffic on the network during
congested periods. Conduct a CPU use assessment on each of the
network devices during busy periods to determine where problems
might be occurring.
- Determine the business model
and goals and obtain a list of business requirements. This
activity helps define the number of classes that are needed and
allows you to determine the business requirements for each
traffic class.
- Define the service levels required
by different traffic classes in terms of response time and
availability. Questions to consider when defining service
levels include what is the impact on business if the network
delays a transaction by two or three seconds. A service level
assignment will include the priority and the treatment a packet
will receive. For example, you would assign voice applications
a high service level (high priority, LLQ and RTP compression).
You would assign low priority data a lower service level (lower
priority, WFQ, TCP header compression).
Determining
which applications are business-critical and necessitate
protection requires you to review all of the applications
competing for network resources. Tools to analyze the traffic
patterns in the network include NetFlow Accounting,
Network-based Application Recognition (NBAR), and QoS Device
Manager (QDM). - NetFlow Accounting provides detail
about network traffic and can be used to capture the traffic
classification or precedence associated with each flow.
- NBAR is a classification tool that can identify traffic up
to the application layer. It provides per-interface,
per-protocol, and bi-directional statistics for each traffic
flow traversing an interface. NBAR also does sub-port
classification; observing and identifying items beyond
application ports.
- QDM is a web-based network
management application that provides an easy-to-use graphical
user interface for configuring and monitoring advanced IP-based