How to calculate traffic shaping bandwidth limitation with load balancing

[Andreas3]

Our customer has two WAN connections of different sizes and uses load balancing and Active-Active AutoVPN. How can I calculate a bandwidth limit?

The customer would like to have 3 classes:
Real-time traffic (VoIP, video, Teams) 30%
Application (Citrix, etc.) 40%
Best Effort (web browsing, internet, etc.) 30%

[GIdenJoe]

You don't need to calculate yourself.
On the traffic shaping page you must define both your WAN circuits down and up speed yourself.

The MX will then calculate it's high/medium/low queues accordingly.

The MX has 4 queues:
Real-time (PQ): this queue has no defined limit in the documentation but will service any incoming traffic with DSCP EF instantly.
High bandwidth queue: 4/7th's of the configured WAN bandwidth.
Medium bw queue: 2/7th's

Low bw queue: 1/7th.

So make sure if you make your rules that you also set the DSCP value which is important for the audio applications found inside the voice and video conferencing application group.

[Andreas3]

So how is it possible that a large download can affect a voice or teams call? I thought that all non-classified traffic goes into the best effort class. So it should not be possible for the line to be so busy that voice calls are disrupted.

[ww]

By default everything is handled in the "normal" queue.

Best is to mark voice with dscp ef on the client so that it would start using the realtime pq

[GIdenJoe]

A download is downstream, traffic comes via the ISP into your connection before any shaping so you don't have any control over the downstream path.  Upstream is a different piece since there you go from high bw to low bw.

And of course you have to make sure your packets are matched and tagged with the correct DSCP value.

By default all your upstream will indeed hit the normal queue and that queue can borrow from the high queue if nothing is in it.

If your circuit is direct internet access the only way to shape your downstream traffic is to have a router in front of your MX and do some random dropping inbound and shape inbound traffic to a little lower than the actual pipe of your ISP.