Defining, building, and enforcing application-aware QoS and shaping options on traditional routers and firewalls can be tough. Class maps, policy maps, service policies, interfaces (and direction!) can become confusing quickly for even simple implementations. Try doing nested policies or shaping applications that aren’t easily definable with a standard access list. Forget it.
Contrast that with Meraki’s goal of making the process required to deploy application traffic policies on MX sane.
My goal here is twofold:
- Show you how QoS policies are configured in Dashboard for MX security appliances
- Unpack the behind-the-scenes processes driving the shaping, marking, and queueing that might not be obvious
1. Create a Global Traffic Shaping Policy
If we want to define a global QoS and shaping policy on an MX appliance, we need to first navigate to Security appliance > Configure > Traffic shaping.
1.1 Setting WAN Interface Bandwidth
The first section you’ll see under the Traffic Shaping options is Uplink Configuration. Here we can use the slider to select the bandwidth available to the WAN and cellular interfaces. If your ISP or MPLS provider has a specific bandwidth cap on the connected circuit, then it’s useful to change the WAN1/2 settings to match.
If the upstream circuit is asynchronous (different up/down throughput available) then simply select the details button to the right of the slider and set the Mb/s values accordingly.
Why is this important? The MX will use the WAN interface uplink bandwidth you define here to intelligently load-balance outbound traffic proportional to the bandwidth actually available. For example, if WAN1 is has twice the bandwidth available of WAN2, the MX will send double the outbound traffic flows out WAN1 to maximize throughput and circuit utilization.
1.2 Per-Client Bandwidth Shaping
If you continue down the Traffic Shaping page to the Global bandwidth limits section, here we can limit the amount of bandwidth any one client can consume at a given time.
This can be particularly useful for networks with clients that often transfer large files or stream HD video services. For sites that are bandwidth constrained, a single user can crush the WAN service for an entire office if you’re not careful. This one setting was developed to prevent that.
Pick a limit that makes sense for the entire network because the rate applied here will affect all clients (unless a more specific Group Policy is created).
See the little SpeedBurst checkbox there? Enabling that allows clients to temporarily exceed the bandwidth limit for up to 10 seconds. This is particularly useful for great user web browsing experience since web traffic is usually bursty during page-load, but needs little after that.
2. Application Shaping Rules
At the very bottom of the Traffic Shaping page you’ll find the Traffic shaping rules section.
2.1 Creating a Rule
Traffic shaping rules can be added by simple selecting the Create a new rule button. Rules have two essential parts:
- Identifying traffic to be limited, shaped, or prioritized (the rule definition)
- The action to be performed
A series of QoS rules can be created and moved in any order you choose. The rules are read and enforced from top down, just like an ACL so keep that in mind.
2.2 Rule Definition
1. Next to Definition click Add+
2. Select the application category (or specific app) from the dropdown menu. If you need to define a policy for an app not listed, choose Custom expressions and add your IP and port details for that app’s traffic.
2.3 Custom Expressions
The custom expressions option for traffic shaping rules is very flexible, but there are some things you should know in terms of matching traffic flows correctly. Multiple applications or custom expression match patterns can be used in the same rule. If any of them match, the corresponding action will be enforced.
2.3.1 Hostname Matching
If you’re looking to match web app traffic, the hostname option is a great way to do so. Just make sure you entering in a DNS pattern that will match the app URL being fetched.
2.3.2 Source vs. Destination IP/Port Matching
The IP and port options all match the destination fields when the MX is doing packet inspection. For example, the expression below would match all traffic from any source destined to the 10.1.1.0/24 network using SSL/TLS.
If you want to match traffic based on source IP/port, make sure to use prepend the expression with localnet:. The example below will match any traffic sourced from host 172.16.0.99.
2.4 Rule Actions
Rules with matching traffic can shape, prioritize, and rewrite QoS markings as needed.
Using the Bandwidth limit option, matching traffic can either:
- Use the global per-client configured above (using the Obey network per-client limit)
- Unlimited bandwidth (using the Ignore network per-client limit selection)
- Choose a limit using the slider (shown below)
2.4.2 Priority and Packet Scheduling
The priority dropdown allows you to define the relative priority for the matching flows. Options are:
- High – 4/7
- Normal – 2/7
- Low – 1/7
Each option represents a queue where the packet scheduler process in the MX will move packets through round-robin. for all packets egressing MX WAN interfaces, at least 57% of bandwidth will be reserved for high priority, 29% for normal, and 14% for low.
2.4.3 Quality of Service Marking
If you would like the MX to add or rewrite the IP header DSCP tags for packets (inbound and outbound) matching the rule, use the DSCP tagging selection. The selections also show the corresponding Wi-Fi Multimedia (WMM) priority marking.
Selecting a DSCP value will remark the packets and is most useful when you need guaranteed priority queueing for different classes of service on upstream WAN circuits (like MPLS for example). If the MX WAN interfaces use an internet handoff, then setting the DSCP values is unnecessary since ISPs don’t respect QoS tags.
Most network best practices recommend marking packets as close to the source as possible, so the frames and IP packets can be queued all the way from source to destination. The classic example is an IP phone marking call traffic directly with EF46. That allows both the switch fabric and routed networks to apply proper priority and queuing end-to-end.
If you mark traffic on network clients or access switching, then the recommended MX QoS policy should be to select a priority queue (high, normal, low), but to not set the DSCP tag since it will be preserved through the MX.
QoS via Group Policies
All of the configuration so far has been applied to the Security appliance > Configure > Traffic shaping page in Dashboard. This is good if you want a single QoS policy that will be applied universally to all clients and VLAN packets as they traverse the security appliance.
Some designs leverage both a global QoS and traffic shaping policy as well as several custom group policies that override or append different rules to a subset of client devices or networks.
Group policies are insanely flexible rules that are defined at the network-level and create a customized rule with ACLs, SSID schedules, QoS profiles, content filtering settings, and more.
Group policies are also incredibly flexible in that they can be applied across platforms with Meraki. For example, a single “Bandwidth Abuser” policy could be created at the network-level to shape music and video services for Netflix-loving MX wired clients and MR wireless clients.
Group policy is a big enough topic to explore in another post, but know that the same QoS and traffic shaping options we defined globally on the Traffic shaping page can also changed or created in group policies (Network-wide > Group policies).