Solved: Cisco 3825 QoS question

niro · ‎12-04-2009

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

Nagendra Kumar Nainar · ‎12-04-2009

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

View solution in original post

jgtheodor · ‎12-04-2009

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!

niro · ‎12-04-2009

I understand that nothing will drop if we're not queuing...however we're sending 20Mb of traffic on this 20Mb link, so there SHOULD be queuing, when I do a show Int gi0/1 I see the output rate of 20Mb, so I would tink the bulk class should start dropping.

jgtheodor · ‎12-04-2009

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?

niro · ‎12-04-2009

I just got it working...I set up a parent class with a shaper 20000000 (20Mbit) and assigned the parent to the interface, now the policies are working. I just don't understand why I need that parent shaper class if I have the bandwidth statement on the interface?

jgtheodor · ‎12-04-2009

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

jgtheodor · ‎12-04-2009

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

niro · ‎12-04-2009

Sure here they are...there are some output drops on show interface now...however before I added the shaper class there were no output drops.

jgtheodor · ‎12-04-2009

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

Nagendra Kumar Nainar · ‎12-04-2009

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

niro · ‎12-04-2009

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

Nagendra Kumar Nainar · ‎12-04-2009

Niro,

Your shaping config seems to be fine for deployment.

HTH,

Nagendra

niro · ‎12-04-2009

Great thanks for the help from both of you!