CCVP: Quality of Service (QoS) Basics – Part 2

Well, after having a great Disney Cruise, I’m posting for the first time in several days. In my last posting, we discussed the foundational topics of the QoS course and exam. However, beginning in this posting, let’s focus on configuration.

The most important configuration concept to understand is the Modular QoS CLI (MQC) three-step process. Using MQC, you’ll be able to configure a ton of QoS mechanisms, including: Class-Based Classification, Class-Based Marking, Class-Based Weighted Fair Queuing (CB-WFQ), Low Latency Queuing (LLQ), Class-Based Weighted Random Early Detection (CB-WRED), Class-Based Policing, Class-Based Shaping, and Class-Based Header Compression.

MQC is simply a three-step process for classifying traffic, creating a policy for the various traffic classes you defined, and applying that policy (typically, to an interface).

MQC – Step 1

The first step in an MQC configuration is to create one or more class maps. Consider the following example:

class-map match-any EMAIL

   match protocol pop3

   match protocol imap

   match protocol smtp

In the above example, the case-sensitive name of the class map is EMAIL. Also, notice the match-any option. This tells the class map that if a packet meets any of the criteria (specified by the match statements) for this class map, then that packet will be classified in that class map. Note that, by default, a class map uses match-all logic, meaning that a packet would have to meet every single criterion to be classified by the class map. Within class map configuration mode, notice that a series of match statements are used to recognize various e-mail protocols.

Consider another example:

class-map VOICE

   match protocol rtp audio

In the above example, notice that there was no match-any or match-all keyword specified. As a result, the default matching logic of match-all is used. However, the matching logic is irrelevant in this example, because there is only a single match statement. Notice that the match statement is matching the Real-time Transport Protocol (RTP), but not just any RTP traffic. Since RTP can be used to carry voice or video, this match statement is specifically matching audio RTP traffic.

Also, be aware that in addition to the class maps you create, there is a default class map named class-default, which matches any traffic that you did not otherwise match with a class map.

MQC – Step 2

Once we’ve created one or more class maps, we can create a policy-map to say what we want to do with the various classes of traffic. Consider the following example:

policy-map KEVINS-EXAMPLE

   class EMAIL

      bandwidth 128

   class VOICE

      priority 64

The above configuration creates a case-sensitive policy map, named KEVINS-EXAMPLE. Within policy map configuration mode, you can enter policy map class configuration mode. I tell my students that this configuration mode is “where the magic happens,” because its from this mode that you can enable the series of QoS mechanisms listed previously.

In this example, we’re saying that we want traffic classified by the EMAIL class-map to have at least 128 kbps of bandwidth if it needs that much, and more if it needs more and more is available. Next, we’re saying that we want traffic classified by the VOICE class to have as much as 64 kbps of bandwidth but no more (to prevent the voice traffic from starving out other traffic). However, the voice traffic gets to go first, out ahead of the other traffic types (but not beyond the 64 kbps limit).

MQC – Step 3

The policy map we created doesn’t do anything until it is applied somewhere. Typically, a policy map is applied to an interface, using the service-policy command. Consider the following example:

interface serial 0/0

   service-policy output KEVINS-EXAMPLE

In the above example, the policy map named KEVINS-EXAMPLE is applied in the outbound direction to interface serial 0/0. As a result, traffic exiting interface serial 0/0 will be classified (by the class maps previously created, or the class-default class-map), its behavior will be influenced by the KEVINS-EXAMPLE policy map.

This three-step example was illustrates the previously mentioned LLQ queuing mechanism. However, at this point, the main thing I want you to understand is the three-step process. Once you understand that, you can use this configuration approach to configure a plethora of QoS mechanisms.

Coming up in my next posting, I’ll to present a series of QoS exam-style questions that we can work through together.

See you soon,

Kevin

• Cisco
• VoIP / Convergence
• CCVP
• cisco voice
• QoS
• VoIP