More in-depth Traffic Shaping Policy with Rule Priority examples – Meraki MX

[WillSparing]

First time playing with VOIP and QoS..so here it goes.

Background - MX to MX sites will be pushing VOIP over the Meraki VPN here soon, they are currently going over the MPLS to locations in another State, just inter-site phone calls and some server to server communications.  Priority is marked at the phone.  Locations have 10Mbps connections.  All Devices operation in full mesh, there will be 5 locations.

I’m currently stuck on how to set Traffic Shaping properly. I’ve read through Cisco’s documentation, but it does not answer all my questions.

https://documentation.meraki.com/MX-Z/Firewall_and_Traffic_Shaping/Using_Packet_Prioritization_on_a_...

https://documentation.meraki.com/MC/MC_Network_Administrator_Guides/Other_Topics/Ensuring_VoIP_Readi...

More to the point, this sentence: “Each traffic rule supersedes each rule below it and the rules below it must strictly adhere to their fractional bandwidth limits.”

So thinking if I just want VOIP to be highest priority as it’s own rule(Rule #1) as high priority.  A 100Mbps is 4/7th reserved for that rule, or ~57Mbps…for just voice if only one rule.  So I figure I need to add service/applications/ports here to balance that out. Or.. I start thinking about putting it as Low Priority 1/7 as Rule #1 ( = 14Mbps), much better for our need per: 
https://documentation.meraki.com/MC/MC_Network_Administrator_Guides/Other_Topics/Ensuring_VoIP_Readi...

Cisco’s Example Assuming 7Mbps up/down:

Case 1:

With 2 high priority rules each get 2Mbps for a total of 4Mbps

With 2 normal priority rules each get 1Mbps for a total of 2Mbps

With 2 low priority rules each get .5Mbps for a total of 1 Mbps

What about another case calling the rule supercedence and adjusting priority levels(priority  “guarantees a certain fraction of the uplink to each priority level”, is not QoS.

Rule 1 – Low priority – 1/7 - Voice  - 1Mbps for Voip (There is existing QoS coming from the phone)

Rule 2 – High Priority – 4/7  RDP/VNC... – 2Mbps for each.

Rule 3 – Normal Priority – 1/7  Misc Video …ext – March madness controls...

It seems like I should stick to assigning High/Medium/Low as Rule 1 – 3, respectively.  Add services accordingly to each.

By now I hope you can spot I seem to be missing some fundamental point that I cannot see, but I can’t pinpoint what it is.  I also do not know why they each get a fraction, but I can configure a plethora or rules with those factions.

Priority seems to be a misnomer here and is part of my uncertainty. The best website I have found to help is below, but they stick to the High/Med/Low configuration as shown in cisco examples: https://dunxd.com/2015/09/10/bandwidth-management-using-traffic-shaping-with-meraki-mx-security-appl...

EDIT:  I've marked solution and am sticking with 3 rules in order of High/Medium/Low.

[Spooster]

Hi WillSparing,

In order to prioritize voice traffic over the other during the congestion, it depends on the number of factors. Can you please answer my following questions:

1) How many phones are connected at each site?

2) Voice CODEC used by the phones?

3) Do the phones marking any QOS?

[WillSparing]

1) How many phones are connected at each site? There is 10 or so at each sub site, 70 or so at the main site.  I work at a legal office, I know there are calls site-to-site, but I can't get too close at what volume they occur or if there is a general rule of thumb when planning the phones.

2) Voice CODEC used by the phones?  I'll have to look this up, I'm not too familiar with the IP Edge system.  The phones support G.711 and G.729A

3) Do the phones marking any QOS?Looking more into this... I'm not sure now.

I know there is QoS, this was setup by a third party initially.  We are in a push to take back more control over our devices/service.  Looking over the website below, I don't see a drastic impact impact in bandwidth per Codec.  Looks like we could assume 90Kbps per active line at most? 

https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html

Thanks for the quick response.  I have not drilled down too much into the specifics, I'll start poking around the system.  I'll continue getting this information. My view point is not 10,000 miles up at this point, but I have not drilled that deep into it.

If you know any youtube vid series, let me know.

[Spooster · Accepted solution]

Hi WillSparing,

For every phone, 100 Kbps bandwidth will be good.
You need to check if phones are already marking voice traffic. If yes, then you need to select that particular DSCP/Precedence and set it to the higher priority in the traffic prioritization rule.
The device will automatically prioritize voice traffic according to this traffic prioritization rule.

I will check for the video series and update you.

[WillSparing]

@Spooster

Okay, that makes sense. If the Cisco SG500 parses that L3 header during transit, should I assume the Meraki acknowledges it, or does it always explicitly need tagged on the Meraki?

I'm guessing if COS is used, it will most definitely need to explicitly need tagged.

I missed the below page originally.  

https://documentation.meraki.com/MX-Z/Firewall_and_Traffic_Shaping/QoS_over_a_Site-to-site_VPN

[PhilipDAth]

Hi @WillSparing, I think you might be over thinking this one.

Unless your rules have overlapping definitions you don't need to worry about the order too much.  Just make each rule unique.

Mark the VoIP traffic as high.  Most implementations I have seen no other QoS is applied.

If I have a customer with RDP I sometimes mark that up (I tend to do that on the MS switches though).

If you have something that consumes a lot of traffic and you want that to get throttled first then mark that down as low.  An example is replication traffic.  You could consider putting SMB file sharing traffic into this category.  Basically "low" gets left over free bandwidth.

[WillSparing]

@PhilipDAth

Good call on SMB, I don't believe that protocol performs well over a WAN to begin with.  I did actually put RDP up, as well as another remote protocol we use.

It seems like Rule 1-3 in High/Med/Low seems to be the easier way to configure this.