ALU - CBWFQ Part 1

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

 

Question:

A Cisco VOIP system has recently been deployed to users in subnet 1.1.3.0/24.  They are experiencing lost packets and unacceptable delay and jitter on the serial link between R2 and R3.  Configure R2 and R3 to guarantee 256,000 bits/sec of bandwidth for RTP traffic traversing the T1.

 

 

 

 

Highlight below for the solution:

 

Solution:

R2 and R3:

class-map match-all CLASS_RTP

 match protocol rtp

!        

policy-map QOS1

 class CLASS_RTP

  priority 256

 class class-default

!

interface Serial1/3

  service-policy output QOS1

 

 

Confirmation:

R3#show policy-map interface

 Serial1/3

  Service-policy output: QOS1

    Class-map: CLASS_RTP (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: protocol rtp

      Queueing

        Strict Priority

        Output Queue: Conversation 264

        Bandwidth 256 (kbps) Burst 6400 (Bytes)

        (pkts matched/bytes matched) 0/0

        (total drops/bytes drops) 0/0

 

    Class-map: class-default (match-any)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 

 

Explanation:

Class Based Weighted Fair Queueing uses Cisco's newer modular quality of service to form QOS policies.  The first step is to create class-maps, these define what traffic will be matched.  In a class map you can match on a myriad of options; the most common being:

• Access-lists
• IP Precedence Values
• DSCP Value
• QOS-Groups   (I will cover these in a future ALU)
• Protocol using NBAR

 

In this case, since RTP encompasses a large range of UDP ports (16384 - 32767), the fastest and least error-prone way to match RTP would be to use NBAR's ability to match a protocol for this task, since all we need is a "match protocol rtp" statement in the class-map.

 

The next step to using Cisco's modular quality of service to form a QOS policy is to combine any class-maps you have into a policy-map to assign actions to traffic matching those classes.  In this case we created a policy called QOS1, and within that referenced the class-map CLASS_RTP.  Within that class there are two types of bandwidth guarantees we can give.  The first is using the "bandwidth" command.   This command allows us to designate a certain amount of bandwidth to a type of traffic, with no priority or preference to when that queue is serviced.  The other option is "priority" which designates a certain level of bandwidth, and services the priority queue before any other queues.  Essentially, that allows your highly delay and jitter sensitive RTP traffic to "cut in line" in front of any other traffic on the interface and be sent first.  Any question that mentions voice, video, or delay/jitter sensitive traffic is a clue to use a priority queue instead of a regular queue.

 

It is important to remember that Cisco's "priority" bandwidth guarantee option in CBWFQ sets a policer on the priority queue to prevent priority traffic from starving other queues on the interface.  For example, if we designate 256kbit/sec of priority bandwidth for RTP traffic and we are downloading a large file via FTP at the same time that we are sending 200kbit/sec of RTP traffic, all RTP traffic will be serviced before any FTP traffic.  However, if we initiate another few calls and are now sending 300kbit/sec of RTP traffic, all traffic above 256kbit/sec will be dropped as long as the FTP download is causing interface congestion.

 

In terms of the CCIE lab, if a question has wording such as "ensure no more than 256kbit/sec of RTP traffic is permitted during times of congestion," then you can be confident that they want you to use the "priority" command.  However, if the question states that RTP traffic should always be given priority treatment on the interface, even to the point of starving all other traffic, you will want to use the legacy priority queuing, not CBWFQ.

 

After you have created class-maps to classify your traffic, and a policy-map to assign actions to those classes, the final step to configuring CBWFQ is to assign that policy-map to the interface using the "service-policy output QOS1" command.  It is important to note that most Cisco platforms, including any you might use in the CCIE lab, do not support inbound queuing, so you can only apply CBWFQ outbound on an interface.

 

 

DocCD items to reference:

Configuration Guide (Low Latency Queueing Configuration Task List)

class-map

policy-map

match protocol

priority

service-policy out

show policy-map interface