Meraki MX Traffic-Shaping

Solved
bayet
Getting noticed

Meraki MX Traffic-Shaping

I'm struggling with the configuration of my Traffic-Shaping and therefore I need some assistance.

 

Issue:

 

We have a 70Mbps internet connection. We also have some important department for which we want the network traffic to always have high priority on the network.

We therefore want to create 2 group-policy and assign the important network traffic High and the other network traffic Normal priority.
This mean High will have 50Mbps en Normal will have 20Mbps.

 

This is the part I don't understand very well.

 

Does this mean that in my example here above, the 50Mbss always will be seen as a reserved bandwidth for the High priority and will never be available for the Normal priority, even in s situation where there are no High priority network traffic.
And the Normal priority never will get more than 20Mbps of the bandwidth even if the rest of the bandwidth is unused by the High priority.

1 Accepted Solution
JohnD
Getting noticed

The explanation that cmr gave is really good -- the MX style traffic shaping differs a lot from how a lot of other enterprise traffic shaping devices work. The "reserved bandwidth" model is really popular but Meraki traffic shaping doesn't operate like that: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Using_Packet_Prioritization_on_a_Tr...


Long story short, there's the usual "High/Normal/Low" prioritization where for every 7 "slots", High gets 4, Normal gets 2, and Low gets 1. In addition to that, there appears to be a new VOIP class in MX 14.x, which can be accessed by DSCP tagging, and that gives you an unspecified higher priority than high.

None of the classes have guaranteed zero packet loss under load, which is a big difference between the way Meraki does this versus how a lot of other vendors do. However, the Meraki approach has the advantage that if the only kind of traffic you have is Low at the moment, you can still use 100% of your bandwidth. Most reserved bandwidth implementations permanently carve that bandwidth away, regardless of whether there's any traffic of that class at the moment.

View solution in original post

5 Replies 5
cmr
Kind of a big deal
Kind of a big deal

I believe it is just how many timeslots each type of traffic gets, the high will get more than the low.   If you have 50Mb of both trying to get down the 70Mb connection then the 50Mb of high should have much less packet loss, possibly even none, whereas the 20Mb will suffer a lot of packet loss.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
NolanHerring
Kind of a big deal

If its two VLANs, then you 'might' be able to get away with creating a group policy for the 20Mbps VLAN, and assign that group policy to the VLAN itself. However that ends up with a per-client bandwidth limitation, not entire VLAN.
Nolan Herring | nolanwifi.com
TwitterLinkedIn
JohnD
Getting noticed

The explanation that cmr gave is really good -- the MX style traffic shaping differs a lot from how a lot of other enterprise traffic shaping devices work. The "reserved bandwidth" model is really popular but Meraki traffic shaping doesn't operate like that: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Using_Packet_Prioritization_on_a_Tr...


Long story short, there's the usual "High/Normal/Low" prioritization where for every 7 "slots", High gets 4, Normal gets 2, and Low gets 1. In addition to that, there appears to be a new VOIP class in MX 14.x, which can be accessed by DSCP tagging, and that gives you an unspecified higher priority than high.

None of the classes have guaranteed zero packet loss under load, which is a big difference between the way Meraki does this versus how a lot of other vendors do. However, the Meraki approach has the advantage that if the only kind of traffic you have is Low at the moment, you can still use 100% of your bandwidth. Most reserved bandwidth implementations permanently carve that bandwidth away, regardless of whether there's any traffic of that class at the moment.
bayet
Getting noticed

Oke, thanks you all for the comments.

The reason is that the customer in any way never want the High to have bandwidth issues. So if there aren't High priority traffic, the Normal can still go on and use the bandwidth and High can reclaimed the bandwidth wen needed.
merakichamp
Building a reputation

@bayet  yes if that is how you have defined your traffic shaping rule to impact your network  as obey bandwidth  otherwise why don't you configure as ignore bandwidth default rule for both policies 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels