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
Does your WAN provider support egress QoS from their cloud?
If they do, you configure QoS policies on your devices as they egress your device toward the WAN cloud, and you insure the ToS markings conform with the provider's QoS cloud policies. (For example, your policy might insure your VoIP obtains LLQ if there's congestion on the interface to the provider's cloud, and the provider insures packets marked with, perhaps DSCP EF, obtain LLQ throughout their cloud, especially upon cloud egress [a common bottleneck].)
If they do not, your device QoS policies can shape for destination's bandwidth. This works fairly well if your traffic flows are logically hub and spoke not multipoint. If traffic flows are multipoint, in theory, you might shape everywhere, and manually allocate bandwidth allocations, but such an implementation "wastes" bandwidth and is very difficult to manage for more than a few sites. (NB: manual allocation with shaping means if a site has 5 Mbps, you would need to insure the aggregation of all other sites that might send traffic to the site doesn't exceed 5 Mbps. You can proportion the 5 Mbps, between all the other sites, anyway you think you need.)
