s09 - ip qos - modular qos cli sp

IP QoS Modular QoS CLI Service Policy -7 • MQC Supports the following QoS mechanisms: – Class-based Weighted Fair Queuing CB-WFQ to guarantee bandwidth – Class-based Low-latency Queuing

Trang 1

Modular QoS CLI Service Policy

Overview

This module describes the policy part of the Modular QoS CLI (MQC) The module describes all the mechanisms that are currently supported by the MQC As well, the module describes the class-based approach to the marking, shaping, policing, dropping and/or scheduling of IP packets using the modular QoS CLI

Objectives

Upon completion of this module, you will be able to perform the following tasks:

n Describe the policy part of the Modular QoS CLI

n Configure packet marking with modular CLI

n Configure policing and shaping with modular CLI

n Configure class-based WFQ with modular CLI

n Configure congestion avoidance mechanisms (WRED) with modular CLI

n Configure low-latency queuing

n Monitor and troubleshoot policy maps

Trang 2

Upon completion of this lesson, you will be able to perform the following tasks:

n Describe and configure policy maps

n List all the QoS mechanisms currently available in the MQC

n Monitor and troubleshoot policy maps

Trang 3

Copyright  2001, Cisco Systems, Inc IP QoS Modular QoS CLI Service Policy 9-3

• One aspect of modularity of the MQC is the configuration part

• MQC is split into two modules:

–Configuration of classification

–Configuration of service policies

• Classification is configured by using class maps

• Service Policy is configured by using policy maps

The Cisco IOS Modular QoS CLI (MQC) is the new, unified method of QoS mechanism configuration in Cisco IOS MQC separates classification and QoS mechanism configuration by separating the configuration tasks into:

n Configuration of class-maps, which define the classification of traffic

n Configuration of service policies, which define how QoS mechanisms are applied to traffic classes

This creates a flexible environment for the modular configuration of many QoS features, and significantly reduces overhead and the possibility of errors because configuration information is not unnecessarily duplicated

Trang 4

Modular QoS CLI

Classification Service Policy

• Up to 256 classes can be used within one service policy

The service policy is used to configure QoS mechanisms, which may be applied to classes The QoS mechanisms implement local per-hop behaviors (PHBs) for attached traffic classes The QoS system, which implements PHB configured via the MQC, is the Class-Based Weighted Fair Queuing system, which integrates many QoS features in a single system, configured via a common (MQC) interface

A service policy can have up to 256 classes used within it and attached to an interface Class-based Weighted Fair Queuing and Class-based Low-latency Queuing are an exception – only 64 classes can be used with one service policy

Trang 5

• MQC Supports the following QoS mechanisms:

– Class-based Weighted Fair Queuing (CB-WFQ) to guarantee bandwidth

– Class-based Low-latency Queuing (CB-LLQ) to guarantee bandwidth and low-latency

– Class-based Policing (CB-Policing) to limit traffic rate by dropping excess traffic

– Class-based Shaping (CB-Shaping) to limit traffic rate by delaying excess traffic

– Class-based Marking (CB-Marking) to mark packets

The MQC configures the CB-WFQ system, which in turn implements the following QoS functions:

n Class-based Weighted Fair Queuing, which is used to guarantee bandwidth within the CB-WFQ system

n Class-based Low-latency Queuing, which is used to guarantee bandwidth and provide low latency to time-critical traffic

n Class-based Policing, which performs rate limiting by traffic policing

n Class-based Shaping, which performs rate limiting by traffic shaping

n Class-based Marking, which performs packet and frame marking

Trang 6

Configuring Policy Maps

policy-map name

Router(config)#

• Enter policy-map configuration mode

• Policy maps are identified by a case-sensitive name

class class-map

Router(config-pmap)#

• Enter the per-class policy configuration mode by using the name of a previously configured class-map

• Use the name “class-default” to configure the policy for the default class

class class-map condition

Router(config-pmap)#

• Optionally you can define a new class-map by entering the condition after the name of the new class map

• Class map will use the match-any strategy

Service policies are configured using the policy-map command Up to 256 classes can be used within one policy-map using the class command with the name of a

The following table shows starting and resulting configuration modes for the

class-map, policy-map and class commands:

Starting configuration mode

Command Configuration mode

Router(config)# class-map Router(config-cmap)#

Router(config)# policy-map Router(config-pmap)#

Router(config-pmap)# class Router(config-pmap-c)#

All traffic that is not classified by any of the class-maps used within the policy map

is part of the default class class-default This class has no QoS guarantees by

default The default cla ss, when used on output, can use one FIFO queue of flow-based WFQ The default class is part of every policy-map even if not

Trang 7

Renaming a policy map would normally require the renaming of all the references

to the policy map Using the rename command simplifies the renaming process by

automatically renaming all references

The remainder of this module focuses on the various QoS mechanisms that are

configured per-class within the policy-map configuration mode (config-pmap-c)

Trang 8

Configuring Policy Maps

service-policy {input | output} policy-map

! policy-map PM class HTTP bandwidth 2000 class class -default bandwidth 6000

!

class-map HTTP match protocol http

! policy -map PM class HTTP bandwidth 2000 class class-default bandwidth 6000

!

interface Serial0/0 service -policy output PM

!

interface Serial0/0 service -policy output PM

!

The last configuration step when configuring QoS mechanisms using the Modular QoS CLI, is to attach a policy map to the inbound or outbound packets, using the

service -policy command

The router immediately verifies the correctness of parameters used in the policy map If there is a mistake in the policy-map configuration, the router will display a message explaining what is wrong with the policy map

The sample configuration shows how a policy map is used to separate HTTP from other traffic HTTP is guaranteed 2Mbps All other traffic belongs to the default class and is guaranteed 6Mbps

Trang 9

service -policy output PM2

!

interface atm 5/0/0.1 point-to-point service -policy output PM1

! interface atm 5/0/0.2 point-to-point pvc 1/40

service-policy output PM2

!

Router( config-subif )#

• Service policies can be attached to an ATM (sub)interface

• Using service policies on the main interface and subinterfaces

at the same time is not supported in the distributed (VIP-based) version

Router( config-if-atm-vc )#

• Service policies can also be attached to an ATM PVC

Service policies can be applied to interfaces, subinterfaces or individual ATM virtual circuits Refer to the “IP QoS – IP over ATM” module for a more detailed description of MQC usage on ATM interfaces

Trang 10

Attaching Policy Maps to Frame

• Using service policies on the main interface and subinterfaces at the same time is not supported in the distributed (VIP-based) version

Service policies can also be used on Frame Relay interfaces or subinterfaces

Trang 11

! interface Serial0/0 encapsulation frame-relay

! interface Serial0/0.1 point-to-point frame-relay class Voice

! map-class frame-relay Voice service-policy output LLQ

!

class-map Voice match protocol vofr

! policy -map LLQ class Voice priority 100

! interface Serial0/0 encapsulation frame -relay

! interface Serial0/0.1 point-to-point frame -relay class Voice

! map-class frame-relay Voice service -policy output LLQ

Trang 12

Policy Map Example

class-map match -all Test1 match protocol http match access-group 10 0 class-map match -any Test2 match protocol http match access-group 10 1

! policy-map Test class Test1 bandwidth 100 class Test2 bandwidth 200 class Test3 access-group 100 bandwidth 300

! access-list 100 permit tcp any host 10.1.1.1 access-list 101 permit tcp any host 10.1.1.2

class-map match-all Test1 match protocol http match access -group 100 class-map match-any Test2 match protocol http match access -group 101

! policy -map Test class Test1 bandwidth 100 class Test2 bandwidth 200 class Test3 access-group 100 bandwidth 300

! access -list 100 permit tcp any host 10.1.1.1 access -list 101 permit tcp any host 10.1.1.2

The example shows the configuration of a policy map using three classes The first

two classes were separately configured using the class-map command The third

class was configured “on the fly” by specifying the match condition after the name

of the class

Class Test1 has two match conditions evaluated in the match-all strategy

Classes Test2 and Test3 use the match-any strategy

Trang 13

Weighted Fair Queueing Bandwidth 200 (kbps) Max Threshold 64 (packets) Class Test3

Weighted Fair Queueing Bandwidth 300 (kbps) Max Threshold 64 (packets)

Router # show policy -map Policy Map Test Class Test1 Weighted Fair Queueing Bandwidth 100 (kbps) Max Threshold 64 (packets) Class Test2

Weighted Fair Queueing Bandwidth 200 (kbps) Max Threshold 64 (packets) Class Test3

Weighted Fair Queueing Bandwidth 300 (kbps) Max Threshold 64 (packets)

The show policy-map command can be used to verify the configuration of a

policy map

Trang 14

Monitoring and Troubleshooting

(depth/total drops/no-buffer drops) 0/0/0

Class-map: class -default (match-any) (1143/0)

Class-map: Test1 (match-all) (1103/3)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 101 (1107)

Match: access-group 102 (1111) Match: protocol http (1115) Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 100 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0

(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any) (1143/0)

25 packets, 19310 bytes

5 minute offered rate 1000 bps, drop rate 0 bps Match: any (1147)

The show policy-map command also displays live information if the interface

keyword is used The sample output shows the parameters and statistics of the policy map attached to outbound traffic on interface FastEthernet0/0

Trang 15

All QoS mechanisms using the Modular QoS CLI (MQC) are configured using the following three commands:

n Class-map global configuration command to configure classification

n Policy-map global configuration command to create a service policy

n Class command in the policy-map configuration mode to attach QoS

mechanisms to a class The MQC supports the following QoS mechanisms:

n Class-based Weighted Fair Queuing

n Class-based Low-latency Queuing

n Class-based Weighted Random Early Detection

n Class-based Policing

n Class-based Shaping

n Class-based Marking

Lesson Review

1 What are the benefits of using MQC?

2 How many classes can be used for one service policy?

Trang 16

Class-based Weighted Fair Queuing

Overview

This lesson describes the enhanced queuing mechanism in Cisco IOS using the Modular QoS CLI

Objectives

n Describe Class-based Weighted Fair Queuing (CB-WFQ)

n Monitor and troubleshoot CB-WFQ

Trang 17

Queuing

• Class-based Weighted Fair Queuing ( CB-WFQ ) is a mechanism that is used to guaranetee bandwidth to classes

• CB-WFQ extends the standard WFQ functionality to provide support for user-defined traffic classes

– Classes are based on user-defined match criteria

– Packets satisfying the match criteria for a class constitute the traffic for that class

• A queue is reserved for each class, and traffic belonging to a class is directed to that class's queue

CBWFQ extends the standard WFQ functionality to provide support for defined traffic classes For CBWFQ, the user defines the traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces Packets satisfying the match criteria for a class constitute the traffic for that class

user-A queue is reserved for each class, and traffic belonging to a class is directed to that class's queue

Once a class has been defined according to its match criteria, you can assign it characteristics To characterize a class, you assign it bandwidth, weight, and maximum packet limit The bandwidth assigned to a class is the minimum bandwidth delivered to the class during congestion

To characterize a class, you also specify the queue limit for that class, which is the maximum number of packets allowed to accumulate in the class's queue Packets belonging to a class are subject to the bandwidth and queue limits that characterize the class After a queue has reached its configured queue limit, enqueuing of additional packets to the class causes tail drop or packet drop to take effect, depending on how the class policy is configured

Trang 18

CB-WFQ

• Up to 64 classes (class maps) and one default class

CB-WFQ

Hardware Queuing System

Class 2? Tail-drop Queue 2

Class-default? Tail-drop Default Queue

CB-WFQ uses up to 64 class maps to classify traffic into their corresponding FIFO queues Tail-drop is the default dropping scheme of CB-WFQ although it can be combined with WRED

The CB-WFQ scheduler is used to guarantee bandwidth based on the configured weights

Trang 19

• Classification uses class-maps

• Availability of certain classification options depends

on the Cisco IOS version

• Some classification options depend on type of interface and encapsulation where service policy is used

– Matching on ISL Priority bits has no effect if ISL is not used

Any classification option can be used depending on the availability in the Cisco IOS version and the support on the selected interface and encapsulation

Trang 20

CB-WFQ Insertion Policy

• Each queue has a maximum number of packets that it can hold (queue size)

• The default maximum queue size is 64

• After a packet is classified to one of the queues, the router will enqueue the packet if the queue limit has not been reached (tail- drop within each class)

• WRED can be used in combination with WFQ to prevent congestion of the class

CB-CB-WFQ reserves 64 FIFO queues in the WFQ system The default queue limit is

64 (tail-drop) and can be configured with WRED (random drop)

Trang 21

• CB-WFQ guarantees bandwidth according to weights assigned to traffic classes

• Weights can be defined by specifying:

– Bandwidth (in kbps)

– Percentage of bandwidth (percentage of configured interface bandwidth)

– Percentage of available bandwidth

• One service policy can not have mixed types

of weights

• The “show interface” command can be used

to display the available bandwidth

The configuration of bandwidth guarantees can be done using one of the following commands:

n The bandwidth command allocates a fixed amount of bandwidth by specifying

the amount in kilobits per second (kbps) The reserved bandwidth is subtracted from the available bandwidth of the interface where the service policy is used The allocated bandwidth must also be within the default or configured

reservable limit (75% by default)

n The bandwidth percent command can be used to allocate a percentage of

the default or configured bandwidth of an interface The default bandwidth usually equals the maximum speed of an interface Sometimes it actually reflects the real speed of an interface (for example: Ethernet or FastEthernet)

The default value can be replaced by using the bandwidth interface

command It is recommended that the bandwidth reflect the real speed of the link The allocated bandwidth is subtracted from the available bandwidth of the interface where the service policy is used

n The bandwidth remaining percent command can be used to allocate a

portion of the available bandwidth The allocated bandwidth is not subtracted from the available bandwidth of the interface where the service policy is used

A single service policy cannot mix different bandwidth commands

Trang 22

Available Bandwidth

• Available bandwidth is calculated according

to the following formula:

BW avail = BW * MaxReservable – SUM(all fixed guarantees)

Configured using the interface “ bandwidth ” command

Configured using the interface

max-reserved -bandwidth command 75% is the default value

Sum of all fixed guarantees using CB-WFQ, CB-LLQ, IP RTP Prioritization

The available bandwidth displayed by the show interface command is calculated

by subtracting all fixed bandwidth reservations from 75% of the default or configured bandwidth of an interface

Trang 23

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set

Keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:04, output 00:00:08, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/0/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 7500 kilobits/sec

Router# show interface Ethernet 0/0 Ethernet0/0 is up, line protocol is up Hardware is AmdP2, address is 00b0.64e2.2860 (bia 00b0.64e2.2860) Internet address is 192.168.20.1 255.255.255.0

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec , reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set

Keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:04, output 00:00:08, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output d rops: 0 Queueing strategy: weighted fair

The figure illustrates a situation where there are no fixed guarantees on the

interface The show interface command confirms that there are 7.5 Mbps of

bandwidth available (only 75% of 10Mbps is reservable by default)

Trang 24

• Maximum Reservable bandwidth is set to 50%

• IP RTP Prioritization is used to guarantee 1 Mbps to VoIP

BW avail = BW * MaxReservable – SUM(all fixed guarantees)

BW avail = 10000 kbps * 50% – 1000 kbps = 4000 kbps

interface Ethernet0/0

ip address 192.168.20.1 255.255.255.0 half-duplex

max-reserved-bandwidth 50 fair-queue

ip rtp priority 16384 16383 1000

interface Ethernet0/0

ip address 192.168.20.1 255.255.255.0 half-duplex

Trang 25

Example 2

Router#show interface Ethernet0/0 Ethernet0/0 is up, line protocol is up Hardware is AmdP2, address is 00b0.64e2.2860 (bia 00b0.64e2.2860) Internet address is 192.168.20.1 255.255.255.0

Keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:04, output 00:00:06, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output d rops: 0 Queueing strategy: weighted fair

Router# show interface Ethernet0/0 Ethernet0/0 is up, line protocol is up Hardware is AmdP2, address is 00b0.64e2.2860 (bia 00b0.64e2.2860) Internet address is 192.168.20.1 255.255.255.0

Keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:04, output 00:00:06, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair

The show interface command confirms the calculation of available bandwidth for

Example 2

Trang 26

Configuring CB-WFQ

bandwidth bandwidth

Router(config-pmap-c)#

• Allocate a fixed amount of bandwidth to a class

• Set the value in kbps

bandwidth percent percent

• Allocate a percentage of bandwidth to a class

• The configured (or default) interface bandwidth is used to calculate the guaranteed bandwidth

bandwidth remaining percent percent

• Allocate a percentage of available bandwidth to a class

Bandwidth guarantee is configured in the cla ss policy-map configuration mode (config-pmap-c) All classes belonging to one policy map should use the same type

of bandwidth guarantee (fixed in kbps, in percentage of interface bandwidth, in percentage of available bandwidth)

Trang 27

queue-limit queue-limit

• Set the maximum number of packets this queue can hold

• The default maximum is 64

• Sets the discard threshold in the “class-default” if flow-based WFQ is used

• WFQ can be configured with 16 to 4096 dynamic queues

The default queue limit of 64 packets can be changed using the queue-limit command It is recommended not to change the default value

The default class can be selected by specifying the class-default name of the

class The default class supports two types of queuing: one FIFO queue (Default)

or a Flow-based WFQ system Both types can be combined with WRED FIFO queue can also get a bandwidth guarantee

The following example shows the configuration of FIFO queuing within the default class The default class is also guaranteed 1 Mbps of bandwidth and the maximum queue size is limited to 40 packets

policy-map A class A bandwidth 1000 class class-default bandwidth 1000 queue-limit 40 This next example shows the configuration of WFQ queuing within the default class The number of dynamic queues is set to 1024 and the discard threshold is set

to 50

policy-map A class A bandwidth 1000 class class-default fair-queue 1024 queue-limit 50

Trang 29

Example 1

policy -map Policy1 class Class1 bandwidth 2000 class Class2 bandwidth 2000

! interface FastEthernet0/0

ip address 10.1.1.1 255.255.255.0 duplex auto

speed 10 max-reserved-bandwidth 80 service-policy output Policy1

ip rtp priority 16384 16383 1000

!

policy-map Policy1 class Class1 bandwidth 2000 class Class2 bandwidth 2000

speed 10 max-reserved-bandwidth 80 service -policy output Policy1

Trang 30

CB-WFQ Example 2

policy -map Policy1 class Class1 bandwidth percent 20 class Class2

bandwidth percent 20

ip rtp priority 16384 16383 1000

!

policy-map Policy1 class Class1 bandwidth percent 20 class Class2

bandwidth percent 20

Trang 31

Examples 1 and 2

Router#show interface fastethernet 0/0 FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is 0030.8546.aa00 (bia 0030.8546.aa00) Internet address is 10.1.1.1 /24

Keepalive set (10 sec) Half-duplex, 10Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:09, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output d rops: 0 Queueing strategy: weighted fair

Router# show interface fastethernet 0/0 FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is 0030.8546.aa00 (bia 0030.8546.aa00) Internet address is 10.1.1.1 /24

MTU 1500 bytes, BW 10000 Kbit , DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set

Keepalive set (10 sec) Half-duplex, 10Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:09, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair

The show interface command confirms the calc ulation of available bandwidth on

the previous CB-WFQ examples

Trang 32

CB-WFQ Example 3

policy -map Policy1 class Class1 bandwidth remaining percent 20 class Class2

bandwidth remaining percent 20

ip rtp priority 16384 16383 1000

!

policy-map Policy1 class Class1 bandwidth remaining percent 20 class Class2

bandwidth remaining percent 20

ip rtp priority 16384 16383 1000

!

BW avail = 10000 kbps * 80% - 1000 kbps = 7000 kbps

Example 3 shows how the available bandwidth can be distributed among the

classes configured with the bandwidth remaining percent command The

reservation does not affect the calculation of available bandwidth (it is not a fixed guarantee)

The bandwidth remaining percent command allows you to allocate bandwidth

as a relative percentage of the total bandwidth available on the interface This command allows you to specify the relative percentage of the bandwidth to be allocated to the classes of traffic In this example, 20 percent of the available bandwidth is allocated to Class1 and 20 percent to Class2 Essentially, you are specifying the ratio of the bandwidth to be allocated to the traffic class The sum

of the numbers used to indicate this ratio cannot exceed 100 percent This way, you need not know the total amount of bandwidth available, just the relative percentage you want to allocate for each traffic class

Each traffic class gets a minimum bandwidth as a relative percentage of the remaining bandwidth The remaining bandwidth is the bandwidth available after the priority queue, if present, is given its required bandwidth, and after any Resource Reservation Protocol (RSVP) flows are given their requested bandwidth

Trang 33

Example 3

Router#show interface fastethernet 0/0 FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is 0030.8546.aa00 (bia 0030.8546.aa00) Internet address is 10.1.1.1 /24

Keepalive set (10 sec) Half-duplex, 10Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:03, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output d rops: 0 Queueing strategy: weighted fair

Router# show interface fastethernet 0/0 FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is 0030.8546.aa00 (bia 0030.8546.aa00) Internet address is 10.1.1.1 /24

Keepalive set (10 sec) Half-duplex, 10Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:03, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair

The show interface command confirms the calculation of available bandwidth for

Example 3

Trang 34

• Displays parameters and statistics of CB-WFQ

Router#show policy-map interface FastEthernet0/0

Service-policy output: Policy1 Class-map: Class1 (match-any)

(depth/total drops/no-buffer drops) 0/0/0 Class-map: class -default (match-any)

The show policy-map interface command displays all service policies applied to

the interface Among the settings, policing parameters and statistics are displayed

Trang 35

CB-WFQ

show queueing fair Router#

• Displays queuing parameters on interfaces

Router# show queueing fair Current fair queue configuration:

Interface Discard Dynamic Reserved Link Prio rity

threshold queues queues queues queu es FastEthernet0/0 64 256 64 8 1 Serial0/0 64 32 0 8 1 Serial0/1 64 32 0 8 1

Router# show queueing fair Current fair queue configuration:

Interface Discard Dynamic Reserved Link Prio rity

threshold queues queues queues queu es FastEthernet0/0 64 256 64 8 1 Serial0/0 64 32 0 8 1 Serial0/1 64 32 0 8 1

CB-WFQ reserves 64 queues

in the WFQ system

One queue is reserved for

IP RTP Prioritization

The show queueing fair command displays all interfaces using Weighted Fair

Queuing The FastEthernet interface show there are 64 reserved queues (for CB-WFQ) One queue is used for IP RTP prioritization

The discard threshold is the number of packets than have to be in the queuing system to start dropping packets in the longest queue

The number of dynamic queues specifies how many queues are used in the default class if flow-based WFQ is used

WFQ reserves 8 queues (link queues) for PAK_Priority packets (link-level messages and keepalives, routing protocol hello messages and keepalives etc.)

Trang 36

pkts output 0, wfq drops 0, nobuffer drops 0 WFQ: aggregate queue limit 0 max available buffers 0

Class 0: weight 50 limit 250 qsize 0 pkts output 0 drops 0 Class 23: weight 30 limit 150 qsize 0 pkts output 0 drops 0 Class 24: weight 20 limit 100 qsize 0 pkts output 0 drops 0

c7500# show queueing interface serial 5/1/0 Interface Serial5/1/0 queueing strategy: VIP -based fair queueing Serial5/1/0 queue size 0

pkts output 0, wfq drops 0, nobuffer drops 0 WFQ: aggregate queue limit 0 max available buffers 0 Class 0: weight 50 limit 250 qsize 0 pkts output 0 drops 0 Class 23: weight 30 limit 150 qsize 0 pkts output 0 drops 0 Class 24: weight 20 limit 100 qsize 0 pkts output 0 drops 0

The show queueing interface command can be used to display the parameters

and statistics of distributed Weighted Fair Queuing (dWFQ) on Cisco 7x00 series routers using Versatile Interface Processors (VIPs)

Trang 37

Class-based Weighted Fair Queuing (CB-WFQ) is a queuing mechanism that can provide bandwidth guarantees for up to 64 classes on one interface

Bandwidth guarantees can be configured by specifying:

n A fixed guarantee in kbps

n A fixed guarantee in a percentage of interface bandwidth

n A dynamic guarantee by specifying a percentage of available bandwidth

Lesson Review

1 What type of guarantee does CB-WFQ provide?

2 Which DiffServ PHB can be implemented using CB-WFQ?

3 What configuration steps are needed to configure CB-WFQ?

Trang 38

n Describe Class-based Weighted Random Early Detection (CB-WRED)

n Monitor and troubleshoot CB-WRED

Trang 39

• Class-based WRED can be used in combination with CB-WFQ

• Using CB-WFQ with WRED allows the implementation of DiffServ’s Assured Forwarding PHB

• Class-based configuration of WRED is identical to standalone WRED

• Flow-based WRED is not available with the Modular QoS CLI

Congestion avoidance techniques monitor the network interface load in an effort to anticipate and avoid congestion at common network bottlenecks Congestion avoidance is achieved through packet dropping using more complex techniques Traditionally, Cisco IOS used standalone RED and WRED mechanisms, as described in the A_QoS_CongestAvoid module, to avoid congestion on an interface Those mechanisms can perform a differentiated drop based on the IP precedence or DSCP-value

The Class-Based Weighted Fair Queueing (CB-WFQ) system supports the use of WRED inside the queueing system, therefore implementing Class-based WRED Each class is queued in its separate queue, and has a queue limit, performing tail-drop by default WRED can be configured as the preferred dropping method in a queue, implementing a differentiated drop based on traffic class and further on the

IP precedence or DSCP value

Note The combination of CB-WFQ with WRED on a single device is currently the only

way to implement the DiffServ’s Assured Forwarding Per-Hop Behavior (AF PFB) using Cisco IOS software

The class-based configuration of WRED is analogous to standalone WRED configuration Flow-based WRED (FRED) is not available within the CB-WFQ queueing system and the Cisco IOS MQC

Trang 40

Drop Probability

10%

100%

Minimum Threshold

Maximum Threshold

Maximum Drop Probability

No drop Random drop Full drop

RED is currently the primary congestion avoidance method used on router interfaces Random Early Detection is a dropping mechanism that randomly drops packets before a queue is full The dropping strategy is based primarily on the average queue length When the average queue gets longer (fuller), RED will be more likely to drop an incoming packet than when the queue is shorter

Because RED drops packets randomly, it has no per-flow intelligence The rationale behind this is that an aggressive flow will represent most of the arriving traffic Therefore it is more probable that RED will drop a packet of an aggressive session RED therefore punishes more aggressive sessions with higher statistical probability, and is able to somewhat selectively slow down the most significant cause of congestion Directing one TCP session at a time to slow down allows for the full utilization of the bandwidth, rather than a utilization that manifests itself as crests and troughs of traffic

As a result, the TCP global synchronization is much less likely to occur, and TCP can utilize the bandwidth more efficiently The average queue size also decreases significantly, because the possibility of the queue filling up is very small This is due

to very aggressive dropping in the event of traffic bursts, when the queue is already quite full

RED distributes losses over time and maintains normally low queue depth while absorbing spikes RED can also utilize IP precedence or DSCP bits in packets to establish different drop profiles for different classes of traffic

Định dạng
Số trang	117
Dung lượng	4,84 MB