QoS this way, use the console or Telnet to access the CLI. Using the CLI approach is simple but only allows basic features to be configured. To implement QoS this way, you must first build a QoS policy (traffic policy) and then apply the policy to the interface. Figure summarizes these points. Figure lists these guidelines for building a QoS policy (traffic policy):

Identify the traffic patterns in your network by using a packet analyzer. This activity gives you the ability to identify the traffic types, for example, IP, TCP, User Datagram Protocol (UDP), DECnet, AppleTalk, and Internetwork Packet Exchange (IPX).
After you have performed the traffic identification, start classifying the traffic. For example, separate the voice traffic class from the business-critical traffic class.
For each traffic class, specify the priority for the class. For example, voice is assigned a higher priority than business-critical traffic.
After applying the priorities to the traffic classes, select a proper QoS mechanism, such as queuing, compression, or a combination of both. This choice determines which traffic leaves the device first and how traffic leaves the device.

Example: Legacy CLI QoS
Figure shows a possible implementation scenario for legacy CLI followed by a sample configuration. In this scenario, a low-speed WAN link connects the office site to the central site. Both sites are equipped with PCs and servers that run interactive applications, such as terminal services. Because the available bandwidth is limited, you must devise an appropriate strategy for efficient bandwidth use. In a network with remote sites that use interactive traffic for daily business, bandwidth availability is an issue. The available bandwidth resources need to be used efficiently. Because only simple services are run, basic queuing techniques, such as PQ or CQ, and header compression mechanisms, such as TCP header compression, are needed to use the bandwidth much more efficiently. Note
PQ and CQ are traditional Cisco priority mechanisms that have been mostly replaced by more advanced mechanisms, such as weighted fair queuing (WFQ), CBWFQ, and LLQ. Depending on the kind of traffic in the network, you must choose suitable queuing and compression mechanisms. In the example in Figure , CQ and TCP header compression are a strategy for interactive traffic quality assurance. The output in Figure illustrates complex configuration tasks that can be involved with using the CLI as follows:

Each QoS feature needs a separate line. CQ needs two lines: one line that sets up the queue list, in this example for Telnet traffic, and a second line that binds the queue list to an interface and activates the list.
PPP multilink configuration needs four lines and another line for TCP header compression.

Content 3.4 Using MQC for Implementing QoS 3.4.3 Modular QoS CLI The Cisco MQC allows users to create traffic policies and then attach these policies to interfaces. A QoS policy contains one or more traffic classes and one or more QoS features. A traffic class classifies traffic, and the QoS features in the QoS policy determine how to treat the classified traffic. The Cisco MQC offers significant advantages over the legacy CLI method for implementing QoS. By using MQC, a network administrator can significantly reduce the time and effort it takes to configure QoS in a complex network. Rather than configuring “raw” CLI commands interface by interface, the administrator develops a uniform set of traffic classes and QoS policies that are applied on interfaces. The use of the Cisco MQC allows the separation of traffic classification from the definition of QoS policy. This capability enables easier initial QoS implementation and maintenance as new traffic classes emerge and QoS policies for the network evolve. Figure summarizes these points. Figure summarizes the three steps to follow when configuring QoS using Cisco MQC configuration. Each step answers a question concerning the classes assigned to different traffic flows:

Build a class map: What traffic do we care about? The first step in QoS deployment is to identify the interesting traffic, that is, classify the packets. This step defines a grouping of network traffic—a class-map in MQC terminology—with various classification tools: Access Control Lists (ACLs), IP addresses, IP precedence, IP Differentiated Services Code Point (DSCP), IEEE 802.1p, Multiprotcol Label Switching Experimental bit (MPLS EXP), and Cisco Network Based Application Recognition (NBAR). In this step, you configure traffic classification by using the class-map command.
Policy map: What will happen to the classified traffic? Decide what to do with a group once you identify its traffic. This step is the actual construction of a QoS policy—a policy-map in MQC terminology—by choosing the group of traffic (class-map) on which to perform QoS functions. Examples of QoS functions are queuing, dropping, policing, shaping, and marking. In this step, you configure each traffic policy by associating the traffic class with one or more QoS features using the policy-map command.
Service policy: Where will the policy apply? Apply the appropriate policy map to the desired interfaces, sub-interfaces, or Asynchronous Transfer Mode (ATM) or Frame Relay Permanent Virtual Circuits (PVCs). In this step, you attach the traffic policy to inbound or outbound traffic on interfaces, subinterfaces, or virtual circuits by using the service-policy command.

Figure is a simple example of using the three-step process. The classification step is modular and independent of what happens to the packet after it is classified. For example, a defined policy map contains various class maps and the configuration within a policy map can be changed independently from the configuration of a defined class map (and vice versa). Further, use of the no policy-map command can disable an entire QoS policy.

Content 3.4 Using MQC for Implementing QoS 3.4.4 Modular QoS CLI Step 1: Configuring Class Maps Step 1 requires you to tell the router what traffic gets QoS and to what degree. An ACL is the traditional way to define any traffic for a router. A class-map defines the traffic into groups with classification templates that are used in policy maps where QoS mechanisms are bound to classes. You can configure up to 256 class maps on a router. For example, you might assign video applications to a class map called Video, and e-mail application traffic to a class map called Mail. You could also create a class map called VoIP traffic and and include all of the VoIP protocols. Figure summarizes these points. Use the class-map global configuration command to create a class map. Identify class maps with case-sensitive names. All subsequent references to the class map must use the same name. Each class map contains one or more conditions that define which packets belong to the class. Figure shows the command syntax for the class-map command. There are two ways of processing conditions when there is more than one condition in a class map:

Match all: Must meet all conditions to bind a packet to the class.
Match any: Meet at least one condition to bind the packet to the class.

The default match strategy of class maps is match all. The match commands specify various criteria for classifying packets. Packets are checked to determine whether they match the criteria that are specified in the match commands. If a packet matches the specified criteria, that packet is considered a member of the class and is forwarded according to the QoS specifications set in the traffic policy. Packets that fail to meet any of the matching criteria are classified as members of the default traffic class. The Cisco MQC does not necessarily require that users associate a single traffic class to one traffic policy. Multiple types of traffic