Meraki MX bandwidth reservation per application

[iores]

Hi,

I need to reserve 10 mbps bandwidth of WAN uplink for certain applications based on destination IP or FQDN. I have never done it with Meraki so I have few question.

1. SDWAN & Traffic shaping >> Traffic shaping rule - I believe this is the place where I need to configure this. Would this be correct? 
2. How "Per-client bandwidth limit" and "Prirority" interact together?
3. Is it true that priority levels High, Normal, and Low will assign the 4/7, 2/7, and 1/7 fraction of uplink bandwidth?
   • For this to work, does this mean that configured values under SDWAN & Traffic shaping >> Uplink configuration, WAN 1 and WAN need to match the actual uplink bandwidth?
4. I believe that Priority needs to be High or Normal, but what to configure for Per-client bandwidth limit?

Best regards,

[GIdenJoe]

Hello,

For these configurations you will indeed find everything you need on the traffic shaping page on the Security & SD-WAN menu.

The per client bw limit does not directly impact the priority.  You can configure them both on one matching rule but the effects don't impact each other directly.

You will find that the bandwith you set on your uplink in that page is actually being enforced in the form of traffic shaping.  So if you have 50 Mbps uplink but you configure 25 Mbps uplink then the MX will limit upload to 25 Mbps.  And yes the calculations for High, Medium, Low are made directly of the bandwidth you have set.

Keep in mind that with priority you can definitely influence upstream traffic but downstream traffic is coming from the internet will come at your firewall depending on the bandwidth over the internet.  Meaning you can't really influence incoming packets. This is why throttling less desired or bulk latency insensitive traffic to a lower per client limit is desirable.

There is also a hidden realtime queue, which is automatically applied to traffic that has been marked as DSCP PHB -> EF.  So while you can match on voice traffic you cannot choose realtime but you can set the DSCP value accordingly to enforce it that way.

[iores]

@GIdenJoe If I only set e.g. High priority without setting the bandwidth limit, does this mean that the entire bandwidth will be assigned for that class, but other traffic will used it as well if the uplink is not totally congested with the high priority traffic? 

Is there any Meraki or experience-based best practice for similar use case?

Calculations for High, Medium, and Low are based on the bandwidth limit or on uplink configuration value? 

[Brash]

What you've said for the WAN side bandwidth is correct

• For the uplink priority to work correctly, you need to set a bandwidth under "SD-WAN & Traffic Shaping -> Uplink Configuration". This is the value that is used for the calculations.
• When a higher priority queue is not in use, its tokens are dynamically reallocated to lower priority queues

See the following document for reference: https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Firewa...

For downstream bandwidth reservations and queuing (for traffic between the client and the MX), you would want to use QoS and CoS tagging.

[GIdenJoe]

They are always based on the value set on the WAN interface.

So to clarify further: the 4/7, 2/7, 1/7 are minimal guarantees.  So if a lower class traffic needs more and upper classes don't the upper bw will be yielded to a lower class.

So in case of no congestion, the priority values will not have any effect but the bw limitations will.

From a logic standpoint you will have to look at it this way.
Only when there are packets buffered and waiting to be sent over the WAN connection due to a lower upload speed the packest will be serviced according to their queues.  So realtime queue gets serviced first until empty.  Then the bandwidth queues start with first high queue.  If that queue doesn't need 4/7th of the bw to be serviced fully then it will yield the rest to the medium queue.  Then the medium queue gets the 2/7 + extra it got from the high queue.  If that isn't necessary, all the rest goes down to the low queue which then has 1/7 + what it received from the medium queue.

I don't think there are formal best practices on Meraki perse but Cisco itself has documents explaning the 4, 8 and 12 class documents and associated design guides if you want to geek out.

What I personally use in Meraki MX are the following:

My first rule is matching in the Category Voice and Video conferencing but matching each AUDIO category inside.  And set that one to ignore bw limit + DSCP EF.  (Btw WiFi also has a traffic shaping page and there you can also set the L2 PCP tag which whould be set to 6).

My second rule is matching ALL Voice and Video conferencing.  Setting that prio to high, ignore bw limit and giving it AF41.

If you want to allow fluent streaming video like Youtube then my next rule matches on streaming where I set prio to high, limit to either per client limit or custom limit and DSCP to AF31.

Then I match all business relevant traffic like databases, work apps, also remote management for us networking guys 😉  That gets medium, ignore bw and AF21.

Then we get to bulk data where email, filetransfers are put.  There you can optionally set bw limit but priority is medium or low with AF11.

Then finally we get the undesired category that contains advertising, online filetransfers etc.  Those also get low prio, have a strict bw limit and get the CS1 tag.

[iores]

@GIdenJoe What is the purpose of bandwidth limit which is configured under the shaping rule if high, normal, and low priority classes don't take this into account when taking 4/7, 2/7, or 1/7 fraction of the bandwidth? 

How to interpret if I have, for example, two rules with high priority and bandwidth limit of 5 Mbps? 

[GIdenJoe]

You will need to stop conflating the two in your mind or you won't be able to grasp the concept.

The bandwidth limit (either obey or custom) will apply to the traffic matching the rule or matching no rules and just uses the configured per client limit.  This applies bi-directionally.  So less desired downstream traffic can be throttled this way.

The high medium low queue is only applying when you have traffic stuck in buffer waiting for it to be emptied.  Usually this will only apply to upstream internet traffic since the bandwidth of the WAN circuit is usually lower than the link between the MX and the LAN.

The only scenario you could have where you for some weird reason configured a high priority but low bandwidth limit to certain traffic you could have that the buffer will not be fully used for the high traffic if it is limited due to the bw limit configured.  So in that case the rules will apply normally.  The high queue will not fully use it's bw and leave some for the lower queue unless you have more high prio traffic from another client at the same time.

[iores]

Would this be correct understaning.

Let's say WAN uplink is 10 Mbps. If high priority is configured, it will get 4/7 or 5.71 Mpbs.

However, if bandwidth limit of 1 Mbps is configured at the same time, assigned bandwidth of 5.71 Mbps will still be the same for the high priority class, it's just it will get sent at 1 Mbps, and will not use its full potential. The rest of 4.71 can be user by either other priority classes or default traffic class.

[ww]

Yes. The 9Mbps can be used by the normal and low prio

[ww]

Your first rule has no priority set? Is that possible in the dashboard?

[iores]

What about the traffic that is not considered by matching rules?

Would it be correct to say that such traffic will use remaining available bandwidth in addition to available bandwidth from high, medium low classes? 

If there is no congestion on WAN uplink, then the whole uplink bandwidth is used normally with Meraki QoS, right? 

[ww]

With default traffic shaping rules disabled

All traffic is "normal"

Unless you change it using a rule

[iores]

I meant the traffic outside the shaping rules. How is such traffic considered?

[ww]

Prio "Normal"

2/7

[iores]

@ww Traffic under default shaping rules - does it fall under the LLQ?