Connect. Secure. Manage.
Meraki SD-WAN Traffic Policies
Configure Meraki SD-WAN traffic policies around important applications, supported classification methods and measurable path-selection behaviour.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Meraki SD-WAN traffic policies decide how supported MX devices use uplinks and VPN paths. We match rules to app, capacity and security needs, then test how traffic is selected. The design also states what happens when a preferred path becomes unsuitable. Each policy has a clear purpose that the support team can explain.
The whole path
Understand how sites, providers, cloud networks and security controls fit together.
Resilience that can be tested
Separate a second circuit from genuine end-to-end service resilience.
Provider coordination
Keep addressing, routing and escalation ownership clear across organisations.
Separate internet and private-network traffic
Internet-bound apps and traffic to remote private networks may use different policy mechanisms and paths. We find the relevant destinations and the supported features in the deployed firmware and licence. A rule governing VPN traffic should not be assumed to control every public-cloud app in the same way.
The review also records where inspection occurs. Local internet breakout, central security and cloud-delivered protection can each introduce different dependencies. The chosen path must remain consistent with the customer's security decision, rather than selecting an apparently faster uplink that bypasses the intended control.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Define the business reason for each preference
Some apps need predictable latency, others require a stable public source address, and some can use any available capacity. We translate those needs into a small, understandable policy set. The rule owner should be able to explain what problem the preference solves and what would justify changing it later.
We also identify traffic that should remain on ordinary routing behaviour. Excessive exceptions make troubleshooting difficult and can prevent the platform from using capacity effectively. A policy should be introduced because the app requires it, not simply because a dashboard setting is available.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Verify matching and policy order
The effective result depends on the criteria supported by the chosen platform and the relationship between applicable rules. We review source networks, destinations, app classification and other relevant conditions. Encrypted or changing app traffic may not provide the same classification certainty as a fixed internal service.
Overlapping rules are checked with representative flows. A specific preference can be ineffective if another rule or routing decision controls the connection first. We compare the intended policy with observed path choice rather than treating the saved setup as sufficient evidence that the need is being met.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Consider load balancing and session behaviour
Using multiple links can improve aggregate capacity or resilience. But it does not mean one app flow automatically receives the combined bandwidth of every circuit. We examine how the supported platform assigns traffic and the implications for apps with long-lived or stateful sessions.
A path change may alter public addressing, inspection state or the route seen by the remote service. Those consequences matter for external allowlists, voice and some business apps. We test the relevant workflow and explain limitations rather than promising transparent movement of every connection between uplinks.
Define fallback when quality or availability changes
Preferred-path policy needs a clear response to failure. We establish whether traffic should use another approved path and what service level is realistic when capacity is reduced. Quality-based decisions are linked to suitable Meraki SD-WAN performance classes where supported, rather than based on a threshold copied from an unrelated site.
Restoration behaviour is also important. A circuit returning after a fault may be unstable, and frequent path changes can affect users even while network access technically exists. We review the supported decision behaviour and check that it suits the customer's app and operating needs.
Pilot policies before broad rollout
A limited rollout allows the team to compare expected and actual path choice without affecting the whole estate. We include the apps and site types most likely to reveal differences, not only the easiest test branch. Existing policies are captured so the change can be reversed if the result is unsuitable.
Acceptance checks include successful workflows, traffic that should remain unaffected and agreed failure scenarios. We examine relevant dashboard evidence alongside endpoint observations. A policy counter increasing proves that a match occurred, not that the user experience improved or that the chosen path retained the required security treatment.
Keep policy ownership visible
The handover records rule purpose, scope, expected path and fallback. Temporary migration exceptions receive removal criteria, while long-lived policies have an owner and review point. Provider changes, new app destinations and firmware updates can all justify revisiting the assumptions behind a rule.
MCI can rationalise a current policy set or implement a defined traffic need within a wider Meraki SD-WAN service. Share the apps, circuits and symptoms driving the request. We can assess whether policy is the right remedy or whether the underlying issue is capacity, routing or an app dependency that path preferences alone cannot resolve.
Technical references
- MX load balancing and flow preferences — Cisco / Cisco Meraki
- Meraki SD-WAN best-practice design — Cisco / Cisco Meraki
Talk to a specialist
What does your network need next?
Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.