- "Do I Know This Already?" Quiz
- Queuing Overview
- Introduction to Queuing
- Class-Based Weighted Fair Queuing
- Low-Latency Queuing
- Compression Techniques
- Foundation Summary
- Q&A
This chapter is from the book
This chapter is from the book
This chapter is from the book
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
|
Packet |
Start |
Finish |
ToS |
Multiplier (based on ToS) |
Dispatch (finish ∴ multiplier) |
|
Small #1 |
12 |
14 |
0 |
8 |
112 |
|
Medium |
11 |
15 |
5 |
3 |
45 |
|
Large |
10 |
17 |
0 |
8 |
136 |
|
Small #2 |
18 |
20 |
5 |
3 |
60 |
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.