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 wha2tsoever (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
As Peter notes, both policers should behave alike and option 1 is a less complex policy.
If your provider is enforcing a hard cap of 50 Mbps, you should try to find out what Tc and Bc (and Be?) they're using, so you can mimic those with your policer. That said, I believe on many platforms, shapers and policer don't account for L2 overhead, so you need to shape/police slower so that the L2 cap isn't exceeded.
As Peter also notes, generally LLQ is used for real-time traffic like VoIP. To avoid it dropping packets, set it's bandwidth setting higher than than you expect you'll ever generate, and continue to use a policer to remark. This will insure, such traffic is dequeued first.
On the idea of not dropping overrate VoIP traffic, i.e. remarking it instead, do be aware although you don't immediately drop the packet, depending on your network and QoS policies, the packet might now be delivered out-of-sequence and/or with too much latency or jitter making it worthless. I.e. you might find you've just used bandwidth for no purpose.
The ideal way to deal with VoIP traffic, is a call admission system, that tracks available bandwidth, and insures new calls are not admitted unless there's bandwidth to support them.
