CCNP 642-811 BCMSN Exam Certification Guide - Cisco press

Defining a QoS Policy 409

Notice that the CoS values now map to these per-hop behaviors, each having a specific drop precedence: 0 (best effort), 10 (AF11), 18 (AF21), 26 (AF31), 34 (AF41), 46 (EF), 48 (Internetwork Control), and 56 (Network Control). Now, if other DSCP values occur within your network traffic, you know exactly how your mapped values will be handled in relation to the others. (DSCP values 48 and 56 do not usually have a class or drop precedence associated with them, because they are reserved for routing protocol and other maintenance protocol traffic.)

Defining a QoS Policy

QoS policies are easy to define and use, thanks to the Modular QoS CLI (MQC) feature. Policies are defined and used in this order:

1.One or more QoS classes are defined to classify (identify) specific traffic. Think of each class as a template that matches a particular kind of traffic flow.

2.One or more QoS policies are defined to reference or group multiple QoS classes as a single entity. The classes identify a group of different types of traffic. Each policy also contains actions that can mark, police, or shape traffic classifed by each class.

3.Each egress interface can be assigned one QoS policy in each direction. For example, one policy can be assigned for inbound traffic on the interface, while another policy can be assigned for outbound traffic. When assigned, the policy begins to classify and act on traffic passing through the interface.

These steps are described in more detail in the next several sections.

Defining a QoS Class to Classify Traffic

First, define the QoS class with this global configuration command:

Switch(config)# class-map class-name [match-all | match-any]

You can configure multiple conditions into the class map to match or classify different types of traffic. If the class should match against all the conditions (the default), use the match-all keyword. Otherwise, use the match-any keyword to allow any of the conditions to trigger a match.

You can classify packets with traditional access lists, matching against any parameter contained in the IP packet header. You can also use Network-Based Application Recognition (NBAR) to match against more complex or dynamic fields.

After you configure the final match command, use the exit command to leave the class map configuration mode.

410 Chapter 17: DiffServ QoS Configuration

Classifying Traffic with an Access List

You must define the IP access list separately, as a global configuration command and not part of the class map. After you configure the access list with the access-list access-list-number or the ip access-list extended command, you can reference the access list as a matching condition using the following class map configuration command:

Switch(config-cmap)# match access-group name access-list

Here, you can specify the access list by name or number.

NOTE You can also easily match against CoS, IP Precedence, or DSCP values without defining a more complex access list. Do this with one of the following class map configuration commands, which match against up to eight values each:

Switch(config-cmap)# match ip precedence ipprec1 [...ipprecN]

Switch(config-cmap)# match ip dscp dscp1 [...dscpN]

Classifying Traffic with NBAR

NBAR offers a more complex inspection of IP packets. NBAR can recognize traffic from several applications, whether the UDP or TCP ports are statically or dynamically assigned. This allows the upper OSI layers to be inspected beyond simple port number matching. HTTP traffic can also be classified according to URL or host name.

To match a traffic flow with NBAR, use the following class map configuration command:

Switch(config-cmap)# match protocol protocol-name

The NBAR feature is periodically updated to support the recognition of newly developed applications. New protocol inspections can be added to an existing Cisco IOS Software version through the use of Packet Description Language Module (PDLM) files. This allows new additions to be added to the NBAR suite without having to upgrade the entire IOS image. You should review the most current information on Cisco.com to determine which protocols NBAR recognizes in your version of the IOS software.

NOTE For more information about NBAR, refer to the article “Network-Based Application Recognition,” which you can find at www.cisco.com/en/US/products/sw/iosswrel/ps1839/ products_feature_guide09186a0080087cd0.html.

The list of protocol names is rather lengthy. Do not worry about learning any of these; just be aware that there are many and expanding all the time. To give you an idea of the wide range of applications that NBAR recognizes, a sample listing of protocol name keywords can include the following:

■ Non-UDP/TCP protocols: egp, eigrp, gre, icmp, ipinip, ipsec

412 Chapter 17: DiffServ QoS Configuration

Marking QoS Information

After you use the class maps to correctly identify or classify the traffic, you can perform one of the following marking actions on that traffic:

■Mark the DSCP value.

Switch(config-pmap)# set ip dscp dscp-value

The DSCP value can be given as a decimal number (0 to 63) or as the name of a DSCP codepoint (ef, af11, or af12).

■Mark the IP Precedence value.

Switch(config-pmap)# set ip precedence ip-precedence-value

The IP Precedence value can be given as a decimal number (0 to 7).

Trusting QoS Information

In some cases, only certain QoS information contained in the classified traffic should be trusted. All other traffic is trusted according to other policies or conditions. Use the following policy map configuration command to establish policy-based trust:

Switch(config-pmap)# trust {cos | dscp | ip-precedence}

For these packets, the specified QoS information will be accepted for use within the switch; however, this information can still be overwritten or manipulated as part of the QoS policy.

Policing Classified Traffic

Although QoS policing is not covered in the BCMSN course, it is mentioned here so that you have an understanding of its use within the QoS process.

A policer is defined according to the scope of the traffic it monitors, as well as to the action it takes upon that traffic flow. An aggregate policer monitors the cumulative amount of data produced by one or more individual flows between a source and destination. In a more granular case, a microflow policer monitors only a single flow between a source and a destination.

Policers use a token bucket algorithm, where the lengths of matching inbound frames are added to the bucket. Every 0.25 ms (or 1/4000 of a second), the maximum sustained committed information rate (CIR) targeted by the policer is subtracted from the bucket. Traffic can also burst over the CIR, up to the normal burst rate, for a short period of time. In addition, traffic that rises above the normal burst rate is measured against the peak information rate (PIR). Traffic that stays within the policed limits (CIR and burst rates) is called in-profile, whereas excessive traffic is called out-of-profile.

414 Chapter 17: DiffServ QoS Configuration

Tuning Egress Scheduling

After you define and apply the QoS classes and policies, you can tune the scheduling process. Packet scheduling involves how the switch places each packet into an egress queue and how each queue is serviced. Catalyst switches support the Weighted Round Robin (WRR) scheduling algorithm.

Each queue associated with an interface is serviced according to its weight, relative to the other queues. Strict-priority queues do not have a weighting value; they are always serviced as long as they have packets waiting.

WRR looks at the weighting values to determine the ratio of how many packets to transmit from one queue versus another. Although the actual configuration command uses the keyword bandwidth, the values are actually relative weights used to form a ratio.

By default, interfaces with two standard queues are assigned weights 4 and 255, respectively. The second queue receives about 64 times the amount of data transmitted on its turn for every one unit of data from the first queue.

To change the weights of the queues, use the following interface configuration command:

Switch(config-if)# wrr-queue bandwidth weight1 weight2 [weight3] [weight4]

Weight values can range from 1 to 255. The number of weight parameters that you can set depends on the number of standard egress queues available on the interface. The number of standard queues varies between Catalyst platforms.

Using Congestion Avoidance

With egress queues, congestion avoidance is partnered with queue scheduling, so the two are indistinguishable. As a result, both features are configured with the WRR configuration commands beginning with wrr-queue.

Mapping Internal DSCP Values to CoS Values for Queueing

Recall that as packets travel within a switch, they each carry an internal DSCP value. That value is mapped from a trusted QoS information source when each packet enters the switch. After the switch determines which egress port each packet will use when exiting, some method must determine how the packet will be queued for transmission.

The internal DSCP values are mapped back into CoS values, which are then used for egress queueing and scheduling.

Using Congestion Avoidance 415

Table 17-4 provides the default DSCP-to-CoS mappings, with each range of DSCP values corresponding to a single CoS value.

Table 17-4 Default DSCP-to-CoS Value Mappings

To change the mapping, repeat the following global configuration command as many times as necessary:

Switch(config)# mls qos map dscp-cos dscp-list to cos-value

Here, the dscp-list can be a single DSCP value (0 to 63), a hyphenated range of values, or multiple values and ranges separated by commas. The cos-value is a single CoS value (0 to 7).

Mapping Packets into Egress Queues

As packets are moved toward the egress ports, they must be sorted so that each is placed in the correct prioritized egress queue. Otherwise, all packets would be put in the same queue, with no preference to any flow or type of traffic.

WRR places packets into egress queues according to a mapping between the CoS value and the queue number. Packets can also be buffered in a queue that has a desired drop threshold. Drop thresholds are used during congestion avoidance, as discussed in the later section, “Setting WRED Thresholds.”

To define the map that associates packet CoS values to specific egress queue drop thresholds, use the following interface configuration command:

Switch(config-if)# wrr-queue cos-map queue-id threshold-id cos-list

Packets with a CoS value specified in the cos-list will be placed in the queue ID given, with the threshold ID applied. By default, the CoS values are divided in half. CoS 0 and 1 go to queue 1 threshold 1, CoS 2 and 3 go to queue 1 threshold 2, CoS 4 goes to queue 2 threshold 1, and CoS 6 and 7 go to queue 2 threshold 2. CoS 5 always gets placed in the strict-priority queue, if one is available.