94 Chapter 4: Per-Hop Behavior: Resource Allocation I
Case Study 4-11: Packet Prioritization Based on Source Address
A large corporate branch ofﬁce connects to the head ofﬁce using a T1 link. One of the
subnets, 220.127.116.11/28 at the branch site, hosts critical applications and servers. The
network administrator for the ﬁeld ofﬁce wants to prioritize any trafﬁc coming from this
subnet over the user trafﬁc generated by the rest of the branch ofﬁce network.
Listing 4-17 lists the conﬁguration to enable priority queuing based on the source IP
Whereas priority queuing potentially guarantees the entire bandwidth for mission-critical
data at the expense of low-priority data, custom queuing guarantees a minimum bandwidth
for each trafﬁc classiﬁcation.
This bandwidth reservation discipline services each nonempty queue sequentially in a
round-robin fashion, transmitting a conﬁgurable percentage of trafﬁc on each queue.
Custom queuing guarantees that mission-critical data is always assigned a certain
percentage of the bandwidth, while assuring predictable throughput for other trafﬁc.
You can think of custom queuing as CBWFQ with lots of conﬁguration details.
You can classify trafﬁc into 16 queues. Apart from the 16 queues is a special 0 queue, called
the system queue. The system queue handles high-priority packets, such as keepalive
packets and control packets. User trafﬁc cannot be classiﬁed into this queue. Custom
queuing is implemented to classify IP packets into any of the 16 queues based on input
interface, simple and extended IP access lists, packet size, and application type.
A popular use of custom queuing is to guarantee a certain bandwidth to a set of places
selected by an access list. To allocate bandwidth to different queues, you must specify the
byte count for each queue.
Listing 4-17 Priority Queuing Based on Source Address
interface serial 0
priority-list 1 protocol ip high list 1
priority-list 1 default low
access-list 1 permit 18.104.22.168 0.0.0.15
Custom Queuing 95
How Byte Count Is Used in Custom Queuing
In custom queuing, the router sends packets from a particular queue until the byte count is
exceeded. Even after the byte count value is exceeded, the packet currently being
transmitted is completely sent. Therefore, if you set the byte count to 100 bytes and your
protocol’s packet size is 1024 bytes, every time this queue is serviced, 1024 bytes are sent,
not 100 bytes.
Assume that one protocol has 500-byte packets, another has 300-byte packets, and a third
has 100-byte packets. If you want to split the bandwidth evenly across all three protocols,
you might choose to specify byte counts of 200, 200, and 200 for each queue. This
conﬁguration does not result in a 33/33/33 ratio, however. When the router services the ﬁrst
queue, it sends a single 500-byte packet; when it services the second queue, it sends a 300-
byte packet; and when it services the third queue, it sends two 100-byte packets. The
effective ratio is 50/30/20. Thus, setting the byte count too low can result in an unintended
Large byte counts produce a “jerky” distribution, however. That is, if you assign 10 KB, 10
KB, and 10 KB to three queues in the example given, each protocol is serviced promptly
when its queue is the one being serviced, but it might be a long time before the queue is
serviced again. A better solution is to specify 500-byte, 600-byte, and 500-byte counts for
the queue. This conﬁguration results in a ratio of 31:38:31, which might be acceptable.
To service queues in a timely manner, and to ensure that the conﬁgured bandwidth
allocation is as close as possible to the required bandwidth allocation, you must determine
the byte count based on each protocol’s packet size. Otherwise, your percentages might not
match what you conﬁgure.
Case Study 4-12: Minimum Interface Bandwidth for Different
A network administrator wants to allocate bandwidth among protocols A, B, and C as 20
percent, 60 percent, and 20 percent, respectively. It was found that on average, the packet
size for protocol A is 1086 bytes, protocol B is 291 bytes, and protocol C is 831 bytes.
To use custom queuing to achieve this functionality, it is necessary to ﬁnd the right byte-
count values for each protocol queue leading to the intended bandwidth allocation.
To determine the correct byte counts, perform the following tasks:
Step 1 For each queue, divide the percentage of bandwidth you want to allocate
to the queue by the packet size, in bytes. The ratios are
20:1086, 60:291, 20:831
0.01842, 0.20619, 0.02407