Qos police and shaping

Unanswered Question
Jan 26th, 2009

Dears ,


I do a policy-map like below .what it will do ?


I want my traffic to limit to 32Mbps with less effect to the customer .


policy-map 32Megd

class any

shape average 30720000

police 32768000 conform-action transmit exceed-action drop


Regards

Haris

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Kerem Gursu Mon, 01/26/2009 - 05:21

Hi Haris ,


In order to limit the traffic , you should consider using policing on the interface.


In order to limit "all" traffic going out from your interface , you need to configure class-default to match.




policy-map 32Megd

class class-default

police 32768000 conform-action transmit exceed-action drop


If you apply this policy to the regarding interface :


Interface x/y

service-policy output 32Megd



you should be dropping the excess traffic above 32 Mbps on your interface .


HTH



johnlloyd_13 Mon, 01/26/2009 - 05:43

if you want the "less effect" on customer traffic, go with the "gentler" kind qos implementation, which is shaping. policing will just tail-drop any excess bandwidth. shaping on the other hand queues excess traffic and send it at a desired constant rate:


policy-map 32Megd

class any

shape average 30720000




Joseph W. Doherty Mon, 01/26/2009 - 06:19

Can you both shape and police at the same level? Unsure, but seems counterproductive. If your configuration can be actually implemented, I would expect the shaper with its slightly lessor bandwidth configuration to keep the policer from activation. (Their Tc values, depending on their defaults, might permit the policer to limit traffic before the shaper buffers it.)


I would suggest just using a shaper.

Haris P Mon, 01/26/2009 - 06:35

Dear Joseph ,


This is what I meant by the configuration .



I Put shaper at 30Mbps and policer at 32 Mbps , so that the policer will not be active and at the same time excess traffic will be shaped to 30Mbps . If I apply Only policing it's affecting very badly to customer traffic


Whether this will make sense ? .


Regards

Haris

Joseph W. Doherty Mon, 01/26/2009 - 09:04

Not unexpected a policer treats customer traffic badly. Since you have the shaper, now, I don't think it makes sense to continue to use the policer. If you remove the policer, don't forget, you might set the shaper for 32 Mbps.

Haris P Mon, 01/26/2009 - 09:46

Dear Joseph ,


My problem is that with traffic shaping , the traffic is exceeding the configured value but with policing it never exceeded the traffic .


As explained before I have the shaping set to 30Mbps and policing to 32Mbps, but i see matches in the policing , which means that shaping is exceeding the configured value . I'm confused from this

Just see the below output of show policy map interface

------------------------------------


Service-policy output: 32Megd


Class-map: any (match-all)

31134835 packets, 28464096580 bytes

5 minute offered rate 9785000 bps, drop rate 0 bps

Match: access-group 100

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

30720000/30720000 192000 768000 768000 25 96000


Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 30666115 2079431444 4363430 564118924 no

police:

cir 32768000 bps, bc 1024000 bytes

conformed 30927853 packets, 28178546635 bytes; actions:

transmit

exceeded 206980 packets, 285547082 bytes; actions:

drop

conformed 9401000 bps, exceed 0 bps


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

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

----------------------------------

Where access-list 100 permit ip any any


Regards

Haris


Joseph W. Doherty Mon, 01/26/2009 - 10:50

Ah, well that's a much better question. Understand your confusion.


It appears, both the shaper and your policer are measuring traffic independently, and with the policer default Bc (1024000 bytes) being larger than the shaper's default Bc (96000 bytes), I wouldn't expect the behavior you're seeing. If the converse was true, I would expect it.


Unless we're looking at a bug, the packets the policer is "unexpectly" dropping probably don't indicate complete failure of the shaper. I suspect there's a good change you still don't need the policer.


The policer drops might be caused by some sync issue between the shaper's bandwidth measurement and the policer's bandwidth measurement. Or, it might be caused by the fact that the shaper has a non-zero Be, although my understanding Be should only be used with peak shaping not average shaping. However, you could explicity set the shaper's Be to zero and see if that results in different behavior. You could also try a 10 ms Tc for the shaper rather than the default 25 ms, or might try having both the shaper and policer with the same Bc.


Again, though, chances are good, that the policer drops are due to some interplay between how the policer measures bandwidth vs. the how the shaper measures bandwidth and for practical purposes, there's no reason you shouldn't be able to use just the shaper.


If you do try some of the other changes I suggested, and results still don't make sense and you think it's imporant, I would then suggest Cisco's TAC.

Actions

This Discussion