CCNP BCRAN Self-Study: Managing Network Performance with Queuing and Compression

Class-Based Weighted Fair Queuing

Because all the problems associated with getting the proper packets out first have not been addressed (thus far), additional queuing methods have been developed. The basic building block of WFQ offers a nice starting point for additional queuing strategies. WFQ separates the packets into flows and applies a weight to high-priority packets so that they can leave first, but as the previous section shows, the potential shortcoming of WFQ is the lack of administrator control.

CBWFQ adds a level of administrator control to the WFQ process. The same WFQ dispatch process is followed. The difference now is that the administrator can control how packets are divided into the conversations or flows.

Thus far, FIFO and WFQ really do not need much configuration. FIFO is really the lack of WFQ, and WFQ is on by default for interfaces that are less than 2 Mbps. There are a few commands to tweak WFQ, but there are no commands to control WFQ. CBWFQ, on the other hand, can be controlled. Figure 15-6 shows how CBWFQ tames WFQ.

Figure 15-6 Class-Based Weighted Fair Queuing

In this example, the administrator has decided that all high-priority traffic should reside in the same flow, regardless of any other conditions that might place them into separate flows. The administrator-defined flows are called classes. The WFQ algorithm is still at work, but the queue definition is under control now. Table 15-3 shows that although the second high-priority packet arrived well after the large packet, it still goes out second in line.

CBWFQ allows the administrator to define the various flows needed to classify traffic into unique conversations. In addition to this separation of traffic, CBWFQ can be used to guarantee that flows receive adequate bandwidth (defined by the administrator).

Table 15-3 CBWFQ Uses WFQ

CBWFQ has three basic components. The first part is defining the flows for specific traffic patterns (class-map command). There are many different ways to determine such flows. The second part is deciding how to handle each flow (policy-map command). Normally, minimum and/or maximum bandwidth requirements are set on each flow. And the final part is to assign this policy to the interface (service-policy command). CBWFQ can also be assigned to a Frame Relay DLCI. The following three sections describe each of these components in turn. The actual configuration and verification commands are then described.

The class-map Command

The first configuration part of CBWFQ is to define the individual flows that are to pass through the queuing system. The class-map command, which is used to create these flows, selects specific traffic to be put into the CBWFQ. It is possible to have many class-map commands, and each one can have up to 64 matching conditions within. Example 15-1 shows how to create a class map.

Example 15-1 The class-map Command

class-map match-all bcran-class

The class-map command, as shown in Example 15-1, defines a named class (using bcran-class as a name) that is used to select traffic. There are two options used when a class map is defined. The preceding command uses the match-all option. This means that all match commands within the class map must be true for this class to succeed. Thus, this is a logical AND condition. The alternate is the match-any command. This states that any one of the match commands causes this class to succeed. This is the logical OR condition.

Within the class map, match commands are used to find packets for this class. Example 15-2 shows a class map with a single match command.

Example 15-2 The match Command

class-map match-all bcran-class
 match access-group 101

In Example 15-2, any packets that are permitted in IP access list 101 are put into the class map bcran-class. Because only a single match statement is used, the class map could be either match-all or match-any.

In Example 15-3, only packets that are permitted in both IP access lists 101 and 102 are entered into the class map.

Example 15-3 The match-all Command

class-map match-all bcran-class
 match access-group 101
 match access-group 102

In Example 15-4, packets that are permitted by either IP access list 101 or 102 are put into the class map. The difference this time is the use of the match-any command when defining the class map.

Example 15-4 The match-any Command

class-map match-any bcran-class
 match access-group 101
 match access-group 102

The match command can be used to examine a wide variety of different criteria. As has been shown, IP traffic in access lists can be examined. Also, the IP precedence value, IP DSCP value, IP RTP ports, COS bits, QoS group number, MPLS experimental bits, and protocol values can be matched in a class-map.

The policy-map Command

A class map consists of one or more match commands to select packets for the class. A policy-map collects one or more class-maps and defines the actions that are taken for each class-map. Thus, for a policy-map command to properly function, a class-map must already exist. Example 15-5 shows how a policy-map is created.

Example 15-5 The policy-map Command

policy-map bcran-policy
 class bcran-class
  bandwidth 48 

Example 15-5 first defines a policy-map named bcran-policy. The policy-map then maps the class-map named bcran-class (created earlier). And, all packets that are officially a member of the class-map are given a minimum bandwidth of 48 kbps. The bandwidth option states that the class-map is guaranteed 48 kbps. Note that the guarantee of bandwidth is not enforced unless the interface is congested.

In reality, the class-map may use more bandwidth if it is available, but if the interface where this policy is applied is busy, this particular class-map will get 48 kbps.

Example 15-6 shows the same policy-map named bcran-policy, but this time, there are three different class statements used.

Example 15-6 A Complete policy map Configuration

policy-map bcran-policy
 class bcran-class
  bandwidth 48 
 class other-class
  bandwidth 24 
 class class-default
  fair-queue 

Two of the class statements reference specific class maps that have already been defined. The first class, called bcran-class, gets a minimum of 48 kbps. The second one, called other-class, gets a minimum of 24 kbps. And everything else that passes through the interface where this policy is applied uses WFQ. The function of the class-default is to catch any traffic that does not match any of the class maps within the policy map.

The preceding configuration example allocates a specific amount of bandwidth to each class-map. Bandwidth can also be allocated to a percentage of the total available bandwidth on an interface, or as a percentage of the remaining bandwidth not claimed by any other class-maps. Other configuration options include policing traffic (throwing out) to either a percentage of bandwidth or to a specific bandwidth value; shaping traffic (buffering); setting various markers; and adjusting the queue limits to avoid tail drops.

The service-policy Command

Now that the CBWFQ policy has been constructed, it must be applied to an interface. The service-policy command is used to map an existing policy map to an interface. Note that CBWFQ policies can be applied to either incoming or outgoing traffic flows.

Example 15-7 shows how to apply a prebuilt policy-class to an interface.

Example 15-7 The service-policy Command

interface serial 0/0
 service-policy output bcran-policy

Only one policy-class can be applied to an interface in one direction. Normally, the policy is applied for egress (output) traffic, because the low-bandwidth region is outside the interface.

The completed configuration that has been discussed piece-by-piece throughout this chapter thus far is shown in Example 15-8.

Example 15-8 The Complete CBWFQ Configuration

! ACL 101 permits telnet from 172.16.1.0/24 to 192.168.1.0/24
access-list 101 permit tcp 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq telnet

! ACL 102 permits priority 5 traffic from 172.16.2.0/24 to 192.168.2.0/24
access-list 102 permit ip 172.16.2.0 0.0.0.255 192.168.2.0 0.0.0.255 precedence critical

! ACL 103 permits priority 5 traffic from 172.16.3.0/24 to 192.168.3.0/24
access-list 103 permit ip 172.16.3.0 0.0.0.255 192.168.3.0 0.0.0.255 precedence critical

! class-map bcran-class1 matches anything from either ACL 101 or 102
class-map match-any bcran-class
 match access-group 101
 match access-group 102

! class-map bcran-class2 matches anything from ACL 103
class-map match-any other-class
 match access-group 103

! policy-map bcran-policy allows class-map bcran-class 48Kbps, 
! class-map other-class 24Kbps, and all other traffic is WFQ
policy-map bcran-policy
 class bcran-class
  bandwidth 48 
 class other-class
  bandwidth 24 
 class class-default
  fair-queue 

! policy-map bcran-policy is applied to outbound traffic on serial 0/0
interface serial 0/0
 service-policy output bcran-policy

CBWFQ Verification

Once CBWFQ has been configured, the individual pieces can be examined from the command-line interface (CLI). The first thing that should be examined is the interface queuing policy. CBWFQ is an upgrade to WFQ. Thus, the queue examination between WFQ and CBWFQ are quite similar. Example 15-9 shows an interface configured for WFQ.

Example 15-9 The show queue Command

Router# show queue serial 0/0
 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 1158 kilobits/sec
! Next, the same interface is shown when the CBWFQ policy is applied:
Router# show queue serial 0/0
 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/1/256 (active/max active/max total)
   Reserved Conversations 2/2 (allocated/max allocated)
   Available Bandwidth 1086 kilobits/sec

At first glance, it may appear that these two queue displays are identical. Both claim that the interface is configured for WFQ. However, closer examination shows that the second display has two reserved conversations. These reservations represent the two class-map references from the policy map that is applied to this interface. However, there is no specific reference to which policy map may be applied to this interface. Thus, the actual policy-map must be displayed to see the actual class-maps within.

In Example 15-10, the policy-map shows that there are three class statements.

Example 15-10 The show policy-map Command

Router# show policy-map 
 Policy Map bcran-policy
  Class other-class
   Weighted Fair Queueing
      Bandwidth 24 (kbps) Max Threshold 64 (packets)
  Class bcran-class
   Weighted Fair Queueing
      Bandwidth 48 (kbps) Max Threshold 64 (packets)
  Class class-default
   Weighted Fair Queueing
      Flow based Fair Queueing
      Bandwidth 0 (kbps) Max Threshold 64 (packets)

In this example, other-class allocates 24 kbps to packets, bcran-class gives 48 kbps to packets, and the class-default class does not promise any bandwidth to the remaining packets. All other packets are handled via WFQ. However, packets that match any of the displayed class maps are only known by examining the class-maps.

In Example 15-11, the contents of both class maps are shown.

Example 15-11 The show class-map Command

Router# show class-map
 Class Map match-any other-class (id 3)
  Match access-group 103 

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

 Class Map match-any bcran-class (id 2)
  Match access-group 101 
  Match access-group 102

class-map other-class has a single match statement and looks at only ACL 103. class-map bcran-class has two match statements for two different ACLs. The ACLs are "OR'd" together, due to the match-any statement. The class-default simply matches everything that has not been matched thus far.

The access lists that are actually the basis for the matching are shown in Example 15-12.

Example 15-12 The show access-list Command

Router# show access-lists 
Extended IP access list 101
  permit tcp 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq telnet
Extended IP access list 102
  permit ip 172.16.2.0 0.0.0.255 192.168.2.0 0.0.0.255 precedence critical
Extended IP access list 103
  permit ip 172.16.3.0 0.0.0.255 192.168.3.0 0.0.0.255 precedence critical

As previously shown in Example 15-8, ACL 101 permits a particular Telnet session. ACL 102 permits a particular series of packets with the priority set to 5. And ACL 103 also deals with priority 5 packets, but this time for a different packet stream.