Congestion Management and Scheduling 363
Congestion Management and Scheduling
Discussed in Chapter 2, congestion management is a technique used to manage traffic flows
at points of congestion within the network. The congestion management process involves
the following three steps:
1 Creating different queues to accommodate network traffic
2 Assigning packets to the various queues based on predefined characteristics
3 Scheduling between the various queues to provide queued packets access to the
available bandwidth when congestion has occurred on the link
This section discusses the various congestion management mechanisms supported on the
FlexWAN module. They include distributed Weighted Fair Queuing (dWFQ), distributed
Class-Based Weighted Fair Queuing (dCBWFQ), and distributed Low Latency Queuing
(dLLQ). Examples are provided in the section demonstrating the necessary configuration
steps, as well as show commands to verify functionality.
Distributed Weighted Fair Queuing
Distributed Weighted Fair Queuing (dWFQ) is a congestion management mechanism that
operates on the FlexWAN’s VIPs and provides fair treatment for outbound flows on
congested interfaces. WFQ is enabled by default on all interfaces operating at 2.048 Mbps
and less. WFQ protects low-bandwidth traffic flows by ensuring high volume conversations
do not monopolize the available bandwidth. The mechanism works by assigning each
traffic flow to its own queue. A flow is defined as packets possessing the same source IP
address, destination IP address, source TCP or UDP port, destination TCP or UDP port,
protocol ID, and type of service value. Once a packet is assigned to a queue, the WFQ
mechanism services each queue ensuring each queue receives a fair share of the available
bandwidth, based on the assigned weight for that flow.
WFQ uses packet size and arrival time in conjunction with a weighting factor to permit
access to the bandwidth. WFQ is QoS aware. If a packet arrives with a high precedence
value, the weight assigned to the packet will be low. Therefore, the higher the precedence
value the lower the weight. The lower weight translates to faster de-queuing and trans-
mission time, which translates to more access to the available bandwidth. dWFQ for a VIP
or FlexWAN is configured on the physical WAN interface. dWFQ operates the same as
WFQ, with the exception weight is not assigned to a packet when executed in a distributed
fashion on one of the VIPs of the FlexWAN module. All traffic flows are provided equal
access to the available bandwidth. However, low bandwidth flows are still protected from
being starved by high bandwidth conversations. The following commands configure flow-
based dWFQ on the target interface. The subsequent show commands allow the adminis-
trator to verify the configuration and monitor the statistics for the applicable interface.
ff
ff
aa
aa
ii
ii
rr
rr
--
--
qq
qq
uu
uu
ee
ee
uu
uu
ee
ee
ff
ff
aa
aa
ii
ii
rr
rr
--
--
qq
qq
uu
uu
ee
ee
uu
uu
ee
ee
[[aa
aa
gg
gg
gg
gg
rr
rr
ee
ee
gg
gg
aa
aa
tt
tt
ee
ee
--
--
ll
ll
ii
ii
mm
mm
ii
ii
tt
tt
{
# packets
}] | [ii
ii
nn
nn
dd
dd
ii
ii
vv
vv
ii
ii
dd
dd
uu
uu
aa
aa
ll
ll
--
--
ll
ll
ii
ii
mm
mm
ii
ii
tt
tt
{
# packets
}]]
ss
ss
hh
hh
oo
oo
ww
ww
qq
qq
uu
uu
ee
ee
uu
uu
ee
ee
ii
ii
nn
nn
gg
gg
ff
ff
aa
aa
ii
ii
rr
rr
[ii
ii
nn
nn
tt
tt
ee
ee
rr
rr
ff
ff
aa
aa
cc
cc
ee
ee
{
type num
}]
ss
ss
hh
hh
oo
oo
ww
ww
ii
ii
nn
nn
tt
tt
ee
ee
rr
rr
ff
ff
aa
aa
cc
cc
ee
ee
{
type num
}
364 Chapter 9: QoS Support on the Catalyst 6500 MSFC and FlexWAN
The command fair-queue enables flow-based dWFQ for the configured interface. After
dWFQ is enabled on the interface, the optional aggregate-limit keyword in conjunction
with the fair-queue command is used to specify the maximum number of packets that may
be present between all queues. Exceeding this value results in enforcement of the individual
queue limits and possible discard for subsequent arriving packets needing to be queued.
The optional individual-limit keyword specifies the maximum number of packets that can
be queued for an individual flow queue. If the number of packets queued for a per flow
queue increases above the number specified by the individual-limit keyword, all subse-
quent arriving packets are dropped. Despite the enforcement of the aggregate and
individual limits, packets already placed in the queue are not discarded. It is not recom-
mended to alter the aggregate-limit or individual-limit values from their default settings.
Before deciding to change the values from their defaults, carefully consider how these
changes will impact network and traffic performance.
dWFQ’s benefit is its relative ease to implement. dWFQ functions independently of access-
lists or the MQC. Although WFQ provides fair access to the available bandwidth, it does
not provide specific bandwidth guarantees for the various queues or classes during periods
of congestion. The next section describes class-based weighted fair queuing and its
benefits.
Distributed Class-Based Weighted Fair Queuing
CBWFQ is the most widely recognized QoS mechanism deployed today. CBWFQ
enhances the functionality available with WFQ.
CBWFQ provides scalable fair treatment of traffic on a class-by-class basis. However,
CBWFQ also assigns minimum bandwidth guarantees to classes of traffic, to ensure
bandwidth is available for critical applications. The minimum bandwidth assigned to a class
is expressed as a percentage or a rate, expressed in kilobits per second. This number
guarantees a class a minimum level of bandwidth in the event congestion is experienced on
the interface, and assigns a weight to all packets matching the criteria of the given class.
This weight denotes the frequency a class is serviced during periods of congestion, ensuring
the fair treatment of all traffic according to the configured policy. Because the weight
assigned to a class is a percentage based on the total available bandwidth for the assigned
interface, it is essential to ensure the bandwidth statement for the interface properly depicts
what is available. Any remaining bandwidth not assigned to one of the configured classes
is allocated to the default class. By default, the sum of all bandwidth assigned to the various
classes cannot exceed 75 percent of the total available bandwidth provisioned for an
interface. The remaining 25 percent provides minimum bandwidth guarantees for Best
Effort, overhead, and network control traffic. Use the following command to assign a
minimum bandwidth to a class:
bandwidth {{
rate
} | percent {
percentage
}}
Congestion Management and Scheduling 365
CAUTION You can alter the 75 percent maximum bandwidth guarantee allocated for all configured classes
by using the interface command max-reserved-bandwidth [percent]. However, before
modifying this value, careful consideration must be given to ensure the configured classes do
not consume the available bandwidth, starving overhead and critical network control traffic.
CBWFQ is configured using the MQC. The minimum bandwidth guarantee assigned to the
appropriate class is configured under the policy-map class. For all administratively defined
classes, a minimum bandwidth must be assigned to the applicable class before fair queuing
is enabled. The exception to this behavior is the default class. A minimum bandwidth
guarantee is not required to configure flow-based WFQ for the default class. Fair-queuing
is configured for a specific class using the command fair-queue [queue-limit {queue #}].
The queue-limit keyword associated with the fair-queue command specifies the maximum
number of possible per-flow queues for the configured class. Optionally, the command
queue-limit {packets}, also configured under the policy-map class, specifies the maximum
number of packets that can be queued for the associated class. If the number of packets queued
for the class increases above the number specified by the queue-limit command, all subse-
quent packets are tail-dropped. Example 9-9 demonstrates configuring flow-based WFQ for
the default class called “class-default.” The default class matches any packets not matched
by the classification criteria specified in the configured class-maps. Configuring flow-based
WFQ for the default class allows queues within the class to fairly share the available
bandwidth.
Unlike policing and shaping, the minimum bandwidth guarantees configured for CBWFQ
do not represent a maximum upper-bound limit. If a particular class is not transmitting, or
fully utilizing the minimum allocated bandwidth, that bandwidth is available to the other
classes, allowing them to transmit above their minimum guarantees. Example 9-13 demon-
strates configuring and verifying CBWFQ behavior.
Example 9-13 Configuring Distributed WFQ
MSFC#configure terminal
MSFC(config)#class-map match-any Low-Priority
MSFC(config-cmap)#match protocol smtp
MSFC(config-cmap)#match protocol secure-http
MSFC(config)#class-map match-any Business-essential
MSFC(config-cmap)#match protocol sqlnet
MSFC(config-cmap)#match protocol sqlserver
MSFC(config)#class-map match-any Video-preso
MSFC(config-cmap)#match protocol netshow
MSFC(config-cmap)#exit
MSFC(config)#policy-map dCBWFQ
MSFC(config-pmap)#class Low-Priority
MSFC(config-pmap-c)#bandwidth 400
MSFC(config-pmap-c)#fair-queue
MSFC(config-pmap-c)#exit
MSFC(config-pmap)#class Business-essential
MSFC(config-pmap-c)#bandwidth 400
MSFC(config-pmap-c)#fair-queue
MSFC(config-pmap-c)#class Video-preso
MSFC(config-pmap-c)#bandwidth 1000
continues
366 Chapter 9: QoS Support on the Catalyst 6500 MSFC and FlexWAN
MSFC(config-pmap-c)#fair-queue
MSFC(config-pmap)#class class-default
MSFC(config-pmap-c)#fair-queue
MSFC(config-pmap-c)#exit
MSFC(config-pmap)#exit
MSFC(config)#interface serial 3/0/2
MSFC(config-if)#service-policy output dCBWFQ
MSFC(config-if)#end
MSFC#show interfaces serial 3/0/2
Serial3/0/2 is up, line protocol is up
Hardware is Serial
Internet address is 192.168.60.1/30
MTU 1500 bytes, BW 4000 Kbit, DLY 20000 usec,
reliability 255/255, txload 165/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Last input 00:00:03, output 00:00:01, output hang never
Last clearing of “show interface” counters 11:15:58
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: VIP-based fair queuing
Output queue :0/40 (size/max)
30 second input rate 1000 bits/sec, 3 packets/sec
30 second output rate 2653000 bits/sec, 1271 packets/sec
94583 packets input, 5754020 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
44615858 packets output, 2920117041 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
RTS up, CTS up, DTR up, DCD up, DSR up
MSFC#show policy-map interface serial 3/0/2
Serial3/0/2
service-policy output: dCBWFQ
class-map: Low-Priority (match-any)
104897 packets, 26826925 bytes
30 second offered rate 374000 bps, drop rate 0 bps
match: protocol smtp
41512 packets, 6226800 bytes
30 second rate 97000 bps
match: protocol secure-http
63385 packets, 20600125 bytes
30 second rate 274000 bps
queue size 0, queue limit 100
packets output 105295, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
bandwidth: kbps 400, weight 10
fair-queue: per-flow queue limit 25
class-map: Business-essential (match-any)
147389 packets, 26827900 bytes
30 second offered rate 374000 bps, drop rate 0 bps
match: protocol sqlnet
Example 9-13 Configuring Distributed WFQ (Continued)
Congestion Management and Scheduling 367
NOTE The FlexWAN module supports configuring dCBWFQ on a per-VC basis. This is supported
for available bit rate (ABR) and variable bit rate (VBR) classes of service. Unspecified bit
rate (UBR) and UBR+ do not provided bandwidth guarantees. dCBWFQ are configured
using the MQC. As a result, service policies are applied to individual virtual circuits (VCs)
and individual members of a VC bundle. To implement flow-based WFQ on a per-VC basis,
the default class is configured for fair-queue under the policy map. So long as traffic is not
matched by other classification criteria, the traffic defaults to the default class where flow-
based WFQ is applied. For additional information on IP-to-ATM CoS, refer to the
following technical document available at Cisco.com:
“Configuring IP to ATM Class of Service”
96712 packets, 21760200 bytes
30 second rate 278000 bps
match: protocol sqlserver
50677 packets, 5067700 bytes
30 second rate 94000 bps
queue size 0, queue limit 100
packets output 147934, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
bandwidth: kbps 400, weight 10
fair-queue: per-flow queue limit 25
class-map: Video-preso (match-any)
191646 packets, 67076100 bytes
30 second offered rate 937000 bps, drop rate 0 bps
match: protocol netshow
191646 packets, 67076100 bytes
30 second rate 937000 bps
queue size 0, queue limit 250
packets output 192407, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
bandwidth: kbps 1000, weight 25
fair-queue: per-flow queue limit 62
class-map: class-default (match-any)
138172 packets, 33814224 bytes
30 second offered rate 472000 bps, drop rate 0 bps
match: any
138172 packets, 33814224 bytes
30 second rate 472000 bps
queue size 0, queue limit 550
packets output 138803, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
fair-queue: per-flow queue limit 137
MSFC#show queueing fair interface serial 3/0/2
Current fair queue configuration:
Serial3/0/2 queue size 0
pkts output 1002701, wfq drops 0, nobuffer drops 0
WFQ: aggregate queue limit 1000 max available buffers 1000
Class 0: weight 55 limit 550 qsize 0 pkts output 235046 drops 0
Class 2: weight 25 limit 250 qsize 0 pkts output 326801 drops 0
Class 8: weight 10 limit 100 qsize 0 pkts output 180851 drops 0
Class 11: weight 10 limit 100 qsize 0 pkts output 260001 drops 0
Example 9-13 Configuring Distributed WFQ (Continued)
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.