Accepted Solutions
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Correct.
The major difference, of course, is the shaper will queue.
For example, using a policer, on a 7 Mbps external facing ingress, might look like:
policy-map ingress-police
class ftp
police average 5000000
class class-default
police average 20000000
Ftp in the above couldn't have more than 5 Mbps, even if there's available bandwidth.
If we do something like this (on internal facing egress):
policy-map shape7m
class class-default
shape average 6000000 !unfortunately, has to be less than ingress
service-policy managecongestion
policy-map managecongestion
class ftp
fair-queue
queue-limit 8
bandwidth percent 10
class class-default
fair-queue
queue-limit 8
bandwidth percent 90
FTP or other traffic could use 6 Mbps (up to 7 Mbps in bursts, depends on shaper's 2nd parameter [not shown in above]) but if there's congestion, FTP gets less bandwidth and the shallow queues should drop signal FTP flows to slow (with more packets in a flow, hit first).
NB: you can create additional/different classes, just using FTP as an example.
Notes:
Above syntax requires HQF QoS IOS version. Somewhat similar function could be done with pre-HQF IOS versions.
You're unlikely to find any text describing this approach (or other techniques I use 
).
Thanks for your reply,
I had the suspect that with my equipment I couldn't achieve much on QoS performance, but I tought that it was at least worth a try.
During my tests I did see differences between shaping and policing, almost identical to the Cisco reference graph with small downloads:
With the only difference that for larger downloads the transfers didn't maintain a constant rate but started to oscillate near the policer level, I though the tcp congestion algorithm was the cause and that shaping would be a better option.
Using both of them (police/shaping) on different kind of traffic would help with burst data?
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Correct.
The major difference, of course, is the shaper will queue.
For example, using a policer, on a 7 Mbps external facing ingress, might look like:
policy-map ingress-police
class ftp
police average 5000000
class class-default
police average 20000000
Ftp in the above couldn't have more than 5 Mbps, even if there's available bandwidth.
If we do something like this (on internal facing egress):
policy-map shape7m
class class-default
shape average 6000000 !unfortunately, has to be less than ingress
service-policy managecongestion
policy-map managecongestion
class ftp
fair-queue
queue-limit 8
bandwidth percent 10
class class-default
fair-queue
queue-limit 8
bandwidth percent 90
FTP or other traffic could use 6 Mbps (up to 7 Mbps in bursts, depends on shaper's 2nd parameter [not shown in above]) but if there's congestion, FTP gets less bandwidth and the shallow queues should drop signal FTP flows to slow (with more packets in a flow, hit first).
NB: you can create additional/different classes, just using FTP as an example.
Notes:
Above syntax requires HQF QoS IOS version. Somewhat similar function could be done with pre-HQF IOS versions.
You're unlikely to find any text describing this approach (or other techniques I use ).
