QoS

Shape Average Vs Shape Peak – Part 3

/ Will Robinson / Leave a comment

In my previous post in this series I covered the difference between Shape Average, Shape Peak and Shape with no Excess. Now that that’s out of the way, let’s get down to configuration examples. I’ll use similar specifications to the ones I used last time:

  • CIR = 512kbps (512,000 bps)
  • Bc = 5,120 bps
  • Tc = 10ms (0.001 seconds)
  • Be = 5,120 bps for Shape Average and Shape Peak. (Shaping with no Excess will be covered in my next post).

Shape Average

Below is a basic Shape Average policy map with a 512kb shaper applied.

R1(config)#policy-map ShapeAverage-512k
R1(config-pmap)# class class-default
R1(config-pmap-c)#shape average 512000
R1(config-pmap-c)#interface fa0/0
R1(config-if)#service-policy output ShapeAverage-512k
R1(config-if)#do sh policy-map int f0/0

 FastEthernet0/0

  Service-policy output: ShapeAverage-512k

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
           512000/512000    3200   12800     12800     25        1600

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         0         0         0         0         no

Continue reading →

Understanding MQC, Part 3: Output Analysis

/ Will Robinson / 2 Comments

In my previous post I implemented a basic QoS configuration. In this post I will demonstrate how the “bandwidth” and “priority” commands treat their respective classes, as well as how to interpret the “show policy-map interface” command output.

Parent Shaper

Below is the output seen when the “show policy-map interface” command is issued. The Parent Policy’s class-default Class Map (at the top of the output seen below) represents all of the Child Class Maps’ counters put together.

For example, if 5 packets are dropped from the “MATCH-Voice” Class Map and 10 packets are dropped from the “MATCH-BulkData” Class Map, 15 drops will be shown under the Parent Policy.

Router#sh policy-map int gi 0/1
 GigabitEthernet0/1
  Service-policy output: PARENT-EGRESS-Shaper
    Class-map: class-default (match-any)
      1 packets, 68 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any 
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 2/158
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000
      Service-policy : CHILD-EGRESS-BandwidthAllocation
        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
        Class-map: MATCH-BulkData (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            0 packets, 0 bytes
            30 second rate 0 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth 300 kbps
        Class-map: MATCH-Voice (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp ef (46)
            0 packets, 0 bytes
            30 second rate 0 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0

        Class-map: class-default (match-any)
          1 packets, 68 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: any 
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1/98

Continue reading →

Understanding MQC, Part 2: Basic Configuration

/ Will Robinson / Leave a comment

In my previous post I mentioned the six steps which are required in order to implement a QoS solution. In this post I’ll use those steps to create an example implementation. Before I do though, I’ll first cover the “priority” and “bandwidth” commands.

Priority & Bandwidth Commands

In Step 3 of the process you must assign a a portion of bandwidth to the Class Map. The two main options used here are “priority”and “bandwidth”. Details on what each of them do can be found here.

In short though, the “priority” command is used for time sensitive applications where packets need to be sent ASAP, for example, VoIP calls. To ensure that these packets are sent as soon as possible, the router uses a special queuing process called Low Latency Queuing (LLQ) whereby all priority packets are sent immediately, even if there are other packets which on the router first.

The “bandwidth” command is used for non-time sensitive traffic, such as large file backups.

Continue reading →

Understanding MQC, Part 1: The Basics

/ Will Robinson / Leave a comment

Over the course of my next few blog posts I will be covering Modular QoS CLI (MQC), Weighted Fair Queue (WFQ), Class-Based Weighed Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ).

Configuring MQC is not an easy job for those who have never done it before, but thankfully once you understand the basics it’s not very difficult to delve deeper. So let’s get started!

Most Important Rule of QoS

I need to stress the most important rule of QoS – That is, QoS is not implemented if there is no congestion on the link. This is because if there is no congestion on the link, then packets are being sent as soon as they’re being received, therefore there is no need for QoS to kick in.

It is a simple rule to understand but it is easily forgotten.

Continue reading →

Shape Average Vs Shape Peak – Part 2

/ Will Robinson / Leave a comment

Note: If you haven’t read Shape Average Vs Shape Peak – Part 1 already, I suggest you read it first and then return to this entry.

Three Types of Shaping

There are three types of shaping, and they are called:

  • Shape Average
  • Shape Peak
  • Shaping with no Excess

Using the following details, I will explain how each shaping type answers the following question – What if after an interval (10 milliseconds) only 3,00 bits are sent – what happens to the remaining 2,000 tokens in the Token Bucket?

  • CIR = 500kbps (500,000 bps)
  • Bc = 5,000 bps
  • Tc = 10ms (0.001 seconds)
  • Be = 5,000 bps for Shape Average and Shape Peak, 0 bps for Shaping with no Excess

Continue reading →

Shape Average Vs Shape Peak – Part 1

/ Will Robinson / Leave a comment

When I first started looking in to the differences between Shape Average and Shape Peak, I soon found myself getting lost in all of the acronyms – Tc, Bc, Be, CIR, PIR, and so on. However, after some research and labbing, it all became much clearer. I plan to put together my notes and lab tests in a series of blog posts in the hope that they will assist others in understanding how it works.

Note, as this is quite a complex topic I will start with a high level overview to assist readers in getting their minds around the basics. The future posts will delve deeper in to the details.

Syntax

Below is the syntax of the command. Each option will be described below.

shape {average | peak} cir [bc] [be]

Definitions

Below is a list of the acronyms which are used in shaping.

  • Tc – Time interval (in milliseconds).
  • Bc – Committed burst size (in bits). This is the amount of traffic that can be sent per interval (Tc).
  • Be –  Excess burst size (in bits). A burstable rate which can be sent in conjunction with the Bc to achieve greater speeds per interval (Tc).
  • CIR – Committed Information Rate (in bits per second). The guaranteed rate of traffic which can be sent per second, as agreed on the traffic contract with your ISP.
  • PIR – Peak Information Rate (in bits per second). This figure represents Bc + Be.

Continue reading →