CAR provides policing functions and marking. Chapter 5, “Traffic Policing and Shaping,” covers the policing details of CAR and CB policing. However, a quick review of policing before getting into CAR’s marking features will help you appreciate why CAR includes marking.

Policing, in its most basic form, discards traffic that exceeds a particular traffic contract. The contract has two components: a rate, stated either in bits per second or bytes per second; and a burst size, stated in either bits or bytes. The traffic conforms to the contract if it sends at the rate, or below, and it does not send a burst of traffic greater than the burst size. If the traffic exceeds the traffic rate over time, or exceeds the single burst size limit, the policing function drops the traffic in excess of the rate and the burst size. Therefore, the simplest form of policing has two rigid actions: either to forward packets or to drop them.

CAR’s marking function allows for additional policing action besides just forwarding or dropping a packet. Consider a typical case where policing is used, as in Figure B-1. ISP1 needs to police traffic to protect customers who conform to their contracts from congestion created by customers who do not conform. If the network is not congested, however, it might be nice to go ahead and forward the nonconforming customer traffic. Doing so doesn’t really cost the ISP anything, so long as the network is not congested. If the network is congested, however, ISP1 wants to discard the traffic that exceeds the contract before discarding traffic that is within its respective contract.

Figure B-1 Policing: Excess Traffic Marked with Higher Discard Value

For instance, the conforming traffic can be marked with DSCP AF41, and the nonconforming traffic with DSCP Default. The congestion-avoidance QoS tools in ISP1 can be configured to aggressively discard all DSCP Default traffic at the first signs of congestion. So, when ISP1 experiences congestion, policing indirectly causes the excess traffic to be discarded; in periods of no congestion, ISP1 provides service beyond what the customer has paid for.

You can also use CAR to just mark the traffic. CAR classifies traffic based on a large number of fields in the packet header, including anything that can be matched with an IP ACL. Once matched, CAR can be configured to do one action for conforming traffic, and another for excess traffic. If the two actions (conform and exceed actions) are the same action, in effect, CAR has not policed, but rather has just marked packets in the same way.

CAR configuration includes the classification, marking, and enabling features all in a single configuration command: the rate-limit interface subcommand. (CB marking, you may recall, separates classification, marking, and enabling on an interface into three separate commands.) Tables B-2, B-3, and B-4 list the pertinent CAR configuration and exec commands, respectively.

Table B-2 Configuration Command Reference for CAR

Table B-3 Possible Actions with CAR rate-limit Command

Table B-4 EXEC Command Reference for CAR

The first CAR marking example, shown in Example B-1, uses the following criteria for marking packets. In this example, R3 is marking packets that flow right to left in Figure B-2.

Figure B-2 CAR Marking Sample 1: VoIP Marked with DSCP EF, Everything Else Marked BE

The configuration does not take nearly as many different commands as the CB marking example, because most of the interesting parameters are contained in the rate-limit commands. Cisco Express Forwarding (CEF) is disabled, just to make the point that although you can use CEF with CAR, it is not required. ACL 102 defines some classification parameters that CAR will use to match VoIP packets, looking at UDP ports between 16,384 and 32,767. The ACL logic matches all VoIP payload, but it will also match VoIP Real Time Control Protocol (RTCP) traffic, which uses the odd-numbered UDP ports in the same port range. Finally, two rate-limit commands under FA0/0 enable CAR, define policing limits, classification details, and marking details.

The first of the two rate-limit commands matches a subset of all traffic using classification, whereas the second rate-limit command just matches all traffic. CAR uses the information configured in these two commands sequentially; in other words, if a packet matches the first CAR statement’s classification details, the statement is matched, and its actions are followed. If not, CAR compares the next statement, and so on. In this example, the first CAR rate-limit command matches VoIP packets by referring to ACL 102, and the second statement, because it does not refer to an ACL, matches all packets.

Now examine the first rate-limit command, rate-limit input access-group 102 10000 20000 30000 conform-action set-dscp-transmit 46 exceed-action set-dscp-transmit 46, in detail. The input keyword means that CAR examines traffic entering the interface. The access-group 102 command means that packets permitted by ACL 102 are considered to match this rate-limit command. The next three values represent the committed rate, the burst size, and the excess size, which make up the traffic contract. The conform-action keyword identifies that the next parameter defines the action applied to conforming traffic, and the exceed-action keyword identifies that the next parameter defines the action applied to traffic that exceeds the traffic contract. In this example, both the conform and exceed actions are identical: set-dscp-transmit 46, which marks the DSCP value to decimal 46, or DSCP EF. (The rate-limit command does not allow the use of DSCP names.)

In this example, the actual traffic contract does not matter, because the actions for conforming traffic and excess traffic are the same. The true goal of this example is just to use CAR to mark packets VoIP—not to actually police the traffic. Chapter 5 includes CAR examples with different conform and exceed actions. The three values represent the committed rate (bps), the committed burst size (bytes), and the committed burst plus the excess burst (bytes). The excess burst parameter essentially provides a larger burst during the first measurement interval after a period of inactivity. (Chapter 5 covers the details of these settings.)

The second rate-limit command, rate-limit input 10000 20000 30000 conform-action set-dscp-transmit 0 exceed-action set-dscp-transmit 0, matches all remaining traffic. The only way that CAR can classify packets is to refer to an IP ACL, or a CAR rate-limit ACL, from the rate-limit command. The second rate-limit command does not refer to an ACL with the access-group keyword, so by implication, the statement matches all packets. Both actions set the DSCP value to zero. Essentially, this example uses CAR to mark traffic with either DSCP 46 or 0 (decimal), without discarding any packets due to policing.

Because CAR cannot take advantage of NBAR, CAR cannot look at the URL for HTTP requests, as the CB marking example did. The slightly modified criteria for CAR marking in Example B-2 is as follows:

Figure B-3 shows the network in which the configuration is applied, and Example B-2 shows the configuration.

Figure B-3 CAR Marking Sample 2 Network

The show interface Fastethernet 0/0 rate-limit command lists the pertinent statistical information about CAR’s performance. The output has one stanza correlating to each rate-limit command on the interface, as highlighted in the example. Under each stanza, the number of packets and bytes that conformed, and the number of packets and bytes that exceeded the traffic contract, are listed. Because this CAR configuration was intended only for marking traffic, the number of packets and bytes in each category does not matter; Chapter 6, “Traffic Policing and Shaping,” takes a closer look at the two values. For comparison purposes, however, consider the bps rates of the combined conformed and exceeded values. For instance, the second rate-limit command referenced ACL 110, which matched the two VoIP calls between R1 and R4. These two values total 55 kbps, which is the amount of traffic expected from a pair of G.729a calls over an Ethernet network.

PBR enables you to route a packet based on other information, in addition to the destination IP address. In most cases, engineers are happy with the choices of routes made by the routing protocol, with routing occurring based on the destination IP address in each packet. For some specialized cases, however, an engineer may want some packets to take a different path. One path through the network may be more secure, for instance, so some packets could be directed through a longer, but more secure, path. Some packets that can tolerate high latency may be routed through a path that uses satellite links, saving bandwidth on the lower-latency terrestrial circuits for delay-sensitive traffic. Regardless of the reasons, PBR can classify packets and choose a different route. Figure B-4 shows a simple example, where FTP traffic is directed over the longer path in the network.

Figure B-4 PBR: FTP Traffic Routed over Longer Path

PBR supports packet marking and policy routing. As you learned in previous sections, CAR supports marking because CAR’s main feature, policing, benefits from having the marking feature available as well. Similarly, PBR includes a marking feature, because in some cases, PBR is used to pick a different route for QoS reasons—for instance, to affect the latency of a packet. So, PBR’s core function can benefit from marking a packet, so that the appropriate QoS action can be taken as the packet traverses the network. Just as with CAR, you can use PBR’s marking feature without actually using its core feature. In other words, you can use PBR just for classification and marking, without choosing a different route. The examples in this chapter focus only on PBR as a marking tool.

Unlike CB marking and CAR, PBR only processes packets entering an interface; you cannot enable it for packets exiting an interface. The reason PBR only processes incoming packets relates to its core function: policy routing. PBR needs to process packets before a routing decision has been made. Therefore, PBR processes packets entering an interface, preempting the normal routing logic based on destination IP address.

Finally, one other difference between PBR and the other classification and marking tools covered so far (CB marking and CAR) is that PBR can classify based on routing information, instead of totally relying on information in the frame or packet header. PBR can look up the entry in the routing table that matches a packet’s destination address, for instance, and then classify based on information about that route. For example, the metric associated with that route, the source of the routing information, or the next-hop interface associated with the route can be checked. In most cases, this routing information does not help you with differentiating between different types of traffic. An FTP server, an IP Phone, a video server, and some web servers may all be in the same subnet, for instance, but the routing information about that subnet could not help PBR distinguish between those different types of traffic. Therefore, typically the most useful classification feature of PBR, when used for marking, is just to refer to an IP ACL.

PBR configuration uses yet another totally different set of configuration commands as compared to CB marking and CAR. PBR does separate the classification, marking, and enabling features into different commands. Tables B-5 and B-6 list the pertinent PBR configuration and exec commands, respectively. Following the tables, two example PBR configurations are shown. The two examples use the same criteria as the two CAR samples.

Table B-5 Configuration Command Reference for PBR¹

Table B-6 EXEC Command Reference for PBR Marking

Example B-3 shows the first PBR marking example, which uses the same criteria as Example B-1 for CAR. In this example, R3 is marking packets that flow right to left in Figure B-5.

Figure B-5 PBR Marking Sample 1: VoIP Marked with IP Precedence 5, Everything Else Marked IP Precedence 0

PBR uses route-map commands, along with match and set route-map subcommands, to classify and mark the packets. This configuration uses a route map named voip-routemap, which includes two clauses. The first clause, clause 10, uses a match command that refers to VoIP-ACL, which is a named IP ACL. VoIP-ACL matches UDP port numbers between 16,384 and 32,767, which matches all VoIP traffic. If the ACL permits a packet, the route map’s first clause acts on the set command, which specifies that IP precedence should be set to 5.

The second route map clause, clause 20, matches the rest of the traffic. The route map could have referred to another IP ACL to match all packets; however, by not specifying a match statement in clause 20, all packets will match this clause by default. By not having to refer to another IP ACL to match all packets, less processing overhead is required. The set command then specifies to set precedence to zero.

The ip policy route-map voip-routemap command enables PBR on interface FA0/0 for incoming packets. Notice that the direction, input or output, is not specified, because PBR can only process incoming packets.

The last PBR-specific command is ip route-cache policy. IOS process-switches PBR traffic by default; to use fast switching on PBR traffic, use the ip route-cache policy command.

The second PBR configuration (Example B-4) includes classification options identical to CAR example 2 (see Example B-2). A major difference between PBR and CAR is that PBR cannot set the DSCP field, so it sets the IP Precedence field instead. The slightly modified criteria, as compared with CAR example 2, for PBR example 2 is as follows:

Figure B-6 shows the network in which the configuration is applied, and Example B-4 shows the configuration.

Figure B-6 PBR Marking Sample 2 Network

The output of the show ip policy command lists only sparse information. The show route-map command enables you to view statistical information about what PBR has performed. This command lists statistics for any activities performed by a route map, including when one is used for PBR. Notice that the four sets of classification criteria seen in the configuration are listed in the highlighted portions of the show route-map output, as are packet and byte counters.

IOS voice gateways provide many services to connect the packetized, VoIP network to nonpacketized, traditional voice services, including analog and digital trunks. IOS gateways perform many tasks, but one of the most important tasks is to convert from packetized voice to nonpacketized voice, and vice versa. In other words, voice traffic entering a router on an analog or digital trunk is not carried inside an IP packet, but the IOS gateway converts the incoming voice to a digital signal (analog trunks only) and adds the appropriate IP, UDP, and RTP headers around the digital voice (both analog and digital trunks). Conversely, when a VoIP packet arrives, and the voice needs to be sent out a trunk, the IOS gateway removes the packet headers, converts the voice to analog (analog trunks only), and sends the traffic out the trunk.

Although this book does not attempt to explain voice configuration and concepts to much depth, some appreciation for IOS gateway configuration is required for some of the functions covered in this book. In particular, Chapter 8, “Call Admission Control and QoS Signaling,” which covers Voice call admission control (CAC), requires a little deeper examination of voice. To understand classification and marking using dial peers, however, only a cursory knowledge of voice configuration is required. Consider Figure B-7, for instance, which shows two analog IOS voice gateways, R1 and R4, along with Examples B-5 and B-6, which show the pertinent configuration on R1 and R4.

Figure B-7 Network with Two Analog Voice Gateways

For voice traffic passing through an IOS gateway, marking the traffic using dial peers provides an easy-to-configure, low-overhead way to mark the packets. Prior to IOS Releases 12.2(2)XB and 12.2(2)T the ip precedence command was used to mark all VoIP traffic with an IP precedence value. After these IOS releases, you can use the ip qos dscp command to separate and individually mark the voice signaling and voice payload traffic. These markings can be DCSP values, or IP precedence values if backward compatibility is needed. Refer to Tables B-5 and B-6 for ip qos dscp command options.

QPPB allows routers to mark packets based on information contained in the routing table. Before packets can be marked, QPPB first must somehow associate a particular marked valued with a particular route. QPPB, as the name implies, accomplishes this task using BGP. This first step can almost be considered as a separate classification and marking step by itself, because BGP routes are classified, based on information that describes the route, and marked with some QoS value.

The classification feature of QPPB can examine many of the BGP path attributes. The two most useful BGP attributes for QPPB are the autonomous system number (ASN) sequence, referred to as the autonomous system path, and the community string. The autonomous system path contains the ordered list of ASNs, representing the ASNs between a router and the autonomous system of the network described in the route. In Figure B-10, R1 receives a BGP update for Network 1, listing ASNs 300 and 400 in the autonomous system path and a BGP update for Network 2, listing ASNs 300 and 500 in the autonomous system path. QPPB can be used to mark the route to Network 1 (Customer 1) with one precedence value, while marking the route to Network 2 (Customer 2) with another precedence value, based on the autonomous system path received for the route to each customer.

The community attribute provides a little more control than does the autonomous system path. The autonomous system path is used to avoid routing loops, and the contents of the autonomous system path changes when aggregate routes are formed. The community attribute, however, allows the engineer to essentially mark any valid value. For instance, R3 could set the community attribute to 10:200 for the route to Network 1, and advertise that route toward the left side of the network diagram. Other routers could then use QPPB to classify based on the community attribute of 10:200, and assign the appropriate precedence value to the route to Network 1. QPPB configuration would essentially create logic as follows: “If the community attribute contains 10:200, mark the route with precedence 4.”

Example B-10 lists the QPPB configuration just for marking the route based on the autonomous system number. With this configuration, no packets are marked, because the QPPB configuration is not complete. (The complete configuration appears in the next section.) QPPB is a two- step process, and Example B-1 just shows the configuration for the first step.

This example shows R2’s configuration for QPPB. (Note that the entire BGP configuration is not shown, just the configuration pertinent to QPPB.) The table-map BGP router subcommand tells IOS that, before adding BGP routes to the routing table, it should examine a route map called mark-prec4-as400. Based on the match and set commands in the route map, when BGP adds routes to the routing table, it also associates either precedence 4 or precedence 0 with each route.

The route map has two clauses—one that matches routes that have autonomous system 400 anywhere in the autonomous system path sequence attribute, and a second clause that matches all routes. Clause 10 matches ASN 400 by referring to autonomous system path ACL 1, which matches any autonomous system path containing ASN 400, and sets the precedence to 4 for those routes. Clause 20 matches all packets, because no specific match command is configured, and sets the precedence to 0.

After QPPB has marked routes with IP precedence or QoS group values, the packet marking part must be performed. After the packets have been marked, traditional QoS tools can be used to perform queuing, congestion avoidance, policing, and so on, based on the marked value.

QPPB’s packet-marking logic flows as follows:

The three-step logic for QPPB packet marking follows the same general flow as the other classification and marking tools; in this case, however, the classification options, and the marking options, are quite limited. QPPB packet classification is based on the routing table entry that matches the packet, and QPPB packet marking just marks the packet with the same value found marked in the route.

Figure B-11 shows with the same network, but with the marking logic on R2 shown.

Figure B-11 QPPB Per-Packet Marking Logic

QPPB allows for marking of packets that have been sent to Customer 1, and for marking packets that have been sent by Customer 1. For packets entering R2’s S0 interface, for instance, the packet is going toward Customer 1, so the destination IP address is in Network 1. Therefore, the QPPB logic on R2’s S0 should compare the packet’s destination IP address to the routing table; if the appropriate QoS field has been set in the route, the packet is marked with the same value. That takes care of packets passing through R3 that are headed to Customer 1.

For packets that Customer 1 has sent, going from right to left in the figure, QPPB on R2 can still mark the packets. These packets typically enter R2’s S1 interface, however, and the packets have a source IP addresses in Network 1. To associate these packets with Network 1, QPPB examines the routing table entry that matches the packet’s source IP address. This match of the routing table is not used for packet forwarding; it is used only for finding the precedence or the QoS group value to set on the packet. In fact, the table lookup for destination addresses does not replace the normal table lookup for forwarding the packet, either. Because the routing table entry for Network 1 has IP precedence set to 4, QPPB marks these packets with precedence 4.

Example B-11 shows the completed configuration on R2, with the additional configuration for per-packet marking highlighted.

The bgp-policy interface subcommand enables QPPB for packets entering the interface. The destination or source keyword identifies whether QPPB should perform table lookup on the packets’ destination or source addresses, respectively. On S0, the destination keyword is used, because the packets entering S0 presumably are going toward Customer 1. Conversely, on S1 the source keyword is used, because the packets entering S1 presumably were sent by Customer 1. Finally, the ip-prec-map keyword implies that the precedence should be set based on the routing table entry, and not the QoS group.

QPPB can classify based on both the autonomous system path and the community string. BGP considers the autonomous system path as a well-known mandatory path attribute; therefore, in the earlier examples, R3 could just examine the autonomous system path. Conversely, BGP considers the community string to be an optional transitive attribute—which means that the community string does not have to be set, and is not set without some additional configuration causing it to be set.

Example B-12 shows the same network, with the same goal of giving Customer 1 premium service. In this example, however, the BGP community attribute is used. The community attribute is set by R3, for routes received from Customer 1 via BGP. With the community attribute set, other routers can use it for classifying the BGP routes and marking the routes with precedence 4. The example shows R3’s QPPB configuration. Example B-12 lists the configuration on R3, and Example B-13 lists the configuration on R2.

In Example B-12, R3 has just set the community string to 4:50 for BGP routes learned from neighbor 192.168.1.1, which is a router at Customer 1. To set the community, BGP uses route-map set-comm based on the neighbor 192.168.1.1 route-map set-comm in command. This route map contains 1 clause, which matches all routes because there is no match command in clause 10, and sets the community string to 4:50. IOS BGP does not forward the community attribute by default, so the neighbor 192.168.2.2 send-community command is needed to make R3 send the community string to R2, whose BGP ID is 192.168.2.2. So, R3 has set all incoming routes from R4 with community 4:50, and includes the community attribute in the updates sent to R2.

Example B-13 shows the configuration for QPPB on R2. The configuration is similar to Example B-11, with the highlighted sections pointing out the added or changed configuration. The table-map BGP router subcommand still directs BGP to mark the routes with precedence 4, but this time using a new route map, mark-prec4-comm. This route map uses two clauses. The first clause, clause 10, matches the community set by R3 by referring to IP community list 1 using the match community 1 command. The community list, created in the single global command ip community-list 1 permit 4:50, just matches all BGP routes whose community string contains 4:50. Route map mark-prec4-comm sets IP precedence 4 for BGP routes that match the community sting. The second route map clause, clause 20, matches all routes because no explicit match statement is configured, and sets the IP precedence to 0 for these routes.

The packet-marking function, as opposed to the route-marking function, is enabled by the bgp-policy interface subcommands, which are exactly the same as shown earlier in Example B-6.

As mentioned earlier, QPPB confuses most people the first time they learn about it. Therefore, you should understand a bit more about it. The first aspect of QPPB you should understand pertains to what BGP updates contain in support of QPPB, and the second aspect of QPPB you should understand is what really happens when QPPB marks a route.

First, BGP updates do not include the IP precedence or QoS group value inside the BGP update. QPPB reacts to the information in a normal BGP update to perform QoS marking of BGP routes, and then in turn performs packet marking based on the marked routes. In other words, BGP RFCs did not add any specification for adding a QoS marking field to the information inside the update. Therefore, to mark based on BGP routes, QPPB uses preexisting fields in the BGP update, such as the autonomous system path and the community attribute. In fact, the BGP-4 RFCs added the community attribute to provide a flexible field for marking BGP routes for future unforeseen purposes, such as QPPB. Figure B-12 depicts the general idea:

Figure B-12 BGP Updates and QPPB Route Marking: No QoS-Marked Fields in BGP Update

When marking IP precedence in packets, QPPB marks the same field already covered in depth in this chapter—the first 3 bits of the ToS byte. When QPPB marks the QoS group, it actually marks a header that is added to the packet when passing through a 7500, GSR, or ESR series router. However, QPPB must mark the route first, and then mark the packet based on the route that matches the source or destination IP address in the packet. To understand what mark the route really means, you must take at least a cursory look at Cisco Express Forwarding (CEF).

IOS provides several different processing paths in software for forwarding packets. Process switching is one of those paths, and is the most processor-intensive path. Fast switching is another switching path still in use today. CEF is yet another switching or forwarding path, and CEF has been designed to be very efficient. Other switching paths have also been added over the years, some specific to particular hardware models. The one thing all these optimized forwarding paths have in common is that they optimize for the forwarding process by streamlining two functions: the process of matching the correct route in the routing table, and the process of building and adding the new data-link header to the packet.

CEF optimizes forwarding by creating a new table that includes entries for the routes in the routing table. This table is called the Forwarding Information Base (FIB). The FIB optimizes the process of locating a route by performing a table lookup in the FIB rather than the less- efficient table lookup of the routing table. In other words, CEF switching crunches the routing table into the FIB, and then uses the FIB to make the forwarding decisions. (This in itself is somewhat of an oversimplification of CEF; for more detail, refer to Vijay Bollapragada’s Inside Cisco IOS Software Architecture [Cisco Press, 2000].)

CEF optimizes the creation of new data-link headers by creating a table that contains the new data-link header associated with each next-hop IP address in the FIB. By doing so, when FIB table lookup is complete, the header can be added to the packet with little processing.

When QPPB marks a route, it actually marks either or both of the two fields inside each entry in the FIB. The FIB contains IP precedence and QoS group fields in order to support QPPB. Therefore, when CEF crunches the routing table to create FIB entries, when QPPB is configured, the appropriate FIB precedence and QoS group fields are set. Figure B-13 shows the general idea.

Figure B-13 “Marking the Route”: Marking the CEF FIB

QPPB provides convenient classification and marking when BGP is already in use. Because QPPB bases classification decisions on BGP information, however, the classification process should consume less overhead per packet than the other generalized classification and marking tools.

Flow-Based dWFQ classifies packets based on the flow, examining the source and destination IP address and port and the protocol type. All of the other main features of dWFQ differ slightly when compared to WFQ. Table B-15 lists several points for comparison.

Table B-15 WFQ Functions and Features

The first big difference between WFQ and dWFQ involves the tail-drop policy. dWFQ has to answer two simple questions when it determines whether to drop a packet:

If either of these questions is true (the aggregate packet limit or the individual queue limit has been exceeded), the new packet is discarded. Unlike WFQ, dWFQ cannot enqueue a packet, only to discard it later because its sequence number (SN) is larger than a new packet’s SN. dWFQ uses the terms “aggregate limit” and “individual limit” to describe the limit over all queues and the limit per queue, respectively.

Unlike WFQ, dWFQ ignores the IP precedence value when calculating the SN of a packet. In other words, dWFQ does not actually weight the packet, totally ignoring the contents of the ToS byte. In effect, all packets are weighted equally, so dWFQ always prefers lower-volume flows in comparison to higher-volume flows.

Another difference between the two is that dWFQ does allow for the maximum queue length to be changed, but the number of queues remains constant at 512.

Finally, one other difference between WFQ and dWFQ has to do with how dWFQ works internally. dWFQ uses a mechanism called a calendar queue to sort all the packets waiting in a dWFQ queue. WFQ uses a simple sorted linked list. The effect is the same—both schedulers select the packet with the lowest SN as the next packet to be forwarded to the TX Queue/TX Ring. By using a calendar queue, however, dWFQ actually performs the final scheduling function more efficiently, which is particularly useful on higher-speed interfaces. (Note that the internals of calendar queues is not important for the QoS exam; if you want to read more, however, refer to Inside Cisco IOS Software Architecture.)

dWFQ Configuration

dWFQ configuration, like WFQ, takes little effort. The fair-queue interface subcommand enables flow-based dWFQ on the interface. If you want to change the aggregate or individual queue limits, you use the fair-queue aggregate-limit and fair-queue individual-limit commands, respectively. You can use the same familiar show commands to examine the status of dWFQ. Tables B-16 and B-17 list the configuration commands and exec commands for Flow-Based dWFQ.

Table B-16 Configuration Command Reference for Flow-Based dWFQ

Table B-17 EXEC Command Reference for Flow-Based dWFQ

Coincidentally, in some cases, a valid configuration for WFQ can be identical to a valid configuration for dWFQ. For instance, the fair-queue subcommand is used to enable both WFQ and dWFQ on an interface. Example B-21 shows a configuration on the familiar R3, which has now been upgraded to a 7500 series router with VIP2-50 line cards:

Example B-21 dWFQ Configuration

ip cef
!
interface serial 0/0/1
 encapsulation ppp
 description Serial interface on VIP2-50
 fair-queue

In the example, CEF has been enabled globally, and the fair-queue command has been added to the serial interface. If the serial interface were not on a VIP at all, WFQ would be performed. With a VIP2-50 installed, dWFQ would be performed.

Figure B-16 summarizes the sequencing and main features of dWFQ.

Figure B-16 Flow-Based dWFQ: Summary of Main Features

ToS-Based dWFQ uses a totally different classification method and a totally different scheduler as compared with WFQ. After reading this section, you may wonder why Cisco calls this tool WFQ at all, because it does not resemble WFQ in very many ways! ToS-Based WFQ classifies based on the 2 low-order bits in the IP Precedence field—in other words, the second and third bits of the Precedence field. It places packets into one of four queues based on these values. It does not consider the flow at all; it is a class-based tool, as opposed to a flow-based tool. Classification is based on the 2 low-order bits in the IP Precedence field, as opposed to WFQ’s flow-based classification.

Although the details are not published, ToS-Based dWFQ does use a fair-queuing scheduler, with the weighting based on the bandwidth percentages configured in each case. If only 2 queues were used, and one queue were given 75 percent of the bandwidth, and the other queue were given 25 percent, for example, internally, IOS calculates weights for the 2 queues with a ratio of 3:1. That’s why it’s called WFQ, although ToS-Based dWFQ differs significantly from WFQ. Table B-18 lists points for comparison, which are illustrated in Figure B-17.

Table B-18 ToS-Based WFQ Functions and Features

Figure B-17 ToS-Based dWFQ: Summary of Main Features

The classification function cannot be changed for ToS-Based WFQ. It always places packets into one of four queues, based on the 2 low-order bits in the IP Precedence field. In other words, precedence 0 and 4 go into Queue 0, because decimal 0 converts to 000, and decimal 4 converts to 100—so the 2 low-order bits are equal. Likewise, precedence 1 and 5 end up in Queue 1, precedence 2 and 6 in Queue 2, and precedence 3 and 7 in Queue 3.

The drop policy is just like dWFQ, using an aggregate limit and individual queue limit method to set the value.

The scheduler provides a percentage of bandwidth for each queue. Cisco does not publish the scheduler logic, but it works like WFQ, using SNs. IOS derives the weights for each queue based on the configured bandwidth percentages. Interestingly, the parameter is actually called weight, although it is interpreted as a percentage of bandwidth. The percentages default to 10 percent, 20 percent, 30 percent, and 40 percent, for Queues 0 through 3, respectively. You can configure the percentages for Queues 1 through 3, with the rest being assigned to Queue 0.

ToS-Based WFQ Configuration

The configuration for ToS-Based dWFQ is simple. Tables B-19 and B-20 list the generic commands, and an example follows these tables.

Table B-19 Configuration Command Reference for ToS-Based dWFQ

Table B-20 EXEC Command Reference for ToS-Based dWFQ

Configuring the fair-queue tos subcommand on an interface enables ToS-Based dWFQ. For this command to work, distributed CEF (dCEF) must be enabled, and the interface must really be on a VIP2-xx, where xx is 40 or higher. Example B-22 shows a sample configuration, along with changes to the bandwidth percentages given to Queues 1, 2, and 3. In this case, Queue 0 gets 39 percent of the link bandwidth, because 61 percent has been assigned using configuration commands.

Example B-22 ToS-Based dWFQ Configuration

ip cef
!
interface serial 0/0/1
 encapsulation ppp
 description Serial interface on VIP2-50
 fair-queue tos
 fair-queue tos 1 weight 30
 fair-queue tos 2 weight 30
 fair-queue tos 3 weight 1

QoS Group–Based dWFQ behaves almost identically to ToS-Based WFQ. The classification feature of each is similar, but with QoS Group–Based dWFQ, the classification is based on the QoS group value assigned to the packet. The QoS group is a value between 0 and 99, inclusive, which is assigned to the packet as it passes through a single router. QoS Group–Based dWFQ classifies a packet into 1 of 100 queues, numbered 0 through 99, matching the QOS group assigned to the packet. (Queue 0 is the default queue.)

The drop policy and scheduler work just like ToS-Based dWFQ as well. The bandwidth percentages can be spread among as many as 100 queues. Table B-21 lists the familiar points for comparison, this time highlighting QoS Group–Based dWFQ, and Figure B-18 depicts the general sequence of events when using QoS Group–Based dWFQ.

Table B-21 QoS Group–Based WFQ Functions and Features

Figure B-18 QoS Group–Based dWFQ: Summary of Main Features

QoS Group–Based WFQ Configuration

The configuration for QoS Group–Based dWFQ is simple. Tables B-22 and B-23 lists the generic commands.

Table B-22 Configuration Command Reference for QoS Group–Based dWFQ

Table B-23 EXEC Command Reference for QoS Group–Based dWFQ

Configuring the fair-queue qos-group subcommand on an interface enables QoS Group–Based dWFQ. For this command to work, dCEF must be enabled, and the interface must really be on a VIP2-xx, where xx is 40 or higher. Example B-23 shows a sample configuration, along with changes to the bandwidth percentages given to Queues 1, 2, and 3. In this case, queue 0 gets 39 percent of the link bandwidth, because 61 percent has been assigned using configuration commands.

Example B-23 QoS Group–Based dWFQ Configuration

ip cef
!
interface serial 0/0/1
 encapsulation ppp
 description Serial interface on VIP2-50
 fair-queue qos-group
 fair-queue qos-group 1 weight 30
 fair-queue qos-group 2 weight 30
 fair-queue qos-group 3 weight 1

Example B-23 lists the same basic parameters as Example B-13, but with QoS Group–Based dWFQ in this case. Of course, more queues could be used, with different weights (bandwidth percentages) for each queue.

Of the three dWFQ options, useful on the 7500 series routers only, dWFQ (also called Flow- Based dWFQ) is most similar to WFQ. It is flow based, uses a similar (although slightly different) drop policy, and uses the same scheduling logic. However, the other differences are significant: dWFQ does not consider the IP precedence when assigning SNs, and it only allows 512 queues.

The other two dWFQ options, ToS-Based dWFQ and QoS Group–Based dWFQ, stand out in their lack of similarity to WFQ. Neither are flow based, the number of queues is predetermined, and the scheduler assigns weights based on bandwidth percentages, which is more like CQ or CBWFQ. Like dWFQ, these two options are available only on 7500 series routers.

ToS-Based dWFQ classifies based on the 2 low-order bits in the IP Precedence field, which may require you to rethink your QoS classification and marking strategy. For instance, Cisco recommends that you mark video payload with AF41, and the least-important data with DSCP BE. The video needs high bandwidth, low delay, and low jitter. The unimportant data can get the leftover bandwidth, with no significant delay requirements. With DSCP AF41’s binary code being 100010, however, and DSCP BE being 000000, ToS-Based dWFQ would work poorly. (The low-order 2 bits of the IP Precedence field are in bold, and in both cases, the value is binary 00.) Similarly, DSCP EF traffic and DSCP AF11, AF12, and AF13 would all be placed in the same queue with ToS-Based dWFQ. Therefore, you would need to reconsider the QoS policy for marking before using this tool.

From an exam-preparation perspective, try to focus on the details of WFQ and the comparisons between the tools that Table B-24 outlines.

Table B-24 Summary of dWFQ Functions and Features

MDRR configuration requires you to understand GSR architecture to a small degree. MDRR configuration also introduces some new terminology. Table B-26 lists the configuration commands related to MDRR, and following the tables is an explanation of the new terminology, the formula used to calculate the QV per queue, and an explanation of the flow of the configuration commands.

Table B-26 Command Reference for MDRR

After you understand the basic concepts, you just need to understand a few facts about how the configuration commands work before being able to configure basic MDRR. First, the low- latency queue is always Queue 7, and instead of being referred to as Queue 7, the low-latency queue is referred to with the low-latency keyword. The next thing to note is that the QoS configuration details are configured as subcommands of the cos-queue-group command. In other words, the classification details, choosing QVs by using the weight keyword, and selecting strict or alternate LLQ scheduling, are configured as subcommands of the cos-queue- group command. MDRR configuration does not enable you to specify the QV for each queue, but rather you configure a value called weight. The QV is then calculated from the weight using the following formula:

Here, MTU is the maximum transmission unit configured for the interface. Weight values can be configured between 1 and 2048, but Cisco recommends using low values—in fact, for the lowest-weight queue, use a value of 1.

Finally, like LAN switches, GSR routers benefit from having both input and output queuing. MDRR can be applied to an interface for input packets using the rx-cos command, and for output packets using the tx-cos command.

The following criteria is used in the upcoming example configuration:

Example B-24 shows the configuration and show commands.

Most of the commands in the sample are configuration subcommands under the cos-queue- group my-sample command. For instance, the precedence 0 queue 0 command maps precedence 0 packets to Queue 0; a similar command maps the appropriate precedence values to queues, as stated in the policy before the example. Similarly, WRED parameters apply per precedence, so the precedence 0 random-detect-label 0 command links precedence 0 packets to a set of WRED parameters with a WRED label of 0. At the end of the example, the random- detect-label 0 command creates a WRED label 0, with no specific parameters—even if you want to take default WRED parameters, you still need to create the label, and refer to it with a command such as precedence 0 random-detect-label 0 to enable WRED for those packets.

The weights are configured with the queue command seen toward the end of the configuration. The queue 0 1 command assigns a weight of 1 to Queue 0, and the queue 1 3 command assigns a weight of 3 to Queue 1. The queue low-latency strict command defines that Queue 7, the low-latency queue, should use strict scheduling.

Finally, at the top of the configuration, the rx-cos my-sample command enables cos-queue-list my-sample for packets entering interface pos 3/0. Similarly, the tx-cos my-sample interface subcommand enables MDRR for packets exiting pos 3/1.

MDRR provides queuing services on GSR 12000 series routers. It assigns a percentage bandwidth through the use of the weight keyword, with the percentages being much more exact than CQ through the deficit feature of the MDRR scheduler. MDRR allows two options for treatment of the low-latency queue, strict and alternate, which gives the engineer more flexibility in how to deal with delay- and jitter-sensitive traffic.

The classification feature of MDRR only supports IP precedence, which can be seen as a negative. Because most networks deploy GSRs in the core of the network, however, a good QoS design, with classification and marking at the edge of the network, can work very well with the precedence-based classification of MDRR.