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

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.

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

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.