Cisco Introduction IP QoS (Course)

Introduction
Overview
The module presents a thorough overview of quality of service models and
mechanisms as implemented in complex service provider and enterprise networks.
It includes the following topics:
n Introduction to IP Quality of Service
n Integrated Services Model
n Differentiated Services Model
n Building Blocks of IP QoS Mechanisms
n Enterprise Network Case Study
n Service Provider Case Study
Objectives
Upon completion of this module, you will be able to perform the following tasks:
n Describe the need for IP QoS
n Describe the Integrated Services model
n Describe the Differentiated Services model
n Describe the building blocks of IP QoS mechanisms (classification, marking,
metering, policing, shaping, dropping, forwarding, queuing)
n List the IP QoS mechanisms available in the Cisco IOS
n Describe what QoS features are supported by different IP QoS mechanisms
Introduction to IP Quality of Service
Objectives
Upon completion of this lesson, you will be able to perform the following tasks:
n Describe different types of applications and services that have special resource
requirements
n List the network components that affect the throughput, delay and jitter in IP
networks
n List the benefits of deploying QoS mechanisms in IP networks
n List QoS mechanisms available in Cisco IOS
n Describe typical enterprise and service provider networks and their QoS-related
requirements
2 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Why IP QoS?
• Application X is slow!
• Video broadcast occasionally stalls!
• Phone calls over IP are no better than over satellite!
• Phone calls have really bad voice quality!
• ATM (the money-dispensing-type) are non-

responsive!
• ...
© 2001, Cisco Systems, Inc. IP QoS Introduction-5
The purpose of this module is to determine the following:

n What is, or might be, missing in today’s IP networks?
n What can IP Quality of Service (QoS) do to help solve the problem?
A decade ago when the Internet was still in its early stages there was not much
available. Most users were using Gopher to find information and FTP to retrieve it.
The Internet was something new and exciting and no one was really bothered by
the fact that it was slow.
Today, however, the Internet is serving a large population of all walks of life. The
Internet has also grown in its service offering. Users are using the Internet to view
static or dynamic information, transmit voice and video, shop, play etc.
Along with these new applications of the Internet come some demands on the
service(s) it provides:
n Some applications are slow
n Video broadcast or conferencing may have bad picture quality or appear jerky
n Voice sessions may have bad voice quality or periods of silence
n Critical transactions may take too long (too many seconds)
n Bulk transfers take too long (too many hours)
This module focuses on most common quality-related problems people encounter in
IP networks.
Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 3

Because ...
• Application X is slow! (not enough BANDWIDTH)

• Video broadcast occasionally stalls! (DELAY
temporarily increases – JITTER)
• Phone calls over IP are no better than over satellite!
(too much DELAY)
• Phone calls have really bad voice quality! (too many
phone calls – ADMISSION CONTROL)
• ATM (the money-dispensing-type) are non
responsive! (too many DROPs)
• ...
Quality of Service is usually identified by the following parameters:

n Amount of bandwidth available to a certain application or user
n Average delay experienced by IP packets on end-to-end or link basis
n Jitter that affects applications that transmit packets at a certain fixed rate and
expect to receive them at approximately the same rate (for example, voice and
video)
n Drops of packets when a link is congested can severely impact fragile
applications
n Admission control which prevents too many sessions from congesting links
and causing degradation in quality of service (for example, voice sessions)

What Causes ...
• Lack of bandwidth – multiple flows are

contesting for a limited amount of bandwidth
• Too much delay – packets have to traverse
many network devices and links that add up
to the overall delay
• Variable delay – sometimes there is a lot of
other traffic which results in more delay
• Drops – packets have to be dropped when a
link is congested
If the network is empty any application should get enough bandwidth, acceptable
low and fixed delay and not experience any drops. The reality, however, is that
there are multiple users or applications using the network at the same time.

Available Bandwidth
IP IP IP IP
256 kbps 512 kbps
10 Mbps 100 Mbps
BW max = min(10M, 256k, 512k, 100M)=256kbps

BW avail = BWmax /Flows
• Maximum available bandwidth equals the bandwidth of the weakest link
• Multiple flows are contesting for the same bandwidth resulting in much
less bandwidth being available to one single application.
The example above illustrates an empty network with four hops between a server
and a client. Each hop is using different media with a different bandwidth. The
maximum available bandwidth is equal to the bandwidth of the slowest link.
The calculation of the available bandwidth, however, is much more complex in
cases where there are multiple flows traversing the network. The calculation of the
available bandwidth in the illustration is a rough approximation.

End-to-end Delay
IP IP IP IP
Propagation Propagation Propagation

delay (P1) delay (P2) delay (P3) Propagation
delay (P4)
Processing and Processing and Processing and
queuing delay (Q1) queuing delay (Q2) queuing delay (Q3)
Delay = P1 + Q1 + P2 + Q2 + P3 + Q3 + P4 = X ms
• End-to-end delay equals a sum of all propagation, processing
and queuing delays in the path
• Propagation delay is fixed, processing and queuing delays are
unpredictable in best-effort networks
The figure illustrates the impact a network has on the end-to-end delay of packets
going from one end to the other. Each hop in the network adds to the overall delay
because of the following two factors:
1. Propagation (serialization) delay of the media that, for the most part, depends
solely on the bandwidth.
2. Processing and queuing delays within a router, which can be caused by a wide
variety of conditions.
Ping (ICMP echoes and replies) can be used to measure the round-trip time of IP
packets in a network. There are other tools available to periodically measure
responsiveness of a network.

Processing and Queuing Delay
Forwarding
bandwidth
IP IP IP IP
Processing Delay Queuing Delay

Propagation Delay
• Processing Delay is the time it takes for a router to take the packet from an
input interface and put it into the output queue of the output interface.
• Queuing Delay is the time a packets resides in the output queue of a router.
• Propagation or Serialization Delay is the time it takes to transmit a packet.
n Processing Delay is the time it takes for a router to take the packet from an
input interface and put it into the output queue of the output interface. The
processing delay depends on various factors, such as:
– CPU speed
– CPU utilization
– IP switching mode
– Router architecture
– Configured features on both input and output interface
n Queuing Delay is the time a packet resides in the output queue of a router. It
depends on the number and sizes of packets already in the queue and on the
bandwidth of the interface. It also depends on the queuing mechanism.
n Propagation or Serialization Delay is the time it takes to transmit a packet. It
usually only depends on the bandwidth of the interface. CSMA/CD media may
add slightly more delay due to the increased probability of collisions when an
interface is nearing congestion.

Packet Loss
Forwarding
IP IP IP IP IP
Tail-drop
• Tail-drops occur when the output queue is full. These are the most
common drops which happen when a link is congested.
• There are also many other types of drops that are not as common and
may require a hardware upgrade (input drop, ignore, overrun, no
buffer, ...). These drops are usually a result of router congestion.
The usual packet loss occurs when routers run out of buffer space for a
particular interface (output queue). The figure illustrates a full output queue of an
interface, which causes newly arriving packets to be dropped. The term used for
such drops is simply “output drop” or “tail-drop” (packets are dropped at the tail of
the queue).
Routers might also drop packets for other (less common) reasons, for example:
n Input queue drop - main CPU is congested and cannot process packets (the
input queue is full)
n Ignore - router ran out of buffer space
n Overrun - CPU is congested and cannot assign a free buffer to the new packet
n Frame errors (CRC, runt, giant)—hardware-detected error in a frame

How to Increase Available
Bandwidth?
TCP Header Compression
RTP Header Compression
cTCP data
Compress
the Headers
IP TCP data Fancy

FIFO queuing
queuing
Compress
the Payload
Priority Queuing (PQ)
Custom Queuing (CQ)
Stacker
Compressed packet Modified Deficit Round Robin (MDRR)
Predictor Class-based Weighted Fair Queing (CB-WFQ)
• Upgrade the link. The best solution but also the most expensive.
• Take some bandwidth from less important applications.
• Compress the payload of layer-2 frames.
• Compress the header of IP packets.
There are several approaches to solving a problem of insufficient bandwidth:

n The best approach is to increase the link capacity to accommodate all
applications and users with some extra bandwidth to spare. This solution sounds
simple enough but in the real world it brings a high cost in terms of the money
and time it takes to implement. Very often there are also technological
limitations to upgrading to a higher bandwidth.
n Another option is to classify traffic into QoS classes and prioritize it according
to importance (business-critical traffic should get enough bandwidth, voice
should get enough bandwidth and prioritized forwarding and the least important
traffic should get the remaining bandwidth). There are a wide variety of
mechanisms available in the Cisco IOS that provide bandwidth guarantees, for
example:
– Priority or Custom Queuing
– Modified Deficit Round Robin (on Cisco 12000 series routers)
– Distributed ToS-based and QoS-group-based Weighted Fair Queuing (on
Cisco 7x00 series routers)
– Class-based Weighted Fair Queuing
n Optimizing link usage by compressing the payload of frames (virtually)
increases the link bandwidth. Compression, on the other hand, also increases
delay due to complexity of compression algorithms. Using hardware
compression can accelerate the compression of packet payloads. Stacker and
Predictor are two compression algorithms available in Cisco IOS.
n Another link efficiency mechanism is header compression. This mechanism is
especially effective in networks where most packets carry small amounts of

data (payload-to-header ratio is small). Typical examples of header
compression are TCP Header Compression and RTP Header Compression.

How to Reduce Delay?
TCP Header Compression

RTP Header Compression
cRTP data
Compress
the Headers
IP UDP RTP data Fancy

FIFO queuing
queuing
Compress
the Payload
Priority Queuing (PQ)
Custom Queuing (CQ)
Stacker Strict Priority MDRR
Compressed packet
Predictor IP RTP prioritization
Class-based Low-latency Queuing (CB-LLQ)
• Forward the important packets first.
• Compress the payload of layer-2 frames (it takes time).
• Compress the header of IP packets.
Assuming that a router is powerful enough to make a forwarding decision in a

negligible time it can be said that most of the processing, queuing delay and
propagation delay is influenced by the following factors:
n Average length of the queue
n Average length of packets in the queue
n Link bandwidth
There are several approaches to accelerate packet dispatching of delay-sensitive
flows:
n Increase link capacity. Enough bandwidth causes queues to shrink, making sure
packets do not have to wait long before they can be transmitted. Additionally,
more bandwidth reduces serialization time. On the other hand, this might be an
unrealistic approach due to the costs associated with the upgrade.
n A more cost-effective approach is to enable a queuing mechanism that can give
priority to delay-sensitive packets by forwarding them ahead of other packets.
There are a wide variety of queuing mechanisms available in Cisco IOS that
have pre-emptive queuing capabilities, for example:
– Priority Queuing
– Custom Queuing
– Strict-priority or Alternate Priority queuing within the Modified Deficit
Round Robin (on Cisco 12000 series routers)
– IP RTP prioritization
– Class-based Low-latency Queuing

n Payload compression reduces the size of packets and, therefore, virtually
increases link bandwidth. Additionally, compressed packets are smaller and
need less time to be transmitted. On the other hand, compression uses complex
algorithms that take time and add to the delay. This approach is, therefore, not
used to provide low-delay propagation of packets.
n Header compression on the other hand is not as CPU-intensive and can be used
in combination with other mechanisms to reduce delay. It is especially useful for
voice packets that have a bad payload-to-header ratio, which is improved by
reducing the header of the packet (RTP header compression).
By minimizing delay, jitter is also reduced (delay is more predictable).

How to Prevent Packet Loss?
Weighted Random Early Detection (WRED)
IP data Dropper Fancy

FIFO queuing
queuing
Custom Queuing (CQ)

Modified Deficit Round Robin (MDRR)
Class -based Weighted Fair Queuing (CB-WFQ)
• Guarantee enough bandwidth to sensitive packets.
• Prevent congestion by randomly dropping less important packets
before congestion occurs
Packet loss is usually a result of congestion on an interface. Most applications that

use TCP experience slow down due to TCP adjusting to the network’s resources
(dropped TCP segments cause TCP sessions to reduce their window sizes). There
are some other applications that do not use TCP and cannot handle drops (fragile
flows).
The following approaches can be taken to prevent drops of sensitive applications:
n Increased link capacity to ease or prevent congestion.
n Guarantee enough bandwidth and increase buffer space to accommodate bursts
of fragile applications. There are several mechanisms available in Cisco IOS
that can guarantee bandwidth and/or provide prioritized forwarding to drop-
sensitive applications, for example:
– Priority Queuing
– Custom Queuing
– Modified Deficit Round Robin (on Cisco 12000 series routers)
– IP RTP prioritization
– Class-based Weighted Fair Queuing
– Class-based Low-latency Queuing
n Prevent congestion by dropping other packets before congestion occurs.
Weighted Random Early Detection can be used to start dropping other packets
before congestion occurs.
There are some other mechanisms that can also be used to prevent congestion:
n Traffic Shaping delays packets instead of dropping them (Generic Traffic
Shaping, Frame Relay Traffic Shaping and Class-based Shaping).

n Traffic Policing can limit the rate of less important packets to provide better
service to drop-sensitive packets (Committed Access Rate and Class-based
Policing).

Which Applications Have Which
QoS Requirements?
Throughput Delay Loss

Loss Jitter
Interactive Not
Low Low Low
(e.g. Telnet) Important
Batch (e.g. Not Not
High
High Low
FTP) Important Important
Fragile (e.g. Low Low None Not
SNA) Important
Voice Low Low and Low Low

Predictable
Low and
Video High
High Low Low
Predictable
• Enterprise networks are typically focused on

providing QoS to applications
When QoS is considered in a network implementation, important applications and

their QoS requirements have to be identified. The figure illustrates a table of
different types of applications with the corresponding QoS requirements
(throughput or bandwidth, delay, loss and jitter).
Once the applications are identified and prioritized it must be decided which QoS
mechanisms are to be put in place.
The approach to provide QoS to applications is usually used in Enterprise
Networks where important (business-critical) applications are easy to identify.
Most applications can be classified based on TCP or UDP port numbers. Some
applications use dynamic port numbers that, somewhat, makes classification more
difficult. Cisco IOS supports Network-based Application Recognition (NBAR),
which can be used for such application.

Which Services can be
Implemented in a Network?
Throughput Delay Loss

Loss Jitter
Gold Guaranteed Low Low Low
No No No
Silver
Silver Guaranteed Guarantee Guarantee Guarantee
Bronze Guaranteed No No No
Limitted Guarantee Guarantee Guarantee
Best Effort No No No No
Guarantee Guarantee Guarantee Guarantee
... . . .. . . .. . . .. . . ..
• Service provider networks typically offer services

based on source and destination addresses
Service providers, on the other hand, are there to provide connectivity to

customers. They typically are not concerned with the applications that customers
are using. They are, however, interested in providing different levels of services to
customers. Some customers are willing to pay more for their connectivity to the
Internet, providing they obtain some guarantees. The figure illustrates one of the
many different approaches to defining services. In reality, each service provider
creates its own list of services according to market research and competitive
needs. Cisco IOS is simply the tool used to implement those services.

How can QoS be Applied?
• Best effort – no QoS is applied to packets

(default behavior)
• Integrated Services model – applications
signal to the network that they require
special QoS
• Differentiated Services model – the network
recognizes classes that requires special QoS
By investigating the history of the Internet it can be divided into three QoS-related
periods:
n Best-effort. The Internet was designed for best-effort, no-guarantee delivery
of packets. This behavior is still predominant in today’s Internet.
n Integrated Services model. Introduced to supplement the best-effort delivery
by setting aside some bandwidth for applications that require bandwidth and
delay guarantees. The Integrated Services model expects applications to signal
their requirements to the network. Resource Reservation Protocol (RSVP) is
used to signal QoS requirements to the network.
n Differentiated Services model. Added to provide more scalability in
providing QoS to IP packets. The main difference is that the network
recognizes packets (no signaling is needed) and provides the appropriate
services to them.
Today’s IP networks can use all three models at the same time.

Summary
IP Quality of Service is used to improve performance of IP networks. Quality of
Service can be measured based on available bandwidth, end-to-end delay, packet
loss and jitter. Different QoS mechanisms can be used to provide a predictable
service.
There are many different types of QoS mechanisms available in the Cisco IOS:
n Queuing mechanisms: Priority Queuing (PQ), Custom Queuing (CQ),
Weighted Fair Queuing (WFQ) with its distributed versions, IP RTP
Prioritization, Modified Deficit Round Robin (MDRR), Class-based Weighted
Fair Queuing (CB-WFQ) and Class-based Low-latency Queuing (CB-LLQ)
n Traffic Shaping mechanisms: Generic Traffic Shaping (GTS), Frame Relay
Traffic Shaping (FRTS) and Class-based Shaping
n Traffic Policing mechanisms: Committed Access Rate (CAR) and Class-
based Policing
n Dropping mechanisms: Weighted Random Early Detection (WRED)
n Link Efficiency mechanisms: Stacker, Predictor, TCP Header Compression
and RTP Header Compression
n Signaling mechanism: Resource Reservation Protocol (RSVP)
Review Questions
Answer the following questions:
n What are the relevant parameters that define the quality of service?
n What can be done to give more bandwidth to an application?
n What can be done to reduce delay?
n What can be done to prevent packet loss?
n Name the three QoS models?

Integrated Services Model
Objectives
n Describe the IntServ model
n List the key benefits and drawbacks of the IntServ model
n List some implementations that are based on the IntServ model
n Describe the need for Common Open Policy Service (COPS)

Integrated Services
• The Internet was initially based on a best-

effort packet delivery service
• Today's Internet carries many more different
applications than 20 years ago
• Some applications have special bandwidth
and/or delay requirements
• The Integrated Services model (RFC1633)
was introduced to guarantee a predictable
behavior of the network for these
applications
The Internet Engineering Task Force (IETF) is responsible for standardization of

the Internet and most of the protocols used in the Internet. When faced with a
challenge, vendors introduce their own solutions. However, the IETF is there to
create standards that allow different vendor’s equipment to interoperate. One of
the challenges in the past was to introduce Quality of Service into the best-effort
driven Internet. The Integrated Services (IntServ) model was proposed as standard
with Resource Reservation Protocol (RSVP) as the mechanism used to signal QoS
requirements to the network.
The IntServ model is described in the RFC 1633
(http://www.ietf.org/rfc/rfc1633.txt).
The use of RSVP for Integrated Services is described in RFC 2210
(http://www.ie tf.org/rfc/rfc2210.txt).

IntServ Building Blocks
Local Remote Admission Local

Admission Control Admission
Control Control
Policy Enforcement
Point (PEP)
request request request request
reserve reserve reserve reserve
request
reply
Policy Decision
Point (PDP)
• Resource Reservation is used to identify an application (flow)

and signal if there are enough available resources for it
• Admission Control is used to determine if the application (flow)
can get the requested resources
The IntServ model itself describes the application of QoS in IP networks.

Additional standards were developed to cover the exact protocols used to
implement Quality of Service:
n Resource Reservation is implemented using the Resource Reservation Protocol
(RSVP)
n Admission Control is either implemented locally on the routers or offloaded to
central servers
Common Open Policy Service (COPS) is another IETF standard that defines a
protocol that can be used for policy exchange between network devices (Policy
Enforcement Point or PEP) and policy servers (Policy Decision Point or PDP).
An additional standard was added to integrate RSVP with COPS.
The COPS (Common Open Policy Service) Protocol is defined in RFC 2748
(http://www.rfc-editor.org/rfc/rfc2748.txt).
COPS usage for RSVP is defined in RFC 2749
(http://www.rfc-editor.org/rfc/rfc2749.txt).

Reservation and Admission
Protocols
• The resource ReSerVation Protocol (RSVP)

was developed to communicate resource
needs between hosts and network devices
(RFC 2205-2215)
• Common Open Policy Service (COPS) was
developed to offload admission control to a
central policy server (RFC 2748-2753)
Following is a list of some of the IETF standards (RFCs) that describe RSVP,
COPS, the IntServ model and applications:
n Resource ReSerVation Protocol (RSVP), Version 1, Functional Specification
(http://www.ietf.org/rfc/rfc2205.txt)
n RSVP Management Information Base using SMIv2
n RSVP Extensions for IPSEC Data Flows (http://www.ietf.org/rfc/rfc2207.txt)
n Resource ReSerVation Protocol (RSVP), Version 1, Applicability Statement,
Some Guidelines on Deployment (http://www.ietf.org/rfc/rfc2208.txt)
n Resource ReSerVation Protocol (RSVP), Version 1, Message Processing
Rules (http://www.ietf.org/rfc/rfc2209.txt)
n The Use of RSVP with IETF Integrated Services
n Specification of the Controlled-Load Network Element Service
n Specification of Guaranteed Quality of Service
n Integrated Services Management Information Base using SMIv2
n Integrated Services Management Information Base, Guaranteed Service
Extensions using SMIv2 (http://www.ietf.org/rfc/rfc2214.txt)
n General Characterization Parameters for Integrated Service Network Elements

n The COPS (Common Open Policy Service) Protocol
n COPS usage for RSVP (http://www.ietf.org/rfc/rfc2749.txt)
n RSVP Extensions for Policy Control (http://www.ietf.org/rfc/rfc2750.txt)
n Signaled Preemption Priority Policy Element
n Identity Representation for RSVP (http://www.ietf.org/rfc/rfc2752.txt)
n A Framework for Policy-based Admission Control
(http://www.ie tf.org/rfc/rfc2753.txt)
n SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission
Control over IEEE 802-style networks (http://www.ietf.org/rfc/rfc2814.txt)
n Definitions of Managed Objects for Common Open Policy Service (COPS)
Protocol Clients (http://www.ietf.org/rfc/rfc2940.txt)
n COPS Usage for Policy Provisioning (COPS-PR)

RSVP-enabled Applications
• RSVP is typically used by applications

carrying voice or video over IP networks
(initiated by a host)
• RSVP with extensions is also used by MPLS
Traffic Engineering to establish MPLS/TE
tunnels (initiated by a router)
RSVP, as a resource reservation protocol, was designed for use by end devices in
networks (for example, personal computers and servers). It is a protocol that has
to be supported by an application that requires network resources and needs
guarantees.
n Typical examples of applications that would benefit from RSVP are voice
sessions that require a small amount of bandwidth with low-delay propagation.
n Cisco routers that act as voice gateways can use RSVP to request resources
(controlled-load and guaranteed-delay).
n Cisco routers that use Multiprotocol Label Switching (MPLS) Traffic
Engineering (MPLS/TE) use RSVP with extensions to reserve bandwidth and
set up MPLS/TE tunnels through MPLS and RSVP enabled networks.
n Cisco Soft Phone or Microsoft NetMeeting are Windows applications that use
RSVP to get resources for their VoIP sessions.
There are an increasing number of applications that use RSVP to request QoS
guarantees from a network.

IntServ Implementation Options
RSVP
1) Explicit RSVP on each network node
Class of Service
or
Best Effort
2) RSVP ‘pass -through’ and CoS transport
- map RSVP to CoS at network edge
- pass -through RSVP request to egress
3) RSVP at network edges and ‘pass -through’ with
- best-effort forwarding in the core (if there is
enough bandwidth in the core)
The figure illustrates three options available when implementing QoS mechanisms
via RSVP in a network.
1. The first option is to simply enable RSVP on all interfaces of all the routers in
the network. This approach is mainly used in enterprise networks that have
more predictable RSVP flows (in terms of quantity and direction because they
typically use hub-and-spoke topology). Large service provider networks are
less inclined to use RSVP throughout their networks either because RSVP
would require too many concurrent reservations on a single interface or
because the routers are not capable of providing guarantees to individual flows
on high-bandwidth interfaces.
2. An alternative option is to use RSVP on network edges where there is
typically less bandwidth per interface and congestion is more likely. The edge-
to-core routers (for example, access or distribution layer routers) mark RSVP
flows with IP markers, which can then be used in a DiffServ enabled core—
the Differentiated Services model is covered in the next lesson).
3. Another option is to use RSVP on network edges and rely on best-effort
delivery in a non-congested core.

Explicit RSVP Transport
IntServ End-to-End
RSVP
All Routers
• WFQ applied per flow
based on RSVP requests
In the first scenario, each router in the network processes RSVP messages and
keeps track of the special resource needs for each individual RSVP flow.
Weighted Fair Queuing (WFQ) can be used in the backbone to provide resource
allocation on a flow-by-flow basis.
One concern with this approach is that RSVP is resource intensive on backbone
routers - in terms of the amount of signaling and the amount of special information
that they need to keep on each RSVP flow.
A second issue is that WFQ is a very CPU-intensive algorithm and does not run at
high speed on today’s routers. In the backbone, high speed is a mandatory
requirement.

RSVP Pass-Through
IntServ - DiffServ Integration
RSVP RSVP
Precedence
Classifier
WRED
Premium Egress Router
Standard
• RSVP protocol
sent on to destination
Ingress Router • WFQ applied to
• RSVP protocol manage egress flow
Mapped to classes
Passed through to egress Backbone
• WRED applied based
on class
An alternative to enabling RSVP end-to-end is to use RSVP as a means to signal

special requirements between the customer and the ISP edge, but not to use it in
the backbone. In this model, packets are mapped on RSVP flows into special
service classes which give each class preferential treatment in the core of the
network when congestion occurs. This avoids the scalability problem of end-to-end
RSVP, since these flows are processed between the end station and the network
edge and not in the middle of the backbone.
By using WRED on routers, instead of WFQ, much higher speeds can be
supported. Alternatively, Class-based WFQ can be used on moderate-speed links
to provide better control of bandwidth allocation. The third option is not to use
RSVP in the core and rely on best-effort delivery if the core is not congested.
Lastly, mapping classes of service to ATM is more straightforward than mapping
RSVP directly to ATM.
This concept may accelerate the ability of ISPs to offer an RSVP service and
enable new application areas.

IntServ Support in IOS
• RSVP and Weighted Fair Queuing supported

since ’95
• RSVP signaling for VoIP calls supported on
all VoIP platforms
• IOS supports hop-by-hop and pass-through
RSVP
• RSVP-to-DSCP (DiffServ Code Point)
mapping (RSVP proxy) in 12.1T
Both RSVP and WFQ have been available for some time and can be used on all
low-end platforms and on high-end platforms that are typically used to concentrate
customer networks.
Newer RSVP mechanisms include:
n Mapping of RSVP to DSCP (the Differentiated Services model with the details
of the DiffServ Code point is covered in the next lesson).
n Mapping of RSVP to ATM SVCs (this technology is covered in the “IP QoS -
IP over ATM” module).

Benefits and Drawbacks of the
IntServ Model
+ RSVP benefits:
• Explicit resource admission control (end to end)
• Per-request policy admission control
(authorization object, policy object)
• Signaling of dynamic port numbers (for example,
H.323)
–RSVP drawbacks:
• Continuous signaling due to stateless architecture
• Not scalable
The main benefits of RSVP are:

n It signals QoS requests per individual flow. The network can then provide
guarantees to these individual flows. The problem of this is that it does not scale
to large networks because of the large numbers of concurrent RSVP flows.
n It informs network devices of flow parameters (IP addresses and port
numbers). Some applications use dynamic port numbers, which can be difficult
for network devices to recognize. NBAR is a mechanism that has been
introduced to supplement RSVP for applications that use dynamic port numbers
but do not use RSVP.
It supports admission control that allows a network to reject (or down-grade) new
RSVP sessions if one of the interfaces in the path has reached the limit (all
reservable bandwidth is booked).
The main drawbacks of RSVP are:
n Continuous signaling due to stateless operation of RSVP.
n RSVP is not scalable to large networks where per-flow guarantees would have
to be made to thousands of flows.

Common Open Policy Service
• Common Open Policy Service (COPS)

provides the following benefits when used
with RSVP:
– Centralized management of services
– Centralized admission control and authorization of
RSVP flows
• RSVP-based QoS solutions become more
scalable
The Common Open Policy Service (COPS) is an add-on to RSVP. It can be used
to offload certain tasks from network devices to a central server. The result is that
the configuration of individual devices is more standardized (template-based) and
all individual parameters are managed from a centralized location. In addition,
COPS supports admission control of individual flows (the network device
determines the available resources and the central server authorizes the flow).

Summary
The Integrated Services (IntServ) model was introduced to allow vendors of
routers to add interoperable QoS mechanisms to their best-effort packet
forwarding. Resource Reservation Protocol (RSVP) is used by end-devices to
signal QoS requirements to the network. Common Open Policy Service (COPS) is
used to offload policy management to central servers.
Review Questions
n What are the two building blocks of the Integrated Services model?
n Which protocol is used to signal QoS requirements to the network?

Differentiated Services Model
Objectives
n Describe the DiffServ model
n List the key benefits of the DiffServ model compared to the IntServ model
n Describe the purpose of the DS field in IP headers
n Describe the interoperability between DSCP-based and IP-precedence-based
devices in a network
n Describe the Expedited Forwarding service
n Describe the Assured Forwarding service

• Differentiated Services model describes

services associated with traffic classes
• Complex traffic classification and
conditioning is performed at network edge
resulting in a per-packet Differentiated
Services Code Point (DSCP).
• No per-flow/per-application state in the core
• Core only performs simple ‘per-hop
behavior's’ on traffic aggregates
• Goal is Scalability
The Differentiated Services (DiffServ) model describes services associated

with traffic classes. Traffic classes are identified by the value of the DiffServ
Code Point (DSCP replaces IP precedence in the ToS field of the IP header).
The main goals of the DiffServ model are to provide scalability and a similar level
of QoS to the IntServ model, without having to do it on a per-flow basis. The
network simply identifies a class (not application) and applies the appropriate per-
hop behavior (QoS mechanism).
The DiffServ model and associated standards are described in the following IETF
standardization documents (RFCs):
n An Architecture for Differentiated Services
n Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers (http://www.ietf.org/rfc/rfc2474.txt)
n Assured Forwarding per-hop behavior (PHB) Group
n An Expedited Forwarding per-hop behavior (PHB)

Additional Requirements
• Wide variety of services and provisioning

policies
• Decouple service and application in use
• No application modification
• No hop-by-hop signaling
• Interoperability with non-DS-compliant nodes
• Incremental deployment
The DiffServ model describes services and allows for more user-defined services
to be used in a DiffServ-enabled network.
Services are provided to classes. A class can be identified as a single application
or, as in most cases, it can be identified based on source or destination IP address.
The idea is for the network to recognize a class without having to receive any
request from applications. This allows the QoS mechanisms to be applied to other
applications that do not have the RSVP functionality, which is the case for 99% of
applications that use IP.
The introduction of the DiffServ Code Point (DSCP) replaces the IP precedence
but maintains interoperability with non-DS compliant devices (those that still use IP
precedence). Because of this backward-compatibility DiffServ can be gradually
deployed in large networks.

DiffServ Elements
• The service defines QoS requirements and

guarantees provided to a traffic aggregate;
• The conditioning functions and per-hop behaviors
are used to realize services;
• The DS field value (DS code point) is used to mark
packets to select a per-hop behavior
• Per-hop Behavior (PHB) is realized using a particular
QoS mechanism
• Provisioning is used to allocate resources to traffic
classes
A traffic aggregate is a collection of all flows that require the same service. A
service is implemented using different QoS mechanisms (a QoS mechanism
implements a per-hop behavior).
The DiffServ field (DS fie ld) is the former 8-bit Type of Service field. The main
difference is that the DSCP supports more classes (64) than IP precedence (8).
The most important part of designing QoS is to provision services as explained on
the next page.

Why is Provisioning Important?
• QoS does not create bandwidth!

• QoS manages bandwidth usage among
multiple classes
• QoS gives better service to a well-
provisioned class with respect to another
class
Provisioning requires a thorough network analysis to determine parameters for

services that are being deployed in the network. The result of provisioning is the
allocation of bandwidth among all classes in times of congestion.
Services are implemented by defining per-hop behavior (PHB) properties. PHBs
are implemented by using the available QoS mechanisms in networks devices.

Topological Terminology
DS interior node
DS Egress
DS Ingress Boundary node
Boundary node
Boundary link
Upstream
DS domain Downstream
DS domain
DS region
Traffic Stream = set of flows
Behaviour Aggregate (flows with the same DSCP)
A DS domain consists of DS boundary nodes and DS interior nodes. DS

boundary nodes interconnect the DS domain to other DS or non-DS-capable
domains. While DS interior nodes only connect to other DS interior or boundary
nodes within the same DS domain. Both DS boundary nodes and interior nodes
must be able to apply the appropriate PHB to packets based on the DS code
point; otherwise unpredictable behaviour may result.
DS boundary nodes act both as a DS ingress node and as a DS egress node for
traffic traversing the network in different directions. Traffic enters a DS domain at
a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress
node is responsible for ensuring that the traffic entering the DS domain conforms
to any Traffic Conditioning Agreement (TCA) between it and the other domain
to which the ingress node is connected. A DS egress node may perform traffic
conditioning functions on traffic forwarded to a directly connected peering domain,
depending on the details of the TCA between the two domains.
A differentiated services region (DS Region) is a set of one or more contiguous
DS domains. DS regions are capable of supporting differentiated services along
paths that span the domains within the region.
The DS domains in a DS region may support different PHB groups internally and
different code point-PHB mappings. However, to permit services that span across
the domains, the peering DS domains must each establish a peering Service
Level Agreement (SLA) that defines (either explicitly or implicitly) a TCA. The
TCA specifies how transit traffic from one DS domain to another is conditioned at
the boundary between the two DS domains.
It is possible that several DS domains within a DS region may adopt a common
service provisioning policy and may support a common set of PHB groups and

code point mappings. This eliminates the need for traffic conditioning between
those DS domains.

Traffic Terminology
• Flow: a single instance of an application-to-

application flow of packets which is identified by
source address, source port, destination address,
destination port and protocol id.
• Traffic stream: an administratively significant set of
one or more flows which traverse a path segment. A
traffic stream may consist of a set of active flows
which are selected by a particular classifier.
• Traffic profile: a description of the temporal
properties of a traffic stream such as average and
peak rate and burst size.
The terminology used throughout the course includes the following:

n Flow (or microflow) is a sequence of packets identified by source and
destination IP addresses, protocol identifier (for example, TCP and UDP) and
source and destination port numbers.
n Traffic stream is a collection of flows with a common set of parameters (for
example, the same port number and the same source and destination network).
n Traffic profile specifies typical properties of a traffic stream (average rate and
burstiness). Provisioning should be performed based on traffic profiles and the
importance of traffic streams.

Traffic Terminology
• Behavior Aggregate (BA) is a collection of

packets with the same DS code point
crossing a link in a particular direction.
• Per-Hop Behavior (queuing in a node)
externally observable forwarding behavior
applied at a DS-compliant node to a DS
behavior aggregate.
• PHB Mechanism: a specific algorithm or
operation (e.g., queuing discipline) that is
implemented in a node to realize a set of one
or more per-hop behaviors.
Other important terms used throughout the course are:

n Behavior Aggregate (BA) identifies packets marked with the same DSCP
n Per-hop Behavior (PHB) is applied to each BA according to the QoS policy
n PHB mechanism is the actual QoS mechanism that satisfies PHB specification
Other terms can be found in RFC 2475, which defines the Differentiated Services
model (http://www.ie tf.org/rfc/rfc2475.txt).

Packet Header Terminology
DSCP field: 6bits Unused: 2bits
Former ToS byte = new DS field
• DS code point: a specific value of the DSCP portion

of the DS field, used to select a PHB (Per-Hop
Behavior; forwarding and queuing method)
• DS field: the IPv4 header ToS octet or the IPv6 Traffic
Class octet when interpreted in conformance with
the definition given in RFC2474. The bits of the
DSCP field encode the DS code point, while the
remaining bits are currently unused.
The DiffServ model uses the DS field in the IP header to mark packets according
to their classification into Behavior Aggregates (BAs). The DS field occupies the
same eight bits of the IP header that were previously used for the Type of Service
(ToS) field.
There are three IETF standards describing the purpose of those eight bits:
n RFC 791 includes specification of the ToS field where the high-order three bits
are used for IP precedence. The other bits are used for delay, throughput,
reliability and cost.
n RFC 1812 modifies the meaning of the ToS field by removing any meaning
from the five low-order bits (those bits should all be zero).
n RFC 2474 replaces the ToS field with the DS field where the six high-order bits
are used for the DiffServ Code Point (DSCP). The remaining two bits are
currently not used.
Each DSCP value identifies a Behavior Aggregate (BA). Each BA is assigned a
per-hop behavior (PHB). Each PHB is implemented using the appropriate QoS
mechanism or a set of QoS mechanisms.

DSCP Encoding
• Three pools:
– “xxxxx0” Standard Action
– “xxxx11” Experimental/Local Use
– “xxxx01” EXP/LU (possible std action)
• Default DSCP: “000000”
• Default PHB: FIFO, tail-drop
Unlike IP precedence, which lacked any standard definitions of values and

corresponding PHBs, the DSCP has half of its value range reserved for standard
defined PHBs.
The low-order bit of the DSCP identifies whether the DSCP value identifies a
standard action (PHB) or a user-defined action.
The second bit could, potentially, (in the future) also be used to identify additional
standard actions.
The default value of DSCP is 0. The associated PHB is FIFO service with a
tail-drop. FIFO queuing is discussed in the “IP QoS – Queuing mechanisms
module”.
The default DSCP value seamlessly maps to the default IP precedence value,
which is also 0 according to RFC 1812.

DSCP Usage
DS Code point selects per-hop behavior

(PHB) throughout the network
• Default PHB
• Class Selector (IP precedence) PHB
• Expedited Forwarding (EF) PHB
• Assured Forwarding (AF) PHB
The following per-hop behaviors are defined by IETF standards:

n Default PHB – used for best-effort service
n Class Selector PHB – used for backward compatibility with non-DS
compliant devices (RFC 1812 compliant devices and, optionally, RFC 791
compliant devices)
n Expedited Forwarding PHB – used for low-delay service
n Assured Forwarding PHB – used for guaranteed bandwidth service
The Default PHB and the Class Selector PHB are described in RFC 2474
(http://www.ietf.org/rfc/rfc2474.txt), Expedited Forwarding PHB is described in
RFC 2598 (http://www.ietf.org/rfc/rfc2598.txt) and Assured Forwarding in
RFC 2597 (http://www.ietf.org/rfc/rfc2597.txt).

Backward Compatibility Using the
Class Selector
• Non-DS compliant node: node that does not

interpret the DSCP correctly or that does not
support all the standardized PHB’s
• Legacy node: a non-DS compliant node that
interprets IPv4 ToS such as defined by
RFC791 and RFC1812.
• DSCP is backward compatible with IP
Precedence (Class Selector Code point, RFC
1812) but not with the ToS byte definition
from RFC 791 (“DTR” bits)
The history of the eight bits in question (ToS field alias DS field) can be divided
into three periods according to the RFCs describing the purpose of those bits:
RFC 791
RFC 791 defines the Type of Service field with the following components:
n Bits seven, six and five are used for IP precedence
n Bit four is used for delay (0 = Normal Delay, 1 = Low Delay)
n Bit three is used for throughput (0 = Normal Throughput, 1 = High
Throughput)
n Bit two is used for reliability (0 = Normal Reliability, 1 = High Reliability)
n Bits one and zero are not used and should be zero (bit one was later applied a
meaning of monetary-cost by RFC 1349; this RFC also replaces individual bits
with a four-bit ToS value to allow more types of services)
RFC 1812
RFC 1812 loosens the strict representation of the ToS field (obsole tes RFC 795).
RFC 2474
RFC 2474 replaces the ToS field with the DS field where a range of eight values
(Class Selector) is used for backward compatibility with IP precedence. There is
no compatibility with the delay, throughput, reliability and monetary-cost bits.

Class Selector Code Point
• Compatibility with current IP precedence

usage (RFC 1812)
• “xxx000” DS code points
• Differentiates probability of timely forwarding
(PTF)
– PTF (xyz000) >= PTF(abc000) if xyz > abc
RFC 1812 simply prioritizes packets according to the precedence value. The PHB
is defined as the probability of timely forwarding. Packets with higher IP
precedence should (on the average) be forwarded in less time than packets with
lower IP precedence.
RFC 2474 adopts this set of PHBs and values by creating the Class Selector PHB
group. Class Selector can be identified by the low-order three bits of the DSCP or
low-order five bits of the DS field: all bits are zero.

Expedited Forwarding
• Expedited Forwarding (EF) PHB:

– Ensures a minimum departure rate
– Guarantees bandwidth – the class is guaranteed
an amount of bandwidth with prioritized
forwarding
– Polices bandwidth – the class is not allowed to
exceed the guaranteed amount (excess traffic is
dropped)
• DSCP value: “101110”; looks like IP precedence 5 to
non-DS compliant devices
The Expedited Forwarding PHB is identified based on the following parameters:

n Ensures a minimum departure rate to provide the lowest possible delay to
delay-sensitive applications
n Guarantees bandwidth to prevent starvation of the application if there are
multiple applications using Expedited Forwarding PHB
n Polices bandwidth to prevent starvation of other applications or classes that
are not using this PHB
n Packets requiring Expedited Forwarding should be marked with DSCP binary
value “101110” (46 or 0x2E)
Non-DS compliant devices will regard EF DSCP value as IP precedence 5 (101),
which is the highest user-definable IP precedence and is typically used for
delay-sensitive traffic such as Voice over IP.

IOS EF PHB Implementations
• Priority Queuing
• IP RTP Prioritization
• Class-based Low-latency Queuing (CB-LLQ)
• Strict Priority queuing within Modified Deficit
Round Robin (MDRR) on GSR
Expedited Forwarding PHB can be implemented on Cisco routers using several

different QoS mechanisms:
n Routers running older Cisco IOS versions can use Priority Queuing (PQ) and
put delay-sensitive traffic into a “high” priority queue. Priority Queuing,
however, does not fully comply with the specification of the EF PHB – it does
not have the capability to police the bandwidth used by the EF class.
n IP RTP Prioritization can be used in combination with Weighted Fair Queuing
(WFQ) or Class-based Weighted Fair Queuing (CB-WFQ). IP RTP
Prioritization provides expedited forwarding with bandwidth guarantee and
bandwidth policing.
n Class-based Low-latency Queuing (CB-LLQ) is a mechanism similar to IP
RTP Prioritization. It is the preferred mechanism for implementing EF PHB.
n Strict Priority within Modified Deficit Round Robin (MDRR) on the Cisco
12000 series routers provides low-latency queuing but does not police
bandwidth. Alternate Priority MDRR prevents starvation of other classes but
it does not police bandwidth of the EF class.

Assured Forwarding
• Assured Forwarding (AF) PHB:

–Guarantees bandwidth
–Allows access to extra bandwidth if
available
• Four standard classes (af1, af2, af3 and af4)
• DSCP value range: “aaadd0” where “aaa” is
a binary value of the class and “dd” is drop
probability
The Assured Forwarding PHB is identified based on the following parameters:

n Guarantees a certain amount of bandwidth to an AF class
n Allows access to extra bandwidth, if available
n Packets requiring AF PHB should be marked with DSCP value “aaadd0”
where “aaa” is the number of the class and “dd” is the drop probability
There are four standard-defined AF classes. Each class should be treated
independently and have bandwidth allocated based on the QoS policy.

AF Encoding
Class Value Drop Value

Probability
AF1 001dd0 (dd)
Low 01
AF2 010dd0 Medium 10
AF3 011dd0 High 11
AF4 100dd0
• Each AF class uses three DSCP values
• Each AF class is independently forwarded with its
guaranteed bandwidth
• Differentiated RED is used within each class to
prevent congestion within the class
As the figure illustrates there are three DSCP values assigned to each of the four
AF classes.
Assured Forwarding class Drop Probability DSCP value
AF class 1 Low 001 01 0
Medium 001 10 0
High 001 11 0
Medium 010 10 0
High 010 11 0
Medium 011 10 0
High 011 11 0
Medium 100 10 0
High 100 11 0

AF PHB Definition
• A DS node MUST allocate a configurable,

minimum amount of forwarding resources
(buffer space and bandwidth) per AF class
• Excess resources may be allocated between
non-idle classes. The manner must be
specified.
• Reordering of IP packets of the same flow is
not allowed if they belong to the same AF
class
An AF implementation must attempt to minimize long-term congestion within each

class, while allowing short-term congestion resulting from bursts. This requires an
active queue management algorithm. An example of such an algorithm is Weighted
Random Early Detection (WRED).
The AF specification does not define the use of a particular algorithm, but does
require that several properties hold.
An AF implementation must detect and respond to long-term congestion within
each cla ss by dropping packets, while handling short-term congestion (packet
bursts) by queuing packets. This implies the presence of a smoothing or
filtering function that monitors the instantaneous congestion level and
computes a smoothed congestion level. The dropping algorithm uses this
smoothed congestion level to determine when packets should be discarded.
The dropping algorithm must treat all packets within a single class and precedence
level identically. This implies that, for any given smoothed congestion level, the
discard rate of a particular microflow's packets within a single precedence level
will be proportional to that flow's percentage of the total amount of traffic passing
through that precedence level.
The congestion indication feedback to the end nodes, and thus the level of packet
discard at each drop precedence in relation to congestion, must be gradual rather
than abrupt. This allows the overall system to reach a stable operating point.
WRED uses two (configurable) smoothed congestion level thresholds. When the
smoothed congestion level is below the first threshold, no packets of the relevant
drop precedence are discarded. When the smoothed congestion level is between
the first and the second threshold, packets are discarded with linearly increasing
probability, ranging from zero to a configurable value reached just prior to the
second threshold. When the smoothed congestion level is above the second

threshold, packets of the relevant drop precedence are discarded with 100%
probability.
To allow the AF PHB to be used in many different operating environments, the
dropping algorithm control parameters must be independently configurable for each
packet drop precedence and for each AF class. Within the limits above, this
specification allows for a range of packet discard behaviours.

AF PHB Implementation
• CBWFQ (4 classes) with WRED within each

class
• (M)DRR with WRED within each class
• Optionally Custom Queuing (does not
support differentiated dropping)
As with Expedited Forwarding there are multiple QoS mechanisms in the Cisco
IOS that can accommodate some or all of the requirements of Assured Forwarding
PHB:
n The preferred implementation is to use the Class-based Weighted Fair Queuing
(CB-WFQ) with four classes (four independent queues) and Weighted Random
Early Detection (WRED) within each queue.
n A similar solution can be provided on the Cisco 12000 series routers by using
the Modified Deficit Round Robin (MDRR) queuing with WRED in each
queue. The AF PHB can also be implemented using the old-fashioned IP
precedence. The only restriction is the number of available IP precedence
values.
n Example 1:
n Four classes but no differentiated dropping:
n AF1—IP precedence 1
n Example 2:
n Two classes with differentiated dropping (two drop precedence values):
n AF1—IP precedence 1 for high-drop, IP precedence 2 for low-drop
n AF1—IP precedence 3 for high-drop, IP precedence 4 for low-drop

n In both examples IP precedence 0 can be used for a best-effort class and IP
precedence 5 for an EF class.
n A similar solution as shown in Example 1 is also possible with Custom
Queuing, except it has no support for differentiated dropping and DSCP. A
workaround is possible if access-lists are used to match the DSCP value
(direct matching of DSCP available only in IOS 12.1 and above) with a
combination of IP precedence and ToS value.

Summary
After completing this lesson, you should be able to perform the following tasks:
n Describe the DiffServ model
n List the key benefits of the DiffServ model compared to the IntServ model
n Describe the purpose of the DS field in IP headers
n Describe the interoperability between DSCP-based and IP-precedence-based
devices in a network
n Describe the Expedited Forwarding service
n Describe the Assured Forwarding service
Review Questions
n What are the benefits of the DiffServ model compared to the IntServ model?
n What is a DiffServ Code Point?
n Name the standard PHBs?
n How was backward compatibility with IP precedence achieved?
n Describe the PHB of Assured Forwarding.
n Describe the PHB of Expedited Forwarding.

Building Blocks of IP QoS Mechanisms
Objectives
n Describe different classification options in IP networks
n Describe different marking options in IP networks
n List the mechanisms that are capable of measuring the rate of traffic
n List the mechanisms that are used for traffic conditioning, shaping and avoiding
congestion
n List the forwarding mechanisms available in Cisco IOS
n List the queuing mechanisms available in Cisco IOS

Router Functions
Defragmentation
Decompression (payload, header) Rate -limiting
Source -based qos-label/precedence setting Random dropping
Destination-based qos-label/precedence Shaping
setting Compression (payload, header)
Rate -limiting Fragmentation
Class -based marking Queuing and scheduling
Policy-based-routing ...
...
Input Output
Input I/O Forwarding Output I/O
Processing Processing
Process switching
Fast/optimum switching
Netflow switching
CEF switching
• Depending on the configuration, a router may perform a number of

actions prior to forwarding a packet (input processing)
• Depending on the configuration, a router may perform a number of
actions prior to enqueuing a packet in the hardware queue (output
processing)
Basic router function takes packets received on the input interface, makes a
forwarding decision and transmits the packet out through the output interface.
Today’s routers, however, can do much more than that. The figure lists a small
subset of features that affect packet processing on input or output interfaces.
Following is a list of some of the features available with Cisco routers:
n Payload compression (Stacker, Predictor)
n Header compression (TCP and RTP header compression)
n BGP-policy marking (CEF-based marking or QoS Policy propagation through
BGP)
n Traffic Policing (CAR, CB Policing)
n Traffic Shaping (GTS, FRTS, CB-Shaping)
n Class-based marking
n Encryption (CET or IPsec)
n WRED
n Policy-based Routing
n Accounting (IP accounting, NetFlow accounting)
n Filtering (access lists)
n Reverse-path checking
n Address and port translation (NAT, PAT)
n Stateful filtering (firewalling)
n Web-cache redirection

IP QoS Actions
• Classification – Each class-oriented QoS mechanism

has to support some type of classification (access
lists, route maps, class maps, etc.)
• Metering – Some mechanisms measure the rate of
traffic to enforce a certain policy (e.g. rate limiting,
shaping, scheduling, etc.)
• Dropping – Some mechanisms are used to drop
packets (e.g. random early detection)
• Policing – Some mechanisms are used to enforce a
rate limit based on the metering (excess traffic is
dropped)
• Shaping – Some mechanisms are used to enforce a
rate limit based on the metering (excess traffic is
delayed)
IP QoS mechanisms can perform different types of actions. All QoS mechanisms
can be divided into the following QoS actions:
n Classification – most QoS mechanisms support multiple classes. There are
different classification tools available with different QoS mechanisms (for
example, access lists, route maps, class maps and rate-limit access lists). Some
QoS mechanisms have the capability to match directly on certain parameters.
For example:
– CAR (QoS group and DSCP)
– WRED (IP precedence)
– ToS-based dWFQ (IP precedence)
– QoS-group-based dWFQ (QoS group)
– WFQ (flow parameters)
– PQ and CQ (interface, packet size and protocol)
n Some mechanisms require the information about traffic rate of classes (for
example, CAR, GTS, FRTS, CB-Shaping, CB-Policing, CB-WFQ, CB-LLQ,
MDRR and IP RTP Prioritization).
n Some mechanisms are used for dropping purposes. They utilize a dropping
scheme different from the usual tail-drop. WRED is an example of such
mechanism.
n Some mechanisms are used to limit traffic rate by dropping excess traffic
(CAR and CB-Policing).
n Some mechanisms are used to limit traffic rate by delaying excess traffic (GTS,
FRTS and CB-Shaping).

IP QoS Actions
• Marking – Some mechanisms have the capability to

mark packets based on classification and/or
metering (e.g. CAR, class-based marking, etc.)
• Queuing – Each interface has to have a queuing
mechanism
• Forwarding – There are several supported
forwarding mechanisms (process switching, fast
switching, CEF switching, etc.)
n Some mechanisms have the capability to mark packets with different types of
markers (IP precedence, DSCP, QoS group, MPLS experimental bits, ATM
CLP bit, Frame Relay DE bit and 802.1q or ISL priority/cos bits)
n Some mechanisms are used for queuing on output interfaces (for example,
FIFO, PQ, CQ, WFQ, dWFQ, ToS-based dWFQ, QoS-group-based dWFQ,
CB-WFQ, IP RTP Prioritization and MDRR)
n Cisco IOS also has different types of forwarding mechanisms (Process
Switching, Fast Switching, Optimum Switching, Silicon Switching, Autonomous
Switching, NetFlow Switching, Cisco Express Forwarding and Policy-based
routing)

DiffServ Mechanisms in IOS
Meter
Classifier Marker Conditioner Queuing

Inbound
traffic Shaping Scheduling
stream Dropping Dropping
• Most traditional QoS mechanisms include extensive built-in classifiers

– Committed Access Rate (CAR)
– QoS Policy Propagation via BGP (QPPB)
– Route-maps
– Queuing mechanisms
– ...
• Modular QoS CLI (first implemented in 12.0(5)T) separates classifier
from other actions
– Includes all traditional classifiers + Network Based Application Recognition
(NBAR)
Most QoS mechanisms include several different classification options. The

following table lists some QoS mechanisms with the corresponding classification
options.
QoS Mechanism Classification options
Committed Access Rate (CAR) Access list
Rate limit access list
QoS-group
DSCP
QoS Policy Propagation through BGP Route map
(QPPB)
Policy-based routing Route map
Generic Traffic Shaping Access list
Priority Queuing and Custom Queuing Access list
Packet size
Input interface
Protocol
All mechanisms available using the Class map which can use: another class
modular QoS CLI (CB-WFQ, CB-LLQ, map, access list, protocol (including
CB-Shaping, CB-Policing, CB-Marking) NBAR), input interface, source or
destination MAC address, IP
precedence, DSCP, QoS group, MPLS
experimental bits, etc.)

Meter

Inbound
• Token Bucket model is used for metering

– Generic Traffic Shaping (GTS)
– Frame Relay Traffic Shaping (FRTS)
– Class-based Weighted Fair Queuing (CB-WFQ)
– Class-based Low Latency Queuing (CB-LLQ)
– Class-based Policing
– Class-based Shaping
– IP RTP Prioritization
The figure lists QoS mechanisms in the Cisco IOS that have the capability to
measure the rate of traffic by using the Token Bucket model.

Meter

Inbound
• Marker is used to set: • Marking mechanisms:

– IP precedence – Comitted Access Rate (CAR)
– DSCP – QoS Policy Propagation
– QoS group through BGP (QPPB)
– MPLS experimental bits – Policy-based Routing (PBR)
– Frame Relay DE bit – Class-based Marking
– ATM CLP bit
– IEEE 802.1Q or ISL CoS
The figure lists markers that can be set using Cisco routers and the queuing
mechanisms that have marking capabilities.
The following table lists all the mechanisms that have marking capabilities and the
markers that are supported by those mechanisms.
QoS Mechanism Available markers
Committed Access Rate (CAR) IP precedence
DSCP
QoS group
MPLS experimental bits
QoS Policy Propagation through BGP IP precedence
(QPPB) QoS group
Policy-based Routing (PBR) IP precedence
QoS group
Class-based Marking IP precedence
DSCP
QoS group
MPLS experimental bits
ATM CLP bit
Frame Relay DE bit
802.1Q/ISL cos/priority

Comparison of Markers
Marker
Marker Preservation Value range
IP precedence Throught a network 8 values, 2 reserved

(0 to 7)
DSCP Throught a network 64 values, 32 are standard

(0 to 63)
QoS group
group Local to a router 100 values
(0 to 99)
Throughout an MPLS network
MPLS experimental
experimental bits
bits 8 values
(optionally throughout
throughout an
entire IP network)
Frame Relay DE bit Throughout a Frame Relay 2 values
network (0 or 1)
ATM CLP bit Throughout an ATM 2 values
network (0 or 1)
IEEE 802.1Q or
or ISL
ISL CoS
CoS Throughout a LAN 8 values
switched network (0 to 7)
The figure describes the differences between markers in terms of preservation of

the marker and a value range. Markers can:
n Be local to the router (the QoS group is not part of a packet or frame; it is a
piece of information attached to a packet while it is stored in the router’s
memory)
n Have a limited range due to layer-2 technology that they use (ATM CLP, FR
DE, 802.1q/ISL cos/priority, MPLS exp bits)
n Have an unlimited range (IP precedence, DSCP)

Meter

Inbound
• Shaping mechanisms:
– Hardware shaping on ATM VC
The figure lists four mechanisms that are used for traffic shaping purposes. All of
these mechanisms are implemented in software (Cisco IOS) except for ATM
shaping which is implemented in hardware.
Traffic shaping is used to limit the departure rate of packets, frames or cells by
delaying them if they exceed the contractual rate. A token bucket model is used to
measure the arrival rate and determine when packets can be forwarded.

Meter

Inbound
• Dropping mechanisms
– Committed Access Rate (CAR) and Class-based
Policing can drop packets that exceed the
contractual rate
– Weighted Random Early Detection (WRED) can
randomly drop packets when an interface is
nearing congestion
Another way of enforcing rate limits is to drop excess traffic. Committed Access
Rate (CAR) and Class-based Policing can be used for this purpose.
Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism
that randomly drops packets when interfaces are nearing congestion.

Meter
Classifier Marker Conditioner Forwarding Queuing

Inbound
• Cisco Express Forwarding (CEF) is

recommended from IOS 12.0
• Some QoS features work only in combination
with CEF
The Cisco IOS supports a large number of different forwarding mechanisms

(depending on the platform and the IOS version). From the QoS perspective it can
be said that:
n Most newer mechanisms require Cisco Express Forwarding (CEF)
n Some older mechanisms do not work with CEF (Process or Fast switching is
required)
Some other forwarding mechanisms available in the Cisco IOS include:
n Process switching, which is the oldest forwarding mechanisms available since
the first releases of Cisco IOS.
n Fast switching, which is the first optimization of forwarding. It uses a cache to
store most used destinations and it is performed in the interrupt code to improve
performance.
n Optimum switching, which is a further optimized version of fast switching on
high-end routers.
n NetFlow switching, which forwards packets by recognizing and caching flow
information.

Meter

Inbound
• Traditional queuing mechanisms

– FIFO, Priority Queuing (PQ), Custom Queuing (CQ)
• Weighted Fair Queuing (WFQ) family
– WFQ, dWFQ, CoS-based dWFQ, QoS-group dWFQ
• Advanced queuing mechanisms
– Class-based WFQ, Class-based LLQ
The last mechanism that handles packets in the IOS is the queuing mechanism.
The figure lists most of the queuing mechanisms.

Meter

Inbound
• Tail drop on queue congestion

• WFQ has an improved tail-drop scheme
• WRED randomly drops packets when nearing
congestion
All queuing mechanisms include a drop policy. Most mechanisms use a simple tail-
drop scheme (the last packet to arrive is dropped if there is no room in the queue).
Weighted Fair Queuing (WFQ) uses a more intelligent dropping scheme, which
is discussed in the “IP QoS – Queuing mechanisms” module. Some queuing
mechanisms also include the Weighted Random Early Detection (WRED) to
prevent congestion in their queues.

Summary
n Describe different classification options in IP networks
n Describe different marking options in IP networks
n List the mechanisms that are capable of measuring the rate of traffic
n List the mechanisms that are used for traffic conditioning, shaping and avoiding
congestion
n List the forwarding mechanisms available in the Cisco IOS
n List the queuing mechanisms available in the Cisco IOS
Review Questions
n Name the QoS building blocks.
n What is the purpose of classification?
n What is the purpose of marking?
n Which markers do you know?
n Which mechanisms can classify and mark packets?
n Which mechanisms have the ability to measure the rate of traffic?
n Which forwarding mechanisms do you know?
n Which queuing mechanisms do you know?
n How, when and where do routers drop packets?

Enterprise Network Case Study
Objectives
n Describe a typical structure of an enterprise network
n Describe the need for QoS in enterprise networks
n List typical QoS requirements in enterprise networks
n List the QoS mechanisms that are typically used in enterprise networks

Traditional
Enterprise Networks
Core
(central sites
and
data centres)
X.25 (ancient), Frame Relay (old),

ATM (newer)
Distribution
(regional centres)
X.25 (ancient), Frame Relay (old),

ATM (newer)
Access
(branch offices)
• Traditional enterprise network use a hub-and-spoke topology

• Redundant connections are used to improve resilience
• Partial mesh can be used between the core sites and the distribution
sites
This lesson describes typical Enterprise Networks to show the topology and
technologies involved in such networks. Designing IP QoS networks largely
depends on the topology and QoS requirements.
The figure illustrates a three-layered network:
1. The core interconnects the data center(s) with the distribution-layer routers.
2. The distribution layer routers concentrate links towards a number of access-
layer routers.
3. The access-layer routers connect branch offices to the network.
Most traffic in enterprise networks goes between branches and the data center.

Modern
Enterprise Networks
Core
(central sites
and
data centres)
MPLS/VPN (new)
Access
(branch offices)
• Modern enterprise network use a full mesh topology provided by an MPLS/VPN

backbone
• Redundant connections to the backbone can be used to improve resilience
• The MPLS/VPN backbone uses redundant connections and a partial mesh to
improve resilience
Modern enterprise networks can use MPLS/VPN backbones to get a virtual full
mesh even though most traffic still goes between the data center and the branches.
Implementing QoS in such environments requires QoS guarantees from the service
provider and provisioning in the enterprise part of the network.

QoS in Enterprise Networks
• Typical enterprise networks have a large

number of different applications
• Some applications are business-critical and
require some guarantees (bandwidth, delay)
• The network should provide enough
resources to these business-critical
applications
• Applications are usually identified based on
TCP or UDP port numbers
Enterprise networks are typically concerned with providing differentiated QoS to

applications. Applications can be classified based on TCP or UDP port numbers
and marked with IP precedence or DSCP at network edges. The network should
guarantee resources to all business-critical applications (classes).

Case Study
• Typical line speeds

– Core - Distribution < 2 Mbps
– Distribution - Branch 64 kbps - 256 kbps
• Typical protocols
– SNA, NetBIOS, Desktop protocols (IPX), Some
TCP/IP, Voice, Multimedia
• Typical QoS requirements
– SNA and voice are high priority
– Guaranteed bandwidth for some application
– Rest of the traffic is best-effort
The figure shows a case study where relatively low bandwidths are used which
calls for QoS to manage bandwidth according to the needs of the enterprise.

Case Study
Implementation #1
• Core - Distribution
– Custom queuing
• Distribution - Branch
– Priority queuing or
– Custom Queuing with a priority queue
• Options
– Traffic shaping
– Adaptation to Frame Relay congestion notification
The figure lists mechanisms that could be used to accommodate the need of the
enterprise. This solution would normally be used in networks where an old IOS
version is being used and an upgrade is not an option (due to the cost of getting
newer IOS versions, memory upgrade, flash upgrade, etc.). The listed mechanisms
(Priority Queuing and Custom Queuing) have been available since Cisco IOS
version 10.0.

Case Study
Implementation #2
• Core - Distribution
• Distribution - Branch
• Options
– Weighted Random Early Detection (WRED)
This figure shows a solution using advanced mechanisms to provide better control
of bandwidth usage. This solution requires newer Cisco IOS software versions
(12.1 or 12.2, depending on the details of the implementation).

Summary
n Describe a typical structure of an enterprise network
n Describe the need for QoS in enterprise networks
n List typical QoS requirements in enterprise networks
n List the QoS mechanisms that are typically used in enterprise networks
Review Questions
n What is the typical enterprise network topology?
n How is resilience achieved?
n Based on which information do typical enterprise networks apply QoS?

Service Provider Case Study
Objectives
n Describe a typical structure of a service provider network
n Describe the need for QoS in service provider networks
n List typical QoS requirements in service provider networks
n List the QoS mechanisms that can be used in service provider networks

Typical
Service Provider Networks
Partial mesh Core

ATM, SONET/SDH, DPT, GE, ... Rings
Redundant connections
ATM, SONET/SDH, DPT, GE, ... Rings
Distribution
(regional POPs)
Single connections
Frame Relay, ATM, Leased line (analog, TDM), Optional redundant connections
dial-up (PSTN, ISDN, GSM), xDSL, (fast)ethernet, ... Dial backup
Access
(customers)
• Typical service provider networks use a high -speed partially-meshed core (backbone)
• Regional POPs use two or more connections to the core
• There may be another layer of smaller POPs connected to distribution-layer POPs
• Customers are usually connected to the service provide via a single point-to-point link (a
secondary link or a dial line can be used to improve resilience)
As the figure illustrates, Service Provider networks significantly differ from typical
enterprise networks. Enterprise Networks are used as a tool to support the
enterprise whereas with Service Providers the network is the business itself.
Enterprise networks are concerned with providing quality to business-critical
applications and Service Providers tend to broaden their service offering by
introducing QoS.

QoS in Service Provider Networks
Networks
• Service providers extend their service offerings by

introducing quality
• Customers can get bandwidth guarantees (like CIR
in Frame Relay)
• Customers can get delay guarantees (like CBR in
ATM)
• Customers can get preferential treatment in case of
congestion (Olympic service)
• QoS mechanisms have to be deployed where
congestion is likely (usually at network edge)
• Customer’s traffic is identified based on source or
destination IP addresses
Service Providers want to offer customers more than plain connectivity. Service
Providers want to establish differentiated levels of service for customers with
incremental pricing and SLA agreements. The customer should not only shop
around among a number of service providers that offer connectivity to the Internet
or provide MPLS/VPNs, but also have a menu of services they can choose from.
Some customers are satisfied with the best-effort service; some want certain
service guarantees.

Case Study
A service provider wants to offer gold,

silver, bronze and premium services
• Premium gets 40% of available bandwidth
with a low-delay guarantee
• Gold gets 30% of available bandwidth
• Silver gets 20% of available bandwidth
• Bronze gets 10% of available bandwidth
The case study shows an example of a Service Provider which offers

differentiated service levels where customers can choose the type of service they
want and are willing to pay for.
The service provider offers four services. Each of the services is basically a virtual
service-provider network using a common infrastructure. The Premium service is
guaranteed the most bandwidth and low-delay propagation of packets. Each of the
following services is guaranteed less bandwidth. Premium customers will benefit
most in times of congestion, whereas Bronze customers will only receive 10
percent of any link’s bandwidth.

Case Study
Implementation
• Class-based Weighted Fair Queuing (CB-

WFQ) on slow to moderate-speed links
• Class-based Low Latency Queuing (CB-LLQ)
on slow to moderate-speed links
• Weighted Random Early Detection (WRED)
on fast links
Service Provider networks would generally use newer Cisco IOS software and
can therefore deploy the latest available mechanisms. The case study is
implemented using CB-WFQ in combination with WRED and CB-LLQ at
networks edges (between access and distribution layer). WRED can be used on
high-speed links (on core links).

Summary
n Describe a typical structure of a service provider network
n Describe the need for QoS in service provider networks
n List typical QoS requirements in service provider networks
n List the QoS mechanisms that can be used in service provider networks
Review Questions
n What is the typical topology of service provider networks?
n Based on which information do typical service provider networks apply QoS?

Summary
After completing this module, you should be able to perform the following tasks:
n Describe the need for IP QoS
n Describe the Integrated Services model
n Describe the Differentiated Services model
n Describe the building blocks of IP QoS mechanisms (classification, marking,
metering, policing, shaping, dropping, forwarding and queuing)
n List the IP QoS mechanisms available in the Cisco IOS
n Describe what QoS features are supported by different IP QoS mechanisms

Review Questions and Answers
Introduction to IP Quality of Service
Question: What are the relevant parameters that define the quality of service?
Answer: Throughput (bandwidth), delay and jitter.
Question: What can be done to give more bandwidth to an application?
Answer: An application can get more throughput by increasing the bandwidth of
the links in the path and/or using a QoS mechanism to guarantee bandwidth when
the application has to contend with other flows. Payload and header compression
also virtually increase the available bandwidth by reducing the overhead.
Question: What can be done to reduce delay?
Answer: Delay can be reduced by increasing the bandwidth of the links in the path
and/or using a queuing mechanism that ensures minimum queuing delay for delay-
sensitive applications. Header compression will also help by reducing the
serialization delay of small packets on low-speed links. Payload compression would
have a similar result but it increases the delay because of the complexity of the
compression algorithm.
Question: What can be done to prevent packet loss?
Answer: Packet loss can also be prevented by providing enough bandwidth.
Alternatively a differentiated dropping mechanism can be used to drop packets of
less important flows to prevent drops of high-priority flows. Another option is to
use a queuing mechanism to guarantee enough bandwidth to high-priority flows.
Question: Name the three QoS models?
Answer: Best effort, Integrated services and Differentiated services.
Integrated Services Model

Question: What are the two building blocks of the Integrated Services model?
Answer: Resource reservation and admission control.
Question: Which protocol is used to signal QoS requirements to the network?
Answer: Resource reservation protocol (RSVP) is used to reserve network
resources for applications.

Question: What are the benefits of the DiffServ model compared to the IntServ
model?
Answer: DiffServ provides more scalable QoS solutions by applying QoS
mechanisms (per-hop behavior) to traffic classes instead of individual applications.
The DiffServ model does not require any signaling mechanism thus allowing QoS
provisioning to non-RSVP applications.

Questions: What is a DiffServ Code Point?
Answer: The DSCP is used to mark IP packets. It occupies the high-order 6 bits
of the DiffServ field (former ToS field).
Questions: Name the standard PHBs?
Answer: Expedited Forwarding (EF), Assured Forwarding (AF) and Class Selector
(CS).
Questions: How was backward compatibility with IP precedence achieved?
Answer: Backward compatibility is provided by using the DSCP values that map
into IP precedence values that are typically used to achieve a similar goal: EF
maps into IP precedence 5, AF1 maps into IP precedence 1, AF2 maps into IP
precedence 2, AF3 maps into IP precedence 3, AF4 maps into IP precedence 4,
the default DSCP maps into the default IP precedence 0.
Questions: Describe the PHB of Assured Forwarding.
Answer: AF PHB provides a bandwidth guarantee to a traffic class with the
possibility to use more bandwidth if it is available.
Questions: Describe the PHB of Expedited Forwarding.
Answer: EF PHB provides a bandwidth guarantee to a traffic class and it ensures
a minimum queuing delay. The traffic class is also limited to the provisioned
bandwidth.

Building Blocks of IP QoS Mechanisms
Review Questions
n Name the QoS building blocks.
Classification, marking, metering, dropping, policing, shaping and queuing.
n What is the purpose of classification?
Classification is used to assign packets to traffic classes with different
QoS requirements (behavior aggregates).
n What is the purpose of marking?
Marking is used to allow simplified classification on other devices in the
network.
n Which markers do you know?
IP precedence, DSCP, MPLS experimental bits, QoS group, Frame
Relay DE bit, ATM CLP bit, 802.1q CoS bits, ISL priority bits.
n Which mechanisms can classify and mark
packets?
Policy-based Routing (PBR)
Committed Access Rate (CAR)
QoS Policy Propagation through BGP (QPPB)
Class-based Policing
Class-based Marking
n Which mechanisms have the ability to measure
the rate of traffic?
Generic Traffic Shaping (GTS)
Frame Relay Traffic Shaping (FRTS)
Class-based Weighted Fair Queuing (CB-WFQ)
Class-based Low Latency Queuing (CB-LLQ)
Class-based Shaping
IP RTP Prioritization
n Which forwarding mechanisms do you know?
Process Switching, Fast Switching, Optimum Switching, NetFlow
Switching, CEF switching …

n Which queuing mechanisms do you know?
FIFO, Priority Queuing (PQ), Custom Queuing (CQ), WFQ, dWFQ,
CoS-based dWFQ, QoS-group dWFQ, Class-based WFQ, Class-based
LLQ
n How, when and where do routers drop packets?
Routers typically drop packets when an output interface is congested.
The output queue fills up and the newly arriving packets have to be
dropped (tail drop).

Enterprise Network Case Study
Review Questions
n What is the typical enterprise network topology?
Enterprise networks typically use the hub-and-spoke topology.
Resilience is achieved by using redundant links.
n Based on which information do typical enterprise
networks apply QoS?
Enterprise networks typically provide QoS to applications. Applications
are typically identified based on the TCP or UDP port numbers.

Service Provider Case Study
Review Questions
n What is the typical topology of service provider
networks?
Typical service provider networks use a partially meshed core with a
redundant hub-and-spoke topology for the POPs.
Resilience is achieved by using partial mesh (core) and redundant links
(distribution, access).
n Based on which information do typical service
provider networks apply QoS?
Service providers typically apply QoS to customer traffic. Customer
traffic is identified based on source or destination IP addresses.

Classification and
Marking
Overview
This module describes the mechanisms that are used to classify and mark IP
packets. This module builds on the knowledge acquired from the introductory
module where classification and marking is discussed. Theoretical knowledge is
supplemented by detailing Policy-based routing (PBR) and QoS Policy Propagation
through BGP (QPPB) mechanisms.
Objectives
Upon completion of this module, you will be able to:
n Describe Policy-based routing and how it is used to classify and mark IP
packets
n Describe QoS Policy Propagation through BGP and how it is used to classify
and mark IP packets
n List other mechanisms that also support classification and marking capabilities
(Committed Access Rate, Class-based Policing and Class-based Marking)
Traffic Classification and Marking
Classification
• Most QoS mechanisms in the Cisco IOS
include some type of classification
• Some mechanisms classify packets
automatically, some require manual
configuration
Marking
• Only a small number of mechanisms also
include a marking capability
© 2001, Cisco Systems, Inc. Classification and Marking-3
This module focuses on the QoS mechanisms that are used for classification and
marking purposes only. Most QoS mechanisms include some type of classification
but only a small number of mechanisms also include marking capability.
Classification is the term used for identifying a Behavior Aggregate to which a
packet belongs. A Behavior Aggregate is a collection of flows requiring the same
quality of service.
Marking is the term used for coloring packets by applying a class-identifying
value to one of the following markers: IP precedence, DSCP, QoS group (value is
local to a router), MPLS experimental bits (can be used only in MPLS-enabled
networks), ATM CLP bit (value can be used only within ATM networks), Frame
Relay DE bit (value can be used only within Frame Relay networks), IEEE 802.1q
or ISL cos/priority bits (value can be used on within LAN-switched networks).
2-2 IP QoS Classification and Marking Copyright  2001, Cisco Systems, Inc.
Traffic Classification and Marking
• This module describes the two mechanisms

that are used for classification and marking
only:
– Policy-based Routing (PBR)
– QoS Policy Propagation through BGP (QPPB)
• Other classification and/or marking
mechanisms are described in other QoS
modules
This module describes the two QoS mechanisms that are used purely for
classification and marking purposes:
n Policy-based Routing (PBR)
n QoS Policy Propagation through BGP (QPPB)
There are other QoS mechanisms that also support classification and marking:
n Committed Access Rate (CAR) – this mechanism is described in the “IP
QoS – Traffic Shaping and Policing” module
n Class-based Policing (CB-Policing) – this mechanism is described in the
“IP QoS – Modular QoS CLI (Chapter 2)” module
n Class-based Marking (CB-Marking) – this mechanism is described in the
“IP QoS – Modular QoS CLI (Chapter 2)” module
Copyright  2001, Cisco Systems, Inc. IP QoS Classification and Marking 2-3
Policy-based Routing
Objectives
Upon completion of this lesson, you will be able to:
n Describe Policy Based Routing (PBR)
n Configure PBR on Cisco routers
n Monitor and troubleshoot PBR
• Policy-based Routing (PBR) is a mechanism

that can be used to bypass the default
destination-based forwarding functionality of
routers
• PBR is implemented using a route map
where match commands are used to classify
packets and set commands are used to
process packets
• Route maps are applied to interfaces for
processing of inbound packets (forwarding
and/or marking)
The primary function of Policy-based Routing (PBR) is to bypass the

destination-based forwarding functionality of routers by using a route map to make
a forwarding decision based on other information.
One additional feature of Policy Based Routing is the ability to modify IP packets
by marking them with IP precedence or QoS group.
PBR “match” and “set” Options
Set:
• Output interface (bypass the
Match on: routing table)
• Standard and extended access • Next-hop address (bypass the
lists routing table)
• Length of packets (min,max) • ToS field (QoS marking)
• IP precedence (QoS marking)
• QoS group (QoS marking)
IP
Input Output
interface interface
PBR has two primary applications:

• Implementation of more complex routing paradigms than a
simple destination-based forwarding
• Classification and marking of packets for QoS purposes
PBR classifies packets based on standard or extended access lists, the length of
packets and the incoming router interface (a route map is applied to an input
interface).
The route map sets the following parameters:
n Output interface: force the router to forward packets to an interface even if it
would not provide for optimal routing
n Next-hop address: to make a forwarding decision by using a different next-hop
address than the one determined by the routing table
n ToS value: the ToS value in this case applies to bits 4,3,2 and 1 of the ToS field
n IP precedence: three-bit field used to identify a class of service
n QoS group: the local parameter with an expanded value range
The first two parameters (output interface and next-hop address) are used to
bypass the default destination-based routing. The other three parameters are used
for QoS purposes (ToS value is less commonly used).
PBR Capabilities
PBR can only

classify and mark
Meter inbound or locally-
originated packets
Inbound Dropper
or
Classifier Marker
Locally-originated
Forwarding
Outbound
Meter
Shaper Queuing
Classifier Marker
Dropper
The figure illustrates the “full” QoS building-block scheme showing that PBR
works only on input and that it supports only classification and marking. The
“Forwarding” box could be colored as well since PBR can be used to make a
forwarding decision. PBR contains no mechanism for metering or dropping of data
packets.
Configuring Classification and
Marking Using PBR
• Create a route map

• Apply the route map to an incoming interface
and/or
• Apply the route map to locally originated
traffic
• Monitor and debug policy routing
© 2001, Cisco Systems, Inc. Classification and Marking -10
Configuring PBR involves the following steps:

n Creating a route map where the match statement is used to match with the
source or destination IP address or with any other parameter that can be
matched by an access list (standard or extended). It can also match packets
based on their size.
n Applying the route-map to:
n An input interface to process inbound packets on that interface or
n To locally originated packets
Route Map Rules
Router(config)#
route-map <name> [permit | deny] [<sequence-number>]
match <condition>
set <parameter>
• Route maps are identified by a case sensitive name
• Route maps can have multiple statements (same name,
different sequence number)
• Packets are processed in the specified sequence
• Packets not matched by the route map are forwarded using the
default destination-based forwarding
• If packets are matched by the “match” condition but the route
map statement is using the “deny” option, the default
destination-based forwarding is applied to the packet
A brief refresher about route maps:

n Route maps can have one or more statements. A route map, or a set of
route-map statements with the same name is identified by a case-sensitive
name .
n Individual route-map statements are identified by their name and sequence
number. When packets are processed by a route map they are evaluated in
the order specified by sequence numbers.
n A route map is basically made to be a filtering mechanism. When used for
PBR:
n permit means “do whatever the set commands says”
n deny means “do not do anything”
n When a packet is matched by one of the route-map statements it is processed
by that statement and the processing of the packet ends. Ordering route-map
statements correctly is therefore necessary.
PBR Classification
Router(config-route-map)#
match ip address <#acl>
• Classify using a standard access list against the source

address
• Classify using an extended access list against the source
and/or destination address, source and/or destination TCP/UDP
port, IP precedence, DSCP, ToS
match length <min> <max>
• Classify using a range of packet lengths that will be matched by

the route map statement
Route maps have a number of match options but only two can be used for policy-
based routing purposes:
n match ip address is used to examine the packet’s headers with a standard or
an extended access list
n match length is used to mach packets based on their length
PBR Marking
set ip precedence <precedence>
• Set the specified IP precedence to packets matched by the route map

• IP precedence supports 8 classes, two are reserved (6 and 7)
set ip qos-group <qos-group>
• Classify using a range of packet lengths that will be matched by the

route map statement
• QoS group supports 100 classes (0-99)
set ip tos <tos>
• Set the low-order 4 bits of the Type-of-service (ToS) field

• These bits are used to specify the delay, throughput and reliability
parameters (specified in RFC 791, no longer used after RFC 1812)
The following marking options are available with route maps:

n IP precedence
n QoS group
n ToS value (the four bits below IP precedence in the ToS field) used for
Delay, Throughput, Reliability and Monetary Cost
IP precedence is encoded into the three high-order bits of the ToS field in the IP
header. It supports eight classes of which two are reserved and should not be used
for user-defined classes (IP precedence 6 and 7). Ip precedence 0 is the default
value and is usually used for the best-effort class.
QoS group has one major advantage over IP precedence and one major
drawback:
n QoS group supports up to 100 classes. Values 0 to 99 can be used to mark
packets.
n QoS group is a parameter that is local to the router where it is set. It is not part
of any header. It is usually set on input interface and later examined (matched)
on output interfaces. Once the packet is transmitted, the QoS-group
information is lost, and the next router must reclassify and mark the packet.
ToS value is encoded into bits 4,3,2 and 1 of the ToS field (according to older
RFCs 791 and 1349). This value was made obsolete by the introduction of the
DiffServ Code Point, which does not take into account compatibility with these
bits.
Applying a Route Map
Router(config-if)#
ip policy-map <route-map-name>
• Specifies the route map used to set QoS and other

policy-routing parameters for packets received
through the specified interface
Router(config)#
ip local policy-map <route-map-name>
• Specifies the route map used to set QoS and other

policy-routing parameters for packets generated by
the router
Once a route map is configured it must be applied to either packets coming into the
router through an interface or to packets being generated by the router.
The first command (ip policy-map) is used for forwarded packets.
The second command (ip local policy-map) is used for packets generated by a
router and is typically used for tunneling packets (e.g. DLSw)
Note Policy-based routing is a mechanism that puts interfaces into Process Switching
mode. This will significantly degrade performance. PBR has been available in
the fast-switching path since Cisco IOS version 11.3. The ip route-cache policy
command can be used on an interface to enable caching for PBR. This
command has been available since Cisco IOS software version 12.0.
Monitoring and Troubleshooting
PBR
Router#
show route-map <name>
• Displays the route map and number of packets and

bytes matched by each statement
Router#
debug ip policy
• Displays all packets matched by policy routing route-

maps
The show route-map command is used to display the route map with its match
and set options.
The debug ip policy command is used to display all packets being processed by
PBR.
The show ip policy command is used to see a list of all interfaces that are enabled
for PBR. The output also displays the corresponding route maps.
The show ip local policy command is used to display the configured parameters
for local PBR with a number of packets and bytes that have been policy-routed by
the local PBR.
Monitoring and Debugging
Policy Routing
Router#show
Router#show route-map
route-map CPE
CPE
route-map
route-map CPE,
CPE, permit,
permit, sequence
sequence 10
Match
Match clauses:
ip address
address (access-lists):
(access-lists): 199
Set clauses:
clauses:
ip precedence
precedence flash-override
flash-override
Policy routing matches: 3418 packets, 412108 bytes
route-map
route-map CPE,
CPE, permit,
permit, sequence
sequence 20
Match
Match clauses:
ip address
address (access-lists):
(access-lists): MatchPing
MatchPing
Set clauses:
clauses:
ip precedence
precedence priority
priority
Policy
Policy routing
routing matches:
matches: 8282 packets,
packets, 31045
31045 bytes
bytes
Router#show
Router#show access-list
access-list MatchPing
MatchPing
Extended
Extended IP
IP access
access list MatchPing
MatchPing
permit icmp any any echo (25 matches)
Router#
Router#
The figure shows a sample output of the show route-map and show access-list
commands.
Monitoring and Debugging
Router#debug
Router#debug ip
ip policy
policy
Policy
Policy routing
routing debugging
debugging is
is on
on
Router#ping
Router#ping 192.168.1.1
192.168.1.1
Type
Type escape
escape sequence
sequence to
to abort.
abort.
Sending
Sending 5,
5, 100-byte
100 -byte ICMP
ICMP Echos
Echos to
to 192.168.1.1,
192.168.1.1, timeout
timeout is
is 22 seconds:
seconds:
!!!!!
!!!!!
Success
Success rate
rate is
is 100
100 percent
percent (5/5),
(5/5), round-trip
round -trip min/avg/max
min/avg/max == 28/31/32
28/31/32 ms
ms
Router#
Router#
2d02h:
2d02h: IP:
IP: s=192.168.1.2
s=192.168.1.2 (local),
(local), d=192.168.1.1,
d=192.168.1.1, len
len 100,
100, policy
policy match
match
2d02h:
2d02h: IP:
IP: route
route map
map CPE,
CPE, item
item 20,
20, permit
permit
...
...
The debug ip policy command is similar to the debug ip packet except that the
debug ip policy only displays policy-routed packets. This command should be
used with caution as it may produce too much output.
IP Precedence Marking
Case Study #1
• Branch office of a bank has two LANs connected to

an access router
• Ethernet0 is the front office with the real time transactions
• Ethernet1 is the back office with non-real time transactions
(like e-mail)
• The network provides different services to two
classes:
• Business traffic (marked with IP precedence 2)
• Other traffic (marked with IP precedence 0)
• Packets coming from Ethernet 0 should be classified
and marked as Business traffic
• Packets coming from Ethernet 1 should be classified
and marked as Other traffic
The case study involves a bank branch office where a single router connects two
LANs to the corporate network via one serial interface. This case study focuses
on the classification and marking part of a larger QoS solution, which includes
other QoS mechanisms.
Case #1- Solution
Mark all traffic with

precedence 2
Mark all traffic with

E0
precedence 0
WAN core
interface
interface ethernet
ethernet 0
ip policy-map
policy-map set-prec-2
set-prec-2
E1 !! Core
Branch interface
interface ethernet
ethernet 1
office ip policy-map
policy-map set-prec-0
set-prec-0
!!
route-map
route-map set-prec-2
set-prec-2 permit
permit 10
10
set ip
ip precedence 2
!!
route-map
route-map set-prec-0
set-prec-0 permit
permit 10
10
set ip
ip precedence 0
Policy-based routing can be used to mark packets with IP precedence values. All
packets from Ethernet 0 are marked with IP precedence 2. Since matching is
applied to all packets no “match” command is needed in the route map. The other
route map is applied to the other Ethernet interface and it marks packets with IP
precedence 0.
IP Precedence Marking
Case Study #2
• Branch office of a bank has one LAN connected to an

access router
• The network provides different services to three
classes:
• Transaction traffic (marked with IP precedence 2)
• Business traffic (marked with IP precedence 1)
• Other traffic (marked with IP precedence 0)
• TN3270 should be marked as Transaction traffic

• Internal HTTP should be marked as Business traffic
• All other traffic should be marked as Other traffic
The second case study is more complicated because classification is not done
based on the input interface. Instead, classification if performed based on
application (TCP or UDP port numbers).
Case #2 - Solution
WAN core
E0
interface
interface eth
eth 0
0 Core
ip
ip policy-map
policy-map set-prec
set-prec
Branch
Mark
Mark IP
IP precedence:
precedence: !!
office
route-map
route-map set-prec permit
set-prec permit 10
10
Telnet
Telnet = 22 match
match ip
ip address
address CorporateWebTraffic
CorporateWebTraffic
Corporate
Corporate Web
Web == 1 set
set ip precedence 11
everything
everything else
else == 0 route-map
route-map set-prec
set-prec permit
permit 20
20
match
match ip
ip address
address TN3270
TN3270
set
route-map
route-map set-prec
set-prec permit
permit 30
30
set
!!
ip
ip access-list
access-list extended
extended CorporateWebTraffic
CorporateWebTraffic
permit
permit tcp
tcp any
any 10.1.1.0
10.1.1.0 0.0.0.255
0.0.0.255 eq
eq www
www
ip
ip access-list
access-list extended
extended TN3270
TN3270
permit
permit tcp
tcp any
any any
any eq
eq telnet
telnet
A route map is created with three statements, one for each application:
n The first statement uses an access list to identify corporate web traffic
(destination port 80). IP precedence 1 is applied to these packets.
n The second statement uses another access list to identify outbound telnet
sessions. IP precedence 2 is applied to these packets.
n The last statement sets IP precedence 0 to all other packets.
Route Map - Review
• Policy routing with route maps can classify

and mark IP packets based on a wide variety
of conditions
• No metering, shaping or dropping is possible
• Performance depends on the IOS version
– Policy routing is fast -switched in 11.3 and 12.0
– (d)CEF or Net Flow-switched in 12.0(3)T
Policy-based Routing features:

n Static classification and marking (no metering, shaping, policing or dropping is
possible).
n PBR has performance limitations due to implementation (complex access lists
can degrade performance, sub-optimal order of statements can also degrade
performance due to sequential processing) and the IOS version (newer IOS
versions support fast-switched operation of PBR).
Summary
Policy based routing is used for two purposes:
n Bypassing the traditional destination-based forwarding
n Marking of IP packets with Ip precedence or QoS group
Lesson Review
n What are the applications of Policy-based Routing?
n What configuration tool is used to implement PBR?
n How can PBR be applied to IP traffic?
n Describe the classification options with PBR.
n Describe the marking options with PBR.
Objectives
n Describe the QPPB mechanism
n Configure the QPPB mechanism on Cisco routers
n Monitor and troubleshoot QPPB
IP QoS Policy Propagation
Through BGP (QPPB)
• QPPB uses BGP attributes to advertise class of

service to other routers in the network
• BGP Communities are usually used to propagate
class of service information bound to IP networks
• Packet classification policy can be propagated via
BGP without having to use complex access lists at
each of a large number of border (edge) routers
• A route map is used to translate BGP information
(e.g. BGP Community value) into IP precedence or
QoS group
QoS Policy Propagation through BGP is a mechanism that can be split into two
parts:
n Policy propagation via BGP, where a QoS policy is encoded into a BGP
attribute. BGP Communities are typically used to encode a QoS policy.
n Marking of packets with IP precedence or QoS group based on the QoS policy
learned via BGP.
BGP Policy is usually set on ingress routers (ingress for route propagation, egress
for packet forwarding) in an Autonomous System. BGP then carries the
information to other routers in the AS and translates (using a route map) this
information into IP precedence or QoS group. Marking is then enabled on per-
interface basis.
QPPB Capabilities
QPPB can only

Meter classify and mark
inbound packets
Inbound Dropper
or
Classifier Marker
Locally-originated
Forwarding
Outbound
Meter
Shaper Queuing
Classifier Marker
Dropper
Similar to PBR, QPPB also supports classification and marking only on the input
interface.
BGP Marking
Meter
Inbound
traffic
stream
Classifier Marker Dropper
1. Propagate the class of service by encoding it into BGP attributes:

• BGP communities,
• AS paths,
• IP prefixes or
• any other BGP attribute
2. Translate the selected BGP attribute into either:
• IP precedence or
• QoS group
3. Enable Cisco Express Forwarding (CEF) and packet marking on
interfaces
QoS policy can be applied to source or destination IP addresses or networks.

When BGP entries are inserted into the routing table a route map is used to
translate a certain BGP parameter or attribute into IP precedence or QoS group.
Packet marking is then enabled on input interfaces.
Cisco Express Forwarding
Review
• The two main components of CEF operation

– Forwarding Information Base
– Adjacency Tables
• CEF was first introduced on the following
platforms:
– Cisco 7x00 series in 11.1CC
– All RISC-based platforms in IOS 12.0
• QPPB is only supported on high-end routers
(Cisco 7x00 and above)
QPPB has the following requirements:

n Cisco Express Forwarding (CEF)
n A high end platform (Cisco 7x000 routers)
Review: Standard IP Switching
Address Prefix AS-Path Next hop Communities Other attr.

BGP table 10.0.0.0 /8 42 13 1.2.3.4 37:12
... ... ... ... ... ...
Protocol Address Prefix Next-hop Outgoing interface

IP routing
BGP 10.0.0.0 /8 1.2.3.4 ---
table
conn. 1.2.3.0 /24 --- Ethernet 0
Address Prefix L2 header

Switching
10.0.0.0 /8 MAC header
cache
... ... ...
IP address MAC address

ARP cache 1.2.3.4 0c.00.11.22.33.44
... ...
The figure illustrates how BGP routing information is used on routers that are
configured with the default switching operation:
n A BGP entry is inserted into the main routing table (the network points to the
BGP next-hop address.
n A recursive routing lookup is needed when the first packet arrives. After the
output interface is identified, a cache entry is generated. Multi-access media
requires additional information from the ARP cache.
n The subsequent packets are forwarded using the fast-switching cache.
Review: CEF Switching

BGP table 10.0.0.0 /8 42 13 1.2.3.4 37:12
... ... ... ... ... ...
Protocol Address Prefix Next-hop Outgoing interface

IP routing
BGP 10.0.0.0 /8 1.2.3.4 ---
table
OSPF 1.2.3.0 /24 1.5.4.1 Ethernet 0
conn. 1.5.4.0 /24 --- Ethernet 0
Address Prefix Adjacency pointer

FIB table 10.0.0.0 /8 1.5.4.1
(CEF cache) ... ... ...
ARP cache
IP address Layer 2 header IP address MAC address
Adjacency
1.5.4.1 MAC header 1.5.4.1 0c.00.11.22.33.44
table
... ... ... ...
CEF switching is different from the default operation in the following ways:
n CEF switching cache (the FIB table and the adjacency table) reflects the
information from the main routing table. Changes in the FIB table are not
triggered by packets but by changes in the main routing table itself.
n The CEF switching cache is split into two tables:
n Forwarding Information Base (FIB) which contains all networks that
are taken from the routing table. Those entries point to directly accessible
next-hops. Adjacency pointers are used to get information about these
next-hops from the Adjacency table
n Adjacency table contains a list of directly connected neighboring IP
devices. A layer-2 header is created in advance to accelerate the
encapsulation process.
CEF Switching with QoS
Packet Marking
BGP table 10.0.0.0 /8 42 13 1.2.3.4 37:12
... ... ... ... ... BGP table...
map
Protocol Address Prefix Next-hop Outgoing interface Precedence QoS group

IP routing
BGP 10.0.0.0 /8 1.2.3.4 --- 3 7
table
OSPF 1.2.3.0 /24 1.5.4.1 Ethernet 0 --- ---
conn. 1.5.4.0 /24 --- Ethernet 0 --- ---
Address Prefix Adjacency pointer Precedence QoS group

FIB table 10.0.0.0 /8 1.5.4.1 3 7
(CEF cache) ... ... ... ... ...
ARP cache
IP address Layer 2 header IP address MAC address
Adjacency
1.5.4.1 MAC header 1.5.4.1 0c.00.11.22.33.44
table
... ... ... ...
When using CEF for packet marking a table map is used in the BGP configuration
mode to process routes inserted into the routing table. A route map (used as a table
map in BGP) can translate any BGP parameter or attribute into IP precedence or
QoS group. This information is then passed on to the FIB table.
Once packet marking is enabled the router will perform two CEF lookups:
n The first lookup is used to mark packets
n The second lookup is used to make a forwarding decision
QPPB Configuration Tasks
• Create a route map to set IP precedence or

QoS group
• Apply the route map to BGP routes
transferred to main IP routing table
• Enable per-interface packet marking
Before configuring routers to support QPPB, a QoS design, which must include the
following, is needed:
n BGP attribute used to encode class of service (BGP Communities are usually
used)
n Marker (when using QPPB only IP precedence or QoS group can be used)
The following configuration steps are necessary on routers that perform packet
marking:
n Enable CEF
n Create a route map that translates a BGP attribute into IP precedence or QoS
group
n Apply the route map to process BGP routes before they are entered into the
main routing table.
n Enable per interface marking.
Setting IP Precedence or QoS
Group in the IP Routing Table
Router(config-router)#
table-map <route-map-name>
• Specifies the route map used to set additional

routing table attributes
Router(config)#
route-map <name> permit <seq>
set ip precedence <precedence>
set ip qos-group <group>
• Specifies IP precedence and QoS group values in the

routing table/FIB table entry
Use the table -map command in the BGP configuration mode to populate the main
routing table with the class of service information.
A route map can “tag” networks with IP precedence, QoS group or both.
Enable Per-interface Packet
Marking
Router(config-if)#
bgp-policy source ip-prec-map
• Applied to packets received through this interface

• Uses FIB to map packet source IP address to IP
precedence
• Rewrites IP precedence in the packet
Router(config-if)#
bgp-policy source ip-qos-map

• Uses FIB to map packet source IP address to QoS
group
• QoS group attached to the incoming packet
Once the FIB table contains the class of service information (IP precedence or
QoS group), marking can be configured on input interfaces.
CEF-based marking is performed based on the following:
n Find the source address (taken from the packet being marked) in the FIB
table and mark it with the IP precedence value attached to the
address/network. Use the bgp-policy source ip-prec-map interface
command to mark the packet.
n Find the source address (taken from the packet being marked) in the FIB
table and mark it with the QoS group value attached to the address/network.
Use the bgp-policy source ip-qos-map interface command to mark the
packet.
Enable Per-interface Packet
Marking
Router(config-if)#
bgp-policy destination ip-prec-map

• Uses FIB to map packet destination IP address to IP
precedence
• Rewrites IP precedence in the packet
Router(config-if)#
bgp-policy destination ip-qos-map

• Uses FIB to map packet destination IP address to
QoS group
• QoS group attached to the incoming packet
n Find the destination address (taken from the packet being marked) in the
FIB table and mark it with the IP precedence value attached to the
address/network. Use the bgp-policy destination ip-qos-map interface
n Find the destination address (taken from the packet being marked) in the
FIB table and mark it with the QoS group value attached to the
address/network. Use the bgp-policy destination ip-qos-map interface
All four commands can be attached to the same interface (although not
recommended) and they are processed in the following order:
n Source-based IP precedence marking
n Source-based QoS group marking
n Destination-based IP precedence marking (overrides source-based marking)
n Destination-based QoS group marking (overrides source-based marking)
Case Study
WAN core
NAP router NAP router POP router
Customer
AS 24 AS 12 (AS 73)
Create an end-to-end IP QoS solution in a

Service Provider network:
• Customer in AS 73 is a Premium customer
• All packets to and from AS 73 shall be sent with
precedence flash
This case study shows how customer networks can be marked with a BGP
community identifying a class of service, which is then propagated throughout the
Autonomous System 12 and used on edge routers to classify and mark packets
towards the customer networks with IP precedence flash (IP precedence 3).
Each IP precedence value is also identified by a name:
IP precedence IP precedence
value name
0 Routine
1 Priority
2 Immediate
3 Flash
4 Flash-override
5 Critical
6 Internet
7 Network
Step #1
Distribute QoS functions
WAN core
Customer
AS 24 AS 12 (AS 73)
packets for AS73

marked with
precedence flash
packets from serial

interface marked with
precedence flash
To achieve the same level of quality in both directions the packets going to and
coming from the customer network must first be classified and marked.
Classification and marking of packets coming from the customer network is trivial:
n PBR without a match statement is used on the interface connection from the
customer network to the ISP’s network.
n Another option is to use other mechanisms such as Committed Access Rate
(CAR), Class-based Policing or Class-based Marking.
Classifying and marking packets going to the customer network is a more difficult
task because:
n Classifying and marking must be performed on all edge routers.
n Classifying and marking requires the identification of the customer network.
Using PBR, CAR, CB-Policing or CB-Marking does not scale because it
involves the use of access lists (this is especially difficult if customer networks
are dynamically learned via BGP).
QPPB is the only scalable mechanism that can classify and mark packets based on
their source or destination IP address.
Step #2
Select QoS mechanisms
WAN core
Customer
AS 24 AS 12 (AS 73)
CEF-based marking
packets for AS73

marked with
precedence flash PBR on interface
packets from serial

interface marked with
precedence flash
The case study will employ PBR to do the marking of outbound packets (from the
customer perspective). QPPB will be used to mark inbound packets on remote
edge (border) routers.
Step #3 - Design Individual QoS
Mechanisms
Mark BGP routes from AS 73

with special community (12:17)
Configure community propagation
WAN core
Customer
AS 24 ASSet
12 FIB table (AS 73) on
based
BGP community
Configure CEF packet marking

for packets coming from adjacent AS
Customers networks are tagged with BGP Community 12:17 and sent to all internal
BGP neighbors.
Edge routers use a table map to translate BGP Community 12:17 into IP
precedence 3.
Destination-based precedence marking is enabled on interfaces connecting the AS
to other ASs.
Mark Routes Coming From AS 73
WAN core
Customer
AS 24 AS 12 (AS 73)
router bgp 12
neighbor 1.2.3.4 remote-as 73
neighbor 1.2.3.4 route-map Premium in
!
route-map Premium permit 10
set community 12:17 additive
The figure illustrates how a route map is used to process inbound BGP routing
updates coming from the customer’s AS 73. The BGP community attribute 12:17 is
added to the routing updates.
Configure Community
Propagation
WAN core
Customer
AS 24 AS 12 (AS 73)
router bgp 12
neighbor 2.3.4.5 remote-as 12
neighbor 2.3.4.5 send-community
BGP Community propagation is not enabled by default. It is, therefore, necessary

to use the send-community option on all internal BGP sessions to allow BGP
Communities to be propagated throughout the autonomous system.
Set FIB Table Based on BGP
Community
WAN core
router bgp 12 Customer
AS 24 AS 12
table-map PremiumCheck (AS 73)
!
route-map PremiumCheck permit 10
match community 17
set ip precedence flash
!
route-map PremiumCheck permit 20
set ip precedence 0
!
ip community-list 17 permit 12:17
The edge routers use route maps to translate BGP Community values into
appropriate IP precedence values. The figure illustrates how all routes carrying
BGP community 12:17 are tagged with IP precedence 3 in the routing table and the
FIB table. All other networks are tagged with IP precedence 0.
Note Setting IP precedence 0 on all packets not specifically matched by a table map is
also a security feature because it prevents IP precedence spoofing. Anyone
trying to use a high IP precedence value (e.g. 6 or 7) will be remarked with IP
precedence 0 and get the best-effort service.
Configure CEF Packet Marking
WAN core
Customer
AS 24 AS 12 (AS 73)
ip cef
!
interface hssi 0/0
bgp-policy destination ip-prec-map
!
The last configuration step is to enable CEF-based marking on border interfaces.

The case study requires that all packets going to (destination-based marking) the
customer’s network be marked with IP precedence 3.
QPPB marking is only available in combination with CEF switching. The global ip
cef command enables CEF switching on all interfaces that support CEF.
IP QoS and BGP Interaction
Review
• IP QoS features work independently of BGP

routing
• BGP is used only to propagate policies for
source or destination IP prefixes through the
network
• QPPB works only on high-end platforms
Although QPPB support is only available on high-end routers there is no limitation

when it comes to tagging BGP routes. Only marking routers have to support
QPPB: all other routers simply have to support BGP.
Summary
QPPB is a mechanism that is used to implement more scalable QoS solutions. It
uses BGP to propagate QoS policy information and CEF to mark packets with IP
precedence or QoS group.
Lesson Review
n Why is QPPB needed?
n How is QoS policy propagated through a network?
n How are QoS traffic classes defined by QPPB?
n Which IP forwarding mechanisms support QPPB?
Other QoS Mechanisms with Classification and
Marking Capability
Objectives
n Explain how most QoS mechanisms support some type of classification
n Name CAR, CB-Policing and CB-Marking as mechanisms that support
classification and marking
Classification
• Most QoS mechanisms include some type of

classification
• Some mechanisms have automatic
classification (e.g. WFQ, WRED, ...)
• Some mechanisms require manual
configuration of classification (e.g. CQ, PQ,
CB-WFQ, ...)
Most QoS mechanisms include some type of classification:

n Some mechanisms classify packets automatically. Weighted Fair Queuing
(WFQ), for instance, classifies packets into flows. Weighted Random Early
Detection (WRED) classifies packets based on their IP precedence values,
etc.
n Other mechanisms require manual configuration of classification.
Marking
The following mechanism (in addition to

PBR and QPPB) contain classification
and marking capability :
• Committed Access Rate (CAR)
• Class-based Policing
• Class-based Marking
Only a few remaining mechanisms have marking capabilities:

n Committed Access Rate (CAR), which is used for traffic policing
n Class-based Policing, which is also used for traffic policing
n Class-based Marking, which is used for classification and marking purposes
only. It may however be combined with other mechanisms available with the
Modular QoS CLI
CAR and Class-based Policing are discussed in detail in the “IP QoS – Traffic
Shaping and Policing” module.
Class-based Marking is discussed in detail in the “IP QoS – Modular QoS CLI
(Service Policy)” module.
This module includes a high-level overview of these QoS mechanisms.
• CAR is a mechanism used for traffic policing

• CAR uses a token bucket model to measure the rate
of traffic and (optionally) drop excess traffic
• CAR can also be used to mark packets with:
– IP precedence
– DiffServ Code Point (DSCP)
– MPLS experimental bits
– QoS group
• CAR can mark packets with different values
depending on whether they conform or exceed the
specified policy
CAR is a mechanism used to limit the traffic rate of a class and optionally mark
packets with one of the following markers:
n IP precedence
n DSCP
n MPLS experimental bits
n QoS group
CAR can also mark packets with two different values depending on whether they:
n Conform to the policy (packet is within the contractual bit-rate)
n Exceed the policy (packet is over the contractual bit-rate)
Conforming and exceeding packets can be marked with different values.
• Class-based Policing is similar to CAR except it is implemented

using the modular QoS CLI
• CB-Policing uses two token buckets to determine if packets
conform, exceed or violate the QoS policy
• CB-Policing can also be used to mark packets with:
– IP precedence
– DiffServ Code Point (DSCP)
– QoS group
– ATM CLP bit
– Frame Relay DE bit
• CB-Policing can mark packets with different values
depending on whether they conform, exceed or violate the
policy
Class-based Policing (CB-Policing) is a mechanism similar to CAR with the

following main differences:
n Modular QoS CLI is used to implement CB-Policing on Cisco routers
n CB-Policing supports more marking options than Committed Access Rate
n CB-Policing uses two token buckets to identify not just conforming and
exceeding packets but also violating packets.
Class-based policing can mark packets with three different values depending on
whether they conform, exceed or violate the policy.
Class-based Marking can mark packets with the following markers:
n IP precedence
n DSCP
n QoS group
n ATM CLP bit
n Frame Relay DE bit
Class-based Marking
• Class-based Marking is used to classify and mark

packets
• This mechanism uses the modular QoS CLI where
classes are manually configured
• Class-based Marking can mark packets with the
following markers:
– IP precedence
– DSCP
– QoS group
– ATM CLP bit
– Frame Relay DE bit
– IEEE 802.1Q or ISL’s CoS
Class-based Marking is also implemented using the Modular QoS CLI.

It supports the following markers:
n IP precedence
n DSCP
n QoS group
n ATM CLP bit
n Frame Relay DE bit
n IEEE 802.1Q or ISL cos/priority bits
Class-based marking can be combined with other mechanisms available in the
Modular QoS CLI.
Summary
The following mechanisms are used for classification and marking purposes:
n QoS Policy Propagation through BGP (QPPB)
n Committed Access Rate (CAR)
n Class-based Policing
n Class-based Marking
PBR is a mechanism that was primarily intended for bypassing the destination-
based forwarding and marking packets with IP precedence or QoS group.
QPPB is a mechanism that can also be used to mark packets with IP precedence
or QoS group. Its main advantage is scalability.
Lesson Review
n Which mechanisms in IOS support classification and marking of packets?
n Which fields or parameters can be used to mark packets in Cisco IOS?
Summary
n Describe Policy-based routing and how it is used to classify and mark IP
packets
n Describe QoS Policy Propagation through BGP and how it is used to classify
and mark IP packets
n List other mechanisms that also support classification and marking capabilities
(Committed Access Rate, Class-based Marking)
Question: What are the applications of Policy-based Routing?
Answer: PBR is used to bypass the destination-based forwarding or to classify
and mark packets.
Question: What configuration tool is used to implement PBR?
Answer: Route maps are used to implement PBR.
Question: How can PBR be applied to IP traffic?
Answer: PBR can be applied to input packets or packets originated by the
router.
Question: Describe the classification options with PBR.
Answer: PBR’s classification options include standard and extended access lists
as well as packet size based classification. PBR can also classify based on the
input interface because it is used on per-interface basis.
Question: Describe the marking options with PBR.
Answer: PBR can set the next-hop address or output interface to bypass the
default destination based forwarding. PBR can also mark packets with the
following options: ToS bits, IP precedence or QoS group.

Question: Why is QPPB needed?
Answer: QPPB can propagate a QoS class of service information throughout an
autonomous system. This allows more scalable QoS designs where classification is
performed on one router and automatically propagated to all other routers in the
AS.
Question: How is QoS policy propagated through a network?
Answer: BGP is used to propagate the CoS by encoding it into any available BGP
attribute.
Question: How are QoS traffic classes defined by QPPB?
Answer: QPPB is limited to assigning IP networks to traffic classes.
Question: Which IP forwarding mechanisms support QPPB?
Answer: QPPB requires CEF switching to mark packets with IP precedence or
QoS group.
Other QoS Mechanisms with Classification and Marking Capability
Question: Which mechanisms in IOS support classification and marking of
packets?
Answer:
Policy-based Routing (PBR)
Class based Marking
Question: Which fields or parameters can be used to mark packets in Cisco IOS?
Answer: IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay
DE bit, ATM CLP bit, 802.1q CoS bits, ISL priority bits.
Queuing Mechanisms
Overview
This module describes the queuing mechanisms that can be used on output
interfaces.
n Queuing Overview
n FIFO Queuing
n Priority Queuing
n Custom Queuing
n Weighted Fair Queuing
n Distributed Weighted Fair Queuing
n Modified Deficit Round-robin
n IP RTP Prioritization
Objectives
n Describe and configure FIFO Queuing (FQ)
n Describe and configure Priority Queuing (PQ)
n Describe and configure Custom Queuing (CQ)
n Describe and configure basic Weighted Fair Queuing (WFQ), distributed WFQ,
ToS-based distributed WFQ and QoS-group-based distributed WFQ
n Describe and configure Modified Weighted Round-robin (MDRR) queuing
n Describe and configure IP RTP Prioritization
Queuing Overview
Objectives
n Understand how queuing works on Cisco routers
n List the most used queuing mechanisms
3-2 Queuing Mechanisms Copyright  2001, Cisco Systems, Inc.

Queuing in Cisco IOS
• Cisco routers running Cisco IOS have a number of

different queuing mechanisms
• This module focuses on the following:
– First In First Out (FIFO)
– Priority Queuing (PQ)
– Custom Queuing (CQ)
– Weighted Fair Queuing (WFQ) with the different
distributed versions
– Modified Deficit Round Robin (MDRR)
– IP RTP Prioritization
• These mechnisms are implemented as software
queues
© 2001, Cisco Systems, Inc. Queuing Mechanisms -5
The lesson discusses how output queuing mechanisms are implemented on Cisco
routers running Cisco IOS. It discusses most of the queuing mechanisms in detail,
except Class-based Weighted Fair Queuing and Class-based Low-latency
Queuing, which are discussed in the “IP QoS – Modular QoS CLI (Chapter 2)”
module.
Copyright  2001, Cisco Systems, Inc. Queuing Mechanisms 3-3

Output Interface Queue Structure
Software Hardware
Output
Forwarder Queuing Queue Interface
System (TxQ)
Any supported Always FIFO

queuing mechanism
• Each Interface has its hardware and software queuing

system
• The hardware queuing system always uses FIFO queuing
(Transmission queue or TxQ)
• The software queuing system can be selected and
configured depending on the platform and Cisco IOS
version
Queuing on routers is necessary to accommodate bursts when the arrival rate of

packets is greater than the departure rate due to one of the following two reasons:
n Input interface is faster than the output interface
n Output interface is receiving packets coming in from multiple other interfaces
Initial implementations of queuing used a single FIFO (first-in first-out or first-come
first-serve queuing) strategy. More complex queuing mechanisms were introduced
when special requirements need routers to differentiate between packets of
different importance.
Queuing was split into two parts:
n The hardware queue that still uses FIFO strategy, which is necessary for the
interface drivers to transmit packets one by one. The hardware queue is
sometimes referred to as the transmit queue or TxQ.
n The software queue that schedules packets into the hardware queue based on
the QoS requirements
Listed on the previous graphic are some of the available software queuing
strategies with their goals:
n FIFO: no differentiation of packets (true fairness but no guarantees)
n Priority Queuing (PQ): strict prioritizing of packets
n Custom Queuing (CQ): service (bandwidth) guaranteed to up to 16 classes
n Weighted Fair Queuing (WFQ) and Distributed WFQ: service (bandwidth)
guarantee to individual flows
n Distributed ToS-based WFQ: service (bandwidth) guaranteed to up to 4 classes

n Distributed QoS-group-based WFQ: service (bandwidth) guaranteed to up to
100 classes
n Modified Deficit Round-robin (MDRR): service (bandwidth) guaranteed to up
to 8 classes; low-delay guarantee if Strict or Alternate Priority is used
n IP RTP Prioritization: low-delay guarantee
Most queuing mechanisms depend on the availability on different platforms and
Cisco IOS versions. For example:
n MDRR is only available on Cisco 12000 series routers (GSR)
n Distributed ToS-based and QoS-group-based WFQ are only available on Cisco
7x00 series routers with Versatile Interface Processors (VIP)

Bypassing the Software Queue
Hardware
Software Queue Yes Hardware Queue No
Empty? Full? Queue
(TxQ)
No Yes
Software
Queuing
System
• When a packet is being forwarded the router will bypass the

software queue if:
– the software queue is empty and
– the hardware queue is not full
The implementation of software queuing was optimized for periods when the
interface is not congested. The software queuing system is bypassed whenever
there is no packet in the software queue and there is room in the hardware queue.
The software queue is, therefore, only used when data must wait to be placed into
the hardware queue.

Hardware Queue (TxQ) Size
• Routers determine the length of the hardware

queue based on the configured bandwidth of
the interface
• Long TxQ may result in poor performance of
the software queue
• Short TxQ may result in a large number of
interrupts which causes high CPU utilization
and low link utilization
The double queuing strategy (software and hardware queue) has its impacts on the
result of overall queuing:
n Software queue is used for a certain reason. If the hardware queue is too long
it will contain a large number of packets scheduled in the FIFO fashion. This is
probably against the QoS design that required a certain complex software
queuing system (for example, Custom Queuing).
So why use the hardware queue at all? Or why not just set its length to one? That
would force all packets to go through the software queue and be scheduled one by
one to the interface for transmission. This approach has the following drawbacks:
n Each time a packet is transmitted, the interface driver interrupts the CPU and
requests more packets to be delivered into its hardware queue. Some queuing
mechanisms have complex scheduling that takes time to deliver more packets.
The interface does not send anything during that time (link utilization is
decreased) if the hardware queue is empty because its maximum size is one.
n The CPU schedules packets one by one instead of many at the same time (in
the same interrupt interval). This increases the CPU utilization.
Choosing the appropriate length of the hardware queue is very important. The
default TxQ size is determined by the IOS based on the bandwidth of the media
and should be fine for most queuing implementations. Faster interfaces have longer
hardware queues because they produce less delay. Slower interfaces have shorter
hardware queues to prevent too much delay in the worst-case scenario where the
entire hardware queue is full of MTU-sized packets.

Queuing Components
Forwarded Packets
Software Queuing System
Class 1? Add/Drop Queue 1
Hardware
Queuing System
Class 2? Add/Drop Queue 2
Hardware Q Interface
Scheduler
Class n? Add/Drop Queue n
• Each queuing mechanism has three main components that define it:
– Classification (selecting the class)
– Insertion policy (determining whether a packet can be enqueued)
– Service policy (scheduling packets to be put into the hardware queue)
The figure illustrates the actions that have to be taken before a packet can be
transmitted:
n Most queuing mechanisms include classification of packets.
n Once a packet is classifie d, a router has to determine whether it can put the
packet into the queue or it has to drop the packet. Most queuing mechanisms
will drop a packet only if the corresponding queue is full (tail-drop). Some
mechanisms use a more intelligent dropping scheme (Weighted Fair Queuing)
or a random dropping scheme (Weighted Random Early Detection).
n If the packet is allowed to be enqueued it will be put into the FIFO queue for
that particular class.
n Packets are then taken from the individual per-class queues and put into the
hardware queue.
Queuing systems differ in the following ways:
n Classification options: some mechanisms classify packets automatically (for
example, WFQ), while other mechanisms require manual configuration of
classification (for example, PQ or CQ).
n Insertion policy: most queuing mechanisms use the tail-dropping scheme.
n Scheduling policy: this is the most important part of every queuing mechanism
because it determines the order in which the packets will leave the router.

Summary
n Understand how queuing works on Cisco routers
n List the most used queuing mechanisms
Review Questions
n Which queuing mechanisms do Cisco routers support?
n When is a software queuing mechanisms not used?
n How does TxQ length affect the software queuing system?

FIFO Queuing
Objectives
n Describe FIFO queuing
n Describe the drawbacks of FIFO queuing
n Configure FIFO queuing on Cisco routers
n Monitor and troubleshoot FIFO queuing

FIFO Queuing
Forwarded Packets
FIFO Queuing System Hardware

Queuing System
All in one FIFO

Tail-drop Queue 1 Hardware Q Interface
queue Scheduler
Routers serve packets in the

first-come first-serve fashion
FIFO uses one single queue
Newly arriving packets are

dropped if the queue is full
All packets are
classified into one class
• Software FIFO queue is basically an extension to the

hardware FIFO queue
© 2001, Cisco Systems, Inc. Queuing Mechanisms-14
FIFO queuing has no classification because all packets belong to the same class.
Packets are dropped when the output queue is full (tail-drop). The scheduler
services packets in the order they arrived.
Software FIFO queue is basically an extension of the hardware FIFO queue.

Benefits and Drawbacks of FIFO
Queuing
+ Benefits
• Simple and fast (one single queue with a simple
scheduling mechanism)
• Supported on all platforms
• Supported in all switching paths
• Supported in all IOS versions
– Drawbacks
• Unfair allocation of bandwidth among multiple flows
• Causes starvation (aggressive flows can monopolize
links)
• Causes jitter (bursts or packet trains temporarily fill
the queue)
FIFO queuing might be regarded as the fairest queuing mechanism but it has a long
list of drawbacks:
n FIFO does not fairly allocate bandwidth among multiple flows. Some flows
receive more bandwidth because they use larger packets or send more packets.
n FIFO is extremely unfair when an aggressive flow is contesting with a fragile
flow. Aggressive flows send a large number of packets, many of which are
dropped. Fragile flows send a modest amount of packets and most of them are
dropped because the queue is always full due to the aggressive flow. This type
of behavior is called starvation.
n Short or long bursts cause a FIFO queue to fill. Packets entering an almost full
queue have to wait a long time before they can be transmitted. Another time,
the queue might be empty causing packets of the same flow to experience
almost no delay. Variation in delay is called jitter.
In spite of all the drawbacks FIFO is still the most used queuing mechanism
because of the following benefits:
n It is simple and fast. Most high-end routers with fast interfaces are not really
challenged by the drawbacks mentioned earlier. Furthermore, routers are not
capable of complex classification and scheduling when they have to process a
large number of packets per second. FIFO is, therefore, the most suitable
queuing mechanisms on these platforms.
n It is supported on all platforms.
n It is supported in all IOS versions.

Configuring FIFO Queuing
Router(config-if)#
no fair-queue
fair-queue
• FIFO queuing is enabled by default on all interfaces

that have a default bandwidth of more than 2Mbsp
• Weighted Fair Queuing is enabled if the bandwidth is
less than 2Mbps
• Disable WFQ to enable FIFO on interfaces that have
less than 2Mbps of bandwidth
Cisco routers have two default queuing mechanisms:

n All interfaces with the default bandwidth above 2Mbps use FIFO queuing. No
configuration is necessary on such interfaces.
n All interfaces with the default bandwidth below 2Mbps use Weighted Fair
Queuing (WFQ). The no fair-queue command must be used to disable WFQ
and enable FIFO.
There is no special command that specifically enables FIFO.

Configuring FIFO Queuing
Router(config-if)#
hold-queue <buffers>
<buffers> out
• FIFO queuing allows a maximum of 40 packets to be

stored in the output queue
• This command can be used to increase or decrease
the maximum number of buffered packets
• A large value can be set to support longer bursts
(less drops, more buffer usage)
• A small value can be set to prevent bursts (more
drops)
One of the considerations when using FIFO queuing is the maximum burst size.
Routers allow (by default) up to 40 packets to be in the output queue. Shortening
the queue causes more drops, especially for bursty sessions. Lengthening the
queue allows more packets to be enqueued. A long queue should be used to allow
bursts without drops.
The hold-queue command is used to set the maximum number of packets in the
output queue.

FIFO Example
The Ethernet interface has a default

bandwidth of 10Mbps.
FIFO is the default queuing and it does
not need to be configured.
interface
interface Ethernet0/0
ip
ip address
address 1.1.1.1
1.1.1.1 255.0.0.0
255.0.0.0 The serial interface (A/S) has a default
!! bandwidth of 128 kbps.
interface WFQ is the default queuing and it has
interface Serial0/0
Serial0/0 to be disabled to enable FIFO queuing.
ip
ip address
address 2.2.2.2
2.2.2.2 255.0.0.0
255.0.0.0
no
no fair-queue
fair-queue Up to 50 frames are allowed to be
hold-queue enqueued before the router will start
hold-queue 50
50 out
out tail-dropping newely arriving packets.
!!
The example shows how FIFO can be enabled on an interface that uses WFQ by
default. The serial interface in question has the default bandwidth of 128 kbps
(below 2 Mbps). The ethernet interface has the default bandwidth of 10 Mbps
(above 2 Mbps) and requires no configuration.
The maximum output queue size was also slightly increased from the default 40 to
50.

FIFO
Router#
show interface
interface [<interface>]
[<interface>]
• The command displays information about the selected
interface(s)
Router#show
Router#show interface
interface Serial0/0
Serial0/0 The queue is currently empty ( 0/50).
Serial0/0
Serial0/0 isis up,
up, line
line protocol
protocol is
is up
up There can be a maximum of 50 frames in the
Hardware
Hardware is PowerQUICC Serial queue (0/50).
Internet
Internet address is 1.1.1.1/8
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 128
128 Kbit,
Kbit, DLY
DLY 20000
20000 usec,
usec,
reliability
reliability 255/255,
255/255, txload
txload 1/255,
1/255, rxload
rxload 1/255
1/255
Encapsulation
Encapsulation HDLC,
HDLC, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec) FIFO queuing is enabled
Last
Last input 00:00:02, output 00:00:04, output hang neveron an interface with the
input 00:00:02,
Last
Last clearing
clearing of "show
"show interface"
interface" counters never default bandwidth of
128kbps.
Queueing
Queueing strategy:
strategy: fifo
fifo
Output
Output queue
queue 0/50,
0/50, 00 drops;
drops; input
input queue
queue 0/75, 0 drops
55 minute
minute input
input rate
rate 00 bits/sec,
bits/sec, 00 packets/sec
packets/sec
55 minute
minute output
output rate
rate 00 bits/sec,
packets/sec
……
FIFO queuing is not supported by a large arsenal of show and debug commands.
The show interface command can be used to determine the queuing strategy of
an interface and to display the following statistics:
n The current queue size (buffer usage)
n The maximum queue size (default 40 or whatever is configured with the
hold-queue out command)

Summary
FIFO queuing is the oldest queuing mechanism in the Cisco IOS. It is used on fast
interfaces because of its simplicity and speed. FIFO produces undesirable behavior
on congested (low-speed) interfaces that manifest itself as:
n Unfair allocation of bandwidth
n Starvation of less-aggressive flows
n Delay
n Jitter
FIFO is the default queuing mechanism on all interfaces that have the default
bandwidth of more than 2 Mbps. FIFO queuing can be enabled on interfaces with
the default bandwidth of 2 Mbps or less by disabling WFQ.
Review Questions
n Why is FIFO the fastest queuing mechanism?
n Describe the classification and scheduling of FIFO queuing.
n List the drawbacks of FIFO queuing.

Priority Queuing
Objectives
n Describe Priority Queuing
n Describe the benefits and drawbacks of Priority Queuing
n Configure Priority Queuing on Cisco routers
n Monitor and troubleshoot Priority Queuing

Priority Queuing
Forwarded Packets
Priority Queuing System
High? Tail-drop Queue 1
Hardware
Medium? Tail-drop Queue 2 Queuing System
Pre-emptive
Scheduler Hardware Q Interface
Normal? Tail-drop Queue 3
Low? Tail-drop Queue 4
• Priority Queuing (PQ) uses four FIFO queues

Priority Queuing (PQ) is one of the first mechanisms that allowed classification of
packets into multiple classes. Scheduling is done in strict priority.
PQ can classify packets into one of the four queues:
n High queue
n Medium queue
n Normal queue (the default queue)
n Low queue
Scheduling prefers packets in the same order. Each class uses one FIFO queue,
where packets are dropped if a queue is full.

Priority Queuing
Classification
• Priority Queuing classification for IP supports the

following options:
– Source interface
– IP access list (standard and extended)
– Packet size (greater or smaller than specified)
– Fragments
– TCP source or destination port numbers
– UDP source or destination port numbers
Priority Queuing can classify IP packets with the following tools:

n Direct matching on the source interface.
n Standard or extended IP Access list. Extended IP access lists support matching
on the following parameters:
– Source IP address
– Destination IP address
– Source TCP or UDP port number or port range
– Destination TCP or UDP port number or port range
– IP precedence (high-order three bits of the ToS field)
– DSCP (high-order six bits of the ToS field)
– ToS value (bits one through four of the ToS field)
– Fragments
– TCP flags (ACK, SYN, RST, URG, PSH)
n Direct matching of TCP or UDP source and destination port numbers.
n Direct matching of fragments.
n Direct matching of packets based on their size.

Priority Queuing
Classification
• Priority Queuing also supports classification of other protocols
with the following options:
– Protocol-specific access list (if available for the specified
protocol)
• Some of the supported protocols are:
– IPX
– CLNS
– DECNET
– AppleTalk
– VINES
– DLSw
Priority Queuing is a multi-protocol QoS mechanism because it supports

classification tools for other (non-IP) protocols. The figure lists the match options
for some of the supported Layer-3 protocols as well as other higher-layer
protocols.
Although other protocols are supported, the classification options are not as
powerful as with IP. Most protocols can use their corresponding access lists to
classify packets. Matching on packet size is also available with all supported
protocols.

Priority Queuing
Insertion Policy
• Each queue has a maximum number of

packets that it can hold (queue size).
• After a packet is classified to one of the
following queues the router will enqueue the
packet if the queue limit has not been
reached (tail-drop within each class).
Priority Queuing is basically a collection of four parallel FIFO queues. Each queue
suffers from all FIFO problems isolated to the class (unfair, starvation, delay,
jitter). Each queue uses the tail-drop scheme when the queue is full.
Each of the four queues can be configured with the maximum number of packets
that it can hold.

Priority Queuing
Scheduling
Packet in No
HIGH
queue?
Packet in No
Yes
MEDIUM
queue?
Packet in No
Yes
NORMAL
queue?
Packet in No
Yes
LOW
queue?
Yes
Dispatch Packet
And start checking the Hardware Q
HIGH queue again
Priority Queuing uses strict priority scheduling. As long as there are packets in the
high queue no other queue will be served. If the high queue is empty the router
starts serving the medium queue.
Congestion in any of the queues, except the low queue, causes a different type of
starvation. A congested higher-priority queue causes all lower-priority queues to
starve (class starvation).

Benefits and Drawbacks of
Priority Queuing
+ Benefits
• Provides low-delay propagation to high-priority
packets
• Supported on most platforms
• Supported in all IOS versions (above 10.0)
– Drawbacks
• All drawbacks of FIFO queuing within a single class
• Starvation of lower -priority classes when higher-
priority classes are congested
• Manual configuration of classification on every hop
As mentioned previously, Priority Queuing suffers from the same drawbacks as

FIFO queuing, except it is localized to four classes. Each class can experience
starvation, delay and jitter if one or more flows in the class cause congestion.
Furthermore, one higher-priority queue can cause all other queues to starve if it is
congested.
Priority Queuing requires manual configuration of classification.
The main benefit of PQ is that it enables the user to create a class that is used for
applications that require low delay (high queue).

Configuring Priority Queuing
• Configure priority lists

–Configure classification
–Select a queue
–Set maximum queue size
• Apply the priority list to outbound traffic on
an interface
The configuration of Priority Queuing can be split into the following four steps:
1. Classify data into four classes
2. Assign a queue to each class
3. Set the maximum queue size (if the default is not appropriate)
4. Apply the priority queuing system to one or more interfaces

Priority Queuing Classification
Router(config)#
priority-list list-number
list-number protocol protocol-name
{high|medium|normal|low} queue-keyword keyword-value
• Selects the queue based on layer-3 protocol

• Additional classification (queue-keyword):
– fragment (IP packets with non-zero fragment
offset)
– gt/lt <size>: based on packet size (including L2
frame)
– list <acl>: ACL classification
– tcp/udp <port>: TCP or UDP port number
• System and link-level messages are classified in
high by default
The first three configuration steps are achieved using the priority-list command.
A Priority Queuing system is identified with a common number (list-number).
Priority Queuing supports the following direct classification options of IP packets:
1. Match fragments
2. Match packets based on their size
3. Match packets based on their source or destination TCP/UDP port number
A far more powerful classification tool is an access list (standard or extended).

Priority Queuing Classification
Router(config)#
priority-list list-number interface intf {high|medium|normal|low}
{high|medium|normal|low}
• Classifies the packet based on incoming interface

Router(config)#
priority-list list-number default
default {high|medium|normal|low}
• Classifies all unclassified packets in a default queue
Additionally, PQ supports classification based on source interface.

By default, all traffic not specifically classified goes into the normal queue. This
behavior can be changed by using the priority-list default command.
Note The priority-list commands are evaluated in the order they were entered. This is
especially important when overlapping classification is configured for separate
queues.
For example:
Line 1: all IP traffic goes into the high priority queue
Line 2: all TCP traffic goes into the medium queue
The medium queue in this example would never g et any packets because it
appears second in the configuration and it is a subset of the first line.

Priority Queuing Scheduling and
Dropping Parameters
Router(config)#
priority-list list-number queue-limit high medium normal low
low
• Specifies the maximum queue sizes of individual

priority queues
Router(config-if)#
priority-group list
• Assigns Priority Queuing definition to an interface
Priority Queuing uses the following default maximum queue sizes for the four
queues:
n High queue has a default queue limit of 20
n Medium queue has a default queue limit of 40
n Normal queue has a default queue limit of 60
n Low queue has a default queue limit of 80
The last configuration step is to apply a priority-list to an interface. Use the
priority-group command with a corresponding priority-list number to enable
Priority Queuing on an interface.

Sample PQ Configuration
E0
WAN core
E1
Core
interface
interface serial0
serial0
Branch priority-group
priority-group 1
office
priority-list
priority-list 1 protocol
protocol ip high list 101
priority-list
priority-list 1 interface
interface ethernet
ethernet 00 medium
medium
priority-list
priority-list 1 default normal
priority-list
priority-list 1 queue-limit 20 40 60 80
access-list
access-list 101
101 permit
permit tcp
tcp any
any any
any eq 23
The figure illustrates a simple example where outbound traffic is classified into the
following three classes:
1. All outbound telnet sessions (access list 101) are using the high priority queue
2. All traffic coming into the router via interface Ethernet 0 is forwarded through
the medium queue
3. All other traffic is using the default normal queue

Monitoring Priority Queuing
Router#
show interface
interface interface
• Displays information and statistics about queuing

on interface
Router#
show queueing [priority|custom|fair|random-detect] interface
• Displays queuing parameters on interfaces
Router#
show queue
queue interface
interface
• Displays queue contents
The show interface command can be used to determine the queuing strategy of
an interface. If the queuing strategy is PQ some statistics are also displayed.
The show queueing priority command can be used to display all non-default
parameters of priority lists.
Note To use the show queueing command, you must enter at least the first six
characters to differentiate the command (show queuei vs. show queue).

Show Interface
Router#show
interface serial
serial 1/0
1/0
Serial1/0
Serial1/0 isis up,
up, line
line protocol
protocol is
is up
up
Hardware
Hardware is
is M4T
M4T
Internet
Internet address
address is
is 20.0.0.1/8
20.0.0.1/8
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 19
19 Kbit,
Kbit, DLY
DLY 20000
20000 usec,
usec, rely
rely 255/255,
255/255, load
load 93/255
93/255
Encapsulation
Encapsulation HDLC,
HDLC, crc
crc 16,
16, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
Last
Last input
input 00:00:00,
00:00:00, output
output 00:00:00,
00:00:00, output
output hang
hang never
never
Last
Last clearing
clearing ofof "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0
0/75/0 (size/max/drops);
(size/max/drops); Total
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: priority-list
priority-list 11
Output
Output queue
queue (queue
(queue priority:
priority: size/max/drops):
size/max/drops):
high:
high: 0/20/0,
0/20/0, medium:
medium: 0/40/0,
0/40/0, normal:
normal: 0/60/0,
0/60/0, low:
low: 0/80/0
0/80/0
55 minute
minute input
input rate
rate 18000
18000 bits/sec,
packets/sec
55 minute
minute output
output rate
rate 7000
7000 bits/sec,
packets/sec
…… rest
rest ignored
ignored ...
...
The show interface command displays the parameters and the statistics of all four
priority queues. The first parameter is the current size of the queue, the second is
the maximum allowed size of the queue and the third parameter is the number of
drops since the last clearing of counters.

Show Queuing Priority
Router#show
Router#show queueing
queueing priority
Current
Current priority
priority queue
queue configuration:
configuration:
List
List Queue Args
Args
11 high
high protocol ip list 101
11 medium
medium interface
• The “show queueing priority” command

displays only the non-default parameters
The show queueing priority command lists all non-default parameters.

The figure shows the two parameters:
n All packets permitted by access list 101 go into the high queue
n All packets coming from interface Ethernet6/0 go into the medium queue
The commands that set default parameters are not displayed, either in the running
configuration or by using this command.

Summary
Priority Queuing uses four FIFO queues. Strict priority queuing is used. Starvation
within a single class or starvation of lower-priority classes is possible when one
flow congests a higher-priority queue.
Priority queuing can be used to guarantee all the bandwidth and low-delay
propagation.
Review Questions
n When would you use priority queuing?
n What are the benefits and drawbacks of priority queuing?
n How many classes does priority queuing support?
n How does priority queuing schedule packets?

Custom Queuing
Objectives
n Describe Custom Queuing
n Describe the benefits and drawbacks of Custom Queuing
n Configure Custom Queuing on Cisco routers
n Monitor and troubleshoot Custom Queuing

Custom Queuing
Forwarded Packets
Custom Queuing System
Class 1? Tail-drop Queue 1
Hardware
Class 2? Tail-drop Queue 2 Queuing System
Round
Robin Hardware Q Interface
Scheduler
• Custom Queuing (CQ) uses 16 FIFO queues for

user defined traffic classes
Custom Queuing (CQ) is similar to Priority Queuing in the way it is configured and
in the supported classification options. The scheduling, however, is completely
different.
CQ uses up to 16 queues that can be used for user-defined classes. The
classification options are identical to those of Priority Queuing.
The scheduling mechanism uses the round-robin service where each queue is
allowed to forward a certain number of bytes (not packets).
Tail-drop is still used within each individual queue.

Custom Queuing
Classification
• Custom Queuing classification for IP supports the

following options:
– Source interface
– IP access list (standard and extended)
– Fragments
– TCP source or destination port numbers
– UDP source or destination port numbers
• Custom Queuing classification is identical to that of
Priority Queuing
Custom Queuing (similar to Priority Queuing) can classify IP packets with the
following tools:
n Direct matching on the source interface.
n Standard or extended IP Access list. Extended IP access lists support matching
on the following parameters:
– Source IP address
– Destination IP address
– Source TCP or UDP port number or port range
– Destination TCP or UDP port number or port range
– IP precedence (high-order three bits of the ToS field)
– DSCP (high-order six bits of the ToS field)
– ToS value (bits one through four of the ToS field)
– Fragments
– TCP flags (ACK, SYN, RST, URG, PSH)
n Direct matching of TCP or UDP source and destination port numbers.
n Direct matching of fragments.
n Direct matching of packets based on their size.

Custom Queuing
Insertion Policy
• Each queue has a maximum number of

packets that it can hold (queue size).
• After a packet is classified to one of the
following queues the router will enqueue the
packet if the queue limit has not been
reached (tail-drop within each class).
Once the packet is classified a router has to determine if the packet can be
enqueued. The packet is dropped if the queue is full.
Each queue, unless configured otherwise, can buffer up to 20 packets before the
first packet is dropped.

Custom Queuing
Scheduling
No
Is Queue N
Packet in No Next Queue Yes
over the
Queue N? (increase N)
threshold?
Yes
Dispatch
Packet Hardware Q
• Custom Queuing uses round-robin service policy

• Each queue is allowed to forward a configurable
amount of bytes (threshold) in one round
Custom Queuing uses round-robin scheduling, where each queue gets some
service (bandwidth). Each queue is configured with the number of bytes
(byte-count) it can send in one round. The last packet is always sent, even if the
total amount of bytes sent in one round is above the limit (byte-count). The router
then starts processing the next queue.

Custom Queuing
Scheduling Parameters
1500 1499 1500
Threshold (byte-count) = 3000
Up to 4499 bytes can be forwarded

in one round in the worst case
• The threshold (byte count) parameter specifies the lower

boundary on how many bytes the system allows to be delivered
from a given queue during a particular cycle
• The router is allowed to send the entire packet even if the sum
of all bytes is more than the threshold
The figure illustrates the worst case scenario where the following parameters were
used to implement Custom Queuing on an interface:
n MTU of the interface is 1500 bytes
n Byte-count is 3000 (twice the MTU)
The example shows how the router first sent two packets with a total size of 2999
bytes. Since this is still within the limit (3000) the router can send the next packet
(MTU-sized). The result was that the queue received almost 50% more bandwidth
in this round than it should.
This is one of the drawbacks of Custom Queuing – it does not allocate bandwidth
accurately.

CQ Design Guideline
• Configure the amount to remove from a

queue in each round to configure the
proportional “weight” of the queue
• Amounts to remove should approximate a
small multiple of the interface’s MTU
• Ratio between largest and smallest queue
should be a small positive integer, not more
than 10:1
The limit or weight of the queue is configured in bytes. The accuracy of Custom
Queuing depends on the weight (byte-count) and the MTU.
If the ratio between the byte-count and the MTU is too small CQ will not allocate
bandwidth accurately.
If the ratio between the byte-count and the MTU is too large CQ will cause long
delays. This problem is discussed in detail on the next two pages.

Delay vs. Bandwidth Allocation
Queue 1
5999 4500
Round
Queue 2 Robin 64 kbps
Scheduler
4499 3000 MTU=1500
Queue 3
2999 1500
BW
BW (Queue 1) == bc1/(bc1+bc2+bc3)
bc1/(bc1+bc2+bc3) == 4500/9000 == 50%
Delay
Delay (Queue
(Queue 1)
1) = (bc2+bc3)/Bandwidth = 562ms
Worst-case
Worst-case Delay
Delay (Queue
(Queue 1) = ((bc2+1499) +(bc3+1499))/Bandwidth
+(bc3+1499))/Bandwidth == 937ms
The figure illustrates sample calculations of bandwidth guarantees and the

maximum delay.
The time it takes to complete a round depends on the bandwidth of the interface,
the MTU size and the sum of all queue byte-counts.
The case study parameters are:
n The first queue uses a byte-count of 4500 (three times the MTU)—5999 bytes
can be sent in the worst case
n The second queue uses a byte-count of 3000 (two times the MTU)—4499
bytes can be sent in the worst case
n The third queue uses byte-count 1500 (MTU)—2999 bytes can be sent in the
worst case
The first calculation shows that the first queue should receive approximately 50%
of the bandwidth.
The second calculation shows the round-robin delay of 562ms for Queue 1 when
all classes are congested.
The third calculation shows the round-robin delay of 937ms for Queue 1 when all
classes are congested and manage to send the maximum number of bytes
(byte-count + MTU - 1) in one round. Although this worst case is very unlikely it is
also unlikely that classes will use the exact configured maximum.

Worst-case Delay
• MTU=1500, byte-count (4500, 3000, 1500)

Max(delay)=(5999+4499)*8/64000=1312 ms
• MTU=1000, byte-count (4500, 3000, 1500)
Max(delay)=(5499+3999)*8/64000=1187 ms
• MTU=250, byte-count (450, 300, 150)
Max(delay)=(699+549)*8/64000=156 ms
Expected delay=(500+500)*8/64000=125 ms
Custom queuing is not appropriate for low-
delay environment. Changing MTU and byte-
counts might be a workaround.
The figure shows several calculations where the worst-case maximum delay was
reduced by reducing both the MTU and the byte-counts.
Note The calculation merely shows the impact the MTU and the byte-count have on
the delay. Lowering the MTU is not a recommended solution because it
potentially increases the CPU utilization of the router due to fragmentation of
packets.

Custom Queuing
+ Benefits
• Guarantees throughput to traffic classes (prevents
starvation between traffic classes)
– Drawbacks
• Manual configuration of classification on every hop
• Not accurate bandwidth allocation
• High jitter due to implementation of scheduling
In addition to all the benefits and drawbacks of Priority Queuing, Custom Queuing
can also guarantee bandwidth to up to 16 classes.
Custom Queuing can cause all queues to experience delay due to the
implementation of scheduling (one round can take a long time).

Custom Queuing Classification
Router(config)#
queue-list list-number protocol protocol-name
protocol-name
queue-number
queue-number queue-keyword keyword-value
• Classifies the packet into a custom queue based on

protocol and other protocol-specific criteria
• Selection criteria identical to priority queuing
Router(config)#
queue-list list-number interface incoming-intf queue-number
queue-number
• Classifies the packet into a custom queue based on

incoming interface
Custom queuing uses the same classification options as Priority Queuing. Instead
of using names queues are numbered (1 to 16).

Custom Queuing Classification
Router(config)#
queue-list list-number default
default queue-number
• Classifies all unclassified packets into a default

queue
Router(config-if)#
custom-queue list-number
• Starts custom queuing on an interface and assigns

specified CQ definition to the interface
All traffic that is not specifically classified is put into Queue 1.

n Use the queue -list default command to change the default queue.
n Use the custom-queue interface command to apply a queue-list to an
interface.

Custom Queuing
Router(config)#
queue-list list queue
queue queue-number byte-count bc
• Specifies the lower boundary on how many bytes

the system allows to be delivered from a given
queue during one round-robin cycle
Default: 1500 bytes
Router(config)#
queue-list list queue
queue queue-number limit limit
• Specifies the maximum number of packets in a

queue
• Incoming packets are tail-dropped if the limit is
exceeded
n Use the byte-count option to change the default weight of a queue (default
equals MTU size)
n Use the limit option to change the number of packets that a queue can hold
(default is 20)

Custom Queuing with Pre-
emptive Queues
Forwarded Packets
Custom Queuing has
Custom Queuing System queue 0 for system and
link-level messages which
use pre-emptive scheduling
Class 1? Tail-drop Queue 1 Hardware

Queuing System
Pre -emptive
Scheduler Hardware Q Intf
Round
Robin
Scheduler
Queue 1 is the lowest

custom queue that is
Class 16? Tail-drop Queue 16 serviced by the round
robin scheduler
Custom queuing has another queue—Queue 0. This queue is used for system
packets (routing protocols, link-level messages).
This queue is not served by the round-robin scheduler. Instead, a strict priority
scheduler is used to prioritize packets from this queue.

Custom Queuing with Pre-
emptive Queues
Forwarded Packets
Custom Queuing System

Custom queues can be
configured to use the
Class 0? Tail-drop Queue 0 pre -emptive scheduler
Class 1? Tail-drop Queue 1 Hardware

Queuing System
Pre -emptive
Scheduler Hardware Q Intf
Queue 2 is now the

Round lowest custom queue
Robin that is serviced by the
Scheduler round robin scheduler
The strict priority scheduler can be extended to other queues that are normally
served by the round-robin scheduler.
The figure illustrates how Queue 1 was moved into the priority-scheduled part of
the Custom Queuing system. The delimiter can be set to any queue by specifying
the lowest custom queue (Queue 2 in this example). In fact, Custom Queuing can
be turned into Priority Queuing with 17 queues if Queue 16 is selected as the
lowest custom queue.

Custom Queuing
Router(config)#
queue-list list-number lowest-custom queue-number
queue-number
• Set the lowest queue to be treated as custom queue

• Queues below the specified queue are pre-emptive
priority queues (Q1 having highest priority)
• Queue 0 is always treated as pre-emptive
– System and link-level messages are classified in
Q0 by default
Use the lowest-custom option to achieve the following:

n All queues from Queue 0 to the queue before the one specified in the command
use priority queuing (Queue 0 has the highest priority)
n All queues from the one specified in the command to Queue 16 use the
round-robin scheduler

Custom Queuing
Example
E0
WAN core
interface
interface serial 1/0
1/0
E1 custom-queue-list 5 Core
Branch !!
queue-list
queue-list 55 protocol
protocol ip
ip 11 list
list 101
101
office
queue-list
queue-list 5 queue 1 limit 40
queue-list
queue-list 5 lowest-custom
lowest-custom 22
queue-list
queue-list 5 interface
interface ethernet
ethernet 0/0
0/0 22
queue-list
queue-list 55 queue
queue 22 byte-count
byte-count 3000
queue-list
queue-list 5 protocol ip 3
queue-list
queue-list 55 queue
queue 33 byte-count
byte-count 5000
queue-list
queue-list 5 default
default 4
!!
access-list
access-list 101 permit
permit ip any any precedence
precedence 5
The figure shows a sample configuration where four queues are used:
n Queue 1 is used for delay-sensitive applications (marked with IP precedence
5). It uses the strict priority scheduler.
n Queue 2 is used for all packets coming from interface Ethernet0/0.
n Queue 3 is used for all IP packets that do not end in one of the first two
queues.
n Queue 4 is used for all other traffic.

Custom Queuing - Show Interface
Router#show
interface serial
serial 1/0
1/0
Serial1/0
Serial1/0 isis up,
up, line
line protocol
protocol is
is up
up
Hardware
Hardware isis M4T
M4T
Internet
Internet address
address is
is 20.0.0.1/8
20.0.0.1/8
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 19
19 Kbit,
Kbit, DLY
DLY 20000
20000 usec,
usec, rely
rely 255/255,
255/255, load
load 107/255
107/255
Encapsulation
Encapsulation HDLC,
HDLC, crc
crc 16,
16, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
Last
Last input
input 00:00:00,
00:00:00, output
output 00:00:00,
00:00:00, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: custom-list
custom-list 55
Output
Output queues:
queues: (queue
(queue #:
#: size/max/drops)
size/max/drops)
0:
0: 0/20/0
0/20/0 1:
1: 0/40/0
0/40/0 2:
2: 0/20/0
0/20/0 3:
3: 0/20/0
0/20/0 4:
4: 0/20/0
0/20/0
5:
5: 0/20/0
0/20/0 6:
6: 0/20/0
0/20/0 7:
7: 0/20/0
0/20/0 8:
8: 0/20/0
0/20/0 9:
9: 0/20/0
0/20/0
10:
10: 0/20/0
0/20/0 11:
11: 0/20/0
0/20/0 12:
12: 0/20/0
0/20/0 13:
13: 0/20/0
0/20/0 14:
14: 0/20/0
0/20/0
15:
15: 0/20/0
0/20/0 16:
16: 0/20/0
0/20/0
…… rest
rest ignored
ignored ...
...
The show interface command is used to determine the queuing strategy of an

interface. If custom queuing is used on an interface the following information is
also displayed:
n The number of the queue-list
n Statistics for each of the 17 queues:
– Current size
– Maximum size
– Total number of drops since the last clearing of counters

Show Queueing Custom
Router#show
Router#show queueing
queueing custom
Current
Current custom
custom queue
List
List Queue Args
Args
55 33 default
default
55 11 protocol
protocol ip
ip list 101
55 22 interface
55 11 byte-count
byte-count 3000 limit 40
55 22 byte-count
byte-count 5000
• The “show queueing custom” command

displays only the non-default parameters
The show queueing custom command can be used to display all non-default
parameters of Custom Queuing.

Summary
Custom Queuing introduces a scheduler that can guarantee bandwidth to 16
classes.
In addition to the round-robin scheduling between 16 classes, a number of classes
can be switched to priority scheduling.
Review Questions
n When would you use custom queuing?
n What are the benefits and drawbacks of custom queuing?
n How many classes does custom queuing support?
n How does custom queuing schedule packets?

Weighted Fair Queuing
Objectives
n Describe WFQ
n Describe the benefits and drawbacks of WFQ
n Configure WFQ on Cisco routers
n Monitor and troubleshoot WFQ

• Queuing algorithm should fairly share the bandwidth

among flows by:
– reducing response time for interactive flows by
scheduling them to the front of the queue
– preventing high volume conversations from
monopolizing an interface
• Implementation: Messages are sorted into
conversations (flows) and transmitted by the order
of the last bit crossing its channel
• Unfairness is reinstated by introducing “weight” (IP
precedence) to give proportionately more bandwidth
to flows with higher weight
Weighted Fair Queuing (WFQ) was introduced as a solution to the problems of the
following queuing mechanisms:
n FIFO queuing causes starvation, delay and jitter
n PQ causes starvation of other lower-priority classes and suffers from all FIFO
problems within each of the four queues
n CQ causes long delays and also suffers from all FIFO problems within each of
the 16 queues
The idea of WFQ is to:
n Have a dedicated queue for each flow (no starvation, delay or jitter within the
queue)
n Fairly and accurately allocate bandwidth among all flows (minimum scheduling
delay, guaranteed service)
n Use IP precedence as weight when allocating bandwidth

Forwarded Packets
Weighted Fair Queuing System
Flow 1? WFQ-drop Queue 1
Hardware
Flow 2? WFQ-drop Queue 2 Queuing System
WFQ
Flow N? WFQ-drop Queue N
• WFQ uses per-flow FIFO queues
n WFQ uses automatic classification. Manually defined classes are not supported.
n WFQ dropping is not a simple tail-drop. WFQ drops packets of the most
aggressive flows.
n WFQ scheduler is a simulation of a TDM system (time-division multiplexer).
The bandwidth is equally distributed to all active flows.

Implementations
• Implementation parameters
–Queuing platform: central CPU or VIP
–Classification mechanism
–Weighted fairness
• Modified Tail-Drop within each queue
WFQ is supported on most Cisco routers as well as Versatile Interface Processors

(VIP). The implementation on the VIP slightly differs from the one discussed in
this lesson.
n Classification identifies a flow and assigns a queue to the flow
n Weight is used for scheduling to give proportionately more bandwidth to flows
with a higher IP precedence
n Tail-dropping scheme is improved to drop packets of the most aggressive flows

WFQ Classification
IP TCP Payload WFQ Classification uses the

following parameters:
• source IP address
• destination IP address
• source TCP or UDP port
Src. Dst. Proto. ToS Src. Dst. • destination TCP or UDP
Addr. Addr. Port Port port
• transport protocol
• type of service (ToS) field
A hash algorithm is used to

Hash Algorithm produce the index of the
queue where the packet is
enqueued
#queue (Index of the queue)

• Packets of the same flow end up in the same queue
• ToS field is the only parameter that might change causing
packets of the same flow to end up in different queues
WFQ classification has to identify individual flows (the term conversation is also
used to signify flows). A flow is identified based on the following information taken
from the IP header and the TCP or UDP headers:
n Source IP address
n Destination IP address
n Protocol number (identifying TCP or UDP)
n Type of Service Field
n Source TCP/UDP port number
n Destination TCP/UDP port number
All these parameters are usually fixed for a single flow, although there are some
exceptions:
n A QoS design could mark packets with different IP precedence values even if
they belong to the same flow. This kind of behavior should be avoided when
using WFQ.
n Some applications change port numbers (for example, TFTP).
If packets of the same flow do not have the same parameters (for example, a
different ToS field) the packets can end up in different queues and reordering can
occur.
The parameters are used as input for a hash algorithm that produces a fixed-length
number that is used as the index of the queue.

WFQ Classification
Details
• Fixed number of per-flow queues is configured

• A hash function is used to translate flow parameters
into queue number
• System packets (8 queues) and RSVP flows (if
configured) are mapped into separate queues
• Two or more flows could map into the same queue,
resulting in lower per-flow bandwidth
• Important: the number of queues configured has to
be larger than the expected number of flows
WFQ uses a fixed number of queues. The hash function is used to assign a queue
to a flow. There are eight additional queues for system packets and optionally up to
1000 queues for RSVP flows.
WFQ uses 256 queues by default. The number of queues can be configured in the
range between 16 and 4096 (the number must be a power of 2).
If there are a large number of concurrent flows it is very likely that two flows
could end up in the same queue. It is recommended to have several times as many
queues as there are flows (on the average). This may not be possible in larger
environments where the number of concurrent flows is in thousands.
The probability of two flows ending up in the same flow could be calculated using
the following formula:
Queues!
P =1−
Queues Flows
⋅ ( Queues − Flows)!
The following table lists the probability values for 3 sizes of the WFQ system (64,
128 and 256 queues), with the number of concurrent flows from 5 to 40.
Flows 64 queues 128 queues 256 queues
5 15% 8% 4%
10 52% 30% 16%
15 83% 57% 34%
20 96% 79% 53%
25 100% 92% 70%
30 100% 98% 83%
35 100% 99% 91%
40 100% 100% 96%

WFQ Insertion and Drop Policy
• WFQ has two modes of dropping:

–Early dropping when the congestion
discard threshold (CDT) is reached
–Aggressive dropping when the hold-queue
limit (HQO) is reached
• WFQ always drops packets of the most
aggressive flow
WFQ uses two parameters that affect the dropping of packets.

n The congestive discard threshold (CDT) is used to start dropping packets of
the most aggressive flow, even before the hold-queue limit is reached.
n The hold-queue limit defines the total maximum number of packets that can be
in the WFQ system at any time.

WFQ Insertion and Drop Policy
No No Enqueue
N-th packet N>HQO? N>CDT?
packet
Yes Yes
Worst Worst
Yes No
Finish Finish
Time? Time?
No Yes
Old
Drop the packet with
the worst finish time
(old) and enqueue the
N-th packet (new)
New
• HQO (hold-queue out limit) is the max . number of packets that the WFQ system can hold
• CDT (congestive discard threshold) is the threshold when WFQ starts dropping packets of
the most aggressive flow
• N is the number of packets in the WFQ system when the N -th packet arrives
The figure illustrates the dropping scheme of WFQ. The process can be split into
the following steps:
Step 1 Drop the new packet if the WFQ system is full (hold-queue limit reached) and the
new packet has the worst finish time (the last in the entire system).
Step 2 Drop the packet with the worst finish time in the WFQ system if the system is full.
Enqueue the new packet.
Step 3 Drop the new packet if the queue, where the packet should be enqueued, is the
longest (not in packets but in the finish time of the new packet) and there are more
packets in the WFQ system than the CDT.
Step 4 Otherwise enqueue the new packet.

Case Study
• WFQ system can hold a maximum of ten

packets (hold-queue limit)
• Early dropping (of aggressive flows) should
start when there are eight packets
(congestive discard threshold) in the WFQ
system
The following case study is used to describe how packets are dropped in different
situations.
The WFQ system was reduced to a modest hold-queue limit of ten and a
congestive discard threshold of eight.

Case Study
Interface Congestion
• Absolute maximum (HQO=10) exceeded, new

packet is the last in the TDM system and is
dropped
There are already ten packets in the WFQ system. The new packet would be the
eleventh and also the last in the entire WFQ system. The packet is dropped.

Case Study
Interface Congestion
• Absolute maximum exceeded (HQO=10), new

packet is not the last in the TDM system, last
packet is dropped
In this example there are also ten packets in the system when the eleventh packet
arrives. The new packet, if enqueued, would not be the last in the system. The
packet is therefore allowed to be enqueued and the last packet in the system is
deleted.

Case Study
Flow Congestion
• CDT exceeded (CDT=8), new packet would be

the last in the TDM system and is dropped
This example illustrates how WFQ can drop packets even if the WFQ system is
still within the hold-queue limit. The system, however, is above the CDT limit. In
this case a packet can be dropped if it is the last in the system.

Case Study
Flow Congestion
• CDT exceeded (CDT=8), new packet would

not be the last. Packet is enqueued
This example is different from the previous one in that the new packet would not
be the last in the WFQ system. The packet can be enqueued and no other packet
is dropped.

Drop Mechanism within WFQ
Exceptions
• Packet classified into an empty sub-queue is

never dropped
• The packet precedence has no effect on the
dropping scheme
There is an exception to the CDT rule —if the WFQ system is above the CDT
limit, and the new packet would be the last in the system, the packet is still
enqueued if the flow queue is empty.
The dropping strategy is not directly influenced by IP precedence.

WFQ Scheduling
• Each packet is tagged with its Finish time in

a virtual TDM system
• The scheduler selects the packets with the
earliest finish time tag (thus the packet that
leaves the virtual TDM the earliest)
• Reference: “On the Efficient Implementation
of Fair Queuing", Keshav, Berkeley, 1994
The length of queues (for scheduling purposes) is not in packets but in the time it
would take to transmit all the packets in the queue. The following pages discuss the
WFQ scheduling issue in detail.
The end result is that WFQ adapts to the number of active flows (queues) and
allocates equal amounts of bandwidth to each flow (queue).
The side effect is that flows with small packets (usually interactive flows) get a
much better servic e because they do not need a lot of bandwidth. They, however,
need low-delay, which they get because small packets have a low finish time.

Fair Queuing
Finish Time Calculation
If Flow
Flow FF Active,
Active,
Then FT(Pk+1
k+1) = FT(Pkk) + Size(Pk+1
k+1)
Otherwise FT(P0) = Now + Size(P0)
FT(A1)=0+100
FT(B1)=50+300 A1[100]
B1[300]
FT(A2)=100+20 A2[20]
FT(B2)=350+300 FT(A3)=120+10 A3[10]
B2[300]
t
100 70 60 50 0
Hence the resulting scheduling is:
B2 B1 A3 A2 A1
The figure illustrates how two queues (Queue A and Queue B) are contesting for
link bandwidth. For this example, assume the time units are in milliseconds and time
T (value 0 is used in the figure) is the starting point.
Queue A is receiving packets in the following order and the following times:
n Packet A1 arrives at time T + 0ms and would require 100ms to be transmitted
n Packet A2 arrives at time T + 60ms (the input interface is obviously faster than
the output interface because the arrival time of packet A2 is before the finish
time of packet A1) and would require 20 ms to be transmitted
n Packet A3 arrives at time T + 60ms (the input interface is obviously much
faster than the output interface) and would require 10 ms to be transmitted
Queue B is receiving packets in the following order and the following times:
n Packet B1 arrives at time T + 50ms and would require 300ms to be transmitted
n Packet B2 arrives at time T + 100ms and would also require 300ms to be
transmitted
The finish time of packets in Queue A are:
n Packet A1 has a finish time which is the sum of the current time (because the
queue was empty at the time of arrival) and the time it takes to transmit this
packet (100ms): FTA1 = 0ms + 100ms = 100ms
n Packet A2 has a finish time which is the sum of the finish time of the last
packet in Queue A (Packet A1) and the time it would take to transmit this

n Packet A3 has a finish time which is the sum of the finish time of the last
packet in Queue A (Packet A2) and the time it would take to transmit this
The finish time of packets in queue B are:
n Packet B1 has a finish time which is the sum of the current time (because the
queue was empty at the time of arrival) and the time it takes to transmit this
packet (300ms): FTB1 = 50ms + 300ms = 350ms
n Packet B2 has a finish time which is the sum of the finish time of the last
packet in Queue B (Packet B1) and the time it would take to transmit this
packet (300ms): FTB2 = 350ms + 300ms = 650ms
The packets are scheduled into the hardware queue (TxQ) in the ascending order
of finish times:
1. A1 (100ms)
2. A2 (120ms)
3. A3 (130ms)
4. B1 (350ms)
5. B2 (650ms)
The following remarks should be noted in conclusion of the case study:
n WFQ prevents reordering of packets within a single flow (conversation)
n Small packets are automatically preferred over large packets

Weight in WFQ Scheduling
WFQ system (real size packets)

Flow with P=001 2 1
Flow with P=000 3 2 1
Precedence-1
Virtual Packet Size = Real Packet Size / (IP precedence + 1)
packets appear
half the real size
WFQ system (virtual size packets)

Flow with P=001 4 3 2 1
Precedence -1 flow
gets twice as much
Flow with P=000 3 2 1 bandwidth as
precedence -0 flow
Hardware FIFO Queue

3 3 2 2 1 1
This figure introduces the weight into the finish time calculation. The time it takes
to transmit the packet is divided by IP precedence increased by one (to prevent
division by zero).
The WFQ implementation in Cisco routers was optimized in the following way:
n The real time it takes to transmit the packet is not relevant. The packet size can
be used instead because it is proportional to the transmit time.
n The packet size is not divided by IP precedence (division is a CPU-intensive
operation). Instead, the size is multiplied by a fixed value (one multiplication
value for each IP precedence value).
Packets with IP precedence one appear half the size they really are. The result is
that these packets receive twice as much bandwidth as packets with IP
precedence zero.

Finish Time Calculation
Finish Time is adjusted based on IP precedence of the packet

If Flow F Active,
Then FT(Pk+1) = FT(Pk) + Size(P
Size(P k+1
k+1)/(IPPrec+1)
Otherwise FT(P00) = Now + Size(P0)/(IPPrec+1)
IOS implementation scales the finish time to allow integer

arithmetic
If Flow F Active,
Then FT(Pk+1) = FT(Pk) + Size(P
Size(P k+1
k+1)*4096/(IPPrec+1)
Otherwise FT(P00) = Now + Size(P0)*4096/(IPPrec+1)
RSVP packets and high-priority internal packets (PAK-Priority)

have special weights (4 and 128)
The first formula in the figure is the first optimisation where the finish time is really
the sum of packet sizes divided by an increased IP precedence value.
The second formula shows further optimisation where, instead of dividing, the
packet size is multiplied by 4096/(IP precedence + 1). A value for each IP
precedence is stored in a table and it does not have to be calculated for each
packet.
Packets belonging to RSVP flows and system packets have special low weights
that guarantee them more bandwidth.
Note Cisco IOS versions after 12.0(5)T use a new formula where the weight is
calculated on the following formula: Weight = 32384 / (IP precedence +1)

IP Precedence to Weight
Mapping
IP Precednece Weight
0 4096
1 2048
2 1365
3 1024
4 819
5 682
6 585
7 512
32 (virtual IP precedence) 128 (PAC-Priority)
1024 (virtual IP precedence) 4 (RSVP)
• RSVP packets and high-priority internal packets (PAK-Priority) have

special weights (4 and 128)
• Lower weight makes packets appear smaller (preffered)
The table above shows the mapping between IP precedence values and WFQ
weights.
Note According to the new formula for weight in Cisco IOS versions after 12.0(5)T the
following values are used:
IP precedence 0 weight 32384


Voice and Data integration
• WAN link speed 128 kbps

• Voice requirements 30 kbps
• VoIP is precedence 5 (counts as 6 data
sessions)
• 1 VoIP session, 5 data sessions
– voice gets up to 6/(6+5)*128 = 69 kbps (enough)
• 1 VoIP session, 20 data sessions
– voice gets up to 6/(6+20)*128 = 29 kbps (problem)
The case study above is concerned with the propagation of voice packets across a
128 kbps link without using RSVP.
Assume that VoIP is using G.729 codec that uses approximately 30 kbps of
bandwidth (including RTP, UDP, IP and frame headers).
All voice packets are marked with IP precedence 5.
n The first calculation is where a voice session is contesting for available
bandwidth with 5 precedence-0 data sessions. WFQ would guarantee 69 kbps
to the voice session.
n The second calculation is where the same voice session is contesting for
available bandwidth with 20 precedence-0 data sessions. WFQ would now
guarantee only 29 kbps to the voice session.
The conclusion is that, although WFQ can give a much better service to flows with
small packets or high IP precedence value, it is not an exact tool that can
guarantee a fixed amount of bandwidth.

+ Benefits
• Simple configuration (classification does not have to be
configured)
• Guarantees throughput to all flows
• Drops packets of most aggressive flows
– Drawbacks
• All drawbacks of FIFO queuing within a single queue
• Multiple flows can end up in one queue
• Does not support the configuration of classification
• Can not provide fixed bandwidth guarantees
• Performance limitations due to complex classification and
scheduling mechanisms
The main benefits of WFQ are:

n Simple configuration (no manual classification is necessary)
n Drops packets of the most aggressive flows
The main drawbacks are:
n It is not always possible to have one flow per queue
n Does not allow manual classification
n It cannot provide fixed guarantees

Configuration
Router(config-intf)#
fair-queue [cdt [dynamic-queues [reservable-queues]]]
• congestive-discard-threshold (CDT)
–Number of messages allowed in the WFQ
system before the router starts dropping
new packets for the longest queue.
–The value can be in the range from 1 to
4096 (default is 64)
WFQ is automatically enabled on all interfaces that have a default bandwidth of

less than 2 Mbps.
Use the fair-queue command to enable WFQ on interfaces where it is not enabled
by default or was previously disabled.
The CDT value can be changed from the default 64.

Configuration
fair-queue [cdt [dynamic-queues [reservable-queues]]]
• dynamic-queues
– Number of dynamic queues used for best-effort
conversations (values are: 16, 32, 64, 128, 256,
512, 1024, 2048, and 4096 - the default is 256)
• reservable-queues
– Number of reservable queues used for reserved
conversations in the range 0 to 1000 (used for
interfaces configured for features such as RSVP -
the default is 0)
The number of dynamic queues can also be changed from the default number of
256 queues.
The maximum number of reservable queues should be set when RSVP requires
guarantees for the reserved bandwidth.

Additional Parameters
Router(config-if)#
hold-queue max-limit out
• Specifies the maximum number of packets that can

be in all output queues on the interface at any time
• The default value for WFQ is 1000
• Under special circumstances WFQ can consume a
lot of buffers which may require lowering this limit
The same hold-queue command that can be used with FIFO queuing can also be
used with WFQ. The default hold-queue limit with WFQ is 1,000 packets.
The WFQ system will generally never reach the hold-queue limit because the CDT
limit starts dropping packets of aggressive flows. Under special circumstances it
would be possible to fill the WFQ system. For example, a denial-of-service attack
that floods the interface with a large number of packets (each different) could fill
all queues at the same rate.

Fair Queuing Defaults
• Fair Queuing is enabled by default on

– physical interfaces whose bandwidth is less than
or equal to 2.048 Mbps
– interfaces configured for Multilink PPP
• Fair Queuing is disabled
– if you enable the autonomous or silicon switching
engine mechanisms
– for any sequenced encapsulation: X.25, SDLC,
LAPB, reliable PPP
The figure explains the default behavior of WFQ. As mentioned previously, WFQ
is automatically enable d on all interfaces slower than 2Mbps. WFQ is also required
on interfaces using Multilink PPP.
WFQ cannot be used if reordering of frames is not allowed due to sequence
numbering of Layer-2 frames or if the switching path does not support WFQ.

WFQ
Router#
show interface
interface interface
interface
• Displays interface delays including the activated

queuing mechanism with the summary information
Router#
show queue interface
• Displays detailed information about the WFQ system

of the selected interface
The same show commands can be used as with other queuing mechanisms:
n show interface
n show queue
n show queueing

Show Interface
Router#show
interface serial
serial 1/0
1/0
Hardware
Hardware is
is M4T
M4T
Internet
Internet address
address isis 20.0.0.1/8
20.0.0.1/8
MTU
MTU 1500
1500 bytes,
bytes, BWBW 19
19 Kbit,
Kbit, DLY
DLY 20000
20000 usec,
usec, rely
rely 255/255,
255/255, load
load 147/255
147/255
Encapsulation
Encapsulation HDLC,
HDLC, crc
crc 16,
16, loopback
loopback not
not set
set
Keepalive
Keepalive set
set (10
(10 sec)
sec)
Last
Last input
input 00:00:00,
00:00:00, output
output 00:00:00,
00:00:00, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters never
never
Input
Input queue:
queue: 0/75/0
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue:
queue: 0/1000/64/0
0/1000/64/0 (size/max
(size/max total/threshold/drops)
total/threshold/drops)
Conversations
Conversations 0/4/256
0/4/256 (active/max
(active/max active/max
active/max total)
total)
Reserved
Reserved Conversations
Conversations 0/0
0/0 (allocated/max
(allocated/max allocated)
allocated)
55 minute
minute input
input rate
rate 18000
18000 bits/sec,
packets/sec
55 minute
minute output
output rate
rate 11000
11000 bits/sec,
packets/sec
…… rest
rest deleted
deleted ...
...
The show interface command can be used to determine the queuing strategy. The
summary statistics are also displayed.
The sample output in the figure shows that there are currently no packets in the
WFQ system that allows up to 1,000 packets (hold-queue limit) with CDT 64.
WFQ is using 256 queues. The maximum number of concurrent conversations
(active queues) was 4.

Show Queue
Router#show
Router#show queue
queue serial
serial 1/0
1/0
Input
Input queue:
queue: 0/75/0
Total output
output drops:
drops: 00
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue:
queue: 2/1000/64/0
2/1000/64/0 (size/max
total/threshold/drops)
Conversations
2/4/256 (active/max
active/max total)
total)
Reserved
Conversations 0/0
0/0 (allocated/max
allocated)
(depth/weight/discards/tail
(depth/weight/discards/tail drops/interleaves)
drops/interleaves) 1/4096/0/0/0
1/4096/0/0/0
Conversation
Conversation 124,
124, linktype:
linktype: ip,
ip, length:
length: 580
580
source:
source: 193.77.3.244,
193.77.3.244, destination:
destination: 20.0.0.2,
20.0.0.2, id:
id: 0x0166,
0x0166, ttl:
ttl: 254,
254,
TOS:
TOS: 00 prot:
prot: 6,
6, source
source port
port 23,
23, destination
destination port
port 11033
11033
1/4096/0/0/0
Conversation
Conversation 127,
127, linktype:
linktype: ip,
ip, length:
length: 585
585
source:
source: 193.77.4.111
193.77.4.111 destination:
40.0.0.2, id:
id: 0x020D,
0x020D, ttl:
ttl: 252,
252,
TOS:
TOS: 00 prot:
prot: 6,
6, source
source port
port 23,
23, destination
destination port
port 11013
11013
The show queue command also displays the flow (conversation) statistics:
n Queue depth is the number of packets in the queue
n Weight is 4096/(IP precedence + 1) or 32384/(IP precedence + 1),
depending on the Cisco IOS version
n Discards is the number of drops due to the CDT limit
n Tail drops is the number of drops due to the hold-queue limit

Queuing comparison
Weighted Fair Queuing Priority Queuing Custom Queuing
No queue lists 4 queues 16 queues
Low volume traffic High priority queue Round-robin service

given priority serviced first
Conversation Packet-by-packet
Threshold dispatching
dispatching dispatching
Interactive traffic Critical traffic gets Proportional allocation
gets priority through of bandwidth
Works well on speeds Designed for Designed for
up to 2 Mbps low-bandwidth links medium-speed links
Enabled by default Must configure Must configure
The table shows the main differences between WFQ, PQ and CQ.

Summary
The goal of WFQ is to:
n Perform queuing on a per-flow basis
n Guarantee service to all flows
n Share bandwidth fairly
n Prioritize traffic by giving higher-priority flows proportionately more bandwidth
n Prioritize low-volume (interactive) traffic
Review Questions
n How does WFQ classify packets?
n When does WFQ drop packets?
n How does WFQ schedule packets?

Distributed Weighted Fair Queuing
Objectives
n Describe and configure dWFQ
n Describe and configure ToS-based dWFQ
n Describe and configure QoS-group-based dWFQ
n Monitor and troubleshoot WFQ

Distributed WFQ
• The term “distributed” is primarily used for features

available on Versatile Interface Processors (VIP) on
Cisco 7x00 routers
• Cisco IOS supports the following four versions of
dWFQ:
– Flow-based dWFQ
– ToS-based dWFQ
– QoS-group-based dWFQ
– Distributed Class-based WFQ
• This lesson focuses on the first three versions of
dWFQ
The distributed versions of Weighted Fair Queuing are implemented on Cisco 7x00
series routers with Versatile Interface Processors (VIPs). There are four different
versions of distributed WFQ, three of which are discussed in this module:
n Flow-based dWFQ or simply dWFQ
n ToS-based dWFQ
n QoS-group-based dWFQ or QoS-based dWFQ
VIP is basically a router within a router. It has its own processor and its own
(different) version of the IOS. Most features implemented on VIPs have different
functionality than those available on the Route Switch Processor (RSP).

Flow-based dWFQ
Forwarded Packets
Flow-based dWFQ System
Hardware
Flow 2? WFQ-drop Queue 2 Queuing System
WFQ
• Flow-based dWFQ looks the same as RSP/LE

WFQ, but ...
The structure of Distributed Flow-based WFQ (dWFQ) is similar to that discussed

in the previous lesson.
There are, however, some differences.

Flow-based dWFQ Classification
IP TCP Payload
WFQ Classification uses the
following parameters:
• source IP address
• destination IP address
• source TCP or UDP port
Src. Dst. Proto. Src. Dst. • destination TCP or UDP
Addr. Addr. Port Port port
• transport protocol
A hash algorithm is used to

Hash Algorithm produce the index of the
queue where the packet is
enqueued
#queue (9-bit index of the queue)
• The number of queues is 512 (not tunable)

• ToS is not used for classification (except in IOS version 11.1CC)
Classification identifies flows but it does not use the ToS field. It uses all the other
parameters that identify a flow (conversation):
n Source IP address
n Protocol number (identifying TCP or UDP)
n Source TCP/UDP port number
n Destination TCP/UDP port number
The number of queues is 512 and cannot be changed.

dWFQ Insertion and Drop Policy
• dWFQ drops packets when both the

individual queue limit (IQL) and aggregate
queue limit (AQL) are reached
• dWFQ is not as strict with aggressive flows
as non-distributed WFQ
• This insertion and drop policy is the same for
all three versions of dWFQ (flow-based, ToS-
based and QoS-group-based)
The dropping scheme of dWFQ is similar to that of non-distributed WFQ, except

that it is not as strict with aggressive flows.
The same dropping policy is used for all three versions of dWFQ (Flow-based
dWFQ, ToS-based dWFQ and QoS-group-based dWFQ).

dWFQ Insertion and Drop Policy
No No Enqueue
N-th packet M>QL? N>AQL?
packet
Yes Yes
No
M>IQL?
Yes
• QL (queue limit) is the maximum number of packets the selected que ue can hold
• AQL (aggregate queue limit) is the max. number of packets that the dWFQ system can hold
• IQL (individual queue limit) is the max. number of packets that an individual queue a
congested dWFQ system can hold
• N is the number of packets in the dWFQ system when the N -th packet arrives
• M is the number of packets in the queue to which the packet is cl assified
When a new packet is to be inserted into one of the queues the router follows
these rules:
1. Enqueue the packet if the WFQ system is within the aggregate queue limit
2. Enqueue the packet if the queue is within the individual queue limit
3. Otherwise, drop the packet

Flow-based dWFQ Scheduling
Flow-based dWFQ System Packets are scheduled

(ordered) in advance for
faster transfer to the
Queue 1 hardware queue
Hardware
Queue 2 Queuing System
dWFQ
Scheduler
(Calendar Calendar Queue Hardware Q Interface
Queuing)
Queue N
• Uses Calendar Queuing (optimized version of scheduling based

on finish time, more jitter)
• Weight (IP precedence) is NOT used for scheduling purposes
(pure Fair Queuing)
The scheduler uses the same finish time calculation except it does not include the
weight. It is a pure Fair Queuing mechanism.
The scheduler was also optimized for performance (Calendar Queuing).

Configuring Flow-based dWFQ
Router(config-if)#
fair-queue
fair-queue
• The command enables dWFQ on an interface

connected to a VIP2-40 or newer interface processor
• For all other interfaces, this command enables RSP-
based WFQ
• Can be configured on interfaces but not on
subinterfaces
• dWFQ is not supported on Fast EtherChannel, tunnel,
or other logical or virtual interfaces (MPPP)
Using the fair-queue interface command enables dWFQ if the following

requirements are met:
n Interface is on a VIP2-40 or newer
n Distributed CEF is enabled

Configuring Flow-based dWFQ
Router(config)#
fair-queue aggregate-limit
aggregate-limit aggregate-packets
• The total number of packets in all output queues

before some packets may be dropped
Router(config)#
fair-queue individual-limit individual-packets
• The maximum individual per-flow queue size during

periods of congestion
• Defaults: aggregate-limit depends on the
transmission rate and the available buffer space on
the VIP; individual-limit is half of the aggregate-limit
• Don’t change the defaults unless necessary
Use these two commands to change the default limits that govern the dropping of
packets when individual queues and the WFQ system are congested.

Flow-based dWFQ
Example
interface
interface FastEthernet
FastEthernet 1/1/0
ip
ip address
address 80.0.2.70
80.0.2.70 255.255.255.0
255.255.255.0
fair-queue
fair-queue
fair-queue
aggregate-limit 200
200
fair-queue
fair-queue individual-limit
individual-limit 30
30
!!
• dWFQ on a FastEthernet interface

• dWFQ system should not contain more than
200 packets
• No queue should accept new packets when
the dWFQ system is congested and the
queue is longer than 30 packets
The example illustrates how dWFQ was implemented on a FastEthernet interface.

Show Interface
Router#show
Router#show interfaces
interfaces FastEthernet1/1/0
FastEthernet1/1/0
FastEthernet1/1/0
FastEthernet1/1/0 isis up,
up, line
line protocol
protocol is
is up
up
Hardware
Hardware is
is cyBus
cyBus FastEthernet
FastEthernet Interface,
Interface, address
address is
is 0007.f618.4448
0007.f618.4448
Description:
Description: pkt
pkt input
input i/f
i/f for
for WRL
WRL tests
tests (to
(to pagent)
pagent)
Internet
Internet address
address is
is 80.0.2.70/24
80.0.2.70/24
MTU
MTU 1500
1500 bytes,
bytes, BW
BW 100000
100000 Kbit,
Kbit, DLY
DLY 100
100 usec,
usec, rely
rely 255/255,
255/255, load
load 1/255
1/255
Encapsulation
Encapsulation ARPA,
ARPA, loopback
loopback not
not set,
set, keepalive
keepalive not
not set,
set, 100BaseTX/FX
100BaseTX/FX
ARP
ARP type:
type: ARPA,
ARPA, ARP
ARP Timeout
Timeout 04:00:00
04:00:00
Last
Last input
input never,
never, output
output 01:11:01,
01:11:01, output
output hang
hang never
never
Last
Last clearing
clearing of
of "show
"show interface"
interface" counters
counters 01:12:31
01:12:31
Queueing
Queueing strategy:
strategy: VIP-based
VIP-based fair
fair queuing
queuing
Output
Output queue
queue 0/40,
0/40, 00 drops;
drops; input
input queue
queue 0/75,
0/75, 00 drops
drops
30
30 second
second input
input rate
rate 00 bits/sec,
packets/sec
30
30 second
second output
output rate
rate 00 bits/sec,
packets/sec
…… rest
rest deleted
deleted ...
...
The usual show interface command reveals that VIP-based fair queuing is
enabled (dWFQ). Some other show commands used with other queuing
mechanisms do not display any valuable information (RSP regards this interface as
FIFO).

Show Interface Fair-queue
Router#show
interface fastethernet
fastethernet 1/1/0 fair
fair
FastEthernet
FastEthernet 1/1/0
1/1/0 queue size 0
pkts
pkts output
output 0,
0, wfq drops 0, nobuffer
nobuffer drops
drops 0
WFQ:
WFQ: aggregate
aggregate queue
queue limit
limit 200 individual
individual queue
queue limit
limit 30
max available buffers 0
• Displays dWFQ statistics
This command can be used to display some statistics about dWFQ.

Benefits and Drawbacks of Flow-
based dWFQ
+ Benefits
• Automatic classification
• High performance
– Drawbacks
• Does not use IP precedence as weight
• Only supported on Cisco 7x00 series routers with
VIP 2-40 or newer
The distributed version of WFQ has one advantage over normal WFQ: better
performance.
The main drawbacks include:
n Lack of tuning capability
n Not weighted
n Only supported on VIPs

ToS-based dWFQ
Forwarded Packets
ToS -based dWFQ System
Class 1? WFQ-drop Queue 1
Hardware
Class 2? WFQ-drop Queue 2 Queuing System
dWFQ
• ToS-based dWFQ has four classes

The ToS-based dWFQ differs from Flow-based dWFQ in the following ways:
n Classification is done based on the two low-order IP precedence bits
n Scheduling is configurable by setting weights manually
n Four queues are used

ToS-based dWFQ Classification
IP Payload
ToS -based dWFQ
IP Classification uses the two
Prec. low -order IP precedence bits
to classify packets
XXX 00000
IP precedence
Queue 1 0 and 4
#queue
(2-bit index of Queue 2 1 and 5
the queue)
Queue 3 2 and 6
Queue 4 3 and 7
• The number of queues is 4 (fixed)

• Classification is based on the two low-order IP
precedence bits
The classification uses the two low-order IP precedence bits. The result of
classification is that:
n Packets with IP precedence values 0 and 4 are classified into Queue 0

ToS-based dWFQ Scheduling
• One weight per class configured as a %

–Sum of all weights must be =< 99
–Some bandwidth needed for Class 0
• Tail-Drop within each queue
• First release: 11.1cc, 12.0
Weights that determine how much bandwidth is guaranteed to each class are
configured in percentage points.
Weights can be assigned to Queues 1¸ 2 and 3. Queue 0 gets the rest of the
bandwidth.

Configuring ToS-based dWFQ
fair-queue tos
• Enables ToS-based distributed WFQ
fair-queue tos num
num weight weight
weight
tos number - 2 low order precedence bits (only classes 1, 2 and 3 can be configured
with weight; class 0 takes the remaining bandwidth)
weight - percentage of the output link bandwidth allocated to this class (the sum for all
classes cannot exceed 99)
Defaults:
unclassified traffic is assigned to class 0;
class 1 - 20, class 2 - 30, class 3 - 40
class 0 has the remaining weight (100%-W1-W2-W3); default 10
ToS-based dWFQ is enabled using the fair-queue tos interface command.
Note Distributed CEF has to be enabled prior to using this command.

Configuring ToS-based dWFQ
Router(config-if)#
fair-queue tos
tos num limit class-packets
• Configures maximum number of packets allowed in the selected queue
• If not configured, the default is individual-limit
• If queue limit is not configured it is set to the number of available buffers
multiplited by weight
Router(config-if)#
fair-queue
fair-queue individual-limit
individual-limit individual-packet
individual-packet
• If individual limit is not configured it is set to one quarter of the

number of available buffers
Router(config-if)#
fair-queue aggregate-limit aggregate-packets
• If aggregate limit is not configured is set to the number of availble

buffers
These three optional commands can be used to control individual queue sizes.
The default behavior is:
n Aggregate queue limit equals maximum available buffers
n Individual queue limit equals one quarter of maximum available buffers
n Per-queue limit equals maximum available buffers multiplied by weight

ToS-based WFQ
Configuration Example
interface
interface Hssi0/0/0
Hssi0/0/0
ip address 188.1.3.70 255.255.255.0
fair-queue tos
tos
fair-queue tos
tos 1 weight
weight 20
fair-queue tos
tos 1 limit 27
fair-queue tos
tos 2 weight
weight 30
fair-queue tos
tos 2 limit 27
fair-queue tos
tos 3 weight
weight 40
fair-queue tos
tos 3 limit 27
!!
The example shows how ToS-based dWFQ is configured on VIP-based

interfaces.

Show Interface Fair-queue
Router#show interfaces fair-queue

fair-queue
Hssi0/0/0
Hssi0/0/0 queue
queue size
size 00
pkts
pkts output
output 947,
947, wfq
wfq drops
drops 0, nobuffer drops 0
WFQ:
WFQ: aggregate
aggregate queue
queue limit
limit 386
386 individual
individual queue
queue limit
limit 96
96
max available
available buffers
buffers 386
386
Class
Class 0:
0: weight
weight 10
10 limit
limit 20 qsize
qsize 00 pkts
pkts output
output 947
947 drops
drops 00
Class
Class 1:
1: weight
weight 20
20 limit
limit 27 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
Class
Class 2:
2: weight
weight 30
30 limit
limit 27 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
Class
Class 3:
3: weight
weight 40
40 limit
limit 27 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
The show interface fair-queue command can be issued to display parameters

and statistics for VIP-based interfaces.

Benefits and Drawbacks of ToS-
based dWFQ
+ Benefits
• Automatic classification
• Guarantees throughput to all classes
– Drawbacks
• Only four classes are supported
• Unusual interpretation of IP precedence (high-priority packets
with IP precedence 6 and 7 share queues with lower-priority
packets with IP precedence 2 and 3)
• Only supported on Cisco 7x00 series routers with VIP 2-40 or
newer
The ToS-based dWFQ represents the first class-oriented queuing mechanism

available on VIPs. The main drawbacks of this queuing mechanism are that it:
n Supports only four classes
n Mixes packets of different IP precedence values

QoS-group-based dWFQ
Forwarded Packets
QoS-group-based dWFQ System
Hardware
Class 2? WFQ-drop Queue 2 Queuing System
dWFQ
• QoS-group-based dWFQ supports 100

classes
QoS-group-based dWFQ was introduced to provide a solution to ToS-based dWFQ

drawbacks:
n 4 classes are upgraded to 100 classes
n Classification is more flexible (any other parameter can be translated into the
QoS group number)

Classification
Packet Buffer Frame IP

Payload
Buffer Header Header Header
QoS
group
• The number of queues is 100

• Classification is based on the QoS group parameter
• The parameter is local to the router and it has to be set by some
other QoS mechanism:
– Policy-based Routing (PBR)
– QoS Policy Propagation through BGP (QPPB)
– Class-based Marking
Classification is performed using the QoS group parameter to select one of the 100
queues. The QoS group parameter is local to the router so it has to be set on every
hop using one of the QoS mechanisms that supports marking:
n QoS Policy Propagation through BGP(QPPB)
n Committed Access Rate (CAR)
n Class-based Policing
n Class-based Marking

Scheduling
• Scheduling is identical to that of ToS-based

dWFQ
• One weight per class configured as a %
–Sum of all weights must be =< 99
–Some bandwidth needed for Class 0
• Tail-Drop within each queue
Scheduling and configuration of scheduling and dropping is identical to that of ToS-

based dWFQ. The only difference is that there are up to 100 queues to configure.

Configuring QoS-group-based
dWFQ
fair-queue qos-group
qos-group
• Enables ToS-based distributed WFQ
qos-group num weight weight
qos-group number - classes 1 through 99 can be configured with weight; class 0 takes
the remaining bandwidth
weight - percentage of the output link bandwidth allocated to this class (the sum for all
classes cannot exceed 99)
Defaults:
unclassified traffic is assigned to class 0;
class 1 - 20, class 2 - 30, class 3 - 40
class 0 has the remaining weight (100%-W1-W2-W3); default 10
Replacing ToS-based dWFQ involves using only the fair-queue qos-group

interface command. All existing fair-queue tos commands are replaced with
fair-queue qos-group commands.
Note Replacing ToS-based dWFQ with QoS-group-based dWFQ causes all packets
to go into Queue 0 because classification is no longer perform ed based on IP
precedence value. Some additional configuration steps are necessary.

Configuring QoS-group-based
dWFQ
qos-group num limit class-packets
• Configures individual queue depth

– class-packets - maximum number of packets allowed in the
queue for the class during periods of congestion
• If not configured, the default is individual-limit, which
is half of the aggregate queue limit
fair-queue
fair-queue aggregate-limit aggregate-packets
aggregate-packets
fair-queue
fair-queue individual-limit individual-packet
These commands have the same meaning as with ToS-based dWFQ.

QoS-group-based dWFQ Example
• QoS-group-based dWFQ can be used to

implement mapping of different parameters
into QoS group:
– Assume another mechanism has been configured
to translate QoS class information into QoS group
(e.g. QPPB)
– Use QoS-group-based dWFQ output queuing
• Example:
– allocate 10% to class 1 traffic
allocate 30% to class 2 traffic
allocate 60% to other traffic
The case study involves using three queues.

Classification and marking is performed using QPPB where the QoS group is set
based on some BGP information (for example, BGP community attribute).

QoS-group based WFQ
Configuration Example
interface
interface FastEthernet1/0/0
FastEthernet1/0/0
bgp-policy
bgp-policy destination
destination ip-qos-map
ip-qos-map
!!
...
...
!!
interface
interface Hssi0/0/0
Hssi0/0/0
ip
ip address
address 188.1.3.70
188.1.3.70 255.255.255.0
255.255.255.0
bgp-policy
bgp-policy destination
destination ip-prec-map
ip-prec-map
fair-queue
qos-group
fair-queue
aggregate-limit 60
fair-queue
qos-group 1 weight
weight 10
fair-queue
qos-group 2 weight
weight 30
fair-queue
qos-group 2 limit
limit 27
27
!!

Monitoring QoS-group-based
dWFQ
Router#show
Router#show interfaces
interfaces fair-queue
fair-queue
Hssi0/0/0
Hssi0/0/0 queue
queue size
size 00
pkts
pkts output
output 4,
4, wfq
wfq drops
drops 0,
0, nobuffer
nobuffer drops
drops 00
WFQ:
WFQ: aggregate
aggregate queue
queue limit
limit 60
60 individual
individual queue
queue limit
limit 96
96
max
max available
available buffers
buffers 386
386
Class
Class 0:
0: weight
weight 60
60 limit
limit 231
231 qsize
qsize 00 pkts
pkts output
output 44 drops
drops 00
Class
Class 1:
1: weight
weight 10
10 limit
limit 38
38 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
Class
Class 2:
2: weight
weight 30
30 limit
limit 27
27 qsize
qsize 00 pkts
pkts output
output 00 drops
drops 00
The show interface fair-queue command only displays information for queues
with a weight higher than zero.

Benefits and Drawbacks of QoS-
group-based dWFQ
+ Benefits
• Guarantees throughput to all classes
• A large number of classes (100)
– Drawbacks
• Requires other QoS mechanisms to set QoS group
• Only supported on Cisco 7x00 series routers with
VIP 2-40 or newer
QoS-group-based dWFQ is the first high-performance class-oriented queuing

mechanism. Its main drawback is that it is only available on Cisco 7x00 series
routers with VIPs.

dWFQ Summary
Classification Classes Weighted Implementation

Fairnes
WFQ Per-flow 16 to 4096 Yes (IP RSP/LE

precedence)
dWFQ Per-flow 512 No VIP
IP
ToS dWFQ precedence 4 Manual VIP
QoS dWFQ QoS group 100 Manual VIP
CB-WFQ* Manual 64 Manual RSP/LE/VIP
* Class-based WFQ is covered in the “Modular QoS CLI” module
The figure illustrates the comparison of all versions of Weighted Fair Queuing.
n Traditional WFQ is only available on low-end (LE) routers and the Route
Switch Processor (RSP) of Cisco 7x00 series routers
n All three distributed versions are only available on VIP-based interfaces of
Cisco 7x00 series routers
Class-based WFQ is now available on low-end routers, the RSP and on the VIP
(distributed)

Summary
There are five versions of WFQ:
n Flow-based WFQ (non-distributed, per-flow queuing)
n Flow-based dWFQ (not weighted, per-flow queuing, fixed number of queues)
n ToS-based dWFQ (four queues, limited classification options)
n QoS-group-based dWFQ (up to 100 queues, requires marking on every hop)
n CB-WFQ
Review Questions
n Which distributed Weighted Fair Queuing mechanisms do you know?
n What are the main differences between dWFQ versions?
n What platforms support dWFQ?

Modified Deficit Round-robin
Objectives
n Describe MDRR queuing
n Describe the benefits and drawbacks of MDRR queuing
n Configure MDRR queuing on Cisco GSR routers
n Monitor and troubleshoot MDRR

Modified Deficit Round Robin
• Deficit Round Robin (DRR) is a class-based

queuing mechanism available on Cisco GSR
routers
• MDRR supports 8 classes
• Low-latency queuing is introduced in the
Modified Deficit Round Robin (MDRR)
Modified Deficit Round-robin (MDRR) is a class-oriented queuing mechanism

available on Cisco 12000 series routers (GSR).
It supports eight classes, one of which can be used for low-delay propagation.

MDRR Architecture
Forwarded Packets
Modified Deficit Round Robin
Tail -drop
Class 1? VOQ 1
WRED
Hardware
Tail -drop
Class 2? VOQ 2 Queuing System
WRED
or
MDRR
Crossbar Interface
Scheduler
Switching Fabric
Tail -drop
Class 8? VOQ 8
WRED
• MDRR supports 8 classes (8 RR queues, one can be high-priority)

• MDRR is implemented on the receive side (in front of the Crossbar
Switching Matrix) and on the transmit side (in front of an interface)
MDRR classifies packets based on IP precedence value. Each queue can be

configured to support WRED.
MDRR can be implemented on output to interfaces (as in all other queuing
mechanisms) or in front of the GSR’s Crossbar Switching Matrix.

MDRR Features
• Deficit Round Robin (DRR) is using eight Virtual

Output Queues (VOQ) to prevent head-of-line
blocking
• DRR can use Weighted Random Early Detection
(WRED) within each class to prevent congestion
within the class
• Modified DRR (MDRR) can have one high priority
queue for delay-sensitive traffic being serviced in
either of the two supported modes:
– Strict priority
– Alternate priority
DRR was the first implementation that was later improved by allowing one queue
to be high priority.

MDRR Classification
IP
precedence
0
VOQ 0
IP
precedence VOQ 1
1
VOQ 2
IP VOQ 7
precedence
7
• MDRR supports classification of any IP precedence into any of the

8 virtual output queues
• One of the 8 queues can be used as low-latency queue
Classification is done using IP precedence to put packets into one of the eight
Virtual Output Queues (VOQ). One of these queues can be configured as high
priority.

MDRR Insertion and Drop Policy
Tail-drop
or Virtual Output Queue
WRED
• MDRR uses a traditional tail-drop scheme if a

queue is congested
• MDRR can also use Weighted Random Early
Detection (WRED) to prevent congestion
Each queue uses the tail-drop scheme unless it is configured with WRED.

DRR Scheduling
Each queue can transmit a configured

amount of bytes in one round:
MTU + (weight-1)*512
VOQ 0
Round
VOQ 1
Robin
Scheduler
VOQ 7
• Service policy for one queue in one round:

1. Add MTU+(Weight-1)*512 tokens to the token bucket.
2. Transmit packets until tokens are used up or the queue is empty.
3. Reset the token bucket to 0 if the queue is empty. Otherwise
remember the deficit (how much more tokens were used than
available).
4. Start serving the next queue.
The scheduling of DRR is similar to that of Custom Queuing, except it is more

accurate. DRR remembers the number of bytes it sent above the threshold in the
previous round (deficit).

MDRR Scheduling with
Strict Priority Queue
Str The Strict Priority Low-latency Queue
LL Queue ict is not limitted by the Token Bucket
Qu Priori
eui t mechanism
ng y
VOQ 0
Round
VOQ 1
Robin
Scheduler
VOQ 7
• Service policy for MDRR with Strict Priority:

1. Transmit packets from the Strict Priority Low-latency Queue until the
queue is empty.
2. Serve the next-in-line round robin queue.
3. Start serving the Low-latency queue again.
MDRR can schedule one queue ahead of all the others if it is configured as a Strict
Priority queue. This queue can be used for delay-sensitive applications (for
example, voice).
The problem of this solution is that it can cause other queues to starve if the high
priority queue is congested.

MDRR Scheduling with
Alternate Priority Queue
Alt The Alternate Priority Queue is using
LL Queue er the Token Bucket to limit the amount
Pr nate
Qu iority of bytes it can transmit in one round
eui
VOQ 0 ng
Round
VOQ 1
Robin
Scheduler
VOQ 7
• Service policy for MDRR with Alternate Priority:

1. Transmit packets from the Alternate Priority Low-latency Queue until
the tokens are used up or the queue is empty.
2. Serve the next-in-line round robin queue
3. Start serving the Low-latency queue again.
The high priority queue can be set to Alternate Priority mode where all other
queues still get service, even if the high-priority queue is congested.
The high priority queue, however, experiences slightly more delay because it has to
wait for the currently served queue to reach its threshold or be emptied.

Benefits and Drawbacks of MDRR
+ Benefits
• Accurate bandwidth allocation (takes into account the deficit
from the previous round as opposed to Custom Queuing)
• Prevents head-of-line blocking in front of the crossbar
switching fabric
• Supports low-latency queuing (strict priority and alternate
priority)
– Drawbacks
• Limited classification tools (only IP precedence)
• Limited number of classes (only 8)
• Only supported on Cisco 12000 series routers (GSR)
MDRR is a high performance queuing mechanism that supports eight classes and
allocates bandwidth according to configured weights. It also supports one queue
for low-delay propagation of packets.

Configuring Interface MDRR
Router(config)#
cos-queue-group cos-queue-group-name
cos-queue-group-name
• Create a queue group template and enter COS queue group

configuration mode
Router(config-cos-que)#
precedence precedence queue {queue-number|low-latency}
{queue-number|low-latency}
• Map IP precedence to a queue
queue queue-number weight
• Set weight of a queue
Configuration of MDRR requires a cos-queue -group to be configured first. All

MDRR configuration is performed in the cos-queue -group configuration mode.
The first step is to map an IP precedence value to one of the eight queues. Each
queue can be configured with a weight that determines the number of bytes that
can be transmitted in one round.

Configuring Interface MDRR
queue low-latency {alternate-priority weight|strict-priority}
• Specify the type of low-latency queue
Router(config-if)#
tx-cos cos-queue-group-name
• Associate a COS queue group name with the transmit queues

on an interface
One of the queues can be turned into a high priority queue. The type of queue is
determined by the alternate-priority or strict-priority keywords.
The last step is to apply the cos-queue-group to an output interface.

Configuring Receive MDRR
Router(config)#
slot-table-cos slot-table-name
• Define a slot table name and enter slot table configuration mode
Router(config-slot-cos)#
destination slot
slot {slot-number|all}
{slot-number|all} cos-queue-group-name
• Define destination slot parameters for this slot table name
Router(config)#
rx-cos-slot line-card-number cos-queue-group-name
• Link a slot-table-cos template to a line card
MDRR can also be applied to traffic leaving the line card through the Crossbar
Switching Matrix.
A slot-table -cos has to be configured where the destination line cards are
specified using the destination slot command.
The slot table is then applied to one or more line cards using the rx-cos-slot
command.

MDRR Example
interface
interface POS3/0
POS3/0
ip address 1.0.0.1 255.0.0.0
tx-cos
tx-cos C4template
C4template
!!
cos-queue-group
cos-queue-group C4template
precedence 0 queue 0
precedence 5 queue low-latency
queue 0 10
10
queue 1 20
20
queue 2 40
40
queue
queue low-latency
low-latency alternate-priority
alternate-priority 80
80
exit
exit
!!
The example illustrates a sample configuration of MDRR applied to traffic leaving

the POS interface.

MDRR
Router#
show cos statistics
• Display MDRR statistics
Router#show
Router#show cos statistics
Slot
Slot 33
---------------
---------------
Dest
Dest slot
slot 55
cos-queue-group:
cos-queue-group: C7template
C7template
...
...
Queue
Queue Lengths
Lengths
To
To Fabric
Fabric Queues
Queues (DRR
(DRR configured)
configured) C7template
Queue
Queue Average
Average High
High Water
Water Mark
Mark Weight
Weight
00 712.000
712.000 5562.000
5562.000 10
10
11 702.000
702.000 7716.000
7716.000 10
10
22 702.000
702.000 11540.000
11540.000 10
10
33 753.000
753.000 14368.000
14368.000 10
10
44 0.000
0.000 0.000
0.000 10
10
55 0.000
0.000 0.000
0.000 10
10
66 0.000
0.000 0.000
0.000 10
10
Low latency
Low latency 0.000
0.000 0.000
0.000 10
10
...
...
The show cos statistics can be used to display results of MDRR.

Summary
MDRR is a class-oriented queuing mechanism available on the Cisco 1200 series
routers. It allows bandwidth guarantees to eight classes and low-delay propagation
to one class.
MDRR can be applied to outbound traffic or traffic leaving a line card through the
Crossbar Switching Matrix.
Review Questions
n Describe the scheduling mechanism of MDRR.
n Which two types of low-latency queuing does MDRR support?
n What are the benefits and drawbacks of MDRR?
n Where can MDRR be applied?

Objectives
n Describe IP RTP prioritization
n Describe the benefits and drawbacks of IP RTP prioritization
n Configure IP RTP prioritization on Cisco routers
n Monitor and troubleshoot IP RTP Prioritization

• IP RTP Prioritization provides low-latency

queuing when used in combination with WFQ
or CB-WFQ
• It can only be used with UDP traffic with
predictable port numbers
• It is usually used for VoIP traffic
• IP RTP Prioritization is limited to prevent
starvation of other traffic
IP RTP Prioritization is an add-on to WFQ to support low-delay propagation of

packets. It can be used for UDP traffic only.
IP RTP Prioritization also polices the high priority traffic to prevent starvation of
other queues.

Forwarded Packets
High
Priority?
Weighted Fair Queuing System

Hardware
Queuing System
RTP
Flow 2? WFQ-drop Queue 2 Hardware Q Interface
WFQ
Scheduler
Scheduler
• IP RTP prioritization adds one high-priority

queue to WFQ
IP RTP Prioritization supports one high priority queue. Packets from this queue are
scheduled ahead of other packets as long as they are within the configured rate.
Excess packets are dropped.

IP RTP Priority Classification
Forwarded Packets
IP UDP Payload
UDP
Destination port
UDP port Yes

RTP Queue
In range?
No WFQ
Queuing
System
• IP RTP Prioritization classifies packets based

on the UDP port number
• Classification is specified by a range of UDP
port numbers
IP RTP Prioritization classifies packets based on UDP port numbers.

If the destination UDP port is within the configured range it is enqueued into the
high priority queue.

IP RTP Priority Insertion and Drop
Policy
Classified Packets
Packet
Token Yes
within RTP Queue
Bucket Contract?
No
• IP RTP Prioritization limits the amount of

high-priority traffic
• Excess traffic is dropped
Packets that exceed the policy are dropped. A token Bucket model is used to
measure the arrival rate of packets into this queue.

Benefits and Drawbacks of IP RTP
Prioritization
+ Benefits
• Adds low-latency queuing to WFQ and CB-
WFQ
• Prevents starvation of other traffic
– Drawbacks
• Poor classification options
• Obsoleted by Class-based Low-latency
Queuing
The main benefit of IP RTP Prioritization is that it allows low-latency propagation

when using WFQ.
The main drawback is that it has limited classification capabilities (UDP port range
only).
IP RTP Prioritization was made obsolete by the introduction of Class-based Low
Latency Queuing (discussed in the “IP QoS - Modular QoS CLI” module).

Configuring IP RTP Prioritization
Router(config-if)#
ip rtp priority
priority starting-port port-range
port-range bandwidth
bandwidth
• Creates a separate priority queue for VoIP packets and specifies

maximum bandwidth available to voice traffic
• Maximum bandwidth shall always be slightly larger than actually
required bandwidth due to jitter in the network and the Layer-2
overhead
• Only UDP packets with a destination port number in the configured
range are classified into this queue
Router(config-if)#
max-reserved-bandwidth percent
• Specifies the maximum bandwidth percentage that can be allocated

to class-based WFQ and priority RTP traffic
• The remaining bandwidth is available to flow-classified best-effort
traffic and control packets
• Default: 75% of the interface bandwidth can be reserved
Configuration of IP RTP Prioritization requires using the ip rtp priority command

where the following parameters have to be specified:
n Starting UDP port number
n UDP port range (added to the starting port number)
n Maximum and guaranteed bandwidth
If the requested bandwidth is less than 75% of the bandwidth configured on the
interface, the command will fail. Reservable bandwidth can be increased by using
the max-reserved-bandwidth interface command.

Example
interface
interface Serial0/0
Serial0/0
bandwidth
bandwidth 128
ip
ip address
address 10.0.0.1
10.0.0.1 255.255.255.252
encapsulation ppp
ppp
fair-queue
fair-queue Up to 75% of configured bandwidth is
ip
ip rtp priority 16384 16383 50
50 reservable.
!!
BWavail = BW * 0.75 - BWRTP
Router#show
Router#show queue
queue serial0/0
serial0/0
Input
Input queue:
queue: 0/75/0/0
0/75/0/0 (size/max/drops/flushes);
(size/max/drops/flushes); Total
Total output
output dr
drops:
ops: 00
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Output
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations
0/1/256 (active/max
active/max total)
total)
Reserved
Conversations 0/0
0/0 (allocated/max
allocated)
Available
Available Bandwidth
Bandwidth 46
46 kilobits/sec
kilobits/sec
Router#
Router#
The sample configuration shows how 50 kbps of bandwidth is guaranteed for RTP
traffic. The show queue command shows there is only 46 kbps of bandwidth (128
kbps • 75% -50 kbps = 46 kbps) remaining for WFQ.

Summary
IP RTP Prioritization adds low-latency queuing capability to WFQ. It can only
classify packets into one queue based on the UDP port range.
Review Questions
n When would you use IP RTP prioritization?
n What are the drawbacks of IP RTP prioritization?
n How many high-priority queues does IP RTP prioritization support?

Summary
n Describe and configure FIFO Queuing (FQ)
n Describe and configure Priority Queuing (PQ)
n Describe and configure Custom Queuing (CQ)
n Describe and configure basic Weighted Fair Queuing (WFQ), distributed WFQ,
ToS-based distributed WFQ and QoS-group-based distributed WFQ
n Describe and configure Modified Weighted Round-robin (MDRR) queuing
n Describe and configure IP RTP Prioritization

Queuing Overview
Question: Which queuing mechanisms do Cisco routers support?
Answer: First In First Out (FIFO), Priority Queuing (PQ), Custom Queuing
(CQ), Weighted Fair Queuing (WFQ) with the different distributed versions,
Modified Deficit Round Robin (MDRR), IP RTP Prioritization, Class-based
WFQ and Class-based Low-latency Queuing.
Question: When is a software queuing mechanisms not used?
Answer: Routers bypass the software queue (hold queue) if it is empty and there
is room in the hardware queue (TxQ).
Question: How does TxQ length affect the software queuing system?
Answer: A long TxQ can cause FIFO drawbacks; a short TxQ can cause high
CPU utilization and low link utilization.
FIFO Queuing
Question: Why is FIFO the fastest queuing mechanism?
Answer: It has no classification and the simplest scheduling mechanism.
Question: Describe the classification and scheduling of FIFO queuing.
Answer: FIFO has only one queue and all packets are enqueued into this queue.
Scheduling takes packets out of the queue in the order they arrived (first come
first serve).
Question: List the drawbacks of FIFO queuing.
Answer: FIFO queuing can cause starvation and jitter.
Priority Queuing
Question: When would you use priority queuing?
Answer: To provide minimum-delay forwarding for delay-sensitive packets.
Question: What are the benefits and drawbacks of priority queuing?
Answer: PQ has all the drawbacks of FIFO queuing within each class and in
addition it can cause starvation of lower-priority classes.
Question: How many classes does priority queuing support?
Answer: PQ supports four classes.
Question: How does priority queuing schedule packets?

Answer: PQ schedules packets in the priority order. Lower-priority packets are
scheduled only when all higher-priority queues are empty.
Custom Queuing
Question: When would you use custom queuing?
Answer: CQ is used to guarantee bandwidth to traffic classes.
Question: What are the benefits and drawbacks of custom queuing?
Answer: CQ has all the drawbacks of FIFO queuing within each class. In
addition CQ can cause jitter due to the implementation of scheduling.
Question: How many classes does custom queuing support?
Answer: CQ supports up to 16 classes.
Question: How does custom queuing schedule packets?
Answer: CQ uses weighted round robin scheduling to ensure that each class is
serviced.

Question: How does WFQ classify packets?
Answer: WFQ classifies packets based on the flow information (source and
destination IP addresses and TCP/UDP port numbers, protocol identifier and
ToS field).
Question: When does WFQ drop packets?
Answer: WFQ drops packets of the longest queue when the number of packets
in the queuing system reaches the CDT (congestive discard threshold).
Question: How does WFQ schedule packets?
Answer: WFQ schedules packets with the shortest finish time.
Distributed Weighted Fair Queuing

Question: Which distributed Weighted Fair Queuing mechanisms do you know?
Answer: Distributed WFQ versions: flow-based, ToS-based and QoS-group-
based.
Question: What are the main differences between dWFQ versions?
Answer: Distributed versions of WFQ differ primarily in the classification.
Question: What platforms support dWFQ?
Answer: Cisco 7x00 series routers with VIP-based interfaces support dWFQ.

Modified Deficit Round-robin
Question: Describe the scheduling mechanism of MDRR.
Answer: MDRR uses an improved implementation of round robin scheduling to
provide more accurate allocation of bandwidth.
Question: Which two types of low-latency queuing does MDRR support?
Answer: MDRR can use one queue for strict priority or alternate priority queuing.
Question: What are the benefits and drawbacks of MDRR?
Answer: MDRR is fast accurate and prevents head-of-line blocking in front of the
crossbar switching matrix. MDRR only supports 8 queues and can only classify
based on IP precedence.
Question: Where can MDRR be applied?
Answer: MDRR can be used on output interfaces or in front of the crossbar
switching matrix.
Question: When would you use IP RTP prioritization?
Answer: To provide low-latency queuing with IOS versions that do not support
CB-LLQ.
Question: What are the drawbacks of IP RTP prioritization?
Answer: Limited classification options (only one UDP port range is supported).
Question: How many high-priority queues does IP RTP prioritization support?
Answer: One per interface.

4
Traffic Shaping and

Policing
Overview
This module describes for the QoS mechanisms that are used to limit the available
bandwidth to traffic classes. It discusses two options—traffic policing and traffic
shaping. Committed Access Rate (CAR) is discussed as a mechanism to provide
traffic policing. Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping
(FRTS) are discussed as traffic shaping mechanisms.
n Traffic Shaping and Policing
n Generic Traffic Shaping
n Frame Relay Traffic Shaping
n Committed Access Rate
Objectives
n Describe and configure Generic Traffic Shaping (GTS)
n Describe and configure Frame Relay Traffic Shaping (FRTS)
n Describe and configure Committed Access Rate (CAR)
n Identify other mechanisms that support traffic shaping and policing (Class-
based Policing and Class-based Shaping)
Traffic Shaping and Policing
Overview
The lesson introduces mechanisms for traffic policing and traffic shaping.
Committed Access Rate (CAR), Generic Traffic Shaping (GTS) and Frame Relay
Traffic Shaping (FRTS) are introduced in this section.
Objectives
n Describe the need for implementing traffic policing and shaping mechanisms
n List traffic policing and shaping mechanisms available in Cisco IOS
n Describe the benefits and drawbacks of traffic shaping and policing
mechanisms
4-2 IP QoS Traffic Shaping and Policing Copyright  2001, Cisco Systems, Inc.
Meter

Traffic
stream
• Traffic Shaping and Policing mechanisms are used to rate-limit

traffic classes
• They have to be able to classify packets and meter their rate of
arrival
• Traffic Shaping delays excess packets to stay within the rate
limit
• Traffic Policing typically drops excess traffic to stay within the
limit; alternatively it can remark excess traffic
© 2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing-5
Both shaping and policing mechanisms are used in a network to control the rate at
which traffic is admitted into the network. Both mechanisms use classification, so
they can differentiate traffic. They also use metering to measure the rate of traffic
and compare it to the configured shaping or policing polic y.
The difference between shaping and policing can be described in terms of their
rate-limiting implementation:
n Shaping meters the traffic rate and delays excessive traffic so that it stays
within the desired rate limit. With shaping, traffic bursts are smoothed out
producing a steadier flow of data. Reducing traffic bursts helps reduce
congestion in the core of the network.
n Policing drops excess traffic in order to control traffic flow within specified
limits. Policing does not introduce any delay to traffic that conforms to traffic
policies. It can however, cause more TCP retransmissions, because traffic in
excess of specified limits is dropped.
Copyright  2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing 4-3
Why Use Rate Limiting
• To handle congestion at ingress to ATM/FR

network with asymmetric link bandwidths
• To limit access to resources when high-
speed access is used but not desired
• To limit certain applications or classes
• To implement a virtual TDM system
Rate limiting is typically used to satisfy one of the following requirements:

n Prevent and manage congestion in ATM and Frame Relay networks, where
asymmetric bandwidths are used along the traffic path. This prevents the
layer-2 network from dropping large amounts of traffic by differentiately
dropping excess traffic at ingress to the ATM or Frame Relay networks based
on Layer-3 information (for example: IP precedence, DSCP, access list,
protocol type, etc.)
n Limit the access rate on an interface when high-speed physical infrastructure
is used in transport, but sub-rate access is desired.
n Engineer bandwidth so that traffic rates to certain applications or classes of
traffic follow a specified traffic -rate policy.
n Implement a virtual TDM system, where an IP network is used, but has the
bandwidth characteristics of a TDM system (that is, fixed maximum available
bandwidth). Inbound and outbound policing can, for example, be used on one
router to split a single point-to-point link into two or more virtual point-to-point
links by assigning a portion of the bandwidth to each class, thus preventing any
class from monopolizing the link in either direction.
Typical Traffic Shaping or
Policing Applications
High-speed Low-speed
link link
WAN
Output interface is Congestion in WAN

not congested network results in
queuing and WRED non-intelligent layer-
do not work 2 drops
256 kbps Implementing a

Limiting access to virtual TDM or
resources Leased line over a
FastEthernet
64 kbps single physical link
on one side
128 kbps
Server
Farm Internet
The figure shows three possible applications of rate-limiting (shaping or policing)

mechanisms. The first picture shows a Layer-2 WAN with unequal link
bandwidths along a Layer-3 path. The ingress (left side) of the network has a high-
speed link available into the Layer-2 backbone, which enables it to send traffic at a
high rate. At the egress side, the sent traffic hits a low-speed link, and the Layer-2
network is forced to drop a large amount of traffic. If traffic were rate-limited at
the ingress, optimal traffic flow occurs, resulting in minimal dropping by the Layer-
2 network.
The second picture shows a hosting farm, which is accessible from the Internet via
a shared link. Depending on the service contract, the hosting provider may offer
different bandwidth guarantees to customers, and may want to limit the resources
a particular server uses. Rate limiting can be used to divide the shared resource
(upstream link) between many servers.
The third example shows the option of implementing virtual leased lines over a
Layer-3 infrastructure, where rate-limited reserved bandwidth is available over a
shared link.
Shaping vs. Policing
• Benefits of Shaping
– Shaping does not drop packets
– Shaping supports interaction with Frame Relay
congestion indication
• Benefits of Policing
– Policing supports marking
– Less buffer usage (shaping requires an additional
queuing system)
A shaper typically delays excess traffic using a buffer, or mechanism, to hold

packets and shape the flow when the data rate of the source is higher than
expected. Traffic shaping smoothes traffic by storing traffic above the configured
rate in a queue. Therefore, shaping increases buffer utilization on a router, but
causes non-deterministic packet delays. Shaping can also interact with a Frame
Relay network, adapting to indications of Layer-2 congestion in the WAN.
A policer typically:
n Drops non-conforming traffic
n Supports marking of traffic
n Is more efficient in terms of memory utilization (no additional buffering of
packets in needed)
n Does not increase buffer usage
Both policing and shaping ensure that traffic does not exceed a bandwidth limit, but
they have different impacts on the traffic:
n Policing drops packets more often, generally causing more retransmissions of
connection-oriented protocols
n Shaping adds variable delay to traffic, possibly causing jitter
How do Routers Measure Traffic
Rate
Bandwidth
Link bandwidth
Exceeding traffic
Rate limit
Conforming Traffic
Time
• Routers use the Token Bucket mathematical model to keep
track of packet arrival rate
• The Token Bucket model is used whenever a new packet is
processed
• The return value is conform or exceed
In order to perform rate limiting, routers must meter (or measure) traffic rates
through their interfaces. To enforce a rate limit, metered traffic is said to:
n Conform to the rate limit, if the rate of traffic is below or equal to the
configured rate limit
n Exceed the rate limit, if the rate of traffic is above the configured rate limit
The metering is usually performed with an abstract model called a token bucket,
which is used when processing each packet. The token bucket can calculate
whether the current packet conforms or exceeds the configured rate limit on an
interface.
Token Bucket
200
700
500 bytes Conform Action 500 bytes
© 2001, Cisco Systems, Inc. IP QoS Traffic Shaping and Policing -10
The token bucket is a mathematical model used in a device that regulates the data
flow. The mode has two basic components:
n Tokens: where each token represents the permission to send a fixed number of
bits into the network
n The bucket: which has the capacity to hold a specified amount of tokens
Tokens are put into the bucket at a certain rate by the operating system. Each
incoming packet, if forwarded, takes tokens from the bucket, representing the
packet’s size.
If the bucket fills to capacity, newly arriving tokens are discarded. Discarded
tokens are not available to future packets.
If there are not enough tokens in the bucket to send the packet, the regulator may:
n Wait for enough tokens to accumulate in the bucket (traffic shaping)
n Discard the packet (policing)
The figure shows a token bucket, with the current capacity of 700 bytes. When a
500-byte packet arrives at the interface, its size is compared to the bucket capacity
(in bytes). The packet conforms to the rate limit (500 bytes < 700 bytes), and the
packet is forwarded. 500 tokens are taken out of the token bucket leaving 200
tokens for the next packet.
Token Bucket
200
300 bytes Exceed Action
300
byte
s
When the next packet arrives immediately after the first packet, and no new
tokens have been added to the bucket (which is done periodically), the packet
exceeds the rate limit. The packet size is greater than the current capacity of the
bucket, and the exceed action is performed (drop in the case of pure policing, delay
in the case of shaping).
Token Bucket
Be
Link BW
Bc of tokens is added Link
Utilization
every Tc [ms]
Bc Bc Bc Bc Bc Bc Average BW
Tc = Bc / CIR (CIR)
Tc 2*Tc 3*Tc 4*Tc 5*Tc Time
Bc + B e
• Bc is normal burst size (specifies sustained rate)

• Be is excess burst size (specifies length of burst)
Token bucket implementations usually rely on three parameters: CIR, Bc and Be.
CIR is the Committed Information Rate (also called the committed rate, or the
shaped rate). Bc is known as the burst capacity. Be is known as the excess burst
capacity. Tc is an interval constant that represents time. A Bc of tokens are
forwarded without constraint in every Tc interval.
In the token bucket metaphor, tokens are put into the bucket at a certain rate,
which is Bc tokens every Tc seconds. The bucket itself has a specified capacity. If
the bucket fills to capacity (Bc + Be), it will overflow and therefore newly arriving
tokens are discarded. Each token grants permission for a source to send a certain
number of bits into the network. To send a packet, the regulator must remove,
from the bucket, the number of tokens equal in representation to the packet size.
For example, if 8000 bytes worth of tokens are placed in the bucket every 125
milliseconds, the router can steadily transmit 8000 bytes every 125 milliseconds, if
traffic constantly arrives at the router.
If there is no traffic at all, 8000 bytes per 125 milliseconds get accumulated in the
bucket, up to the maximum size (Bc+Be). One second’s accumulation therefore
collects 64000 bytes worth of tokens, which can be transmitted immediately in the
case of a burst. The upper limit, Bc+Be, defines the maximum amount of data,
which can be transmitted in a single burst, at the line rate.
Note Again, note that the token bucket mechanism used for traffic shaping has both a
token bucket and a queue used to delay packets. If the token bucket did not have
a data buffer, it would be a policer. For traffic shaping, packets that arrive that
cannot be sent immediately (because there are not enough tokens in the bucket)
are delayed in the data buffer.
Although token bucket permits burstiness, traffic bursts are bound. This guarantee
is made so that traffic flow will never send faster than the token bucket's capacity.
In the long-term, this means that the transmission rate will not exceed the
established rate at which tokens are placed in the bucket (the committed rate).
Mechanisms
• Shaping Mechanisms:
• Policing Mechanisms:
There are five token-bucket based rate-limiting methods available in Cisco IOS.
Three methods are shaping mechanisms:
n Generic traffic shaping
n Frame Relay traffic shaping
n Class-based shaping
Two methods are policing mechanisms:
n Committed access rate
n Class-based policing
All these methods are discussed next in specific sections.
Summary
n Describe the need for implementing traffic policing and shaping mechanisms
n List traffic policing and shaping mechanisms available in Cisco IOS
n Describe the benefits and drawbacks of traffic shaping and policing
mechanisms
Lesson Review
1. How do shaping and policing mechanisms keep track of the traffic rate?
2. Which shaping mechanisms are available with the Cisco IOS software?
3. Which policing mechanisms are available with the Cisco IOS software?
4. What are the main differences between shaping and policing?
Generic Traffic Shaping
Overview
This lesson describes the Generic Traffic Shaping (GTS) mechanism.
Objectives
n Describe the GTS mechanism
n Describe the benefits and drawbacks of GTS
n Configure GTS on Cisco routers
n Monitor and troubleshoot GTS
Generic Traffic Shaping
Meter
Shaper
Classifier Marker
Dropper
Traffic
stream
• Can shape multiple classes (classification)

• Can measure traffic rate of individual classes
(metering)
• Delays packets of exceeding classes
(shaping)
Generic Traffic Shaping (GTS) shapes traffic by reducing the outbound traffic flow
to avoid congestion. This is achieved by constraining traffic to a particular bit rate
using the token bucket mechanism. GTS is applied on a per-interface basis and can
use access lists to select the traffic to shape. It works with a variety of Layer-2
technologies, including Frame Relay, ATM, Switched Multi-megabit Data Service
(SMDS) and Ethernet.
As shown in the block diagram, GTS performs three basic functions:
n Classification of traffic, so that different traffic classes can have different
policies applied to them
n Metering, using a token-bucket mechanism, to distinguish between conforming
and exceeding traffic
n Shaping, using buffering, to delay exceeding traffic and shape it to the
configured rate limit
GTS Building Blocks
Shaping
Forwarder Classifier Yes No
WFQ
No
No Shaping
Classifier Yes Yes WFQ
No
Yes
Shaping
Classifier Yes No
WFQ
Yes
No
Physical Interface
queue(s)
GTS is implemented as a queuing mechanism, where there are separate WFQ

delay queues implemented for each traffic class. Each WFQ-queue delays packets
until they conform to the rate-limit, and also schedules them according to the WFQ
algorithm. Conforming traffic is then sent to the physical interface.
Arriving packets are first classified into one of the shaping classes. Traffic not
classified into any class is not shaped. Classification can be performed using
access lists.
Once a packet is classified into a shaping class, its size is compared to the amount
of available token in the token bucket of that class. The packet is forwarded to the
main interface queue if there are enough tokens. A number of tokens taken out of
the token bucket is equal to the size of the packet (in bytes).
If, on the other hand, there are not enough tokens to forward the packet, the
packet is buffered in the WFQ system assigned to this shaping class. The router
will then periodically replenish the token bucket and check if there are enough
tokens to forward one or more packets out of the shaping queue. Packets are
scheduled out of the shaping queue according to the WFQ scheduling algorithm.
GTS Overview
• GTS is multiprotocol
• GTS uses WFQ as the shaping queue
• GTS can be implemented in combination with
any queuing mechanisms:
– FIFO Queuing
– Weighted Fair Queuing (WFQ)
• GTS works on output only
The GTS implementation in Cisco IOS supports multiple protocols and works on a
variety of interface types. WFQ is used as the shaping delay queue, providing fair
scheduling within a traffic class. Other queuing strategies (FIFO, PQ, CQ and
WFQ) may be employed after GTS to provide traffic scheduling on the shaped
traffic. Also, GTS only works at the output of an interface.
GTS can be used to shape all outbound traffic on an interface or it can separately
shape multiple classes. Classification is performed using any type of access list
including all non-ip access lists.
GTS Implementation
Dispatches Dispatches Dispatches

packets at packets at line packets at line
configured rate rate rate
Shaping Software Hardware

Queue Queue Queue
(FIFO, PQ,
(WFQ) (FIFO)
CQ, WFQ, ...)
Bypass the software queue

if it is empty and there is
room in the hardware queue
• The software queue may have no function if

the sum of all shaping rates is less than link
bandwidth
Packet flow through GTS is implemented using three queues. The first, the shaping
queue, is WFQ-based and shapes traffic according to the specified rate using a
token bucket model. This queue dispatches packets to the software queue, which
may be configured with other queuing mechanisms (PQ, CQ, WFQ or FIFO). If
the software queue is empty, traffic is forwarded directly to the output hardware
queue.
GTS supports distributed implementation on VIP adapters. This offloads traffic
shaping from the route switch processor (RSP) to the Versatile Interface
Processor (VIP), and constructs all of the queues in VIP packet memory. Only IP
traffic can be shaped with dWFQ. Another requirement is that dCEF switching
must be enabled.
Configuring GTS
Router(config-if)#
traffic-shape rate bit-rate [burst-size [excess-
burst-size]]
• Enables traffic shaping of all outbound

(sub)interface traffic
• In IOS versions prior to 11.2(19) and 12.0(4),
optimum switching is disabled on all interfaces if
traffic shaping is enabled on any interface
To enable traffic shaping for outbound traffic on an interface, use the traffic-
shape rate interface configuration command. Of the parameters to be specified,
bit-rate is the only mandatory one. The burst-size and excess-burst-size are
optional.
Generic traffic shaping can be used in all switching paths. Older Cisco IOS
versions may use slower switching paths when GTS is in effect.
Configuring GTS
Router(config-if)#
burst-size]]
• Bit rate – average traffic rate in bps (equivalent to

Frame Relay CIR)
• Burst size – amount of traffic sent in a measurement
interval in bits (equivalent to Frame Relay Bc)
Default value: 1/8 of bit rate
Bit rate (in bits per second) is configured as the average traffic rate to which the
traffic should be shaped on the output of the interface.
Burst size (in bits) can be configured to allow for varying levels of allowed
burstiness. That is, traffic, which bursts over the average traffic rate, also
conforms if it falls within the burst rate in an interval. By default, this is set to one
eighth of the average traffic rate, which sets the Tc at one eighth of a second. This
parameter is equivalent to the Frame Relay Bc parameter.
Configuring GTS
Router(config-if)#
burst-size]]
• Excess-burst-size - amount of excess traffic that

can be sent during the first burst in bps (equivalent
to Frame Relay Be)
Default value: no excess burst
• Measurement interval (Tc) is computed from bit-rate
and burst -size
Tc smaller than 25 ms is rejected, Tc greater than
125 ms is reduced
The excess-burst-size parameter (in bits), equivalent to the Frame Relay Be

parameter, defines the excess burst of traffic, which can still be sent through the
first noticed burst. By default, there is no excess burst allowed.
The Tc parameter defines the measurement interval, which is used in the operation
of the token bucket. By default, it is directly computed from the bit rate and the
burst size as Bc divided by the average bit rate. To ensure proper operation of
shaping, those parameters are bounded to values between 25 and 125 ms.
Configuring GTS
Router(config-if)#
traffic-shape group access-list bit-rate [burst
[excess-burst]]
• Shapes outbound traffic matched by the specified access list

• Several traffic-shape group commands can be configured on
the same interface
• The “traffic-shape rate“ and “traffic-shape group“ commands
cannot be mixed on the same interface
• Separate token bucket and shaping queue is maintained for
each traffic-shape group command
• Traffic not matching any access list is not shaped
Classification of traffic to be shaped is performed using access lists. To enable

traffic shaping based on a specific access list for outbound traffic on an interface,
use the traffic-shape group interface configuration command. The traffic-shape
group command allows specification of one or more previously defined access
lists to shape traffic on the interface. One traffic-shape group command must be
specified for each access list on the interface.
Cisco IOS uses separate token buckets and shaping queues for each class, as
differentiated by the access list specification. Traffic not matching any access list
bypasses traffic shaping and is immediately sent to the software or hardware
interface queue.
Use the traffic-shape rate command if no classification is needed and shaping
should be applied to all traffic. Remember that the traffic-shape group command
using an IP access list permitting all IP traffic is not equivalent to the traffic-shape
rate command if non-IP traffic is present in the network.
GTS
Example #1
• ISP wants to sell a service in which a

customer may use all of a E1 line for 30
seconds in a burst, but on a long term
average is limited to 256 kbps
• GTS parameters
– bit-rate: 256000 - output rate is 256000 bps
– burst-size: 32000 the number of bits sent in 125
msec
– excess-burst-size: 61440000 = 2048000 * 30
In the first GTS example, an ISP wants to control the amount of traffic injected
into the Frame Relay WAN by the customer. The SP service uses an E1 line as
the access line, limits the customer to 256 Kbps on the average, but also permits
bursts of up to thirty seconds at the E1 line rate.
The parameters are calculated based on the service requirements. CIR (the
average bit rate) is set at the specified average rate, the burst size is set to one
eighth of the CIR (32000 bits), and the excess burst size reflects the allowed thirty-
second burst at full E1 line rate.
The excess burst size was calculated using the following formula:
1. Each second of transmission at line-speed requires 2 Mbits
2. Thirty second burst therefore requires 30 x 2 Mbits
3. The excess burst size is 30 x 2048000 = 61440000
It takes thirty seconds to empty the token bucket. How long does it take to fill it up
again?
The token bucket is emptied at 2Mbps but it is replenished at 256kbps. It takes
eight times as long to fill it as it does to empty it. Every thirty second burst would,
therefore, require a four-minute silence on the line to accumulate tokens.
GTS
Example #1
WAN
Core
Customer
interface
interface ethernet
ethernet0/0
0/0
traffic-shape
traffic-shape rate
rate 256000
256000 32000
32000 61440000
61440000
!!
interface
interface serial1/0
serial 1/0
traffic-shape
traffic-shape rate
rate 256000
256000 32000
32000 61440000
61440000
• Since ISP wants to control the total amount of load

the configuration would be done on both the
inbound and outbound interfaces
The figure shows the router configuration required to implement this service. All
the output traffic is shaped, and the shaping needs to be configured on all customer
edge sites, which will perform admission control using GTS.
GTS
Example #2
WAN
Core
Customer
interface
interface ethernet
ethernet 0/0
0/0
traffic-shape
traffic-shape group
group 101
101 64000
64000
interface
interface serial
serial 1/0
1/0
traffic-shape
traffic-shape group
group 101
101 64000
64000
!!
access-list
access -list 101
101 permit
permit tcp
tcp any
any any
any eq
eq www
www
• The customer wants to be sure that Web

traffic will never use more than 64 kbps
In the second example, a customer wants to limit web usage, so that web traffic
never uses more than 64 Kbps on the access link. The router configuration is
shown in the figure, using default parameters for traffic bursts. An access list
defines web traffic as the only shaped traffic. All other traffic bypasses GTS and
can use the full access line bandwidth.
Monitoring GTS
Router(config)#
show traffic-shape
• Displays current traffic shaping configuration
MAX = (Bc + Be)/8 Be Bc = Tc * CIR
Router#show traffic-shape
access Target Byte Sustain Excess Interval Increment Adapt
I/F list Rate Limit bits/int bits/int (ms) (bytes) Active
Se3/3 100000 2000 8000 8000 80 1000 -
CIR Bc Tc=Bc/CIR do we listen to

FECN/BECN?
The figure shows the results of the show traffic-shape command issued on a
router that shapes traffic to 100kbps with Bc and Be set to 8000.
To display the current traffic-shaping configuration, use the show traffic-shape
command. To display the current traffic -shaping statistics, use the show traffic-
shape statistics command. Output of both the commands is detailed in the
ensuing figures.
Information displayed includes:
n The rate that traffic is shaped to
n The maximum number of bytes transmitted per internal interval
n Configured sustained bits per interval
n Configured excess bits in the first interval
n Interval being used internally (may be smaller than the committed burst divided
by the CIR)
n Number of bytes that will be sustained per internal interval
n If Frame Relay has FECN/BECN adaptation configured
Monitoring GTS
Router(config)#
show traffic-shape statistic
• Displays traffic shaping statistics

Number of packets/bytes sent
on the interface
traffic-shape statistic
statistic
Access
Access Queue
Queue Packets
Packets Bytes
Bytes Packets
Packets Bytes
Bytes Shaping
Shaping
I/F List
List Depth
Depth Delayed Delayed Active
Active
Se3/3 77 16091
16091 3733112
3733112 414
414 96048
96048 yes
yes
Subset of the previous

Depth of the associated WFQ
queue for delayed packets number of packets/bytes
delayed via the WFQ queue
The show traffic-shape statistics command displays the statistics of traffic

shaping for all the configured interfaces. Displayed in the output is:
n The interface where the traffic-shape rate or traffic-shape group command
is used (traffic-shape rate command is used on interface serial3/3 in the
example)
n The associated access list if the traffic-shape group command is used
n The number of packets currently in the shaping queue (queue depth)
n The total number of packets that have been processed by the traffic-shape
command since the last clearing of interface counters (16091 packets in the
example)
n The total number of bytes that have been processed by the traffic-shape
command since the last clearing of interface counters (3733112 bytes in the
example)
n The total number of packets that have been delayed by the traffic-shape
command since the last clearing of interface counters (414 packets in the
example)
n The total number of bytes that have been delayed by the traffic-shape
command since the last clearing of interface counters (96048 bytes in the
example)
n If the queue depth is more than 0 than shaping is active
The expected result of traffic shaping is a high ratio between transmitted packets
and delayed packets.
If the number of delayed packets is very high (compared to the total number of
packets) then there are probably non-responsive aggressive flows being shaped
and the queue depth could show high buffer utilization.
If the number of delayed packets is zero then it is very likely that the access list
does not match any traffic.
Monitoring GTS
Router(config)#
show traffic-shape queue
• Displays the shaping queue contents

router#show
router#show traffic-shape
traffic-shape queue
queue
Traffic queued in shaping queue on Serial0
(depth/weight) 1/4096
Conversation 254, linktype:
linktype: ip,
ip, length: 232
source:
source: 1.1.1.1,
destination: 1.1.2.47, id: 0x0001, ttl:
ttl: 208,
208,
TOS:
TOS: 00 prot:
prot: 17, source
source port
port 11111,
11111, destination
destination port
port 22222
22222
The show traffic-shape queue command displays the contents of the shaping
queue associated with an interface.
This command can be used to determine the types of flows that are congesting the
shaping queue. The command displays the parameters that are used for
classification within WFQ:
n Source IP address
n Time to live (TTL)
n Type of Service (ToS) field
n Protocol ID
n Source port number
n Destination port number
The example shows that there is a non-responsive UDP flow (protocol 17)
congesting the shaping queue.
GTS on Frame Relay Interfaces
• GTS can be implemented on any type of

(sub)interface
• GTS supports additional features when
implemented on Frame Relay interfaces:
– BECT-to-FECN reflection
– FECN creation on congestion
GTS applies on a per-interface basis, can use access lists to select the traffic to
shape, and works with a variety of Layer-2 technologies, including:
n Frame Relay
n ATM
n Switched Multi-megabit Data Service (SMDS)
n Ethernet
On a Frame Relay subinterface, GTS can be set up to shape to a specified rate
and to adapt dynamically to available bandwidth by integrating Frame Relay
congestion signaling with GTS.
Frame Relay Refresher
• Frame Relay Explicit Congestion Notification

– FECN (Forward Explicit Congestion Notification)
– BECN (Backward Explicit Congestion Notification)
– CLLM (Consolidated Link Layer Management)
• Implicit Congestion Notification
– Network discards detected by end user at
higher layers
– DE (Discard Eligibility) bit
Frame Relay performs congestion notification to its Layer-2 endpoints by including

congestion signaling inside the Layer-2 frame headers.
n The FECN, BECN and DE bits in the Q.922 header of the frame provide in-
band congestion signaling.
n The Forward Explicit Congestion Notification (FECN) is bit set by a Frame
Relay network to notify a device (FR DTE, which may be a router) that it
should initiate congestion avoidance procedures.
n The Backward Explicit Congestion Notification (BECN) is bit set by a Frame
Relay network to notify a device (DTE) that it should initiate proper congestion
avoidance procedures.
n CLLM is an enhanced signaling method, used by Frame Relay switches, which
expands on the FECN/BECN mechanism to improve congestion management.
n The Discard Eligibility (DE) bit indicates that a frame may be discarded in
preference to other frames, if congestion occurs, to maintain the committed
quality of service within the network. Frames with the DE bit set are
considered Be excess data.
Congestion notification may be explicit (honored by Layer-2 devices) or implicit
(detected and honored by higher-layer protocols, not by the Layer-2 network).
FECN/BECN and CLLM are explicit methods, while BE-setting is an implicit
notification method.
Frame Relay FECN/BECN
Congestion Control
Switch
Switch monitors
monitors all
all
transmit
transmit queues
queues for
for
congestion
congestion
R
S
e
e
Frame 1 FECN c
n Frame 11
Frame
Frame e
d No Congestion this Side Congestion this Side
Relay i
e Relay
v
r Switch
Frame
Frame 22 BECN Frame 2 e
r
Same Virtual Circuit (VC)
• FR Switch detects congestion on output queue and informs:
– The receiver by setting the FECN bit on forwarded frames
– The source by setting the BECN bit on frames going in the opposite
direction
A Frame Relay switch can explicitly report congestion in two directions: Forward
and Backward. When a frame queue inside a switch is congested, the switch will
generate congestion signals based on the FECN and BECN bits. If congestion
occurs in a queue towards the main receiver of traffic, FECN signals are sent to
the receiving Layer-2 endpoint and BECN signals are sent to the sending Layer-2
endpoint. FECN and BECN bits are not sent as separate frames, but are
piggybacked inside data frames.
GTS Frame Relay Congestion
Adaptability
• On a Frame Relay (sub)interface, GTS can

adapt dynamically to available Frame Relay
bandwidth by integrating BECN signals
– The GTS bit rate is reduced when BECN packets
are received to reduce the data flow through
congested Frame Relay network
– Adaptation is done on per (sub)interface basis
– GTS bit rate is gradually increased when the
congestion is no longer present (no BECN packets
are received any more)
BECN is the flag that the sending DTE (router as a Frame Relay endpoint) is able
to integrate to determine the congestion status of the Layer-2 WAN.
GTS Frame Relay Congestion
Adaptability Mechanisms
• Bit-rate adaptation
– Traffic shaping bit-rate is reduced when a packet
with BECN bit is received in the Tc
– Traffic shaping bit-rate is increased if no BECN
bits were received in the Tc
• FECN to BECN propagation
– A test packet with BECN bit set is sent to the
sender if a packet with FECN bit set is received
The first adaptation mechanism is bit-rate adaptation. GTS is able to respond to

Layer-2 congestion by reducing its shaping rate to three-quarters of the current
rate, until the Layer-2 network recovers from congestion. When BECN flags are
no longer received, the rate is slowly ramped up again to the original shaping rate.
This is also a lower limit of rate reduction, which bounds the reduction process so
that at least some throughput is maintained. The BECN-integrating functionality is
performed on a per sub-interface (DLCI) basis.
However, if the congestion was caused by simplex traffic (such as a multicast
video stream) or by an aggressive TCP connection, it is expected that the reverse
traffic (frames flowing from the receiver to the sender, marked with the BECN
bit) might come by less frequently than required to feed the integration. So the
receiving DTE (the receiving router) can help matters when it receives a message
with FECN set by first checking to see if it has any data, and if it does not,
originating a message with BECN set. This message might be a Q.922 TEST
RESPONSE message, which would by virtue of its message type be understood to
be a message to discard and not reply to. This feature is called FECN-to-BECN
propagation.
An Example of BECN Integration
becn
9000
BECN Integration
INC added every Tc in the token Bucket

8000
becn
7000
6000
5000
Inc
4000
traffic-shape rate 64000 8000 8000

3000 traffic-shape adaptive 32000
2000 BECN received at Tc#1 and Tc#3
1000 Hypothesis: no idle traffic
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
time represented in units of Tc
The figure shows the shaped rate of a token bucket-based GTS responding to
BECN packets it received. As mentioned, the rate is reduced to three-quarters of
the previous rate for every Tc interval, which saw at least one BECN message
received at the router. When no BECN messages are received in a Tc period, the
shaped rate is brought up slowly, up one-sixteenth of the current rate.
FECN to BECN Propagation
R
S e
FECN
e c
n Frame e
Congestion
d Relay i
e v
Switch
Switch
r BECN in e
Q.922Test r
If there is no reverse traffic,

the switch is not able to set
BECN in frames going back
to sender
The other adaptation method, FECN-to-BECN propagation, configures a Frame

Relay sub-interface to reflect received FECN bits as BECN in Q.922 TEST
RESPONSE messages. This enables the sender to notice congestion in the Layer-
2 network, even if there is no data traffic flowing from the receiver back to the
sender.
Configuring Bit-rate Adaptation
Router(config-if)#
traffic-shape adaptive [bit-rate]
• Configures Traffic Shaping Frame Relay bit-rate

adaptation
bit-rate - lowest bit-rate the traffic is shaped to in
response to continuous BECN signals
Default: 1/2 the specified traffic shaping rate
• Traffic shaping has to be enabled
Frame Relay bit rate adaptation is configured using the traffic-shape adaptive
command, which specifies the lower limit to which the shaped rate should be
reduced in presence of incoming BECN signals. By default, this is half the
configured sustained (committed) rate in GTS. The bit rate is configured in bits per
second.
Configuring FECN to BECN
propagation
Router(config-if)#
traffic-shape
traffic-shape fecn-adapt
• Configures the router to send Frame Relay TEST

message with BECN bit set in response to receiving
a frame with FECN bit set
• Can be used without adaptive traffic shaping
Router(config-if)#
traffic-shape
traffic-shape fecn-create
fecn-create
• Sets FECN bit in all outgoing packets that have

been delayed due to traffic shaping
• Use for debugging/simulation only
The traffic-shape fecn-adapt command enables the FECN-to-BECN

propagation. It can be used without adaptive GTS, as configured with the previous
command.
This feature should be used for testing purposes only. If the feature is combined
with the adaptation feature it is very likely that the first delayed packet will cause
the shaping to slow down to the minimum shaping rate. For example:
1. Router A (sender) sends a frame with a FECN bit because it had to delay
a packet.
2. Router B (receiver) replies with the TEST frame with the BECN bit set
3. Router A (sender) reduces the shaping rate due to the received BECN
causing even more delay and more packets with the FECN bit set.
GTS Frame Relay
Adaptation Design
Conservative scenario
• Set shaping rate to CIR
• Set minimum rate to MIR (or 1/2 CIR)
Optimistic scenario
• Set shaping rate to EIR
• Set minimum rate to CIR
Realistic scenario
• Set shaping rate to EIR
• Set minimum rate to MIR (or 1/2 CIR)
To illustrate different possibilities of adaptation, consider the following three

scenarios for using GTS over a Frame Relay circuit
n In a conservative scenario, where there should be minimal congestion and
dropping, the shaping rate is set to the contracted Frame Relay CIR
(Committed Information Rate) and the minimum rate of adaptation is set either
to MIR (Minimum Information Rate) or half the CIR value. MIR depends on
the provider’s over provisioning of the network and can be as low as one-tenth
of the CIR. This configuration minimizes dropping, but does not allow excess
bandwidth to be fully utilized.
n In an optimistic scenario, the normal shaping rate may be set to the EIR
(Excess Information Rate) and the minimum rate to the CIR. This
configuration would probably cause too much dropping in a loaded Frame
Relay network.
n In a realistic scenario, utilizing most excess bandwidth can be achieved by
setting the shaping rate to the EIR and the minimum adaptation rate to the
MIR (or half the CIR). This would allow full advantage to be made of the
Frame Relay network, if possible, and to adapt to a realistic level if congestion
is indicated.
GTS Frame Relay Adaptation
Example
WAN
Core
Customer interface
interface serial 0/0
0/0
traffic-shape
traffic-shape rate
rate 64000 8000 8000
traffic-shape
traffic-shape adaptive
adaptive 48000
48000
• EIR = 64 kbps
• CIR = 48 kbps
• Assumption: Frame Relay network is usually not
congested
This GTS shape rate adaptation example shows a configuration of GTS, where
traffic is shaped to the EIR of 64 Kbps, with the adaptive floor being equal to CIR,
which is contracted at 48 Kbps. No FECN-to-BECN propagation is configured.
This example would work optimally only if the Frame Relay network is unlikely to
get congested because setting the adaptive floor to the CIR cannot lower the
shaping rate below the CIR. Lowering the rate below the contracted CIR may be
necessary in most commercial Frame Relay networks.
Summary
n GTS can be applied only on output interfaces
n GTS performs traffic shaping or smoothing
n GTS cannot mark or drop packets
n GTS supports BECN and FECN in Frame Relay environments
n GTS does not support cascaded policies
n GTS does not provide managed discard
n GTS cannot run in distributed mode
n GTS supports only extended IP access lists
n GTS supports RSVP as it uses WFQ
Lesson Review
1. What software queuing mechanisms are supported in combination with GTS?
2. Which queuing structure does GTS use?
3. What features does GTS include when used on Frame Relay interfaces?
Frame Relay Traffic Shaping
Overview
The section describes the Frame Relay Traffic Shaping (FRTS) mechanism.
Objectives
Upon completion of this section, you will be able to perform the following tasks:
n Describe the FRTS mechanism
n Describe the benefits and drawbacks of FRTS
n Compare the GTS and FRTS mechanisms
n Configure FRTS on Cisco routers
n Monitor and troubleshoot FRTS
Frame Relay
Traffic Shaping
Meter
Shaper
Classifier Marker
Dropper
Traffic
stream
• Can NOT shape multiple classes

• Can be implemented on per-vc basis (classification)
• Can measure traffic rate of individual virtual circuits (metering)
• Delays packets of exceeding VC-s (shaping)
• Dynamic Traffic Throttling on a Per-VC Basis (BECN or
ForeSight)
• Enhanced Queuing Support on a Per-VC Basis (PQ, CQ or WFQ)
Cisco has long provided support for FECN for DECnet and OSI, and BECN for
SNA traffic using LLC2 encapsulation and DE bit support. FRTS builds upon this
existing Frame Relay support with additional capabilities that improve the scalability
and performance of a Frame Relay network, thereby increasing the density of VCs
and improving response time.
Frame Relay Traffic Shaping (FRTS) can eliminate bottlenecks in Frame Relay
networks that have high-speed connections at the central site and low-speed
connections at branch sites. Rate enforcement can be configured to limit the rate
at which data is sent on the VC at the central site.
Using FRTS, rate enforcement can be configured to either the CIR or some other
defined value such as the excess information rate on a per-VC basis. The ability
to allow the transmission speed used by the router to be controlled by criteria other
than line speed (that is, by the CIR or the excess information rate) provides a
mechanism for sharing media by multiple VCs. Bandwidth can be allocated per
VC, creating a virtual time-division multiplexing (TDM) network.
PQ, CQ and WFQ can also be defined at the VC or subinterface level. Using
these queuing methods allows for finer granularity in prioritising and queuing of
traffic, thus providing more control over the traffic flow on an individual VC. If CQ
is combined with the per-VC queuing and rate enforcement capabilities, Frame
Relay VCs are enabled to carry multiple traffic types, such as IP, SNA and IPX,
with guaranteed bandwidth for each traffic type.
Using information contained in the BECN-tagged packets received from the
network, FRTS can also dynamically throttle traffic. With BECN-based throttling,
packets are held in the buffers of the router to reduce the data flow from the
router into the Frame Relay network. The throttling is done on a per-VC basis and
the transmission rate is adjusted based on the number of BECN-tagged packets
received.
With the Cisco FRTS feature, ATM ForeSight closed loop congestion control can
be integrated to actively adapt to downstream congestion conditions.
FRTS Building Blocks
Enough
No classifier, shaping Shaping
Tokens? No
performed on individual VC Queue
Enough No Shaping
Forwarder Tokens? Yes
+ Queue
Frame Relay maps
Yes
Enough Shaping
Tokens? No
Queue
Yes
Traffic for VCs that are not shaped Physical Interface

queue(s)
In this block diagram, FRTS operation on a physical Frame Relay interface is

shown. There is no global pre-classification of traffic, but packets are sent to their
individual VCs instead. Shaping is then performed on a per-VC basis, with a
separate shaping queue/token bucket for each VC. Packets coming out of their
individual per-VC shapers are then sent to the physical interface queue (Tx
queue/Tx ring).
FRTS Overview
• FRTS is multiprotocol
• FRTS can use one of the following queuing
mechanisms as the shaping queue:
– Weighted Fair Queuing (WFQ)
• FRTS can only be implemented in
combination with WFQ on the interface
• FRTS works on output only
FRTS is a shaping implementation that supports multiple protocols. Unlike GTS,

which performs a WFQ-based scheduling on the entry of the shaper with an
arbitrary scheduling mechanism on the physical interface, FRTS performs its
operations the other way around.
FRTS can use priority queuing, custom queuing, or weighed fair queuing as the
scheduling method on the entry of the shaper. This allows for finer granularity in
the prioritization and queuing of traffic and provides more control over the traffic
flow on an individual VC. If CQ is combined with the per-VC queuing and rate
enforcement capabilities, Frame Relay VCs are enabled to carry multiple traffic
types, with bandwidth guaranteed for each traffic type.
For example, if CQ is combined with the per-VC queuing and rate enforcement
capabilities, FR VC’s can be enabled to carry IP, SNA and IPX traffic, with
bandwidth guaranteed for each.
At the physical interface itself (after the packet has been fancy queued and
shaped) WFQ needs to be enabled in conjunction with FRTS. WFQ is currently the
only supported interface scheduling method.
FRTS can only be configured on the output of an interface.
GTS vs. FRTS
Generic Traffic Shaping Frame Relay Traffic Shaping
• Works on any (sub)interface • Works only on Frame Relay

• Shapes traffic on • Shapes traffic of individual
(sub)interface basis virtual circuits
• Any physical interface • Only WFQ can be used on
queuing can be used physical interface
• Only WFQ can be used for • CQ, PQ or WFQ can be used in
shaping queue shaping queue
Generic Traffic Shaping is equivalent to Frame Relay Traffic Shaping

when it’s configured on point-to-point Frame Relay subinterfaces
The figure compares GTS to FRTS, based on their main differences. Generic
Traffic Shaping:
n Works on any (sub) interface type
n Shapes traffic on that (sub)interface basis
n Can use any physical interface queuing (FIFO, PQ, CQ or WFQ)
n Only uses WFQ as the shaping queue (that is, on the input of the shaper)
In contrast, Frame Relay Traffic Shaping:
n Works only on Frame Relay (sub) interfaces
n Shapes traffic inside individual FR Virtual Circuits
n Only permits WFQ as the physical interface queuing method
n Can use any queuing method as the shaping queue (that is, on the input of the
shaper)
Configuring FRTS
• Define the shaping parameters (map-class)

– Token-bucket parameters
– Frame Relay congestion adaptation
– Shaping queue type
• Enable Frame Relay traffic shaping on
physical interface
• Apply the shaping definition
– For all VCs on (sub)interface
– For individual PVC/SVC
Enabling FRTS on an interface enables both traffic shaping and per-VC queuing on
all the interface's PVCs and SVCs. Traffic shaping enables the router to control
the circuit's output rate and, if configured, to react to congestion notification
information. Queuing enables per-VC scheduling of traffic to be shaped.
Configuring FRTS involves:
Step 1 Defining the shaping parameters with the map-class command
Step 2 Enabling FRTS on the physical interface
Step 3 Applying the shaping parameters to all, or selected, VCs on that interface
Creating a Map Class
Router(config)#
map-class frame-relay name
• Creates a new Frame Relay map class or starts

editing existing map-class
• Map class names are case sensitive
The map-class frame -relay command defines the per-VC shaping and queuing
parameters. A case-sensitive name must be assigned to each map class.
Define Map-class Shaping Queue
Router(config-map-class)#
frame-relay priority-group number
• Selects priority queuing as the shaping queue

structure
frame-relay custom-queue-list number
• Selects custom queuing as the shaping queue

structure
frame-relay
frame-relay fair
fair cdt max-queue rsvp-queues
rsvp-queues max-buf
max-buf
• Selects WFQ as the shaping queue structure

• FRF.12 requires weighted fair queuing
Inside the map class, the frame-relay priority-group, frame-relay custom-

queue -list, and frame-relay fair keywords enable a queuing discipline of either
priority, custom or weighed fair queuing, respectively. This queuing discipline is
used for traffic departing on a VC, before shaping is applied to it. If FRF.12
payload compression is used, WFQ needs to be configured as the queuing
discipline.
Define Traffic Shaping
Parameters
frame-relay [in|out]
[in|out] cir
cir bit-rate
frame-relay [in|out]
[in|out] bc bits
frame-relay [in|out] be bits
• Specifies the shaping parameters in CIR/Bc/Be values

• Tc is computed from CIR and Bc
• Only outgoing values can be specified for FRTS
frame-relay traffic-rate
traffic-rate average-rate peak-rate
• Specifies only the CIR and peak rate

• Tc is specified by the router
• Bc and Be are computed from Tc, average and peak rate
Per-VC traffic shaping parameters specify shaping behavior for the configured
map class. Two configuration mechanisms are available:
n Specification of CIR, Bc and Be parameters of the per-VC token bucket
n Specification of per-VC average rate and peak rate, where Bc and Be are
computed from the default Tc, average rate and peak rate
Define Congestion Adaptation
Mechanism
frame-relay adaptive-shaping
adaptive-shaping becn|foresight
becn|foresight
• Enables adaptive shaping for the Frame Relay map

class
• Congestion indication mechanism could be BECN
or Foresight (CLLM)
frame-relay mincir rate
• Specifies the minimum bit rate for congestion

adaptation algorithm
As part of the map class definition, either BECN or ForeSight are used as the
congestion backward notification mechanism to which traffic shaping will adapt.
The BECN adaptation feature is the same as with GTS, thus the router reacts to
received BECN signals by reducing its shaping rate.
The ForeSight adaptation feature uses the network traffic control software used in
Cisco Frame Relay switches. When the ForeSight feature is enabled on the switch,
the switch will periodically send out a ForeSight message based on the time value
configured. The time interval can range from 40 to 5000 milliseconds. The
ForeSight feature allows Cisco Frame Relay routers to process and react to
ForeSight messages and adjust VC-level traffic shaping in a timely manner.
Note The ForeSight feature is only available in combination with Cisco WAN switches.
The difference between the BECN and ForeSight congestion notification methods
is that BECN requires a user packet to be sent in the direction of the congested
DLCI to convey the signal. The sending of user packets is not predictable and,
therefore, is not reliable as a notification mechanism. Rather than wait for user
packets to provide the congestion notification, timed periodic ForeSight messages
guarantee that the router receives notification before congestion becomes a
problem. Traffic can be slowed down in the direction of the congested DLCI.
Define Dedicated Queue for VoFR
Packets
frame-relay voice bandwidth bps queue depth
• Creates dedicated queue for VoFR packets

• VoFR queue has priority over regular queues
configured on the same VC
• Specified bandwidth has to include L2 and VoFR
overhead
• Voice calls over Frame Relay will not be placed
unless the voice queue is configured
• Voice over FR call will be rejected if there is not
enough bandwidth available in the voice queue
The frame-relay voice-bandwidth map-class command is used to configure how

much bandwidth is reserved for voice over Frame Relay (VoFR) traffic, if used in
the network. The router then creates a dedicated priority queue, used only for
VoFR traffic. If not enough reserved voice bandwidth remains on the PVC, any
new calls that are attempted will be rejected.
When the amount of bandwidth to allocate to voice is calculated, the overall
bandwidth calculation must include the voice packetization overhead and not just
the raw compressed speech codec bandwidth.
Enable FRTS on an Interface
Router(config-if)#
frame-relay traffic-shaping
• Enables Frame Relay traffic shaping on a physical

interface
• No special queuing can be configured on the
interface
• Weighted Fair Queuing is used as the physical
interface queuing mechanism regardless of
interface bandwidth
After the map class is configured, traffic shaping must be applied to the physical
interface. As mentioned, WFQ is the only supported mechanism on the physical
interface running FRTS.
Apply FRTS to a VC
Router(config-if)#
frame-relay class map-class-name
• Applies the specified Frame Relay map class to all

VCs configured on the specified (sub)interface
Router(config-if)#
frame-relay interface-dlci
interface-dlci DLCI
DLCI
class map-class-name
• Applies the specified Frame Relay map class only to

the specified DLCI
• Traffic for DLCIs that have no map class defined (on
DLCI or on (sub)interface) is not shaped
Map class settings are then applied to all or specific VCs on an interface or
subinterface. All VCs without shaping information are not shaped and only use the
physical interface queuing discipline (WFQ).
Frame Relay Traffic Shaping
Example
interface Serial1/1
frame-relay
frame -relay traffic-shaping
!
interface Serial1/1.1 point-to-point
point-to-point
frame-relay
WAN interface-dlci 101
frame -relay 101
class
class slow_vcs
slow_vcs
!
interface Serial1/1.2 Core
point-to-point
point-to-point
frame-relay
frame -relay interface-dlci 102
102
class
class fast_vcs
fast_vcs
Customer !
map-class
map-class frame-relay
frame-relay fast_vcs
fast_vcs
frame-relay
frame -relay custom-queue-list
custom-queue-list 11
frame-relay
frame -relay traffic-rate 32000 64000
!
map-class
map-class frame-relay
frame-relay slow_vcs
slow_vcs
frame-relay
frame -relay priority-group 1
frame-relay
frame -relay traffic-rate 9600
9600 16000
16000
• Customer uses different policies and queuing mechanisms for

each DLCI
The figure shows an FRTS configuration example, where two VCs are individually
shaped with two map class parameter sets. In this example, two generic map
classes are defined, one for generic fast VCs and the other for slow VCs. The fast
VC map class uses custom queuing to allocate bandwidth within the shaped rate.
The slow VC map class uses priority queuing to always forward mission-critical
traffic, and then shape it to the required rate.
Frame Relay QoS Autosense
• Frame Relay QoS parameters are usually

defined manually on the router
• The same parameters are also carried in
ELMI (CLLM) messages
• QoS Autosense allows the router to learn the
DLCI QoS parameters from the switch
– ELMI must be configured on the router and the
switch
– Only Cisco Frame Relay switches are supported
When used in conjunction with traffic shaping, the router can respond to changes in
the network dynamically. This optional feature allows the router to learn QoS
parameters from the Cisco switch and use them for traffic shaping, configuration,
or management purposes.
Enhanced Local Management Interface (ELMI) also simplifies traffic shaping
configuration on the router. Previously, users needed to configure traffic shaping
rate enforcement values, possibly for every VC. Enabling ELMI reduces the
chance of specifying inconsistent or incorrect values when configuring the router.
It is not necessary to configure traffic shaping on the interface to enable ELMI.
One option is to enable it to learn what values being used by the switch. If the
router is required to respond to the QoS information received from the switch by
adjusting the output rate, traffic shaping must be configured on the interface using
the frame-relay traffic-shaping command in interface configuration mode.
Configuring QoS Autosense
Router(config-if)#
frame-relay qos-autosense
• Enable the Enhanced Local Management Interface

feature
• Allows QoS parameters (CIR, Bc, Be) to be passed
by the switch to the router automatically in ELMI
messages
The frame-relay qos-autosense command enables:

n ELMI on the router
n The router to learn QoS parameters from the switch over the ELMI protocol
Monitoring Frame Relay Traffic
Shaping
• Show frame-relay PVC

– Displays VC QoS and shaping parameters
• Show traffic-shape statistics
– Displays GTS and FRTS statistics
• Show traffic-shape queue
– Displays GTS and FRTS shaping queue contents
The listed show commands enable monitoring of per-VC QoS and general GTS
parameters.
Display PVC Information
Router#
show frame-relay pvc
• Displays VC QoS and shaping parameters
Router#show
Router#show frame-relay
frame-relay pvc
pvc 2020
PVC
PVC Statistics
Statistics for
for interface
interface Serial4/0
Serial4/0 (Frame
(Frame Relay
Relay DCE)
DCE)
DLCI
DLCI == 20,
20, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.1Serial4/0.1
input
input pkts
pkts 16963
16963 output
output pkts
pkts 33632
33632 in
in bytes
bytes 4669839
4669839
out
out bytes
bytes 12442428
12442428 dropped pkts
pkts 00 in
in FECN
FECN pkts
pkts 00
in
in BECN
BECN pkts
pkts 00 out
out FECN
FECN pkts
pkts 00 out
out BECN
BECN pkts
pkts 00
in DE pkts
in DE pkts 0 0 out DE pkts
out DE pkts 0 0
out
out bcast
bcast pkts
pkts 31361
31361 out
out bcast
bcast bytes
bytes 9095644
9095644
Shaping
Shaping adapts
adapts toto BECN
BECN
pvc
pvc create
create time
time 1w3d,
1w3d, last
last time
time pvc
pvc status
status changed
changed 1w3d
1w3d
cir
cir 64000
64000 bc
bc 64000
64000 be
be 00 limit
limit 1000
1000 interval
interval 125
125
mincir 32000
mincir 32000 byte increment 1000 BECN response
byte increment 1000 BECN response yes yes
pkts
pkts 1103
1103 bytes
bytes 1632516
1632516 pkts
pkts delayed
delayed 1091
1091 bytes
bytes delayed
delayed 16287
16287
shaping
shaping active
active
traffic
traffic shaping
shaping drops 1136
Current
Current fair
fair queue
configuration:
Discard
Discard Dynamic
Dynamic Reserved
Reserved
threshold
threshold queue
queue count
count queue
queue count
count
64
64 16
16 00
Output
Output queue
queue size
size 46/max
46/max total 50/drops 1136
The show frame -relay pvc command displays information about individual FR
PVC status and provides information about:
n Configured CIR
n Shaping
n Queuing
n Congestion adaptation
Display Shaping Statistics
Router#
show traffic-shape statistics
• Displays GTS and FRTS statistics

Router#show
traffic-shape statistics
statistics
Access
Access Queue
Queue Packets
Packets Bytes
Bytes Packets
Packets Bytes
Bytes Shaping
Shaping
I/F
I/F List
List Depth
Depth Delayed
Delayed Delayed
Delayed Active
Active
Se4/0.1
Se4/0.1 50
50 1283
1283 1903236
1903236 1271
1271 1899472
1899472 yes
yes
Se4/0.2
Se4/0.2 00 14
14 4060 0 0 no
The show traffic-shape statistics command displays the statistics of traffic

shaping for all configured interfaces. In the output, the amount of delayed traffic,
the shaping queue sizes and the amount of transmitted traffic is displayed.
Displayed in the output is:
n The interface where the frame-relay taffic-shaping command is used
n The number of packets currently in the shaping queue (queue depth)
n The total number of packets that have been processed by the frame-relay
taffic-shaping command since the last clearing of interface counters (16091
packets in the example)
n The total number of bytes that have been processed by the frame-relay taffic-
shaping command since the last clearing of interface counters (3733112 bytes
in the example)
n The total number of packets that have been delayed by the frame-relay taffic-
shaping command since the last clearing of interface counters (414 packets in
the example)
n The total number of bytes that have been delayed by the frame-relay taffic-
shaping command since the last clearing of interface counters (96048 bytes in
the example)
n If the queue depth is more than 0 than shaping is active
The expected result of traffic shaping is a high ratio between transmitted packets
and delayed packets.
If the number of delayed packets is very high (compared to the total number of
packets) then there are probably non-responsive aggressive flows being shaped
and the queue depth could show high buffer utilization.
If the number of delayed packets is zero then it is very likely that the access list
does not match any traffic.
Display Shaping Queue
Information
Router#
show traffic-shape queue
• Displays GTS and FRTS shaping queue contents

Router#show
traffic-shape queue
queue
Traffic
Traffic queued
queued in
in shaping
shaping queue
queue on
on Serial4/0.1
Serial4/0.1 dlci
dlci 20
20
Queueing
Queueing strategy:
strategy: weighted
weighted fair
fair
Queueing
Queueing Stats:
Stats: 46/50/64/1377
46/50/64/1377 (size/max
Conversations
1/2/16 (active/max
active/max total)
total)
Reserved
Conversations 0/0
0/0 (allocated/max
allocated)
46/32384/1377/0 /0
Conversation
Conversation 5,
5, linktype:
linktype: ip,
ip, length:
length: 1504
1504
source:
source: 193.77.3.1,
193.77.3.1, id:
id: 0x00F4,
0x00F4, ttl:
ttl: 255,
255, prot:
prot: 1
The show traffic-shape queue command displays the queuing configuration of

individual interfaces.
Display Shaping Queue
Information
PE_2#show
PE_2#show traffic-shape
traffic-shape queue
queue
Traffic
Traffic queued
queued in
in shaping
shaping queue
queue on
on Serial4/0.1
Serial4/0.1 dlci
dlci 20
20
Queueing
Queueing strategy:
strategy: priority-group
priority-group 11
Queueing
Queueing Stats:
Stats: high 16/20/19 (queue/size/max total/drops)
Packet
Packet 1,
1, linktype:
linktype: ip,
ip, length:
length: 1504,
1504, flags:
flags: 0x10000048
source:
source: 193.77.3.1,
193.77.3.1, id:
id: 0x0141,
0x0141, ttl:
ttl: 255,
255, prot:
prot: 11
data:
data: 0x0800
0x0800 0x9105
0x9105 0x2659
0x2659 0x1F89
0x1F89 0x0000
0x0000 0x0000
0x0000 0x3819
0x3819
0x223C
0x223C 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
Packet
Packet 2,
2, linktype:
linktype: ip,
ip, length:
length: 1504,
1504, flags:
flags: 0x10000048
source:
source: 193.77.3.1,
193.77.3.1, id:
id: 0x0141,
0x0141, ttl:
ttl: 255, prot:
prot: 11
data:
data: 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD 0xABCD
0xABCD
The show traffic-shape queue command also displays the contents of the shaping
queue associated with an interface.
The example shows the contents of the high queue in the Priority Queuing system
used as the shaping queue.
Summary
n FRTS enables granular, per-VC queuing and shaping definition
n FRTS can be applied only on output interfaces
n FRTS enables per-VC queuing, which is performed before shaping
n FRTS performs traffic shaping or smoothing within a VC
n FRTS supports the same congestion adaptation mechanisms as GTS
Lesson Review
1. What are the main differences between GTS and FRTS?
2. Where can FRTS be used?
3. What classification options does FRTS have?
Committed Access Rate
Overview
The lesson describes the Committed Access Rate (CAR) mechanism.
Objectives
n Describe the CAR mechanism
n Describe the benefits and drawbacks of CAR
n Describe the differences between CAR, GTS and FRTS
n Configure CAR on Cisco routers
n Monitor and troubleshoot CAR
Committed Access Rate
Meter
Inbound
or
Outbound
• Primarily intended for rate limiting

• Can be used on inbound and outbound traffic
• Does not queue (delay) packets
• Can also mark packets
• Can be implemented for differentiated
marking
Committed Access Rate (CAR) provides the capability to allow the service
provider to rate-limit traffic in and out of router interfaces, thereby enabling various
forms of ingress and egress rate-limiting in a network. CAR is a policing
mechanism, not a queuing mechanism. Therefore it does not buffer or delay
packets, which do or do not conform to the policy, but simply rate-limits them
according to a simple “forward or drop” policy, according to the configuration.
CAR also uses a token-bucket metering mechanism, similar to GTS, but without a
delay queue.
The CAR rate-limiting feature manages a network's access bandwidth policy by
ensuring that traffic falling within specified rate parameters is sent, while dropping
packets that exceed the acceptable amount of traffic or sending them with a
different priority. CAR is often configured on interfaces at the edge of a network
to limit traffic into or out of the network.
CAR can also be used for packet marking. The operator can specify a policy that
determines which packets should be assigned to which traffic class, and use CAR
to implement the marking. The IP header already provides a mechanism to do this,
namely the three precedence bits in the ‘type of service’ field in the IP header.
CAR allows the setting of policies, based on information in the IP or TCP header
such as IP address, application port, physical port or sub-interface, IP protocol,
etc., to decide how the precedence bits should be marked or “colored.” Once
marked, appropriate treatment can be given in the backbone to ensure that
premium packets receive premium service in terms of bandwidth allocation, delay
control, etc.
Note CAR can also be used to police (or “recolor”) precedence bits set externally to
the network either by the customer or by a downstream service provider. Thus
the network can decide to either accept or override external decisions.
CAR is implemented using the following abstract mechanisms:

n The classifier, which differentiates traffic into multiple classes, which may be
treated in a discriminate manner
n The meter, which uses a token-bucket scheme to measure the rate of
classified traffic
n The marker, which can be used to mark or re-mark classified traffic (for
example, with precedence or DSCP values)
n The dropper, which may drop packets (in the rate-limiting scenario) according
to the configured policy
CAR on Input and Output
Meter
Inbound Classifier Marker Dropper
Forwarding
Outbound
Meter
Classifier Marker Dropper Queuing
• CAR on input is processed just before forwarding (most other

QoS mechanisms are processed before CAR)
• CAR on output is processed immediately after forwarding (most
other QoS mechanisms are processed after CAR)
CAR can be configured on router input or output interfaces. When configured on

the input side, CAR is usually processed last in a series of QoS mechanisms.
Therefore, CAR rate-limiting and marking occurs just before the forwarding
decision.
On the output side, CAR is processed just after the forwarding decision. Therefore
all output QoS mechanisms (queuing, WRED, etc.) are generally processed after
CAR.
VIP-based distributed CAR (dCAR) is a version of CAR that runs on the
Versatile Interface Processor (VIP). It is supported on the Cisco 7500 routers with
a VIP2-40 or later versatile interface processor. Distributed Cisco Express
Forwarding (dCEF) switching must be enabled on any interface that uses dCAR,
even when only output-based CAR is configured.
CAR Implementation
Dispatches Dispatches Dispatches

packets at packets at line packets at line
configured rate rate rate
Software Hardware
CAR Queue Queue
(FIFO, PQ,
(FIFO)
CQ, WFQ, ...)
Bypass the software queue

if it is empty and there is
room in the hardware queue
• The software queue may have no function if

the sum of all CAR rates is less than link
bandwidth
Whether configured on input or output, CAR has the option of managing

throughput on a certain interface’s output. With the Cisco IOS queuing design,
there are two output queues:
n A software queue, which may be configured for different queuing types (for
example: FIFO, Priority Queuing, Custom Queuing, Weighted Fair Queuing)
n A hardware interface queue, which is always FIFO and immediately used, if
the software queue is empty
One possible implementation caveat arises when CAR is configured so that the
aggregate policed bandwidth of output flows does not exceed the link bandwidth.
In that case, the software queue is always empty and there is no queuing impact on
traffic.
Interface-wide CAR Diagram
drop
transmit
Class
Class 1?
1? CAR
CAR
continue
drop
transmit Output Queue
Class
Class 2?
2? CAR
CAR or
Forward
continue
drop
transmit
Class n? CAR
CAR
• CAR has three different actions:

– Transmit
– Continue
– Drop
The basic rate-limiting function of CAR does the following:

n Allows control of the maximum rate of traffic transmitted or received on an
interface.
n Provides the ability to define Layer-3 aggregate or granular rate limits and to
specify traffic -handling policies when the traffic either conforms to or exceeds
the specified rate limits.
n Uses granular bandwidth rate limits to match a particular type of traffic based
on precedence, MAC address, or other parameters.
When CAR is in effect, traffic is first classified and then undergoes CAR
processing. CAR then meters the traffic and, based on the result of CAR metering,
traffic either conforms or exceeds the configured policy.
There are three possible basic actions on each packet, depending on it conforming
or exceeding the policy:
n Transmit—the packet is sent.
n Drop—the packet is discarded.
n Continue—the packet is evaluated using the next rate policy in a chain of rate
limits. If there is not another rate policy, the packet is sent.
CAR Diagram
Meter
Meter
Yes Forward
Yes / No
Conforms?
Conforms? Transmit?
Transmit? or
Enqueue
No
Go to
Mark?
Mark? Yes
Continue?
Continue? Next
CAR command
Yes No
Set
Set IP
IP prec?
prec? Set
SetIP
IPPrecedence
Precedence

Much more than documents.

Cisco Introduction IP QoS (Course)

Uploaded by

Document Information

Description:

Copyright:

Available Formats

Cisco Introduction IP QoS (Course)

Uploaded by

Description:

Copyright:

Available Formats

Related titles

Introduction

2 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

• Phone calls over IP are no better than over satellite!

• Phone calls have really bad voice quality!

• ATM (the money-dispensing-type) are non-

© 2001, Cisco Systems, Inc. IP QoS Introduction-5

The purpose of this module is to determine the following:

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 3

• Application X is slow! (not enough BANDWIDTH)

© 2001, Cisco Systems, Inc. IP QoS Introduction-6

Quality of Service is usually identified by the following parameters:

4 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

• Lack of bandwidth – multiple flows are

© 2001, Cisco Systems, Inc. IP QoS Introduction-7

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 5

256 kbps 512 kbps

10 Mbps 100 Mbps

BW max = min(10M, 256k, 512k, 100M)=256kbps

© 2001, Cisco Systems, Inc. IP QoS Introduction-8

6 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Propagation Propagation Propagation

© 2001, Cisco Systems, Inc. IP QoS Introduction-9

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 7

Processing Delay Queuing Delay

© 2001, Cisco Systems, Inc. IP QoS Introduction-10

8 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

© 2001, Cisco Systems, Inc. IP QoS Introduction-11

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 9

IP TCP data Fancy

© 2001, Cisco Systems, Inc. IP QoS Introduction-12

There are several approaches to solving a problem of insufficient bandwidth:

10 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 11

TCP Header Compression

IP UDP RTP data Fancy

© 2001, Cisco Systems, Inc. IP QoS Introduction-13

Assuming that a router is powerful enough to make a forwarding decision in a

12 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 13

Weighted Random Early Detection (WRED)

IP data Dropper Fancy

Custom Queuing (CQ)

© 2001, Cisco Systems, Inc. IP QoS Introduction-14

Packet loss is usually a result of congestion on an interface. Most applications that

14 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 15

Throughput Delay Loss

Voice Low Low and Low Low

• Enterprise networks are typically focused on

When QoS is considered in a network implementation, important applications and

16 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Throughput Delay Loss

Gold Guaranteed Low Low Low

• Service provider networks typically offer services

Service providers, on the other hand, are there to provide connectivity to

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 17

• Best effort – no QoS is applied to packets

© 2001, Cisco Systems, Inc. IP QoS Introduction-17

18 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 19

20 IP QoS Introduction Copyright  2001, Cisco Systems, Inc.

• The Internet was initially based on a best-

© 2001, Cisco Systems, Inc. IP QoS Introduction-22

The Internet Engineering Task Force (IETF) is responsible for standardization of

Copyright  2001, Cisco Systems, Inc. IP QoS Introduction 21

Local Remote Admission Local

reserve reserve reserve reserve