Class-based weighted fair queuing (CBWFQ) builds upon WFQ by adding the concept of traffic
classes. Classes can be defined by a tag within the frame such as type of service (ToS) or differentiated
services code point (DSCP). These tags are added by the end station or the access router
and are used to forward packets through the network core without each router re-examining the
packet to determine that datagram’s priority. We are not defining the methodology used but
simply explaining the fact that you can use this information for CBWFQ.
Common implementations of CBWFQ establish three or four classes of application services,
typically described as gold, silver, bronze, and other. This categorization does not include network
traffic such as routing updates, which should always have priority over user application traffic.
Although some users will take exception to their traffic being described as a low priority, the network
administrator needs to constrain the total number of classes to keep administration manageable
and negate a situation in which bandwidth is being managed to the bit via QoS policy.
One of the strongest benefits to CBWFQ is the ability to define a specific amount of bandwidth
to an application. For example, Financial Information Exchange (FIX) is a common financial systems
protocol that might warrant special attention. Perhaps this application requires a guaranteed
256Kbps to prevent application failure on a T-1 link. CBWFQ can provide this guarantee, and,
perhaps more importantly, will allow the application to use more than the 256Kbps if bandwidth
is available. This is different from CAR, discussed in the next section, which establishes a hard
limit on the bandwidth available to a specific protocol. Please note that by default you cannot allocate
more than 75 percent of the link’s total bandwidth for management by CBWFQ.
With regard to traffic classes, the model is fairly straightforward. When congestion occurs,
the queue will process packets in the gold class before those in the silver class within the constraints
of WFQ. As such, the administrator is defining that the queue should be fair to all applications,
but that gold traffic is the most important. This will lead to the managed unfairness that
is the basis for all QoS policies; under congestion, the network will have to discard something
to stay within the available resources.
ToS and DSCP are not commonly accepted from end nodes because many
applications and some operating systems will automatically tag all packets for
the highest priority. It is recommended that you configure your edge routers to
ignore the end station and tag based on address or port information.
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
Low Latency Queuing
Low latency queuing (LLQ) is actually a strict priority queue within class-based weighted fair
queuing (CBWFQ), discussed in the next section. LLQ is Cisco’s solution for voice and other
very small packets that require real-time processing. LLQ operates by prioritizing key packets
to the front of the queue. Because these packets are small by nature, there is little risk of queue
starvation or other problems. However, administrators should evaluate the demands of other
traffic within the network.
queuing (CBWFQ), discussed in the next section. LLQ is Cisco’s solution for voice and other
very small packets that require real-time processing. LLQ operates by prioritizing key packets
to the front of the queue. Because these packets are small by nature, there is little risk of queue
starvation or other problems. However, administrators should evaluate the demands of other
traffic within the network.
Cisco’s Newer Queuing Technologies
Because of their notable absence in the topics covered by the Remote Access examination, we only
briefly cover some of the newer queuing management technologies in this section. Queue control
has become a more important issue in remote access networking with the proliferation of voice
services and other real-time protocols. As these protocols suffer from congestion and low bandwidth,
they are strong candidates for quality of service (QoS), of which queuing is a part.
Remember that queuing is intended to manage the transmission of packets held in the
router’s buffer. Unlike voice, data networks buffer packets during periods of congestion.
Although we could discuss a wide number of queuing options, three key methods are gaining
prominence in the market: low latency queuing, class-based weighted fair queuing, and committed
access rate.
briefly cover some of the newer queuing management technologies in this section. Queue control
has become a more important issue in remote access networking with the proliferation of voice
services and other real-time protocols. As these protocols suffer from congestion and low bandwidth,
they are strong candidates for quality of service (QoS), of which queuing is a part.
Remember that queuing is intended to manage the transmission of packets held in the
router’s buffer. Unlike voice, data networks buffer packets during periods of congestion.
Although we could discuss a wide number of queuing options, three key methods are gaining
prominence in the market: low latency queuing, class-based weighted fair queuing, and committed
access rate.
The Real Use of Queuing
As with most things in networking, queuing is a trade-off technology that can provide significant
benefit or detriment to the administrator. As a result, when coupled with the implementation and
management overhead involved, most networks forgo queuing and quality of service (QoS) in
favor of other techniques. The most common of these is bandwidth.
The reality is that bandwidth can be used as a QoS mechanism; however, it will not prioritize a
filled queue, which is the point where queuing takes over. This can greatly degrade voice services
(VoIP), but it can also be a factor when the link is presented with a significant amount of additional
data. This can occur under parallel link failure, wherein two paths are reduced to one, presumably
with a resulting 50 percent loss of total bandwidth.
QoS and queuing can provide a mechanism to protect traffic under this model, and might be a
good augmentation to bandwidth services in your network. The challenge is how to categorize
and prioritize traffic—identification of traffic flows, the amount of bandwidth required, the
amount available, the benefit to the firm, and the ability to categorize are all considerations for
the designer to evaluate. NetFlow, a Cisco IOS feature that can audit network traffic, and Network-
Based Application Recognition (NBAR) can help in this process, but NetFlow requires a good
amount of storage and manual evaluation, and NBAR is not recommended for high-capacity links
because of its processor demands.
In addition, you will likely find infighting as a result of your decisions; a group with its traffic
prioritized as bronze will commonly buck and question why an application was rated above
it at gold. Obtaining early sign-off can greatly reduce this contention.
Another queuing option available to the administrator is in-band prioritization. This does not
help user traffic, but can insulate the network from large-scale denial of service attacks. In this
model, queue priority is given to Telnet, Secure Shell (SSH), and TFTP (Trivial FTP) so that
these ports are available to the network administrator when the network is under heavy load.
This load might be due to user traffic or an attack such as Code Red or Nimda. The caution is
that processor load and other factors might be saturated to negate this protection, and, of
course, users will still lose their applications under attack.
benefit or detriment to the administrator. As a result, when coupled with the implementation and
management overhead involved, most networks forgo queuing and quality of service (QoS) in
favor of other techniques. The most common of these is bandwidth.
The reality is that bandwidth can be used as a QoS mechanism; however, it will not prioritize a
filled queue, which is the point where queuing takes over. This can greatly degrade voice services
(VoIP), but it can also be a factor when the link is presented with a significant amount of additional
data. This can occur under parallel link failure, wherein two paths are reduced to one, presumably
with a resulting 50 percent loss of total bandwidth.
QoS and queuing can provide a mechanism to protect traffic under this model, and might be a
good augmentation to bandwidth services in your network. The challenge is how to categorize
and prioritize traffic—identification of traffic flows, the amount of bandwidth required, the
amount available, the benefit to the firm, and the ability to categorize are all considerations for
the designer to evaluate. NetFlow, a Cisco IOS feature that can audit network traffic, and Network-
Based Application Recognition (NBAR) can help in this process, but NetFlow requires a good
amount of storage and manual evaluation, and NBAR is not recommended for high-capacity links
because of its processor demands.
In addition, you will likely find infighting as a result of your decisions; a group with its traffic
prioritized as bronze will commonly buck and question why an application was rated above
it at gold. Obtaining early sign-off can greatly reduce this contention.
Another queuing option available to the administrator is in-band prioritization. This does not
help user traffic, but can insulate the network from large-scale denial of service attacks. In this
model, queue priority is given to Telnet, Secure Shell (SSH), and TFTP (Trivial FTP) so that
these ports are available to the network administrator when the network is under heavy load.
This load might be due to user traffic or an attack such as Code Red or Nimda. The caution is
that processor load and other factors might be saturated to negate this protection, and, of
course, users will still lose their applications under attack.
Configuring Byte Count 972
Configure the byte-count queues carefully, because if the setting is too high, the algorithm will
take longer than necessary to move from one queue to the next. This is not a problem while the
processor empties the queue, but if it takes the processor too long to get back to other queues,
they could fill up and start to drop packets.
This is why it’s important to understand how to configure the bandwidth percentage relationship
by using the byte-count command. Because frame sizes vary from protocol to protocol,
you’ll need to know the average frame sizes of the protocols using the custom queued interface to
define the byte count efficiently. You can do this by using simple math.
Suppose you have a router that uses IP, IPX, and SNA as its protocols. Let’s arbitrarily assign
frame sizes, realizing that the values aren’t the real ones. Assign a frame size of 800 bytes to IP,
1,000 bytes to IPX, and 1,500 bytes to SNA. You calculate a simple ratio by taking the highest
frame value and dividing it by the frame size of each protocol:
IP = 1,500 ÷ 800 = 1.875
IPX = 1,500 ÷ 1,000 = 1.5
SNA = 1,500 ÷ 1,500 = 1.0
These values equal your frame size ratios. To assign correct bandwidth percentages, multiply
each ratio by the bandwidth percentage you want to assign to that protocol. For example, assign
40 percent to IP, 30 percent to IPX, and 30 percent to SNA:
IP = 1.875 × (0.4) = 0.75
IPX = 1.5 × (0.3) = 0.45
SNA = 1 × (0.3) = 0.30
These values now need to be normalized by dividing the results by the smallest value:
IP = 0.75 ÷ 0.3 = 2.5
IPX = 0.45 ÷ 0.3 = 1.5
SNA = 0.3 ÷ 0.3 = 1
Custom queuing will send only complete frames. Because the ratios are fractions, you must
round them up to the nearest integer values that maintain the same ratio. To arrive at the nearest
integer value, multiply the original ratios by a common number that will cause the ratios to
become integers. In this case, you can multiply everything by 2 and get the resulting ratio of
5:3:2. What does this mean? Well, five frames of IP, three frames of IPX, and two frames of SNA
will be sent. Because of the protocols’ varying frame size, the bandwidth percentage works out
just the way you calculated:
IP = 5 frames × 800 bytes = 4,000 bytes
IPX = 3 frames × 1,000 bytes = 3,000 bytes
SNA = 2 frames × 1,500 bytes = 3,000 bytes
Total bandwidth is 10,000 bytes. Percentages are verified by dividing the protocol rate
by the total. After doing the math, you verify that IP = 40 percent, IPX = 30 percent, and
SNA = 30 percent.
Now that the byte count has been calculated (4,000, 3,000, and 3,000), you can apply the
results in the queue-list command. The custom queuing algorithm will forward 4,000 bytes
worth of IP packets, move to the IPX queue and forward 3,000 bytes, and then go to the SNA
queue and forward 3,000 bytes.
The following queue list does not follow the IP, IPX, and SNA example we’ve
been discussing.
See the following example on how to configure and apply custom queuing lists:
Router_B#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router_B(config)#queue-list 1 interface Ethernet0 1
Router_B(config)#queue-list 1 protocol ip 2 tcp 23
Router_B(config)#queue-list 1 protocol ip 3 tcp 80
Router_B(config)#queue-list 1 protocol ip 4 udp snmp
Router_B(config)#queue-list 1 protocol ip 5
Router_B(config)#queue-list 1 default 6
Router_B(config)#queue-list 1 queue 1 limit 40
Router_B(config)#queue-list 1 queue 5 byte-count 4000
Router_B(config)#queue-list 1 queue 4 byte-count 500
Router_B(config)#queue-list 1 queue 3 byte-count 4000
Router_B(config)#queue-list 1 queue 2 byte-count 1000
Router_B(config)#interface serial0
Router_B(config-if)#custom-queue-list 1
Router_B(config-if)#^Z
Router_B#
After analyzing the list, you can see that six queues were configured. The first one was configured
to handle incoming traffic from interface Ethernet 0, and the second is reserved for
Telnet traffic. Queue number 3 is configured for WWW traffic, and the fourth is configured
to handle SNMP traffic. The fifth queue will handle all other IP traffic, while queue number 6
is set up as the default queue where all unspecified traffic will go. A limit of 40 packets was
placed on queue 1 (from the default of 20), and the byte count was changed from the default
value of 1,500 for queues 2, 3, 4, and 5. Finally, after the queue list was created, it was applied
to interface serial 0.
Here is what the configuration looks like:
!
interface Serial0
ip address 10.1.1.1
255.255.255.0
custom-queue-list 1
!
queue-list 1 protocol ip 2 tcp telnet
queue-list 1 protocol ip 3 tcp www
queue-list 1 protocol ip 4 udp snmp
queue-list 1 protocol ip 5
queue-list 1 default 6
queue-list 1 interface Ethernet0 1
queue-list 1 queue 1 limit 40
queue-list 1 queue 2 byte-count 1000
queue-list 1 queue 3 byte-count 4000
queue-list 1 queue 4 byte-count 500
queue-list 1 queue 5 byte-count 4000
As with the other queuing algorithms, you need to verify both the configuration and the
status of custom queuing. Issuing the same command as before, except this time substituting
custom for priority, produces the following output:
Router_B#show queueing custom
Current custom queue configuration:
List Queue Args
1 6 default
1 1 interface Ethernet0
1 2 protocol ip tcp port telnet
1 3 protocol ip tcp port www
1 4 protocol ip udp port snmp
1 5 protocol ip
1 1 limit 40
1 2 byte-count 1000
1 3 byte-count 4000
1 4 byte-count 500
1 5 byte-count 4000
Router_B#
This output information gives you a breakdown of the custom queue lists configured
on the device, detailing queue assignments and any limits or byte counts assigned to each
custom queue.
take longer than necessary to move from one queue to the next. This is not a problem while the
processor empties the queue, but if it takes the processor too long to get back to other queues,
they could fill up and start to drop packets.
This is why it’s important to understand how to configure the bandwidth percentage relationship
by using the byte-count command. Because frame sizes vary from protocol to protocol,
you’ll need to know the average frame sizes of the protocols using the custom queued interface to
define the byte count efficiently. You can do this by using simple math.
Suppose you have a router that uses IP, IPX, and SNA as its protocols. Let’s arbitrarily assign
frame sizes, realizing that the values aren’t the real ones. Assign a frame size of 800 bytes to IP,
1,000 bytes to IPX, and 1,500 bytes to SNA. You calculate a simple ratio by taking the highest
frame value and dividing it by the frame size of each protocol:
IP = 1,500 ÷ 800 = 1.875
IPX = 1,500 ÷ 1,000 = 1.5
SNA = 1,500 ÷ 1,500 = 1.0
These values equal your frame size ratios. To assign correct bandwidth percentages, multiply
each ratio by the bandwidth percentage you want to assign to that protocol. For example, assign
40 percent to IP, 30 percent to IPX, and 30 percent to SNA:
IP = 1.875 × (0.4) = 0.75
IPX = 1.5 × (0.3) = 0.45
SNA = 1 × (0.3) = 0.30
These values now need to be normalized by dividing the results by the smallest value:
IP = 0.75 ÷ 0.3 = 2.5
IPX = 0.45 ÷ 0.3 = 1.5
SNA = 0.3 ÷ 0.3 = 1
Custom queuing will send only complete frames. Because the ratios are fractions, you must
round them up to the nearest integer values that maintain the same ratio. To arrive at the nearest
integer value, multiply the original ratios by a common number that will cause the ratios to
become integers. In this case, you can multiply everything by 2 and get the resulting ratio of
5:3:2. What does this mean? Well, five frames of IP, three frames of IPX, and two frames of SNA
will be sent. Because of the protocols’ varying frame size, the bandwidth percentage works out
just the way you calculated:
IP = 5 frames × 800 bytes = 4,000 bytes
IPX = 3 frames × 1,000 bytes = 3,000 bytes
SNA = 2 frames × 1,500 bytes = 3,000 bytes
Total bandwidth is 10,000 bytes. Percentages are verified by dividing the protocol rate
by the total. After doing the math, you verify that IP = 40 percent, IPX = 30 percent, and
SNA = 30 percent.
Now that the byte count has been calculated (4,000, 3,000, and 3,000), you can apply the
results in the queue-list command. The custom queuing algorithm will forward 4,000 bytes
worth of IP packets, move to the IPX queue and forward 3,000 bytes, and then go to the SNA
queue and forward 3,000 bytes.
The following queue list does not follow the IP, IPX, and SNA example we’ve
been discussing.
See the following example on how to configure and apply custom queuing lists:
Router_B#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router_B(config)#queue-list 1 interface Ethernet0 1
Router_B(config)#queue-list 1 protocol ip 2 tcp 23
Router_B(config)#queue-list 1 protocol ip 3 tcp 80
Router_B(config)#queue-list 1 protocol ip 4 udp snmp
Router_B(config)#queue-list 1 protocol ip 5
Router_B(config)#queue-list 1 default 6
Router_B(config)#queue-list 1 queue 1 limit 40
Router_B(config)#queue-list 1 queue 5 byte-count 4000
Router_B(config)#queue-list 1 queue 4 byte-count 500
Router_B(config)#queue-list 1 queue 3 byte-count 4000
Router_B(config)#queue-list 1 queue 2 byte-count 1000
Router_B(config)#interface serial0
Router_B(config-if)#custom-queue-list 1
Router_B(config-if)#^Z
Router_B#
After analyzing the list, you can see that six queues were configured. The first one was configured
to handle incoming traffic from interface Ethernet 0, and the second is reserved for
Telnet traffic. Queue number 3 is configured for WWW traffic, and the fourth is configured
to handle SNMP traffic. The fifth queue will handle all other IP traffic, while queue number 6
is set up as the default queue where all unspecified traffic will go. A limit of 40 packets was
placed on queue 1 (from the default of 20), and the byte count was changed from the default
value of 1,500 for queues 2, 3, 4, and 5. Finally, after the queue list was created, it was applied
to interface serial 0.
Here is what the configuration looks like:
!
interface Serial0
ip address 10.1.1.1
255.255.255.0
custom-queue-list 1
!
queue-list 1 protocol ip 2 tcp telnet
queue-list 1 protocol ip 3 tcp www
queue-list 1 protocol ip 4 udp snmp
queue-list 1 protocol ip 5
queue-list 1 default 6
queue-list 1 interface Ethernet0 1
queue-list 1 queue 1 limit 40
queue-list 1 queue 2 byte-count 1000
queue-list 1 queue 3 byte-count 4000
queue-list 1 queue 4 byte-count 500
queue-list 1 queue 5 byte-count 4000
As with the other queuing algorithms, you need to verify both the configuration and the
status of custom queuing. Issuing the same command as before, except this time substituting
custom for priority, produces the following output:
Router_B#show queueing custom
Current custom queue configuration:
List Queue Args
1 6 default
1 1 interface Ethernet0
1 2 protocol ip tcp port telnet
1 3 protocol ip tcp port www
1 4 protocol ip udp port snmp
1 5 protocol ip
1 1 limit 40
1 2 byte-count 1000
1 3 byte-count 4000
1 4 byte-count 500
1 5 byte-count 4000
Router_B#
This output information gives you a breakdown of the custom queue lists configured
on the device, detailing queue assignments and any limits or byte counts assigned to each
custom queue.
Subscribe to:
Posts (Atom)