Table of Contents

Configuring Quality of Service

This chapter describes the quality of service (QoS) features built into your switch router and includes information on how to configure the QoS functionality. This chapter includes the following sections:

About Quality of Service

QoS refers to the capability of a network to provide better service to selected network traffic over various technologies, including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks that may use any or all of these underlying technologies.The following sections describe the Best-Effort, Integrated, and Differentiated service models that the QoS functionality offers.

Note   For more information about Policy Based Routing, refer to the Layer 3 Switching Software and Feature Configuration Guide.

Best-Effort Service

Best effort is a single service model in which an application sends data whenever it must, in any quantity, and without requesting permission or first informing the network. For best-effort service, the network delivers data if it can, without any assurance of reliability, delay bounds, or throughput.

The Cisco IOS QoS feature that implements best-effort service is first-in, first-out (FIFO) queueing. Best-effort service is suitable for a wide range of network applications such as general file transfers or e-mail.

Integrated Service

Integrated service is a multiple service model that can accommodate multiple QoS requirements. In this model the application requests a specific kind of service from the network before it sends data. Explicit signalling makes the request. The application informs the network of its traffic profile and requests a particular kind of service that can encompass its bandwidth and delay requirements. The application is expected to send data only after it gets a confirmation from the network. It is also expected to send data that lies within its described traffic profile.

The network performs admission control, based on information from the application and available network resources. It also commits to meeting the QoS requirements of the application as long as the traffic remains within the profile specifications. The network fulfills its commitment by maintaining per-flow state and then performing packet classification, policing, and intelligent queueing based on that state.

Differentiated Service

Differentiated service is a multiple service model that can satisfy differing QoS requirements. However, unlike the integrated service model, an application using differentiated service does not explicitly signal the router before sending data.

For differentiated service, the network tries to deliver a particular kind of service based on the QoS specified by each packet. This specification occurs in different ways, for example, while using the IP Precedence bit settings in IP packets or source and destination addresses. The network uses the QoS specification to classify, mark, shape, and police traffic, and to perform intelligent queueing.

About Layer 3 Switching Quality of Service

Layer 3 switching on the Catalyst 8500 switch router uses the packet classification feature in QoS to partition network traffic into multiple priority levels of classes of service. For example, by using the three precedence bits in the type-of-service (ToS) field of the IP packet header—two of the values are reserved for other purposes—you can categorize packets into a limited set of up to six traffic classes.

After you classify packets, you can utilize other QOS features to assign the appropriate traffic handling policies like congestion management and bandwidth allocation for each traffic class.

About Quality of Service Mechanisms

The Catalyst 8540 campus switch router provides extensive core Quality of Service (QoS) mechanisms that are built into the switch router architecture. These functions ensure policy enforcement and queuing of the ingress port, as well as weighted round-robin (WRR) scheduling at the egress port.

The two mechanisms discussed here are:

This is used when the ingress or the egress interface is an EPIF based interface or when the egress interface is an XPIF based interface without a configured IP QoS output policy.

IP QoS is the implementation of the Differentiated Services (DiffServ) model. It is used when the ingress and egress interfaces are enhanced Gigabit Ethernet interfaces, and the egress interface has an attached IP QoS output policy.

IP Precedence based Class of Service (CoS)

Layer 3 precedence based CoS uses the IP precedence values to partition traffic into multiple classes of service.

The system gathers IP precedence information from the IP header type-of-service field. For an incoming IP packet, the first two (most significant) bits of the service type field determine the delay priority. Layer 3 switching recognizes four QoS classes, Q-0 to Q-3, as summarized in Table 21-1.

Table 21-1   I QoS Delay Priorities and Queues

Your switch router can read the precedence field and switch the packet accordingly, but it cannot reclassify traffic. The edge router or switch is expected to set the precedence field according to its local policy.

The switch router queues packets based on the delay priority and the target next-hop interface.

About Scheduling and Weighted Round-Robin

Frame scheduling becomes increasingly important when an outgoing interface is congested. To handle this situation, network administrators can assign weights to each of the different queues. This provides bandwidth to higher priority applications (using IP precedence), while also granting fair access to lower priority queues. The frame schedule affords each queue the bandwidth allotted to it by the network administrator. This mapping is configurable both at the system and interface levels (as described later in this chapter).

The four queues between any pair of interfaces are configured to be part of the same service class. Bandwidth is not explicitly reserved for these four queues. Each of them is assigned a different WRR-scheduling weight, which determines the way they share the interface bandwidth. The WRR weight is user configurable; you can assign a different WRR weight for each queue.

Tip The higher the WRR weight, the higher the effective bandwidth for that particular queue.

You can find the effective bandwidth (in Mbps) for a particular queue with the following formula:

(W/S) x B = n Mbps,

where

W = WRR weight of the specified queue
S = sum of the weight of all active queues on the outgoing interface
B = available bandwidth in Mbps
n = effective bandwidth in Mbps

For example, if W is 4, S is 15, and B is 100, the formula would be (4/15) x 100 = 26 Mbps, and the effective bandwidth for the specified queue in this example is 26 Mbps.

Configuring Precedence to WRR Scheduling

This section describes the Cisco IOS commands necessary to configure QoS mapping at the system and interface levels. The commands described in this section are unique to the Layer 3 switching software.

Layer 3 switching software enables QoS-based forwarding by default.

To configure QoS scheduling at the system level, use the following command:

To set the precedence back to the default setting for the switch router, use the no version of the qos mapping precedence command.

Table 21-2 shows the default WRR weights for IP precedence.

For a complete description of the qos mapping precedence command, see the ATM and Layer 3 Switch Router Command Reference.

Mapping QoS Scheduling at the Interface Level

Configuring the QoS mapping at the interface level overrides the system-level mapping. Using the qos mapping precedence wrr-weight command, the network administrator can assign different WRR-scheduling weights for a particular precedence traffic between a pair of interfaces.

To configure QoS scheduling at the interface level, use the following command:

The QoS commands are applicable to both Gigabit Ethernet and Fast Ethernet interfaces.

To set the precedence back to the system-level default setting for the switch router, use the no version of the qos mapping precedence wrr-weight command.

Both the source and destination interface parameters are optional. When both are not specified, the system-level QoS mapping is configured. Otherwise, you can specify the source interface, the destination interface, or both, to configure the WRR weight for the traffic streams listed below.

The configuration takes precedence in the following order:

1. Traffic streams with a certain precedence, from a particular source interface to a particular destination interface

2. Traffic streams with a certain precedence to a particular destination interface

3. Traffic streams with a certain precedence from a particular source interface

Verifying the QoS Configuration

To verify the QoS configuration, use the following commands:

About IP QoS on the Enhanced Gigabit Ethernet Interfaces

DiffServ is a mechanism by which network service providers offer differing levels of network service to different traffic classes in order to provide QoS to users.

In a DiffServ network, routers, within the network handle packets on different traffic flows by applying different per-hop behaviors (PHBs). The PHB to be applied is signalled in-band, and is specified by a DiffServ code-point (DSCP) in the IP header of each packet. No explicit out-of-band signalling protocol such as RSVP is used. Per-hop behaviors are defined to configure granular allocation of bandwidth and resource buffering at each node. Per-flow or per-user forwarding state is not maintained within each node of network. The advantage of such a scheme is that many traffic flows can be aggregated to one of a small number of PHBs, simplifying the processing requirement on each router.

The following components are the building block in the Catalyst 8540 Differentiated Services implementation:

Packet Classification

Traffic Conditioning

Per hop behavior (PHB) definition

Figure 21-1 shows all the DiffServ components and their distribution between the ingress and egress points in the forwarding path.

Packet Classification

Packet classifiers select packets in a traffic stream based on the content of some portion of the packet header.

Classifiers are implemented in a ternary content addressable memory (TCAM). TCAM has the capability of providing variable length matches. The order in which classifiers are defined within a policy map is the order in which entries will be programmed in TCAM.

There are two types of classifiers:

Multi-field (MF) classifiers:

Behavior Aggregate (BA) classifiers:

Traffic Conditioning

A traffic stream is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner (marker, meter/policer).

Marking

Packet marking is a traffic conditioning action, performed on an identified flow at the ingress port. The marking action could cause the DSCP / precedence bits to be re-written or left unchanged, depending on user configuration.

The following types of markers are supported:

DSCP markers:

IP-Precedence markers:

Trusted Traffic:

Metering and Policing

Traffic matching a classifier may be metered using the Token Bucket Algorithm. The result of this metering is used to decide whether to police a particular traffic stream or not.

Incoming packets are passed unaltered if the packet conforms to the traffic profile for that class. Out of profile packets are discarded or marked down, depending on user configuration.

There are 32 instances of meters/policers available per physical interface. These may be distributed between Multi-Field/Behavior Aggregate classifiers as required by the user.

Note   There must be at least one traffic conditioning element associated with every classifier in an input policy map.

Per Hop Behavior Definition

Per Hop Behavior or PHB is the externally observable forwarding behavior (in terms of buffer/bandwidth resource allocation), applied to a particular traffic class. This is essentially defined by the queuing/scheduling/buffer management in the forwarding path.

Queuing

Once the traffic stream is classified and conditioned, the forwarding engine is consulted to get the destination interface to which the packet needs to be switched. There are four output queues for each physical interface and each can be assigned to an output traffic class. A direct lookup table, called the queue selector table, is used to determine which is the correct queue for the packet. This table is indexed using a combination of the output interface and DSCP from the packet header.

All entries in this table are initialized to 0 by default (Q0 is the queue for best effort behavior). This mapping may be changed through user configuration.

Figure 21-3 shows queue-implementation for each physical interface. Each queue can be assigned to a particular output traffic class.

Buffer Management

Each queue is associated with a threshold buffer group, which essentially defines a set of parameters for buffer management and drop behavior.

Threshold group parameters are defined as follows:

Discard limit value:

Marking limit value:

The Catalyst 8540 has a maximum of four buffer groups, and the above parameters may be defined for each of these buffer groups through user configuration.

Scheduling

Each of the four traffic classes are served by the scheduler according to it's configured weight. Scheduling is done using the Weighted Round Robin Algorithm.

The WRR scheduler guarantees a minimum bandwidth to each class, based on the assigned weight. Idle bandwidth is shared among the classes in a fair manner.

Congestion Control

Two drop policies are supported, tail drop and XPIF based Random Early Detect (or xRed).

Tail Drop

Queues fill up during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full.

On the Catalyst 8540, the point at which packets will start getting dropped is the user configured discard limit - as soon as the buffer filling drops below this threshold, packets will no longer be dropped) This is the default congestion avoidance mechanism.

xRED

This is a variation of the Random Early Detection Algorithm, as implemented on the Catalyst 8540.

A packet is EFCI-marked if the length of the queue in which it is buffered exceeds a pre-set marking threshold. By counting the number of EFCI-marked packets over an interval at an output port, the degree of congestion of the output port can be assessed.

In a given time interval, if Ne represents the total number of EFCI marked packets and Nt represents the total number of packets, then the ratio Ne/Nt follows the average queue length.

Thus, the port's average queue length is monitored, and packets are randomly discarded with a variable probability if the average queue length exceeds the configured threshold.

Configuring IP QoS Policies Using the Modular CLI

This section describes the tasks for configuring IP QoS functionality with the Modular QoS CLI.

For a complete description of the commands mentioned in this section, refer to the Cisco IOS Quality of Service Solutions Command Reference. The commands are listed alphabetically within the guide. To locate documentation of a specific command, use the command reference, master index, or on-line search.

Note   The Catalyst 8500 does not support all the commands documented in the Quality of Service Solutions Command Reference.

Configuring IP QoS on Enhanced Gigabit Ethernet Interfaces

The IP QoS configuration requires the following three steps, which are detailed in this section:

Step 2   Creating a service policy by associating the traffic class with one or more QoS policies using the policy-map command

Step 3   Attaching the service policy to the interface with the service-policy command

Defining a traffic class

The class-map command is used to define a traffic class.

A traffic class consists of two major elements:

The following commands describe how to configure a traffic class in global configuration mode:

Example

Note   Multiple match commands may be specified within the same class-map.

MF classifiers may only be used within input policy maps while BA classifiers may be used within input and/or output policy maps.

Creating a Service Policy

The policy-map command is used to define a service policy.

A policy map definition consists of:

The following commands show how to configure a service policy on an ingress interface (input policy map):

Example

Note   Input policy maps:

The following commands show how to configure a service policy on an egress interface (output policy map):

Example

Note   Output policy maps:

Configuring Buffer-Groups

Buffer groups are global resources that can be configured to be shared among output traffic classes. Four possible buffer groups are available.

Note   Configuring the discard-limit and the mark-limit using the buffer-group command is optional and not a necessary step in defining a service policy. If the buffer-group is not configured, default values for discard-limit and mark-limit apply.

Attaching a Service Policy to an Interface

Use the service-policy interface configuration command to attach a service policy to an interface and to specify the direction of the policy application (either on packets coming into the interface or packets leaving the interface).

Use the no form of the command to detach a service policy from an interface. The service-policy command syntax is:

service-policy {input | output} policy-map-name

no service-policy {input | output} policy-map-name

Although you can assign the same service policy to multiple interfaces, each interface can have only one service policy attached at the input and only one service policy attached at the output.

Example

TCAM Region for IP QoS

By default, there is no space reserved for IP QoS in TCAM. There needs to be a minimum of 512 entries for the IP QoS region in TCAM, for IP QoS functionality to be enabled.

This size is configurable, but requires a reload to take effect If enough space is not available in TCAM after the reload, IP QoS will get disabled automatically.

Tip TCAM space may be allocated for IP QoS using the command:

sdm ipqos number_of_entries.

Verifying the IP QoS Configuration

To verify the IP QoS configuration, use the following commands:

Example

The following example shows all policy maps configured:

Example

Example