This document explains how routing protocol messages, such as hellos
and database descriptors, as well as other important control traffic are queued
when an outbound router interface is configured with a service-policy using the
commands of the modular quality of service command-line interface (MQC).
Specifically, this document reviews these two mechanisms used by Cisco
IOS® routers to prioritize control packets:
Where the Priority Is Considered
IP Precedence Bits
Type of service (TOS) byte in IP header
Provides priority through the network
Internal packet label inside the router, assigned by interface
Provides priority through the router (per-hop)
Both mechanisms are designed to ensure that key control packets are not
dropped or are dropped last by the router and the queuing system when an
outbound interface is congested.
There are no specific requirements for this document.
The information in this document is based on Cisco IOS Software Release
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
Technical Tips Conventions for more information on document
for Comments (RFC) 791
defines the TOS byte in the header of an IP
packet. Although RFC
redefine this byte as Differentiated Services Code Point (DSCP)
values, a Cisco IOS router still uses the original IP precedence bits of the
TOS byte, as per RFC 791. Notice how the RFC defines the TOS byte:
"The Type of Service provides an indication of the abstract parameters
of the quality of service desired. These parameters are to be used to guide the
selection of the actual service parameters when transmitting a datagram through
a particular network. Several networks offer service precedence, which somehow
treats high-precedence traffic as more important than other traffic (generally
by accepting only traffic above a certain precedence at time of high
As illustrated in the diagram, the IP precedence field occupies the
three most significant bits of the TOS byte. Only the three IP precedence bits
reflect the priority or importance of the packet, not the full value of the TOS
This table lists the values of the precedence bits:
Cisco IOS assigns an IP precedence of 6 to routing protocol packets on
the control plane. As noted by RFC 791, "The Internetwork Control designation
is intended for use by gateway control originators only." Specifically, Cisco
IOS marks these IP-based control packets: Open Shortest Path First (OSPF),
Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol
(EIGRP) hellos, and keepalives. Telnet packets to and from the router also
receive an IP precedence value of 6. The assigned value remains with the
packets when the output interface transmits them into the network.
While the IP precedence value specifies treatment of a datagram within
its transmission through the network, the pak_priority
mechanism specifies treatment of a packet during its transmission
inside the router.
In addition to the core of a router CPU, every interface uses a network
controller or local CPU, which runs a special piece of software called a
driver. The driver code provides interface-specific instructions.
When it receives a packet, the interface driver copies the packet from
a small first-in, first-out (FIFO) buffer to a data buffer in input/output
(I/O) memory. It then attaches a small packet header to the buffer. The packet
header, referred to in Cisco IOS terminology as the paktype structure, contains
key information about the data block in the buffer. Dependent upon the contents
of the packet, the packet header can point to the address in memory where the
Ethernet encapsulation header, Internet Protocol (IP) header, and Transmission
Control Protocol (TCP) header starts.
The Cisco IOS software uses the fields in the packet header to control
the treatment of the packet in interface queues. The packet header includes the
pak_priority flag, which indicates the relative importance of marked packets to
the queuing system.
The RIP and OSPF routing processes that run on the core CPU of a router
mark all traffic they originate with both IP precedence 6 and pak_priority. In
contrast, the Border Gateway Protocol (BGP) instructs TCP to mark its traffic
with IP precedence 6, but does not set pak_priority.
Cisco IOS must also ensure a low drop probability for several types of
non-IP control packets. These packet types include these:
Intermediate System-to-Intermediate System (IS-IS) routing protocol
Enhanced Interior Gateway routing protocol (EIGRP)
Point-to-Point Protocol (PPP) and high-level data link control (HDLC)
keepalives on serial and packet over SONET (POS) interfaces
Operations, administration, and maintenance (OAM) cells and address
resolution protocol (ARP) messages on ATM
Since such traffic is not IP, Cisco IOS cannot match on the IP
precedence value to provide prioritization. Instead, it uses only the internal
pak_priority value in the packet buffer header.
Note: The Cisco Catalyst 6000 / Cisco 7600 Series initially supported the
pak_priority mechanism on the FlexWAN only. Enhancements to the prioritization
of IP and non-IP control packets was subsequently implemented.
Routers such as the Cisco 7500 Route/Switch Processor (RSP) and
lower-end routers (such as the Cisco 7200 and 3600 Series) use a different
mechanism to route and control traffic than the Cisco 7500 Versatile Interface
Processor (VIP). This table summarizes the two approaches and assumes that a
service-policy configured with the MQC is applied to the outbound interface.
Queuing of pak_priority Messages
Cisco 7500 Series (with distributed QoS and
Places pak_priority traffic in the class-default class queue
by default or in a specifically configured (separate) queue.
When queued to class-default, packets go to the tail end of
the queue. The pak_priority flag is used to avoid dropping the high-priority
RSP-based QoS and other platforms, which include the Cisco
7200, 3600, 2600 Series
In other words, on the Cisco 7500 Series, if an output service-policy
is attached to the interface, the packets are classified with respect to the
classes in that policy, and the pak_priority packet is placed at the end of the
chosen class queue. If the pak_priority packet does not match any user defined
class, it is placed at the tail of the class-default queue.
Note: With legacy queuing methods such as priority queuing and custom
queuing or with a default interface FIFO queue, non-RSP routers enqueue
pak_priority messages to the head of the queue to ensure both minimal latency
and minimal drop probability.
As noted in the Packet Prioritization Tags and
Queuing table, Cisco router platforms like the Cisco 7200, 3600 and 2600
series place pak_priority messages into a separate set of queues and not the
class-default set of queues.
There are three sets of queues on an interface:
2^n set of flow-based queues that consider such header values as the
source and destination IP addresses. The actual number of queues is based on
the bandwidth of the interface or virtual circuit. Refer to the description of
the fair-queue command in the
Queues for user-created classes.
Queues accessed on the basis of a hash of the linktype. For example,
IP microflows are classified by the fair queuing system into queues based on a
hash of the source and destination addresses and ports, TOS bits, and IP
protocol number. Frame Relay local management interface (LMI) messages are
queued based on a hash of the magic number that indicates that the message is
LMI. Messages with the pak_priority flag go into these separate linktype
This table lists the various queues and their conversation IDs (as seen
in the output of the show policy-map interface or show queue commands) for an
interface with greater than 512 Kbps of bandwidth.
Conversation / Queue Number
Type of Traffic
1 - 256
General flow-based traffic queues. Traffic that does not match
to a user-created class matches to class-default and one of the flow-based
257 - 263
Reserved for Cisco Discovery Protocol and for packets
marked with an internal high-priority flag.
Reserved queue for the priority class (classes configured with
the priority command). Look for the "Strict
Priority" value for the class in the show policy-map interface
output. The priority queue uses a conversation ID equal to the number of
dynamic queues plus 8.
265 and higher
Queues for user-created classes.
Note: The values in this table are implementation-dependent and subject to
The Intermediate System to Intermediate System (IS-IS) routing control
packets are a special case with respect to queuing and packet prioritization.
The IS-IS is the routing protocol for the Connectionless Network
Protocol (CLNP) of the International Organization for Standardization (ISO).
The developers of CLNP viewed TCP/IP as an interim protocol suite that the Open
System Interconnection (OSI) suite eventually would replace. In order to
support this predicted transition, Integrated IS-IS (or dual IS-IS) was created
as an extension to IS-IS to provide a single routing protocol capable of
routing both Connectionlesss-mode Network Service (CLNS) and IP. The protocol
was designed to operate in a pure CLNS environment, pure IP environment, or a
dual CLNS/IP environment.
Even when IS-IS is used to route only TCP/IP, IS-IS is still an ISO
CLNP protocol. The packets by which IS-IS communicates with its peers are CLNS
protocol data units (PDUs), which in turn means that even in an IP-only
environment, the queuing system and Cisco IOS cannot use IP precedence to
prioritize CLNS control messages. Instead, IS-IS packets receive priority
through the pak_priority mechanism inside the router.
This section considers the three general approaches to designing a
queuing strategy specifically to minimize the chances of dropped control
packets under heavy congestion conditions on the Cisco 7500 series and
VIPs. (Recall that non-RSP platforms place control packets in
separate queues by default.)
When to Use
Description of How to Configure
Match to a separate queue.
Most conservative strategy. Ensures little or no
Use the modular QoS CLI to configure a separate class and use
the bandwidth command to assign a minimum bandwidth
allocation to the matching traffic during periods of congestion. A class
configured with the bandwidth command uses a
scheduling "weight" based on the bandwidth and not on IP precedence. Refer to
Class Based Weighted Fair Queuing on ATM.
Match to class-default with fair queuing.
Sufficient for most configurations. Some control packets can be
dropped in the presence of congestion.
Use the IP precedence 6 automatically assigned by Cisco IOS to
the packet to influence its weight and thus its share of the bandwidth. See
Weighted Fair Queuing on ATM.
Match to class-default with FIFO queuing.
Not recommended for congested links. Some control packets can
be dropped in the presence of congestion.
This approach does not consider IP precedence. With VIP-based
QoS, the pak_priority messages are queued to the tail end of the FIFO queue.
This is an example of how to create a separate queue for RIP control
class-map match-all rp
match access-group 104
access-list 104 permit udp any eq rip any eq rip
!--- Create a class-map that matches an ACL permitting RIP.
!--- Create a policy-map (named "bandwidth") and specify
!--- class RP.
interface Serial1/0:0.1 point-to-point
ip unnumbered Loopback0
ip accounting precedence input
no cdp enable
frame-relay class sample
frame-relay interface-dlci 100 IETF
!--- Apply the map-class named "sample" to the PVC.
map-class frame-relay sample
frame-relay cir 256000
frame-relay bc 2560
frame-relay mincir 256000
no frame-relay adaptive-shaping
service-policy output bandwidth
frame-relay fragment 160
!--- Create a frame relay map-class and apply the service
!--- policy inside the map-class.
Consider these factors when you choose one of these approaches:
The particular routing protocol used and the configured timer values
for hellos and database refresh
The size of the database that needs to be exchanged and whether only
updates/changes or full tables are refreshed periodically
The amount of congestion expected at the interface or virtual
In other words, consider the chances of actually queuing high-priority
packets in the presence of congestion.
Traffic generated by the router represents a special case for outbound
QoS service policies. Some locally generated traffic must be treated as any
other user traffic, and the QoS system must apply the configured QoS mechanisms
to this traffic. An example of such traffic is performance probes that are
designed to measure the behavior incurred by packets of a given class. Other
locally generated traffic, particularly Layer 2 keepalives and routing protocol
messages, are vital to the basic functioning of the router and must not be
subject to some QoS features. For example, weighted random early detection
(WRED) must not drop Layer 2 keepalives when the average queue depth reaches a
In addition, packets destined to the router must be handled carefully.
For example, remember that a service-policy that applies class-based policing
must not apply to packets destined to the router to avoid dropping important
Note: As per design, RP generated packets are not accounted in Modular QoS
CLI counters even though those packets are properly classified/queued. Those
packets are not accounted in the show policy-map
interface command output.
This table lists how packets destined to and from the router currently
interact with key QoS features.
Originally worked only on Cisco Express Forwarding
Support for process switching and fast switching methods is
introduced in Cisco IOS Software Release 12.2(5) (CSCdt74738).
Inbound - Rate limiting can be applied.
Inbound interface must be configured with CEF if Committed Access Rate (CAR)
(and not class-based policing) is used. On a Cisco 7500 series router, traffic
policing can monitor CEF switching paths only.
Outbound - Rate limiting with CAR or
class-based policing works.
When you run Cisco IOS on both the supervisor and the MultiLayer Switch
Feature Card (MSFC) in the Catalyst 6000, the RP marks routing control packets
with IP precedence 6. This remarked value can be used with output scheduling to
map the routing control packets to the high queue, high threshold in the
weighted round robin (WRR) system. Such mapping of routing control packets
sourced by the MSFC happens automatically as long as QoS is enabled globally
with the mls qos command. If you enable QoS, it
causes the system to set up all queuing parameters, such as WRED drop
thresholds, WRR bandwidths, and queue limits. With QoS disabled globally, all
packets are mapped to the low queue, low threshold for output scheduling, of
As noted in the
QoS chapter of the Catalyst 6000 Configuration Guide, QoS supports
classification, marking, scheduling, and congestion avoidance using Layer 2
class of service (CoS) values at Ethernet ingress ports. Classification,
marking, scheduling, and congestion avoidance at Ethernet ingress ports do not
use or set Layer 3 IP precedence or DSCP values. In addition, with any
switching engine, QoS supports Ethernet egress port scheduling and congestion
avoidance with Layer 2 CoS values. As a result, crucial IP and non-IP packets
must be mapped to a CoS value, even if such values are used only internally as
part of the data bus header. Crucial IP packets have their IP precedence value
of 6 mapped to an equivalent CoS value of 6. Crucial non-IP packets, which
include IS-IS packets that originate from the MSFC, are marked with the
pak_priority flag and then such flagged packets are mapped to a CoS value of 6.
This mapping happens automatically in current Cisco IOS releases.
Neither ingress policers nor egress policers mark packets sourced by
the MSFC and destined for transmission through a physical Ethernet interface.
QoS configuration on the Catalyst 6000 is outside the scope of this
document. Refer to
QoS and the
LAN and ATM Switches Support Page for more information.