Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

CCNP 642-811 BCMSN Exam Certification Guide - Cisco press

.pdf
Скачиваний:
161
Добавлен:
24.05.2014
Размер:
10.85 Mб
Скачать

406 Chapter 17: DiffServ QoS Configuration

Figure 17-1 Mapping QoS Parameters to and from Internal DSCP Values

Catalyst Switch

Ingress Port

Classification

 

 

 

 

 

 

 

 

 

 

Congestion

or

 

and

 

 

 

Policers

 

Marking

 

 

 

Scheduling

 

 

 

 

 

 

 

 

 

 

 

 

Avoidance

VLAN

Trust

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Choose Queue

 

 

Choose Drop

CoS

 

 

 

 

 

 

 

 

 

 

 

 

Based on CoS

 

 

Thresholds

 

 

 

 

 

 

 

 

 

 

 

 

Queue 1

 

 

Based on CoS

 

 

 

 

 

 

 

Markdown

CoS

 

 

 

DSCP

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Map

 

 

 

 

Queue 2

 

 

 

 

IP Prec

 

 

 

 

 

 

 

 

DSCP

 

 

...

 

 

Queue

 

 

 

 

 

 

 

 

 

 

 

 

 

Compute

Drop

 

 

 

 

IP Prec

 

Priority

%

 

 

 

 

 

 

Internal

 

 

 

 

 

Port Default CoS

 

 

 

 

 

 

 

 

 

 

 

DSCP

 

 

 

Operations

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

on QoS Values

 

 

 

 

 

 

Trust CoS: mls qos map cos-dscp ...

 

 

 

 

 

 

 

Compute CoS

Trust IP Precedence: mls qos map ip-prec-dscp ...

 

 

 

 

 

 

 

From Internal DSCP

Trust DSCP: mls qos trust dscp ...

 

 

 

 

 

 

 

mls qos map dscp-cos ...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

or

mls qos map dscp-mutation ...

Egress Port

Transmit

Frame

Applying QoS Trust

When inbound packets are accepted into a switch, the switch can be selective about which (if any) of each packet’s QoS information will be trusted. If the packets originate from a trusted source, the QoS information can be safely trusted, too. Usually, it is a best practice to configure switches at the edge of a trusted QoS domain to verify or overwrite any QoS information that comes into the domain. This way, any other switch or router within the domain can blindly trust QoS information that is seen.

You can configure QoS trust in two ways:

Per-interface

As part of a QoS policy on specific types of traffic

The per-interface trust is described in the next section. Policy trust is described as part of the section, “Defining a QoS Policy.”

Trust QoS on an Interface

On each interface where consistent QoS trust is to be defined, use the following interface configuration command:

Switch(config-if)# mls qos trust {cos | dscp | ip-precedence}

Applying QoS Trust 407

Here, one of the following values can be trusted and used internally as the switch makes forwarding decisions:

The inbound CoS, which is taken from trunking tags

DSCP, which is taken from the inbound IP packet headers

IP Precedence, which is also taken from the inbound IP packet headers

Do Not Trust any QoS Information

If you choose to not trust any QoS information (the default condition), use the following interface configuration command:

Switch(config-if)# no mls qos trust

In this case, the inbound CoS and DSCP information are set to one of the following values:

0 (zero), which is the default

The interface default CoS value, which is defined using the mls qos cos cos-value interface configuration command

Then, you can make further modifications to the QoS information as part of a QoS class-based policy.

Mapping Inbound QoS Information

Any inbound QoS information, whether trusted or a fixed CoS value (untrusted), must be mapped into internal DSCP values. Each packet receives this new DSCP value, which is used as the packet travels throughout the switch. A separate map can be configured for these inbound parameters:

CoS—Each of the eight possible CoS values is mapped into an internal DSCP value.

Table 17-2 provides the default mapping, with each DSCP value offering “best effort” delivery.

Table 17-2 CoS-to-Internal DSCP Value Mapping

CoS

0

1

2

3

4

5

6

7

 

 

 

 

 

 

 

 

 

DSCP

0

8

16

24

32

40

48

56

 

Default

AF10

AF20

AF30

AF40

EF

(Internet-

(Network

 

 

 

 

 

 

 

work Control)

Control)

 

 

 

 

 

 

 

 

 

To change the mapping, use the following global configuration command, where each of the dscp values is a number 0 to 63:

Switch(config)# mls qos map cos-dscp dscp1 ... dscp8

408Chapter 17: DiffServ QoS Configuration

IP Precedence—Each of the eight possible IP Precedence values is mapped into an internal DSCP value.

Table 17-3 provides the default mapping, with each DSCP value offering “best effort” delivery.

Table 17-3 IP Precedence-to-Internal DSCP Value Mapping

IP

0

1

2

3

4

5

6

7

Precedence

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

DSCP

0

8

16

24

32

40

48

56

 

Default

AF10

AF20

AF30

AF40

EF

(Internet-

(Network

 

 

 

 

 

 

 

work

Control)

 

 

 

 

 

 

 

Control)

 

 

 

 

 

 

 

 

 

 

To change the mapping, use the following global configuration command, where each of the dscp values is a number from 0 to 63:

Switch(config)# mls qos map ip-prec-dscp dscp1 ... dscp8

DSCP—Inbound DSCP values can be mapped into different internal DSCP values using a DSCP mutation map. This can be handy when the switch is at the boundary between two QoS domains.

By default, no DSCP mutation occurs. If inbound DSCP information is trusted, it is used as-is for the internal DSCP.

To define a DSCP mutation map, first create a named map consisting of up to eight entries by repeating this global configuration command:

Switch(config)# mls qos map dscp-mutation dscp-mutation-name in-dscp to outdscp

Each of the dscp values is a number from 0 to 63. Then, apply the mutation map to a specific ingress interface with this interface configuration command:

Switch(config-if)# mls qos dscp-mutation dscp-mutation-name

NOTE The default mapping from CoS or IP Precedence to DSCP only uses DSCP values that indicate “best effort” delivery. That is fine for a default, but you should always alter the default mapping so that distinct drop precedences are used instead. For example, CoS 3 defaults to AF30 (the zero means “best effort”). It is better practice to map it to something like AF31 so that switches and routers along the way can attempt to drop other less-critical traffic in preference to this traffic.

For example, you can use a common CoS-to-DSCP mapping with the following command:

mls qos map cos-dscp 0 10 18 26 34 46 48 56

You can use Table 16-2 as a handy reference to convert between any QoS parameter or value.

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

Defining a QoS Policy 411

Static UDP/TCP protocols: bgp, cuseeme, dhcp, dns, finger, gopher, http, secure-http, imap, irc, kerberos, l2tp, ldap, pptp, sqlserver, netbios, nfs, nntp, notes, novadigm, ntp, pcanywhere, pop3, printer, rip, rsvp, secure-ftp, secure-imap, secure-irc, secure-ldap, smtp, snmp, secure-nntp, socks, secure-pop3, ssh, secure-telnet, syslog, telnet, xwindows

Stateful (dynamic) UDP/TCP protocols: citrix, citrix app, ftp, exchange, fasttrack, gnutella, http, kazaa2, napster, netshow, rcmd, realaudio, rtp, sqlnet, streamwork, sunrpc, tftp, vdolive

What Happens When NBAR Is Enabled?

As a bonus, think about what happens on a Catalyst switch when NBAR is enabled. Recall from Chapters 3 and 13 how a Layer 3 switch operates. Normally, Cisco Express Forwarding (CEF) is used to efficiently switch packets after the CEF and ternary content addressable memory (TCAM) tables are populated. Packets can be inspected with access lists by using the TCAM, with no performance penalty.

If NBAR is enabled on an interface, packets must also be inspected. For protocols that use a static port number, you can think of NBAR as using an access list for matching. Again, this might not impact switching performance if the TCAM is used. For other “stateful” protocols, involving dynamic port numbers or other information buried within the packet, NBAR must inspect beyond the IP header. In this case, neither access lists nor the TCAM can be used; instead, something must perform the inspection by brute force.

Therefore, when NBAR is configured on an interface, the switch CPU (the MSFC2, for example) must process all traffic passing in and out of that interface. Obviously, this is not as efficient as CEFswitching in hardware, so performance through the interface could suffer.

Defining a QoS Policy

First, define the QoS policy with the following global configuration command:

Switch(config)# policy-map policy-name

Class maps must then be identified so that traffic can be classified for the policy. You can use multiple commands to perform an action on the classified traffic. After the final policy map command is configured, use the exit command to leave the policy map configuration mode.

Identifying the QoS Class Maps

In the policy map, you must identify each class map that will be used as part of an overall QoS policy. Use the following policy map configuration command:

Switch(config-pmap)# class class-name

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.

Defining a QoS Policy 413

Policers can take action on any traffic that stays under the CIR (conform action), rises above the burst rate (exceed action), and rises above the PIR (violate action). The action taken can be the following:

Forward the traffic.

Drop the traffic.

Mark down the DSCP value of the traffic before forwarding.

To define a policer, use the following policy map configuration command:

police [aggregate name] [flow] bits-per-second normal-burst-bytes [extended-burst- bytes] [pir peak-rate-bps] [conform-action action] [exceed-action action] [violateaction action]

Here, an action can be one of the following:

drop—Drop the packet.

set-dscp-transmit [new-dscp]—Set the DSCP value in the packet.

set-prec-transmit [new-precedence]—Set the IP Precedence value in the packet.

transmit—Send the packet normally.

NOTE A policer can also take other unique actions on matched traffic. For example, you can use a policer to identify and dispose of undesirable or unwanted traffic entering (or exiting) your network. A policer can drop packets that are classified by a class map. This is done by giving the policer bogus rates and making all actions (conform, exceed, and violate) set to drop.

Apply a QoS Policy to an Interface

After a QoS policy map has been defined, it can be applied to a physical interface on the switch. An interface can have only one active policy applied in each direction. This means that two policies can be applied to an interface:

One for inbound traffic

One for outbound traffic

Use the following interface configuration command to begin using a policy:

Switch(config-if)# service-policy [input | output] policy-name

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

DSCP

0-7

8-15

16-23

24-31

32-39

40-47

48-55

56-63

 

Default

AF10-AF13

AF20-AF23

AF30-AF33

AF40-AF43

EF

Internetwork

Network

 

 

 

 

 

 

 

Control

Control

 

 

 

 

 

 

 

 

 

CoS

0

1

2

3

4

5

6

7

 

 

 

 

 

 

 

 

 

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.

Соседние файлы в предмете Сети и Телекоммуникации