Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
DQOS Exam Certification Guide - Cisco press.pdf
Скачиваний:
69
Добавлен:
24.05.2014
Размер:
12.7 Mб
Скачать

862 Appendix B: Topics on the CCIP QoS Exam

The three distributed WFQ options are as follows:

Distributed WFQ (dWFQ)

ToS-based WFQ

QoS group–based WFQ

All three tools require distributed CEF (dCEF) processing to be enabled globally, and on the interface on which distributed WFQ is enabled. The following three sections outline the basic similarities and differences among the three distributed WFQ options, respectively.

WFQ terminology can be confusing at best. Table B-8 lists some of the fundamental terms and their respective definitions. Note that some terms can have more than one meaning.

Table B-8

WFQ Terminology

 

 

 

 

 

Term

Possible Use for the Term

 

 

 

 

WFQ

Stands for Weighted Fair Queuing. Can specifically refer to Flow-

 

 

Based WFQ, as described in Chapter 4. Can also refer to the

 

 

broader family of queuing tools that have WFQ as part of their

 

 

names.

 

 

 

 

Flow-Based WFQ

Specifically refers to WFQ as described in Chapter 4.

 

 

 

 

Distributed WFQ, or dWFQ

Stands for distributed WFQ. Can specifically refer to Flow-Based

 

 

dWFQ, as described in the next section. This can also refer to the

 

 

broader family of queuing tools that have dWFQ as part of their

 

 

names. These tools only function on Cisco 7500 series routers.

 

 

 

 

Flow-Based dWFQ

Specifically refers to dWFQ as described in the next section.

 

 

 

 

ToS-Based dWFQ

One of the dWFQ tools, with classification based on the ToS byte.

 

 

 

 

QoS Group–Based dWFQ

One of the dWFQ tools, with classification based on the QoS

 

 

groups.

 

 

 

 

CBWFQ

Stands for Class-Based WFQ. Refers to a queuing tool that can be

 

 

applied to most Cisco routers; it uses the Modular QoS command-

 

 

line interface (MQC) for configuration.

 

 

 

Flow-Based dWFQ

Flow-Based dWFQ classifies packets based on the flow, examining the source and destination IP address and port and the protocol type. All of the other main features of dWFQ differ slightly when compared to WFQ. Table B-9 lists several points for comparison.

Congestion Management (Queuing) 863

Table B-9

WFQ Functions and Features

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Max # of

Can It Be Used on

 

Tool

Classification

Drop Policy

Weighting

Queues

Shaping Queues?

 

 

 

 

 

 

 

 

WFQ

Flow based

Modified tail drop

Based on IP

4096

Yes

 

 

 

 

precedence

 

 

 

 

 

 

 

 

 

 

dWFQ

Flow based

Tail drop for individ-

None

512

No

 

 

 

ual queues, plus a

 

 

 

 

 

 

maximum aggregate

 

 

 

 

 

 

for all queues

 

 

 

 

 

 

 

 

 

 

The first big difference between WFQ and dWFQ involves the tail-drop policy. dWFQ has to answer two simple questions when it determines whether to drop a packet:

Has the aggregate packet limit been exceeded

Has the individual queue limit been exceeded?

If either of these questions is true (the aggregate packet limit or the individual queue limit has been exceeded), the new packet is discarded. Unlike WFQ, dWFQ cannot enqueue a packet, only to discard it later because its sequence number (SN) is larger than a new packet’s SN. dWFQ uses the terms “aggregate limit” and “individual limit” to describe the limit over all queues and the limit per queue, respectively.

Unlike WFQ, dWFQ ignores the IP precedence value when calculating the SN of a packet. In other words, dWFQ does not actually weight the packet, totally ignoring the contents of the ToS byte. In effect, all packets are weighted equally, so dWFQ always prefers lower-volume flows in comparison to higher-volume flows.

Another difference between the two is that dWFQ does allow for the maximum queue length to be changed, but the number of queues remains constant at 512.

Finally, one other difference between WFQ and dWFQ has to do with how dWFQ works internally. dWFQ uses a mechanism called a calendar queue to sort all the packets waiting in a dWFQ queue. WFQ uses a simple sorted linked list. The effect is the same—both schedulers select the packet with the lowest SN as the next packet to be forwarded to the TX Queue/TX Ring. By using a calendar queue, however, dWFQ actually performs the final scheduling function more efficiently, which is particularly useful on higher-speed interfaces. (Note that the internals of calendar queues is not important for the QoS exam; if you want to read more, however, refer to Inside Cisco IOS Software Architecture.)

dWFQ Configuration

dWFQ configuration, like WFQ, takes little effort. The fair-queue interface subcommand enables flow-based dWFQ on the interface. If you want to change the aggregate or individual

864 Appendix B: Topics on the CCIP QoS Exam

queue limits, you use the fair-queue aggregate-limit and fair-queue individual-limit commands, respectively. You can use the same familiar show commands to examine the status of dWFQ. Tables B-10 and B-11 list the configuration commands and exec commands for Flow-Based dWFQ.

Table B-10 Configuration Command Reference for Flow-Based dWFQ

 

Command

 

Mode and Function

 

 

 

 

 

fair-queue

 

Interface configuration mode; enables dWFQ. There

 

 

 

are no other parameters on this command when it’s

 

 

 

used with dWFQ.

 

 

 

 

 

fair-queue aggregate-limit aggregate-packets

 

Interface configuration mode; sets the aggregate

 

 

 

limit of the number of packets held in all dWFQ

 

 

 

queues.

 

 

 

 

 

fair-queue individual-limit individual-packet

 

Interface configuration subcommand; sets the

 

 

 

maximum number of packets in a single queue.

 

 

 

 

Table B-11 Exec Command Reference for Flow-Based dWFQ

 

 

 

 

 

Command

 

Function

 

 

 

 

 

show queue interface-name interface-number

 

Lists information about the packets that are waiting

 

[vc [vpi/] vci]]

 

in a queue on the interface

 

 

 

 

 

show queueing [custom | fair | priority |

 

Lists configuration and statistical information about

 

random-detect [interface atm-subinterface

 

the queuing tool on an interface

 

[vc [[vpi/] vci]]]]

 

 

 

 

 

 

Coincidentally, in some cases, a valid configuration for WFQ can be identical to a valid configuration for dWFQ. For instance, the fair-queue subcommand is used to enable both WFQ and dWFQ on an interface. Example B-12 shows a configuration on the familiar R3, which has now been upgraded to a 7500 series router with VIP2-50 line cards:

Example B-12 dWFQ Configuration

ip cef

!

interface serial 0/0/1 encapsulation ppp

description Serial interface on VIP2-50 fair-queue

In the example, CEF has been enabled globally, and the fair-queue command has been added to the serial interface. If the serial interface were not on a VIP at all, WFQ would be performed. With a VIP2-50 installed, dWFQ would be performed.

Congestion Management (Queuing) 865

Figure B-8 summarizes the sequencing and main features of dWFQ.

Figure B-8 Flow-Based dWFQ: Summary of Main Features

3)Maximum Number of Queues

4)Maximum Queue Length

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5) Scheduling Inside Queue

 

6) Scheduler Logic

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Always 512

 

 

 

Process:

 

1) Classification

Assign SN

2) Drop Decision

 

 

Queues

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

?

 

 

 

 

 

 

 

 

 

 

Unpublished

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SN Calculation

 

 

 

 

 

 

 

Max Length

 

 

 

 

 

 

TX Queue/Ring

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Not Published

Dropped

 

 

 

 

 

 

4096

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

No Weighting in

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Result: Favors

 

 

 

 

 

 

 

 

 

 

Calculation

 

 

 

 

 

 

 

.

 

 

 

 

Flows with Lower

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Byte Volumes

 

 

 

 

 

 

 

 

 

 

 

Modified Tail

.

 

 

 

 

 

 

 

 

Always a Combination Of:

Drop Based on

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Aggregate and

 

 

FIFO

 

 

 

 

 

 

 

- Source/Destination IP Address

 

 

 

 

 

 

 

 

 

Individual Queue

 

 

 

 

 

 

 

 

 

- Transport Protocol Type

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Limits

 

 

 

 

 

 

 

 

 

 

 

- Source/Destination Port

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ToS-Based dWFQ

ToS-Based dWFQ uses a totally different classification method and a totally different scheduler as compared with WFQ. After reading this section, you may wonder why Cisco calls this tool WFQ at all, because it does not resemble WFQ in very many ways! ToS-Based WFQ classifies based on the 2 low-order bits in the IP Precedence field—in other words, the second and third bits of the Precedence field. It places packets into one of four queues based on these values. It does not consider the flow at all; it is a class-based tool, as opposed to a flow-based tool.

Classification is based on the 2 low-order bits in the IP Precedence field, as opposed to WFQ’s flow-based classification.

Although the details are not published, ToS-Based dWFQ does use a fair-queuing scheduler, with the weighting based on the bandwidth percentages configured in each case. If only 2 queues were used, and one queue were given 75 percent of the bandwidth, and the other queue were given 25 percent, for example, internally, IOS calculates weights for the 2 queues with a ratio of 3:1. That’s why it’s called WFQ, although ToS-Based dWFQ differs significantly from WFQ. Table B-12 lists points for comparison, which are illustrated in Figure B-9.

Table B-12 ToS-Based WFQ Functions and Features

 

 

 

 

 

Can It Be Used

 

 

 

 

Max # of

on Shaping

Tool

Classification

Drop Policy

Weighting

Queues

Queues?

 

 

 

 

 

 

ToS-

Class based, predi-

Same as dWFQ

Configured as

4

No

Based

cated on low-order

 

percentage of

 

 

WFQ

2 bits of precedence

 

link bandwidth

 

 

 

 

 

per queue

 

 

 

 

 

 

 

 

866 Appendix B: Topics on the CCIP QoS Exam

Figure B-9 ToS-Based dWFQ: Summary of Main Features

1) Classification

4 Classes, Based on 2 LowOrder IP Precedence Bits

3)Maximum Number of Queues

4)Maximum Queue Length

 

 

 

 

 

 

 

 

5) Scheduling Inside Queue

 

6) Scheduler Logic

 

 

 

 

 

 

 

 

 

 

Always 4

 

 

 

Process:

Assign SN

2) Drop Decision

 

 

Queues

 

 

 

 

 

 

 

 

 

 

 

?

 

 

 

 

 

 

 

 

 

 

Unpublished

 

 

 

 

 

 

 

 

 

 

 

 

SN Calculation

 

 

 

 

 

 

 

Max Length

 

 

 

 

 

 

TX Queue/Ring

 

 

 

 

 

 

 

 

 

 

 

 

 

Not Published

Dropped

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4096

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Result: Gives Each

 

 

 

 

 

 

 

 

.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Queue the

 

 

 

 

 

 

 

 

.

 

 

 

 

Weight Based

 

 

 

 

 

 

 

 

 

 

 

Configured

on Configured

Modified Tail

.

 

 

 

 

Percentage

Percentage

Drop Based on

 

 

 

 

 

 

 

Bandwidth

 

 

 

 

 

 

Bandwidth

Aggregate and

 

 

FIFO

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Individual Queue

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Limits

 

 

 

 

 

 

 

 

 

 

 

The classification function cannot be changed for ToS-Based WFQ. It always places packets into one of four queues, based on the 2 low-order bits in the IP Precedence field. In other words, precedence 0 and 4 go into Queue 0, because decimal 0 converts to 000, and decimal 4 converts to 100—so the 2 low-order bits are equal. Likewise, precedence 1 and 5 end up in Queue 1, precedence 2 and 6 in Queue 2, and precedence 3 and 7 in Queue 3.

The drop policy is just like dWFQ, using an aggregate limit and individual queue limit method to set the value.

The scheduler provides a percentage of bandwidth for each queue. Cisco does not publish the scheduler logic, but it works like WFQ, using SNs. IOS derives the weights for each queue based on the configured bandwidth percentages. Interestingly, the parameter is actually called weight, although it is interpreted as a percentage of bandwidth. The percentages default to

10 percent, 20 percent, 30 percent, and 40 percent, for Queues 0 through 3, respectively. You can configure the percentages for Queues 1 through 3, with the rest being assigned to Queue 0.

ToS-Based WFQ Configuration

The configuration for ToS-Based dWFQ is simple. Tables B-13 and B-14 list the generic commands, and an example follows these tables.

Configuring the fair-queue tos subcommand on an interface enables ToS-Based dWFQ. For this command to work, distributed CEF (dCEF) must be enabled, and the interface must really be on a VIP2-xx, where xx is 40 or higher. Example B-13 shows a sample configuration, along with changes to the bandwidth percentages given to Queues 1, 2, and 3. In this case, Queue 0 gets 39 percent of the link bandwidth, because 61 percent has been assigned using configuration commands.

 

 

Congestion Management (Queuing) 867

 

 

 

 

Table B-13

Configuration Command Reference for ToS-Based dWFQ

 

 

 

 

 

Command

Mode and Function

 

 

 

 

 

 

fair-queue tos

Interface configuration mode; enables ToS-Based

 

 

 

dWFQ. There are no other parameters on this

 

 

 

command when it’s used with dWFQ.

 

 

 

 

 

 

fair-queue aggregate-limit aggregate-packets

Interface configuration mode; sets the aggregate

 

 

 

limit of the number of packets held in all dWFQ

 

 

 

queues.

 

 

 

 

 

 

fair-queue individual-limit individual-packet

Interface configuration subcommand; sets the

 

 

 

maximum number of packets in a single queue.

 

 

 

 

 

 

fair-queue {qos-group number | tos number}

Interface configuration subcommand; sets the

 

 

limit class-packet

individual queue limit for a single queue. Takes

 

 

 

precedence over the fair-queue individual-limit

 

 

 

command.

 

 

 

 

 

 

fair-queue {qos-group number | tos number}

Interface subcommand; sets the percentage link

 

 

weight weight

bandwidth assigned to the queue. The tos parameter

 

 

 

can be 1, 2, or 3.

 

 

 

 

 

Table B-14

Exec Command Reference for ToS-Based dWFQ

 

 

 

 

 

 

Command

Function

 

 

 

 

 

 

show queue interface-name interface-number

Lists information about the packets that are waiting

 

 

[vc [vpi/] vci]]

in a queue on the interface

 

 

 

 

 

 

show queueing [custom | fair | priority |

Lists configuration and statistical information about

 

 

random-detect [interface atm-subinterface

the queuing tool on an interface

 

 

[vc [[vpi/] vci]]]]

 

 

 

 

 

 

Example B-13 ToS-Based dWFQ Configuration

ip cef

!

interface serial 0/0/1 encapsulation ppp

description Serial interface on VIP2-50 fair-queue tos

fair-queue tos 1 weight 30 fair-queue tos 2 weight 30 fair-queue tos 3 weight 1