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
#1 The 33% might be as you say, they are just going by Cisco's generic recommendation, but it also might be to allow some head room in the implicit policer as you can not explicitly set its Bc, Be and Tc.
#2 Yes and no. The way LLQ works, its queue is dequeued, and emptied, before any other queues. The 33% is a policer value. It controls how much bandwidth a particular LLQ class may use. Remember you can have multiple LLQ classes. All their traffic is serviced out of one queue, but each LLQ class can have a different policed rate. So, all traffic in HIGH class, regardless whether one flow or many, will be policed (when there's congestion) to 33%.
#3 Hard to say, again, because we don't know what the implicit policer is using for Bc, Be and Tc and you probably don't know exactly how the provided polices its 20%. (The latter would be nice to know, but often difficult to obtain from the provider. If obtained, though, you can have an explicit policer in the class that matches the provider's values while still keeping the priority % higher.)
I would recommend your VoIP phone roll out use the bandwidth allowance on your MPLS circuits, the 20%, rather than the policy's 33%.
