Per-VC Class-Based, Weighted Fair Queuing on RSP-Based Platforms [IP to ATM Class of Service]

Document ID: 10396

Introduction
Prerequisites
      Requirements
      Components Used
      Network Diagram
      Conventions
Per-(Sub)Interface CBWFQ Sample Configuration
      Verify
Per-VC CBWFQ Sample Configuration
      Comments on the Configuration
      Verify
Weighted-Fair Queuing Configuration
Advanced Configuration
      Class Maps
      Traffic Parameters
      Verify
Known Caveat
Related Information

Introduction

Weighted fair queuing (WFQ) was implemented for slow speed links (such as serial) to provide a fair treatment for each type of traffic. To do its job, WFQ classifies traffic into different flows based on the associated layer 3 and layer 4 information (IP addresses, TCP ports, and so on). You do not need to define access-lists in order for this to work. Therefore, with WFQ, low bandwidth traffic has effective priority over high bandwidth traffic. The high bandwidth traffic shares the transmission media proportionally to assigned weights.

WFQ does have limitations. If the traffic flow increases significantly, WFQ cannot adjust because it is not scalable. Additionally, WFQ is not available on high speed interfaces such as ATM.

A new feature, class-based weighted fair queuing (CBWFQ), has been developed to address the limitations of WFQ. Unlike WFQ, CBFWQ allows you to define traffic classes. Once you have defined classes, you can also apply parameters, such as bandwidth and queue-limit.

Using CBWFQ, the weight specified for a class becomes the weight of each packet that matches the class criteria. This weight is derived from the bandwidth you assign to the class. You can then apply WFQ to these classes, instead of to the flows themselves. Classes can include several flows.

Below is a summary of Per-VC CBWQ availability on Cisco 7500 routers:

Cisco IOS® Software Release 12.0.7XE, 12.1.4T, 12.1.1E, 12.0.7S for per-(sub)interface configuration of distributed CBWFQ.
Cisco IOS Software Release 12.1(5)T and 12.1(5)E and above for per-VC configuration of distributed CBWFQ.

You also need to use a PA-A3 port adapter in a VIP2-50 (Versatile Interface Processor).

Note: You must use Cisco Express Forwarding (CEF) on Cisco 7200 routers, and distributed CEF on Cisco 7500 routers.

Note: It is recommended to use per-VC distributed CBWFQ instead of per-subinterface CBWFQ.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

Cisco 7200 and 7500 series routers
Cisco IOS Software Releases 12.0.7XE, 12.1.4T, 12.1.1E, 12.0.7S, 12.1(5)T, 12.1(5)E, and later

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Network Diagram

This document uses this network setup:

The VPI/VCI value 1/130 is assigned on both ends of the PVC between the 7500 router and the Router A. The traffic generator is connected to interface Fast-Ethernet 0/1/0.

Conventions

For more information on document conventions, refer to Cisco Technical Tips Conventions.

Per-(Sub)Interface CBWFQ Sample Configuration

In this section, you are presented with the per-(sub)interface CBWFQ sample configuration.

Note: To find additional information on the commands used in this section, use the Command Lookup Tool (registered customers only) .

This section uses this configuration:

7500

7500

ip cef distributed
!
class-map match-all telnet
   match access-group 101
class-map match-all loopback
   description traffic between loopbacks
   match access-group 102
class-map match-all ixia
   description traffic from traffic generator
   match input-interface FastEthernet0/1/0
!
policy-map test
   class loopback
     bandwidth 50000
     queue-limit 500
   class ixia
     bandwidth 10000
     queue-limit 500
   class class-default
     fair-queue
     fair-queue queue-limit 200
!
interface ATM2/0/0.130 point-to-point
   ip address 14.0.0.1 255.0.0.0
   no ip directed-broadcast
   pvc 1/130
    vbr-nrt 120000 120000
    broadcast
    encapsulation aal5mux ip
   !
   service-policy output test

Verify

This section provides information you can use to confirm your configuration is working properly.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

show interface atm [x[/y[/z]]].w fair-queue, for example:

       router#show interface atm 2/0/0.130 fair-queue 
        ATM2/0/0.130      queue size 0 
         pkts output      0, wfq drops 0, nobuffer drops 0 
        WFQ: aggregate      queue limit 0 max available buffers 0
       Class 0: weight 56 limit 0 qsize 0 pkts output 0 drops 0 
       Class 2: weight 33 limit 0 qsize 0 pkts output 0 drops 0 
       Class 3: weight 6 limit 0 qsize 0 pkts output 0 drops 0 
       Class 9: weight 5 limit 0 qsize 0 pkts output 0 drops 0

Note: The show interface atm fair-queue command is no longer available in the software supporting per-VC CBWFQ. In this case, use the show commands described in the following section.

Per-VC CBWFQ Sample Configuration

In this section, you are presented with the per-VC CBWFQ sample configuration.

Note: To find additional information on the commands used in this section, use the Command Lookup Tool (registered customers only) .

This section uses this configuration:

7500

7500

ip cef distributed 
! 
class-map match-all loopback 
  match access-group 102 
class-map match-all ixia 
  match access-group 103 
class-map match-all tcp 
  match access-group 101 
!  
policy-map test 
  class tcp 
    bandwidth percent 40 
    queue-limit 200 
  class ixia 
    bandwidth percent 20 
    queue-limit 500 
  class loopback 
    bandwidth percent 10 
    queue-limit 500 
  class class-default 
    fair-queue 
    fair-queue queue-limit 200 
! 
interface ATM5/1/0.130 point-to-point 
 ip address 14.0.0.1 255.0.0.0 
 pvc 1/130  
  vbr-nrt 5000 1000 100 
  broadcast 
  encapsulation aal5snap 
  service-policy out test

Comments on the Configuration

The following background information is important for this configuration:

Class maps classify the traffic. Classification parameters and class maps are defined at the same place.
After defining the classification parameters, you can use a policy map to apply traffic parameters (bandwidth, queue-limit) to these classified flows.
The queue limit is the number of packets that can be stored for that particular class before drops occur.
After the traffic parameters have been defined for each class, you can apply CBWFQ using the service-policy [input|output] policy-map-name command.
When doing per-(sub)interface CBWFQ, the service-policy is directly applied on the (sub)interface and impacts all the VCs configured under that subinterface. When doing per-VC CBWFQ, the service-policy command is directly applied under the desired VC(s).
Per-VC CBWFQ is the recommended configuration.
Traffic not matching one of the defined class maps is assigned a default class map (class-default) which is defined in the policy map. All the non-classified traffic is applied the parameters defined under this class-default. In this case, normal Weighted Fair Queuing is configured for that class.
All commands entered in VC configuration mode take effect only when you exit for this mode. Exiting causes the VC to be removed and recreated with the new configuration parameters, which may include Quality of Service (QoS) policies, shaping rates, etc. If you wish to remove a QoS service policy, you must type exit or press CTRL-Z to ensure that the no form of the command actually takes effect.

We can associate CBWFQ with Weighted Random Early Discard (WRED) as a drop mechanism when the queue limit is reached.

Important Notes:

Before performing the configuration tasks in this section, you must create the classes used to differentiate traffic on the VC and define a policy map to include them. You can configure class policies for as many classes as are defined on the router - up to the maximum of 64. However, the total amount of allocated VC bandwidth (for all classes included in a policy map) must not exceed 75 percent of the VC's available bandwidth.

Because CBWFQ gives you minimum bandwidth guarantee when using the "bandwidth" statement in the policy-map, you can only apply CBWFQ to VCs with ABR, VBR, VBR-rt, and CBR classes of service.

You cannot apply CBWFQ to UBR and UBR+ VCs because both of these service classes are best-effort classes that do not guarantee minimum bandwidth. When CBWFQ is enabled for a VC, all classes configured as part of the service policy are installed in the fair queuing system.

Verify

This section provides information you can use to confirm your configuration is working properly.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

show class-map, for example:

router#show class-map 
 Class Map match-all loopback (id 4)
   Match access-group  102 

 Class Map match-all ixia (id 3)
   Match access-group  103 

 Class Map match-any class-default (id 0)
   Match any 

 Class Map match-all tcp (id 2)
   Match access-group  101

show policy-map, for example:

router#show policy-map
  Policy Map test
    Class tcp
      bandwidth percent 40
      queue-limit 200
    Class ixia
      bandwidth percent 20
      queue-limit 500
    Class loopback
      bandwidth percent 10
      queue-limit 500
    Class class-default
      fair-queue
      fair-queue individual-limit 200

show policy-map interface atm [x[/y[/z]]].w [input|output], for example:

router#show policy-map interface atm 5/1/0.130
 ATM5/1/0.130: VC 1/130 -

  Service-policy output: test (1769)

    Class-map: tcp (match-all) (1771/2)
      95390 packets, 142512660 bytes
      5 minute offered rate 3781000 bps, drop rate 0 bps
      Match: access-group 101 (1775)
      queue size 200, queue limit 200
      packets output 897, packet drops 94499
      tail/random drops 94499, no buffer drops 0, other drops 0
      Bandwidth: 40%, kbps 400
      Queue-limit 200

    Class-map: ixia (match-all) (1781/3)
      95390 packets, 94817660 bytes
      5 minute offered rate 2517000 bps, drop rate 0 bps
      Match: access-group 103 (1785)
      queue size 500, queue limit 500
      packets output 672, packet drops 94726
      tail/random drops 94726, no buffer drops 0, other drops 0
      Bandwidth: 20%, kbps 200
      Queue-limit 500
          
    Class-map: loopback (match-all) (1791/4)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102 (1795)
      queue size 0, queue limit 500
      packets output 0, packet drops 0
      tail/random drops 0, no buffer drops 0, other drops 0
      Bandwidth: 10%, kbps 100
      Queue-limit 500

    Class-map: class-default (match-any) (1801/0)
      95382 packets, 94809708 bytes
      5 minute offered rate 2517000 bps, drop rate 0 bps
      Match: any  (1805)
      queue size 5, queue limit 19
      packets output 1013, packet drops 94379
      tail/random drops 94379, no buffer drops 0, other drops 0
      Fair-queue: per-flow queue limit 4

Weighted-Fair Queuing Configuration

In this section, you are presented with information on the weighted-fair queuing configuration.

Note: To find additional information on the commands used in this section, use the Command Lookup Tool (registered customers only) .

ATM interfaces do not support "native" flow-based WFQ configured directly on an interface with the fair-queue command. However, with the software supporting CBWFQ, we can configure flow-based WFQ within the default class, as shown below:

    policy-map test 
    class class-default 
     fair-queue 
    ! 
    interface ATMx/y.z point-to-point 
     ip address a.b.c.d M.M.M.M 
     pvc A/B 
      service-policy output test

Advanced Configuration

In this section, you are presented with information on advanced configurations.

Note: To find additional information on the commands used in this section, use the Command Lookup Tool (registered customers only) .

Class Maps

It is possible to group the map classes on a 7500 platform to form more complicated class maps. Additionally, it is possible to associate logical operations to class map parameters (to determine if traffic matches a class). The following class maps clarify this concept:

          class-map match-all ixia 
            description traffic from Ixia 
            match input-interface FastEthernet0/1/0 
          class-map match-all ftp1 
            description ftp traffic initiated by the traffic generator 
            match class-map ixia 
            match class-map ftp2 
          class-map match-all ftp2 
            match access-group 103 
          class-map match-any test 
            match access-group 102 
            match input-interface Ethernet0/0/0 
          ! 
          access-list 103 permit tcp any any eq ftp

The difference between match-all and match-any is as follows:

match-all means that a flow will be associated with a class map if ALL the associated conditions are being verified.
match-any means that a flow will be associated with a class-map if ANY associated conditions are being verified (not necessarily all the conditions).

You can also see that a class map can include tests against other configured class maps. In this case, note that a flow will be associated to ftp1 if it matches all the conditions defined under class map ixia and class map ftp2.

Traffic Parameters

With the 7500 platform, you can also define more traffic parameters under the policy map for each of the classes. Below is a list of these parameters.

The QoS policy-map class configuration commands are shown below.

  bandwidth      Bandwidth
  default        Set a command to its defaults
  exit           Exit from QoS class action configuration mode
  no             Negate a command or set its defaults
  police         Police
  set            Set QoS values
  fair-queue     Flow-based Fair Queuing
  priority       Low Latency Queuing
  queue-limit    Queue Max Threshold for Tail Drop
  random-detect  Weighted Random Early Detect
  shape          Traffic Shaping

Verify

There is currently no verification procedure available for this configuration.

Known Caveat

When attaching a policy map to an interface, the classification can sometimes fail on router-generated packets. This problem, which only happened on Cisco 7500 routers, has now been resolved and is documented under Cisco bug ID CSCds28029 (registered customers only) - Need to classify router-generated packets on 7500 VIP.

When you apply a service policy to an ATM PVC on a 7500 Series router running Cisco IOS Software Release 12.0(13)S or 12.1(5)T and are not doing distributed QoS, the classification counters under the show policy-map interface command output will not increment. This issue occurs when classification and packet switching are handled by the Route Switch Processor (RSP). As a workaround, enable distributed QoS with the ip cef distributed command. This issue is resolved via bug ID CSCds34478 (registered customers only) .

As of Cisco IOS Software Releases 12.1(5)T, 12.1(5)E, and 12.0(14)S, only VIP-based or distributed per-VC queuing is supported on the 7500 Series. RSP-based QoS is no longer supported.

Related Information

Updated: Nov 15, 2007

Document ID: 10396

Hierarchical Navigation

IP to ATM Class of Service