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
Your rate-limiter is not a shaper.
Unsure all combinations of an interface defined rate-limiter are valid with a service policy, but in this instance it makes sense as this configured rate-limiter only acts upon ingress traffic and your service policy is configured for egress. I.e. they are not acting on the same traffic.
Yes, using a shaper with QoS often makes much sense. Using a rate-limiter (or policer) with QoS is often driven more by configuration placement or device limitations. (Note: rate-limiting can be done upon ingress or egress, a shaper only upon egress; some platforms will support rate-limiting but not shaping.)
In your config snippet, I'm guessing the rate-limiter is trying allow some bandwidth for traffic to hosts other than those listed in ACL 101. Generally, a better way method than limiting some ingress bandwidth would be to define an egress policy on the other side of your serial link.
The major issues policing ingress traffic, as seen in this example, are non-rate-adaptive traffic can still congest the serial link upstream of the policer, or even if rate-adaptive, it may burst above the rate limits (also creating temporary link congestion).
