Cisco 3825 QoS question

Answered Question

I set up a policy-map on a Cisco 3825, however it doesn't seem to be working properly...I've identified traffic, and when I do a show policy-map interface I see that traffic is being placed in the proper queue, however no traffic ever seems to drop, even though it sould (as we are sending more ten 20Mb of traffic).  Here is the config (it's a 20Mb line).  Am I missing something?

policy-map QoS-out
class RealTime
    bandwidth percent 50
class VOIP
    priority percent 5
class bulk
    bandwidth percent 10
class class-default
    fair-queue

show policy-map interface

GigabitEthernet0/1

  Service-policy output: QoS-out

    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) 35527/7026457

    Class-map: RealTime (match-all)
      1876769 packets, 2481848701 bytes
      30 second offered rate 3977000 bps, drop rate 0 bps
      Match:  dscp af21 (18)
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 1876770/2481850135
      bandwidth 50% (10000 kbps)

    Class-map: VOIP (match-all)
      35527 packets, 7026457 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match:  dscp ef (46)
      Priority: 5% (1000 kbps), burst bytes 25000, b/w exceed drops: 0


    Class-map: bulk (match-all)
      3262407 packets, 4400931367 bytes
      30 second offered rate 12257000 bps, drop rate 0 bps
      Match: ip dscp af11 (10)
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 3258111/4395074366
      bandwidth 10% (2000 kbps)

    Class-map: class-default (match-any)
      1315822 packets, 1433735129 bytes
      30 second offered rate 2712000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
      (pkts output/bytes output) 1320118/1439586180
      Fair-queue: per-flow queue limit 16

interface GigabitEthernet0/1
bandwidth 20000
ip address *.*.*.* *.*.*.*
ip flow ingress
ip flow egress
load-interval 30
duplex full
speed 100
media-type rj45
service-policy output QoS-out

I have this problem too.
0 votes
Correct Answer by Nagendra Kumar ... about 7 years 1 month ago

Hi,

"bandwidth" command under physical interface is just a parameter used to influence routing protocol. Configuring this command under any physical interface will not restrict the traffic @ configured rate. you need shaping or policing to limit the traffic flow over an interface.

QoS will kick in only when there is congestion in physical interface. A router will assume congestion only when packets are placed in software queue (buffer) instead of hardware queue (which is your interface queue). As you might be aware, Gigabit Interface is capable of handling 1Gb per second. When you pump 20 Mb of traffic over an interface which can handle 1 Gb of traffic, no packets will be placed in software queue. So router doesnt face any congestion which is the reason why you were not able to see QoS working in your intial implementation.

Now with Shaping enabled, specific amount of traffic will be transfered on an interval and rest will be kept in shaping queue which is software queue. When packets are in shaping queue, QoS kicks in, which is the reason wy things started working for you with shaping.

HTH,

Nagendra

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
jgtheodor Fri, 12/04/2009 - 08:07

Hi,

With the command "bandwidth percent 10" you make sure that whenever there is congestion in this Link, the relevant class-map has the minimum defined bandwidth. If there is no congestion in the Link then the relevant class-map can allocate more "free" unused bandwidth from the Link. So I believe that everything works fine here. Keep in mind also  that with IOS Images newer than 12.4(20)T the queue mechanism is different.

Take alook below!

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_frhqf_support.html

I hope this help!

jgtheodor Fri, 12/04/2009 - 08:37

I see,

However from the output above if you add the relevant class-map 30 sec rates you will see that the sum is lower from 20 Mbps. Furthermore if you try to saturate the Link, the first class must drop packets is the default class and not the bulk class.

Have you tried to send more traffic than 20 Mbps rates to see what happen?

jgtheodor Fri, 12/04/2009 - 09:10

Could you post the IOS image of your 3825 router and the outputof the "show version" and "show policy-map" commands?

jgtheodor Fri, 12/04/2009 - 09:12

Could you send also the output from the "show interface" command? Have you seen dropped packets in the outout from this command?

jgtheodor Fri, 12/04/2009 - 09:43

Well it is straightforward. I have the same IOS Image in a 3845 router and a relevant policy-map in a Serial Interface without a shaper. Whenever there is congestion in the 2Mbps Link, the policy-map drop packets first from default class.

Take a look to the links below. You will find the Hierarchical Queueing Framework (HQF) and some examples from the Ivan's Pepelnjak blog related to the HQF. Hope help you!

http://blog.ioshints.info/2009/11/challenge-cb-wfq-bandwidthpolice.html

http://blog.ioshints.info/2009/11/cb-wfq-misconceptions.html

http://blog.ioshints.info/2009/10/hierarchical-queueing-framework-queue.html

http://blog.ioshints.info/2009/11/first-hqf-impressions-excellent-job.html

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_frhqf_support.html

Correct Answer
Nagendra Kumar ... Fri, 12/04/2009 - 09:39

Hi,

"bandwidth" command under physical interface is just a parameter used to influence routing protocol. Configuring this command under any physical interface will not restrict the traffic @ configured rate. you need shaping or policing to limit the traffic flow over an interface.

QoS will kick in only when there is congestion in physical interface. A router will assume congestion only when packets are placed in software queue (buffer) instead of hardware queue (which is your interface queue). As you might be aware, Gigabit Interface is capable of handling 1Gb per second. When you pump 20 Mb of traffic over an interface which can handle 1 Gb of traffic, no packets will be placed in software queue. So router doesnt face any congestion which is the reason why you were not able to see QoS working in your intial implementation.

Now with Shaping enabled, specific amount of traffic will be transfered on an interval and rest will be kept in shaping queue which is software queue. When packets are in shaping queue, QoS kicks in, which is the reason wy things started working for you with shaping.

HTH,

Nagendra

Thanks for the response.  Is my parent policy config correct then or is there a more optimum way of doing it?  Shape average 20Mb makes me think that it will allow bursts higher then 20Mb (which I wouldn't want)?

This is the parent policy:

policy-map parent
class class-default
    shape average 20000000
  service-policy QoS-out

Actions

This Discussion