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
When you set IP Precedence (or DSCP), your marking the packet so later analysis only needs to look at the marking. It doesn't directly have anything to do with how packets are treated without configuration (except for Cisco WFQ). I.e. priority percent is how the class is treated, an IP Precedence marking might, or might not, be used to determine what traffic matches the class, but it doesn't, itself, influcence how the traffic is treated (again, except for Cisco's WFQ).
The upside to using bandwidth remaining percent is you don't need to adjust those classes relative percentages when/if you change classes w/o remaining percent. For example, let's say you allocate 20% to LLQ and allocate all the other 80% to non-LLQ classes. Then you determine you need to increase LLQ's allocation to 30%. Now, you have to readjust all your other classes. However, instead of that, if you use remaining percent, you wouldn't need to adjust your other classes. (NB: remaining percent is allocated against 100% of the bandwidth not otherwise allocated.
e.g.:
policy-map x
class llq
priority percent 20
class a
bandwidth remaining percent 70
class class-default
bandwidth remaing percent 30
The 30 and 70 are the percentage of the 80% not allocated.
If your special LAN traffic is strictly ERP, sure you can bump its priority, but possibly better would be recognization of the ERP traffic, and bump its priority. This precludes issues like some high volume data transfer from an "ERP host" getting priority of that traffic when it's not actually ERP traffic.
A real example of how QoS can "surprise you", I elevated/treated SSH traffic, like telnet traffic, so we would have low latency when accessing network devices across the network. It worked great until the day SSH filled our higher priority queue, being adverse to lower class traffic and also adverse to concurrent telnet/SSH.
Additional analysis revealed the high volume flow of SSH was a SCP file transfer. Oops, something I had overlooked, i.e. SCP and SSH looked alike. Needless to say, I revised our QoS policy.
