I config the autoQoS and change the setting below.
The rate limited is controlled the ip (except ACL 15) to consume 6M max.
the AutoQoS, I config 8M for voice traffic.
If it has 6M voice traffic (RTP) and 5M data traffic (non RTP traffic) to FE0/0, what happen?
priority percent 80
bandwidth percent 8
Interface faste 0/0
decription 10M bandwidth
rate-limit output access-group 15 6000000 50000 50000 conform-action continue exceed-action drop
service-policy output AutoQoS-Policy-Trust
access-list 15 deny 192.168.1.32 0.0.0.31
access-list 15 deny 192.168.1.96
access-list 15 deny 192.168.1.99
Rate limiters, or policers, don't block traffic although they can control bandwidth utilization. If there's abusive traffic you want to block, that's better done using an ACL to drop all of it.
With regard to using a rate limiter or policer to keep some heavy bandwidth flows, such as a FTP file copy, from taking too much bandwidth, a rate limiter or policer can be used for that purpose, but using proportional bandwidth queuing is a much better method I believe, if it's available. (Older equipment and/or some swithes QoS features can be very limited; a reason I asked in my earlier post for you to describe the device you're using.)
If, for example, we believe FTP could be a real problem, the example policy as admended, below, would be better.
use match criteria to identify your RTP traffic
class-map match-any bandwidthHog
match protocol FTP
priority percent 80
bandwidth remaining percent 1
The bandwidthHog class guarantees minimal bandwidth but allows 100% usage of the link's bandwidth if it's available. I.e. FTP could use all the link's bandwidth but would be pushed aside by more important traffic.
Normally, the original policy, using FQ within class-default, would also keep a single or couple heavy traffic flows from taking too much bandwidth from other flows, but it tends to not work well if there are lots of heavy flows.