cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3991
Views
20
Helpful
6
Replies

Is my QoS working?

tato386
Level 6
Level 6

I put together a simple QoS config on my 1841 and I am not sure if it is working or not.  When I use the show policy-map command I see it packet counts moving up in certain parts of the output but where it says "packets matched" under queing it matches very little.  Also see where offered rate is 0.  Can someone help me decipher the output?

Thanks,

Diego

!
class-map match-any voice
match  dscp ef
!
!
policy-map QoS
class voice
  priority 384
  set dscp ef
class class-default
  fair-queue
!
!
interface FastEthernet0/1
service-policy output QoS
!
!
router#sho policy-map int Fa0/1
FastEthernet0/1

  Service-policy output: QoS

    Class-map: voice (match-any)
      2754302 packets, 421302949 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match:  dscp ef (46)
        2754302 packets, 421302949 bytes
        5 minute rate 0 bps
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 384 (kbps) Burst 9600 (Bytes)
        (pkts matched/bytes matched) 961/142018
        (total drops/bytes drops) 0/0
      QoS Set
        dscp ef
          Packets marked 2740164

    Class-map: class-default (match-any)
      14340349 packets, 3551815392 bytes
      5 minute offered rate 378000 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 256
        (total queued/total drops/no-buffer drops) 0/0/0
router#

1 Accepted Solution

Accepted Solutions

 I left out the part of the config under fa0/1 where I specify bandwidth 3072. 

The bandwidth command does not specify the speed of the link, nor will it get your traffic to egress the port at that speed.  That command simply controls the weight of the interface for routing protocols.  Congestion is only going to occur on that interface at speeds near 100Mbps.

The proper way to apply QoS to a LAN interface if there is an upstream WAN bottleneck (like you have) is to shape the output of the LAN interface to the speed of the WAN link,  You should be confiugring a 3MB shaper on the f0/1 interface output.  Otherwise, the congestion occurs at the ISP router instead of your router.

To answer your other question, that number is lower because the queueing will only take effect during congestion, so it looks like there may actually have been slight congestion for a few seconds (tops).  Also, take IOS counters with a grain of salt when talking about literal packet matches.  The counters aren't always 1 for 1.  Classiciation counters should always increment, regardless of if queueing is taking place or not.

But still, I consider your QoS a misconfiguration and it likely isn't really behaving like you expect it to.  I highly recommend you configure a parent shaper at 3MB and apply your shaper to the ethernet interface if you want it done right.  Here is a config which will work for you:

class-map match-any rtp
  match ip rtp  16384 16383
class-map match-any voice-control
  match dscp cs3 af31
  match protocol mgcp
  match protocol h323
  match protocol sip
  match protocol skinny

policy-map voice-qos
class rtp
  priority
  set dscp ef
class voice-control
  bandwidth
  set dscp
class class-default
  fair-queue
  random-detect dscp-based
  set dscp 0


policy-map shaper
class class-default
  shape average 3000000
  service-policy voice-qos

interface f0/1
  service-policy output shaper

Estimate either .25K of signaling traffic per phone/gateway across the link, or 8K (whichever number is *greater*).  You can find out how much bandwidth you will need for RTP traffic with the voice-call bandwidth calculator found here:

http://tools.cisco.com/Support/VBC/do/CodecCalc1.do

View solution in original post

6 Replies 6

clileikis
Level 7
Level 7

Try placing a few test calls and running the following command on your voice gateway:

Sh call active voice | I Gap
Sh call history voice | I Gap

It will let you know if there is any delay in milliseconds on your gateways.

Unfortunately,  I don't have any voice gateways.  These are SIP phones connecting to remote IP PBX systems.

Thanks,

Diego

Steven Holl
Cisco Employee
Cisco Employee

As long as your traffic for RTP is coming in with DSCP of EF, that QoS policy will work, sort of.  QoS policies only take effect when there is congestion on the link.  You'd need to push >100Mbs of traffic through the device to get congestion to occur.  Chances are, the 100M link isn't the bottleneck in speed for your network, and you have a lower speed link (WAN link somewhere) where the bottleneck occurs.  Hence, you need to configure a parent shaper on the ethernet interface and shape to the speed of the upstream bottleneck.

See this post for more information:

https://supportforums.cisco.com/message/3216526#3216526

Let me know if you have further questions on those concepts, though.

-Steve

Hi Steve:

I am well aware of QoS not doing anything if there is no congestion.  The fa0/1 interface is connected to an ISP router that has 2xT1 bonded circuits for a total of 3MB.  I left out the part of the config under fa0/1 where I specify bandwidth 3072.  I have run MRTG graphs on this interface where I do see it going all the way to 3MB.  Maybe it had not hit those peaks when I issued the show policy-map command above.

My questions is is concerning the discrepancy of patches matched in different sections of the output.  For instance:

Class-map: voice (match-any)
      424729 packets, 87449414 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match:  dscp ef (46)
        424729 packets, 87449414 bytes
        5 minute rate 0 bps
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 384 (kbps) Burst 9600 (Bytes)
        (pkts matched/bytes matched) 141/27454
        (total drops/bytes drops) 0/0
      QoS Set
        dscp ef
          Packets marked 424729

I see 424729 pkts at the top and bottom of the output but only 141 in the middle section under pkts matched.  Does this mean that only 141 packets required to be acted on by the QoS mechanism out of a total of 424729 patches that matched the policy?

Thanks,

Diego

 I left out the part of the config under fa0/1 where I specify bandwidth 3072. 

The bandwidth command does not specify the speed of the link, nor will it get your traffic to egress the port at that speed.  That command simply controls the weight of the interface for routing protocols.  Congestion is only going to occur on that interface at speeds near 100Mbps.

The proper way to apply QoS to a LAN interface if there is an upstream WAN bottleneck (like you have) is to shape the output of the LAN interface to the speed of the WAN link,  You should be confiugring a 3MB shaper on the f0/1 interface output.  Otherwise, the congestion occurs at the ISP router instead of your router.

To answer your other question, that number is lower because the queueing will only take effect during congestion, so it looks like there may actually have been slight congestion for a few seconds (tops).  Also, take IOS counters with a grain of salt when talking about literal packet matches.  The counters aren't always 1 for 1.  Classiciation counters should always increment, regardless of if queueing is taking place or not.

But still, I consider your QoS a misconfiguration and it likely isn't really behaving like you expect it to.  I highly recommend you configure a parent shaper at 3MB and apply your shaper to the ethernet interface if you want it done right.  Here is a config which will work for you:

class-map match-any rtp
  match ip rtp  16384 16383
class-map match-any voice-control
  match dscp cs3 af31
  match protocol mgcp
  match protocol h323
  match protocol sip
  match protocol skinny

policy-map voice-qos
class rtp
  priority
  set dscp ef
class voice-control
  bandwidth
  set dscp
class class-default
  fair-queue
  random-detect dscp-based
  set dscp 0


policy-map shaper
class class-default
  shape average 3000000
  service-policy voice-qos

interface f0/1
  service-policy output shaper

Estimate either .25K of signaling traffic per phone/gateway across the link, or 8K (whichever number is *greater*).  You can find out how much bandwidth you will need for RTP traffic with the voice-call bandwidth calculator found here:

http://tools.cisco.com/Support/VBC/do/CodecCalc1.do

Steve,

That is a great detailed explanation and sample config.  It looks like I definitely want to go with traffic shaping and your config will be a huge help in getting that going.

Thank you very much,

Diego